Re: take23.org 500 internal server error (probably OT)
On Mon, Apr 08, 2002 at 11:44:24AM -0700, David Nelson wrote: > Since I'm posting, I'll share one more quick question. > Does anyone know how to license software as GPL but > have it only be able to be used by non-profit > companies? Then you can't use GPL. GPL isn't against people making money of software, but against people depriving the users from their rights to change and distribute the software. OSI's "OpenSource" also isn't against people making money, and one rule that OpenSource licences must abide is indiscrimination against people using the software for money. You'll have to make your own licence, then. Regards, Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: AW: activating multimedia files in cgi-bin
On Tue, Mar 26, 2002 at 02:12:52AM +0100, Daniel Jonda wrote:
> Thanks for your fast answer.
> I don't want to "run" them. I want to display them on my website
Oh, ok.
> My problem is :
> I have an image gallery, which is configured to have the images folders
> under the cgi-bin. And it isn`t possible to see them on my website.
> http://www.flyerfabrik.de/cgi-bin/gallery/gallery.cgi
Your script runs fine, so it doesn't seem to be a perl problem.
I think it might be a configuration problem of the script it self, it may
be looking for images on /var/www/cgi-bin/gallery/something instead of
/usr/local/apache/cgi-bin/gallery or the other way around.
Check the source for any reference to the image directory and change it
as appropriate.
> Where can I change the configuration of perl to show these mm-files on
> my website ?
Well, Apache doesn't serve normal files in the cgi-bin directory, he trys
to run them. But the script you use doesn't refer to the image file, but
it serves the image by itself (or so I think by the little I have seen).
The main problem seems to be that the script doesn't find the files, it
lists no image in any category.
So your problem may be the first I told about, or it may be that the
image directory doesn't have the appropriate permissions for the script to
read it and files within it. Make sure the directory has permissions for
execution and reading by the user that apache runs as (normally nobody or
apache) and permissions for reading by that same user. You could just
find /dir -type d -exec chmod 0755 {} \;
find /dir -type f -exec chmod 0644 {} \;
Regards,
Luciano Rocha
Re: activating multimedia files in cgi-bin
On Tue, Mar 26, 2002 at 01:45:13AM +0100, Daniel Jonda wrote: > Hi. > I have a short question about perl and apache httpd server. > Where can I activate that multimedia files like gifs and jpgs > run under my cgi-bin dir ? GIFs, JPGs, etc, don't *run*. They're not executable code. They can be served, as a simple stream of bytes, with the headers informing of the type. But they aren't run, and you shouldn't put them in you cgi-bin dir. Put them any place else, it doesn't matter as long as the webserver is configured to serve them and has permissions to read them. Regards, Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: Ip Address On Outbound
On Wed, Jan 09, 2002 at 12:27:12AM -0500, John Buwa wrote: > How would i changed outgoing requests > to reflect the invoking users ip and not my systems ip? You can't just change the ip you use to connect to other systems... But you may have some luck in using the Via: and X-Forwarded-For: headers: GET / HTTP/1.0 Via: 1.0 agent.mydmn.net:3128 (Yet Another Agent/0.0.1.0a) X-Forwarded-For: 192.168.0.1 Regards, Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: mixing cgi-bin & mod_perl
On Thu, Dec 20, 2001 at 09:29:26PM -0300, Hans Poo wrote: > I think Randall is just trying to show a cool application of File::Find, and > int the menatime save some CPU and memory cycles. Sorry, I didn't mean to be or sound harsh... My apologies to Randall and everybody on this list Regards, Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: mixing cgi-bin & mod_perl
On Thu, Dec 20, 2001 at 03:16:48PM -0800, Randal L. Schwartz wrote: > Luciano> find . -type f -print0 | xargs -0 perl -spi -e >'s/cgi-bin\/some_scr.pl/mod-perl\/some_scr.pl/g;' > > Ewww. Why two processes? Because I would rather type only a single line to do what a 8 line program will do. What's the point of using perl if you aren't lazy? And then, what's the point of using perl if you can be even lazier? Perl extends the normal Unix Tools, but I won't drop them for perl just because it's the cool language of the moment... (Not that I don't like perl, mind you...) Regards, Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: mixing cgi-bin & mod_perl
I would just use: find . -type f -print0 | xargs -0 perl -spi -e 's/cgi-bin\/some_scr.pl/mod-perl\/some_scr.pl/g;' Regards, Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: Comparison of different caching schemes
On Sun, Dec 16, 2001 at 09:58:09AM +1100, Jeremy Howard wrote: > Can anyone suggest a way (under Linux 2.4, if it's OS dependent) to get a > log of CPU (and also IO preferably) usage by process name over some period > of time? What about BSD Process Accounting (supported in most *nix systems) and sysstat (iostat + sar)? regards, Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: Creating an installable web site.
On Thu, Dec 06, 2001 at 11:01:09AM -0500, Chris Pizzo wrote: > Im looking for a way to create an "installable" version of my wesite to > distribute to customers that don't have web access. The site basically > shows the inventory I have and uses a postgres database and mod perl to show > the product sorted in the manner that the user wants to see it. Can someone > point me in the right direction or am I completely out of luck here? Well, depending on your site you have two options: * if the available options for sorting the product are limited, you're best off by saving the resulting pages (wget, etc) on disk. Make sure the links stored are relative to the current dir and that they don't have no characteres that would make them impossible of being stored in vfat/iso9660+joilet+rr/ext2/etc. * have on cd apache with mod_perl and postgresl in installable form with your data. Or have them already installed on the cd. The problem here is that the source for your entire site will have to be distributed too and available for everybody's eyes to see. You'll also have to have different apaches and postgres for every architecture your clients use, and you should configure them to use different ports than the normal ones and above 1024, so that they don't conflict with already running web servers and rdbms. Also, they will have to be configured without absolute paths, and without any creation or writting to files (the cd medium is read-only, of course). Good luck! :) Regards -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: Apache::Registry HEAD request also return document body
> computing the headers, sure. But there are number of things that you > might want to be in the headers (like date last modified, md5 checksum, > content language, content length, etc) and they need the whole page to > be computed anyway. > > You could argue that sending minimalistic headers to speed up head > requests is possible, but then you're fucking proxies which are there to > save you bandwidth and CPU anyway. Well, you won't save CPU if you need to compute the whole page anyway... And we're talking of dynamic generated pages, most won't be cached, and those that will might as well send an Expires: header, in which case the proxy and browser will cache the data unless the user forces the cache to be skiped. > > When I think more about it may be if PerlSendHeader is On, we can adjust > > the code that parses the script's output in search for headers, to > > return when it finds the 'Content-type' header. > > Maybe there should be an option, like > > ManageHeadRequests [On|Off] And another one, Fake or Skip that would just return standard ones, without even bother to run the script... Then the admin will be able to choose the best for it's cause... > The option might be 'Off' by default for backwards compatibility. Backward compatibility with a bug? I don't even think there should be a Off setting. Sending the content in a HEAD request is, IMHO, a violation of the HTTP protocol. Also, I think the handler shoulnd't just terminate the script, but send the output until the end of the headers (the first blank line), close the connection, but wait till the scripts ends by it self. Killing it could provoke database corruption or similar problems... > That would do the Right Thing whenever a HEAD request is invoked on the > script. I'm quite surprised that this whole issue doesn't seem to have > been raised yet - or maybe I missed something? Well, we all have been missing it. :( Most probably because when the scripts were only CGI they worked fine, and switching to mod_perl required just a few checks, normally done with a regular browser. Regards, Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: mod_perl, pipes, and "No child processes"
> > I was under the assumption that doing something similar to: > > my $returnval = $msg->send(); > > Would give a similar answer. > > I'll give the $? a shot though. I've noticed that from the shell, it > always has a 0, and that would show up as false under perl... Well, on the shell and every other program, an exit status of 0 means success, and a higher one means an error of some kind. Btw: /bin/false ; echo $? ==> 1 /bin/true ; echo $? ==> 0 Also, the SIGCHLD is sent when a child exits, no matter if in error. You should then check the $? for the reason of the exit and for the return code, if exited normally. Regards, Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: IPC::Shareable
Make sure that you're not creating a too big shared memory segment and that you're (apache) running with an uid that is allowed to create shared memory segments. >From the apache configuration file: # . On HPUX you may not be able to use shared memory as nobody, and the #suggested workaround is to create a user www and use that user. # NOTE that some kernels refuse to setgid(Group) or semctl(IPC_SET) # when the value of (unsigned)Group is above 6; hugs Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: POST and GET and getting multiple unsynced requests
Hello I've just created a form like that just for testing and it worked fine, () I got only one POST /cgi-bin/printenv/zbr/?zbr=t and the ENV was correct: REQUEST_METHOD="POST" QUERY_STRING="zbr=t" PATH_INFO="zbr" CONTENT_LENGTH="42" texto=&pass=&hdn=&sub=Submeter I'm not using modperl in this example, just a normal CGI, but I don't think it would make any diference. Anyway, could you check your access_log for both the POST and GET? Also, consider using PATH_INFO instead of QUERY_STRING in a POST. After all, that's one of the purposes of that thing... hugs Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: httpd looking for httpd.conf in wrong path
I don't know why the APACHE_PREFIX isn't being honored for the configuration files (it's been a long time since I last compiled mod_perl). But you can resolve the problem by creating a symbolic link of /usr/local/apache to /home/apache or by specifying the root directory with -d /home/apache or -f /home/apache/conf/httpd-conf. Also, make sure you defined DO_HTTPD=1 (and USE_APACI=1) and make install only in the mod_perl directory. hugs Luciano Rocha On Mon, Oct 08, 2001 at 12:41:33PM -0400, Henigan, Timothy wrote: > I'm attempting to build/install Apache and mod_perl from source (running as > root). > > I can build Apache stand-alone with no trouble using the following commands: > - cd /my/src/dir/apache_1.3.20 > - ./configure --prefix=/home/apache > - make && make test && make install > > With the above config, I can start httpd and view pages normally. > > The trouble begins when I try to compile Apache with mod_perl. I try the > following commands: > - cd ../mod_perl-1.26 > - perl Makefile.PL APACHE_PREFIX=/home/apache/ > - make && make test && make install > - cd ../apache_1.3.20 > - make install > > The build completes successfully (I know this becuase there are no error > messages, the tests complete successfully, and the timestamps on the > executable file in the /home/apache/bin directory have changed). When "make > install" finishes, it tells me to try starting apache with > /home/apache/bin/apachectl start. However, when I try it I get the > following message: > "fopen: No such file or directory" > "httpd: could not open document config file > /usr/local/apache/conf/httpd.conf" > "/home/apache/bin/apachectl start: httpd could not be started" > > Any ideas why httpd is looking for httpd.conf in /usr/local/apache/conf when > I specifically built it using APACHE_PREFIX=/home/apache/? I didn't see any > similar problems while looking through the mail archives on Geocrawler. Any > assistance would be appreciated. > > == Version info = > OS: Linux 2.2.14, Intel > Perl: v5.005_03 built for i386-linux > mod_perl: v1.26 > Apache: v1.3.20 > = > > Thanks, > Tim > > -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: FW: Apache_1.3.19/mod_perl-1.24_01/perl5.6.1 on Solaris 2.6/Sun O S 5.6
> $ perl Makefile.PL && make && make test && sudo make install ># if each step is successful, it succeeds automagically, ># otherwise it fails. also more importantly, it wraps ># 'make install' in a sudo call, so the work gets logged ># and you only get to do that one command as root. if ># your system supports it, sudo is often safer than su. sudo for a make is no safer than su, after all, any vaild shell command (including creation and compilation of files) can be put in a makefile. Also, people often say that it's not safe to untar and compile programs as root. Well, unless they are *really* paranoic and check *every* file in the tar, it just doesn't make sense (to me) to don't trust the tar but trust the executable generated by the files in it... It would make more sense to untar, compile, and execute the program under the same uid, and just give it capabilities to bind to lower ports. hugs Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
