Re: A::Registry vs. mod_perl handler philosophy
Hi there, On Fri, 20 Jun 2003, Peter B. Ensch wrote: > I'm beginning to develop apps under mod_perl. I'm > curious as to how people decide between coding for > Apache::Registry vs. mod_perl handlers. Use Apache::Registry only if you have to in order to get legacy CGI scripts working. > It's been suggested to me that content generating > apps should be done under A::R, whereas logging, > authentication Etc. should be implemented as > mod_perl handlers. All new code should use handlers. 73, Ged.
Re: A::Registry vs. mod_perl handler philosophy
Hi Ken, On Fri, 20 Jun 2003, Ken Y. Clark wrote: > On Fri, 20 Jun 2003, Ged Haywood wrote: > > > All new code should use handlers. > > I wouldn't be so strict about such definitions. I didn't say "must". :) > Or am I missing something? You will get better performance from handlers and you can do more with them. I wouldn't deliberately build unnecessary limitations into a new system if I had any choice in the matter. > Whatever works for you, I say. But mayhap I'm too permissive. Well I'm probably not permissive enough... :) 73, Ged.
Re: How big are your Apache kids?
Hi there, On Mon, 30 Jun 2003, Nigel Hamilton wrote: > I recently managed to get the RAM consumption of my server under control. :) > Does anyone have a really lean and mean mod_perl, Apache configuration On the face of it 20Mb looks a bit heavy for mod_perl processes. But it depends so much on what you're doing with them that it really makes no sense to generalize, except for things you already know like not loading modules you don't need. You've probably already checked the tuning section of the Guide for tips, and trawled through the archives for discussions on the subject (of which there have been many:). If you can consider a proxy setup it may be that you can trade off complexity in your configuration against your RAM consumption, but first I'd be asking is it necessary? Only you can answer that one, and in any case RAM is a lot cheaper than software development. 73, Ged.
Re: segmentation fault under mod_perl+XML::XPath
Hi there,
Haven't seen any replies, so I thought you'd like to hear from someone. :)
On Wed, 2 Jul 2003, Ruslan U. Zakirov wrote:
> I've tried to use XML::XPath under mod_perl 1.27 and Apache 1.3.27, but
> got segmentation fault
It's not uncommon to see XML and segfaults in the same post. :(
Have you searched the archives?
> Under command line and CGI it's working fine and all tests during installation of
> XML::XPath were fine, but the same code crush apache+mod_perl.
[snip]
> Apache - with so, unique_id, no expat
> mod_perl with everything as DSO
Whenever I see segfaults in a DSO Apache I'd say try static linking if
you don't know what else to try. :)
> Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Did you compile this Perl yourself? The standard advice is to compile
mod_perl and Perl with the same compiler.
> usemymalloc=n, bincompat5005=undef
Highly unlikely, but maybe a malloc problem?
> ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers=''
You should be OK with that compiler, is that what you're using yourself?
Hope you're not using gcc 3.x with that Perl...
> Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
> cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'
Never heard of Perl (as opposed to mod_perl) dynamic linking causing a
problem, so don't worry about that. (Until later.:)
> Backtrace:
> Program received signal SIGSEGV, Segmentation fault.
> 0x80711c5 in poolCopyString ()
> (gdb) bt
> #0 0x80711c5 in poolCopyString ()
This is the code in xmlparse.c from my 1.3.27 source tree:
--
static const XML_Char *poolCopyString(STRING_POOL *pool, const XML_Char *s)
{
do {
if (!poolAppendChar(pool, *s))
return 0;
} while (*s++);
s = pool->start;
poolFinish(pool);
return s;
}
--
Assuming you're using the same thing...
As far as I can see this must mean that your pointer s is invalid, and
either the dereference *s causes a memory bound error or else the s++
increment tries to increment it off the end of the stack or something.
There's nothing else in that function that would be likely to cause the
fault, if pool were invalid I'd expect it to happen in poolAppendChar().
I have no idea why these might be but it's a bit serious of course.
You're into XS territory, the sort of thing that can easily be thrown
by struct alignment problems such as you might get on the less well
exercised configurations - which probably includes FreeBSD - and an
unsuitable combination of compilers/dso/libraries/...
You shouldn't have to be delving this deeply into these packages, but
if a static link or a compiler change doesn't fix it and you don't
mind cranking gdb a bit further you could find out what that pointer
is pointing to and if it's a valid XML_Char pointer.
Hope this gets you started in the right direction, but please don't
take it as authoritative as I've never used FreeBSD nor XML::XPath.
73,
Ged.
Re: segmentation fault under mod_perl+XML::XPath
Hello again, On Thu, 3 Jul 2003, Ged Haywood wrote: > There's nothing else in that function that would be likely to cause the > fault, if pool were invalid I'd expect it to happen in poolAppendChar(). Of course unless poolAppendChar() turns out to be a function defined by a macro, which it does, so forget that last bit. Could be pool too. :( 73, Ged.
Re: If (!$one_thing) {$other;}
Hi there, On Wed, 2 Jul 2003, Dennis Stout wrote: > This also means I can write a small subroutine to eval a form that's been > posted, and given the authentication passes, add code to the thing while it's > running, AND save the code to the DB so it'll be around for reboots. > > Wouldn't that just be awesome? Can I urge a little caution? 73, Ged.
Re: Is statically-compiled mod_perl better?
Hi there, On Thu, 3 Jul 2003, ColinB wrote: > What is the preferred method of compiling mod_perl - static or dynamic? Static. (But that's just my opinion after years of experience and watching people running into trouble with DSO mod_perl on this List. :) > I have read that *static* linking is likely to load and execute faster, > but may be wasteful of resources if there are multiple proceses each > with its own copy of the common code. In normal circumstances the speed of loading is unlikely to be an issue. If you're using mod_perl 1.x on Linux/Unix/whatever then unless you're using 'httpd -X' or a very strange configuration there will be multiple processes. A recent post by Randal seemed to indicate the memory saved by using a DSO mod_perl wasn't as large as one might think - check the archives. > It therefore seems likely that a statically compiled mod_perl would be > faster, provided that a large number of httpd's are not being run at > the same time. > > Is this correct? There are many factors to consider, but the speed difference between static and DSO isn't often talked about here so you can draw your own conclusions. Check out the tuning section of the Guide, the archives. > It seems that at present it is not possible to build mod_perl 2.0 > statically. It can only be built dynamically and loaded using > LoadModule in httpd.conf. This seems strange if the preferred method of > building is static. True. That's because it's still in development. Check the archives... 73, Ged.
Re: Apache config problem .. please help
Hi there, On Thu, 3 Jul 2003, Dennis Stout wrote: > > I made a simple mod_perl change to the config and when restarting Apache > > I got this error: > > (98)Address already in use: make_sock: could not bind to address > > 0.0.0.0:2250 > > no listening sockets available, shutting down > > /usr/local/apache/bin/apachectl: line 87: 16512 Segmentation fault > > $HTTPD $ARGV > > > > I then backed out the change and retried, got the same error. > > > killall httpd > > then try it again :) In other words there's an Apache still running when you're trying to start a second one which wants to listen on the same socket that the first Apache is already listening on. That isn't permitted. But you shouldn't be getting segmentation faults in that case so something else is probably wrong too. Did you build from source? Did you follow the instructions in the Guide? Linux? 1.3.27/1.27? DSO? Maybe you can post the information requested in the docs? 73, Ged.
Re: Apache config problem .. please help
Hi there, On Thu, 3 Jul 2003, Ranga Nathan wrote: > >In other words there's an Apache still running > > The 'top' output is : > [snip] > How can I get a list of ports being used so I can kill the processes? As I said, there may be more wrong than just what's obvious. It looks like the obvious explanation that another Apache is running is not the right one. At the risk of asking questions I wouldn't have to ask if you'd posted the information I asked for, why port 2205? That's not what I'd expect to see, but without more information I'm groping about in the dark. What's trying to use that port? MySQL perhaps? Why not stop it first, or change the port that Apache is trying to use, or the port that whatever apachectl is trying to start is trying to use, or... > As far as I can tell httpd is not running. The IP is 208.179.25.28 c2h5oh:~$ >>> ping 208.179.25.28 PING 208.179.25.28 (208.179.25.28): 56 data bytes 64 bytes from 208.179.25.28: icmp_seq=0 ttl=236 time=389.6 ms --- 208.179.25.28 ping statistics --- 2 packets transmitted, 1 packets received, 50% packet loss round-trip min/avg/max = 389.6/389.6/389.6 ms c2h5oh:~$ >>> telnet 208.179.25.28 80 Trying 208.179.25.28... telnet: Unable to connect to remote host: Connection refused Looks like you're right. Have you read the stuff I mentioned? > I dont see any apparent signs of hacking either. Don't go tilting at windmills just yet. :) 73, Ged.
Re: Flushing
Hello there, On Sun, 6 Jul 2003, Oskar wrote: > I have script that is doing some time consuming operations This has been discussed many times on the List, check the archives. 73, Ged.
Re: Newbie question about mod_perl capabilities
Hi there, On 7 Jul 2003, Walter H. van Holst wrote: > I am new to mod_perl and am trying to figure out whether it suits my > needs or not. Can I use it to intercept any http CONNECT requests Apache > receives and answer those? The concept of a connection is at the transport level, way below HTTP. The HTTP protocol simply assumes a reliable transport (you don't even need an Internet:) and deals with exchanges of messages. See RFC1945. Read the Eagle Book (*), for more information about where mod_perl fits into the scheme of things. Chapter 3 has a good explanation of the Apache request cycle. 73, Ged. (*) "Writing Apache Modules with Perl and C", ISBN 1-56592-567-X
Re: Newbie question about mod_perl capabilities
Hi there, On 8 Jul 2003, Walter H. van Holst wrote: > On Tue, 2003-07-08 at 10:14, Matt Sergeant wrote: > > > Sorry Ged, Walter is talking about CONNECT which is a proxy request. Argh. :) > Well, thanks to a someone on IRC I have found a code snippet that might > do exactly that. So it appears that mod_perl can do this. And yes, it is > intended for exactly the kind of CONNECT requests you describe. :) 73, Ged.
Re: ProxyPass not getting type of dynamic images?
Hi there, On Mon, 7 Jul 2003, Kirk Bowe wrote: > ProxyPass / http://other.server.with.specified.port.com:8082/ > ProxyPassReverse / http://other.server.with.specified.port.com:8082/ > ProxyReceiveBufferSize 16384 > > Most of it works fine but I appear to be losing content types. Is it something mod_proxy is doing? If you look in apache_1.3.27/src/modules/proxy/proxy_util.c at the function ap_proxy_read_headers() you may find something. You could add some logging. 73, Ged.
Re: compile issue: conflicting types for getline
Hi there, On Thu, 10 Jul 2003, Stewart, Eric wrote: > RedHat Linux 9.0, with Apache 1.3.27, PHP 4.3.2, and mod_perl 1.28, > I'm getting a compile error. [snip] I'm thinking it's more along > the lines of a compiler (IOW, RedHat's use of gcc 3.2.2) issue. It *might* be the compiler, but I doubt it. I think you might be running into RH9-related problems, I've had more than enough of them and I don't even use it on most of my mod_perl boxes... After I had troubles with 3.2.2 (nothing to do with mod_perl at all) I upgraded to 3.2.3 which solved the problems. I never tried to compile mod_perl with 3.2.2 but I've compiled mod_perl pre-releases (not 1.28 as released) using gcc 3.2.3 no trouble at all. This was on a system running Linux 2.5.69, gcc 3.2.3, glibc 2.3.1, perl 5.8.0, Apache 1.3.27 but no PHP. > I'd rather like to avoid "downgrading" either my OS or compiler. Don't do that. You might want to try upgrading gcc to 3.2.3, cleaning up your installation and recompiling everything, including Perl. If it works that will be useful information, please let me know. 73, Ged.
RE: Dynamically banning hosts
Hi there, On Sat, 12 Jul 2003, Jesse Erlbaum wrote: > > Is it possible to dynamically ban IP addresses using mod_perl. > > Yes, it is possible with mod_perl. You can create a PerlAccessHandler In addition to Jesses's comments, I'd suggest that you might want to look at firewalling techniques to eliminate the requests before they ever reach your server. If your mod_perl server is doing the access denial, then there has already been a lot of processor activity wasted on the attack. Something like IPCop is freely available, easy to configure (if you avoid pitfalls with multiple Ethernet cards being shuffled:) and very effective. But there is no easy solution to a determined DOS attack on an open IP. 73, Ged.
Re: must I use mod-perl
Hello there, On Sun, 13 Jul 2003, Bulba007 wrote: > When must I to use mod_perl? It is necessary? No, it's not necessary. You may want to use mod_perl if you want to use Perl scripting with the Apache Web server. At the expense of some complexity, especially in the installation and configuration of your server, it can provide better performance and more control over the server than is possible with CGI scripting. There is a great deal of documentation available. See the mod_perl home page for more information: http://perl.apache.org Because mod_perl version 2 and the documentation for it are still works in progress, assuming that you are using Linux, at the moment I would advise you to consider only mod_perl 1.27 or 1.28 with Apache 1.3.27 if possible. 73, Ged.
Re: must I use mod-perl
Hi there, On Sun, 13 Jul 2003, Dennis Stout wrote: > I downloaded source for Apache, PHP, and mod_perl and compiled it all and had > it working in about the time it took to download it + compile time + about 5 > minutes. > > There is no config to mod_perl really. Either it's there or it isn't. True, it's very quick to install once you get the hang of it. But let's not _over_simplify: you _do_ have to tell Apache what URLs need to be handled by mod_perl or it will just take up RAM and not do anything... :) Once you have an Apache with mod_perl either (I would say preferably) compiled in, or (I would say as a last resort) available as a loadable module, all it takes to get mod_perl to do things for you is a simple configuration directive or two in httpd.conf or your favourite Apache configuration file. Plus your Perl scripts of course. It's all in the documentation. 73, Ged.
Re: Virtual Host Logging Perl Script
Hi there, On Tue, 15 Jul 2003, Jez Hancock wrote: > Does anyone how one could log errorlog entries in a similar manner to > the script above - ie pipe the errorlog to a script which appends one > copy of the error entry to a main error logfile and another copy to the > virtual host's error logfile? It's possible, but I don't think you really want to do it. You would be asking the server to do more than is necessary while handling each request (you probably already are:). Would it not be better for example to rotate your logs frequently, and to process them afterwards, off-line? You would then have a choice of doing things with the various log file analysis tools too. If you are a little bit creative in what you log, it can be simple to extract the information you need for each vhost from one file. Have you considered using something other than flat files for logging? 73, Ged.
Re: perl5.8
Hi there, On Wed, 16 Jul 2003, Grant Cooper wrote: > I was upgrading to perl5.8 using freeBSD > > To install via ports, I typed this : cd /usr/ports/lang/perl5.8 > make install clean > rehash > use.perl port > > What does rehash do? > And what does use.perl port do? This List is for questions related to mod_perl, not for general Perl questions. Please take your question to a more appropriate place, you will find one for example at http://lists.perl.org 73, Ged.
Re: Virtual Host Logging Perl Script
Hi Jez, On Wed, 16 Jul 2003, Jez Hancock wrote: > [snip] We started looking at mod_log_sql: [snip] > but had trouble getting it to work on FreeBSD unfortunately. I'd have thought something a bit lighter might do for this. > Right now it seems a bit silly having a separate ErrorLog line in each > of the apache virtual host stubs, but as far as I am aware there isn't > an easier way is there? You could look at mod_macro. 73, Ged.
Re: How to share subroutine
Hi there, On Wed, 16 Jul 2003, Matthew Wu wrote: >I put all my subroutine in file.pm, what I need to do such that it > can be used by my program? I don't what location I need to put it in and > what kind of configuration I need to modify. I am running Redhat 6.3. At the risk of repetition... :) This is a mailing List specifically for mod_perl issues. Are you using mod_perl? For general Perl questions, if you are using RH6.2 you can start by reading some of the enormous quantities of Perl documentation that should already be on your computer. There are also a few good books, I guess your library should be able to get them for you but you really need to buy a few of them if you are going to work with mod_perl. You will see some suggestions on the mod_perl Web site, perl.apache.org. Please don't ask general Perl questions here. On Linux, start with perldoc perldoc and perldoc perlfaq and for your particular question perldoc -f use but you really need to do that reading. 73, Ged.
Re: Help me understand mod_perl and Environment settings
Hi there, On Thu, 17 Jul 2003, Bernhard Donaubauer wrote: > I just startet learning mod_perl and apache. I use the current version of > mod_perl 1 and apache 1.3. Perl itself has version 6.5.1. Can you be a little more careful with your version numbers in future? > but my testapplication does sometimes see my environment settings and > sometimes not. It changes if I press the refresh button of the browser. Please see the mod_perl Guide at http://perl.apache.org There are references to the symptoms you see at http://perl.apache.org/docs/1.0/guide/debug.html#Sometimes_My_Script_Works__Sometimes_It_Does_Not 73, Ged.
Re: templating system opinions (axkit?) [OT]
Hi Matt, On Wed, 23 Jul 2003, Matt Sergeant wrote: > The main reason I like AxKit is it prevents me from screwing up [snip] > I just write straight perl code. I barely notice that I'm using XML. Can you give us in a couple of sentences your take on the state of XML in general and AxKit in particular? To me somehow things don't seem to be going in quite the same direction any more... 73, Ged.
Re: Advice sought for learning mod_perl (2 or 1)
Hello there, On Thu, 24 Jul 2003, Robert Lee wrote: > I am new to Apache/mod_perl and everything else. We're all still learning... > I bought a fairly good book on Apache/mysql/mod_perl. There are others, see the mod_perl web site: http://perl.apache.org > Unfortunately, it is based on the Apache 1 server and mod_perl1. That's not too bad, there are lots of similarities. > Q1: Is there a similar module to Apache::Request? Depends what you want to do, but not really. Care to try porting it? > Q2: Any real benefits to working on the latest and greatest? Or > should I go to the older versions? Depends what you want to do... :) If you are interested in learning about it and you don't have a project that you have to put on a live Webserver in a couple of months' time, I'd say stay with mp2 and watch it evolve. Maybe get involved in some of the development. I wouldn't consider mp2 for production use yet because of that evolution process if for no other reason, but if you don't have the commercial pressures then it doesn't matter so much and there's no point your spending a lot of time learning about something if it's going to be more-or-less history by the time you need to use it seriously. > I realize that for Q2, I may want to simply go with the more "stable" > versions of the Apache server and mod_perl as I am just learning For your education it's probably worth your while learning how to get the latest CVS versions, at least of mod_perl. The latest versions of Apache2 and mod_perl2 will be quite stable enough for you to use to learn about them. Now your browsers on the other hand... 73, Ged.
Re: DProf on Mac OS X
Hi there, On Fri, 25 Jul 2003, John Siracusa wrote: > Has anyone gotten this to work on OS X? > [snip] > I've used this profiling technique on other Unix-like OSes, so I think > I'm doing it right. I'm sure you're doing it right. > But on OS X, I get a tiny tmon.out file that never grows after the > initial server startup. I don't see any error messages or log lines. > > When I try to use Apache::DProf, I get a bus error on any request: > > [Fri Jul 25 18:52:48 2003] [notice] child pid 3840 exit signal Bus > error (10) I've never tried it on OS X, but I had exactly the same problem when Perl 5.6 first came out. I didn't investigate further since the Perl development team were rather unhelpful about it. And about quite a lot of other things. With hindsight that might be understandable, they must have been taking a lot of flack about that time. The problem persisted until I upgraded to 5.7.2. Any way you can try it on a different OS, or even try a different Perl? And before Stas jumps on me *again* for saying that I have no evidence that 5.8.0 is the culprit in this case. It just smells fishy to me. :) 73, Ged.
Re: MP1, Redhat 7.3: Transmission size limited after some time
Hi there, On Thu, 3 Jul 2003, Gerd Knops wrote: > I got a really odd problem: I have identical mod_perl/apache installs > on FreeBSD 3.x systems and a few Redhat 7.3 systems. > > After some time running OK, the Redhat systems start acting up. > Transmissions are suddenly cut of after somewhere between 90 and 150 kb. [snip] > Restarting the web server fixes it, but a few hours/days later the > problem resurfaces. This makes me think perhaps you have MaxRequestsPerChild set to zero in your configuration? 73, Ged.
Re: Skipped Tests (was: handler help)
Hi there, On Fri, 1 Aug 2003, Tofu Optimist wrote: > sorry to break the thread in two. :( > Why did it skip 6 tests? How did you do the perl Makefile.PL step? 73, Ged.
Re: Skipped Tests (was: handler help)
Hello again, On Fri, 1 Aug 2003, Tofu Optimist wrote: > --- Ged Haywood <[EMAIL PROTECTED]> wrote: > > > How did you do the > > > > perl Makefile.PL > > > > step? > > % cd /usr/src > % tar xzvf apache_1.3.xx.tar.gz > % tar xzvf mod_perl-1.xx.tar.gz > % cd mod_perl-1.xx > % perl Makefile.PL APACHE_SRC=../apache_1.3.xx/src DO_HTTPD=1 USE_APACI=1 > EVERYTHING=1 So your non-root user has write permission in /usr/src? H... > % make && make test && make install This can't work, you need to be root to make install. 73, Ged. PS: Did you build your own Perl? Have you cleaned up any old Apaches and mod_perls? (RH9 comes with Apache2, you probably want to get rid of that:).
Re: Skipped Tests (was: handler help)
Hi there, On Fri, 1 Aug 2003, Tofu Optimist wrote: > Rather than /usr/src, I put in /home/aprk That's fine. But in future, tell us what you did, not some fiction... :) > Yes, you are correct. make && make test as non-root, > then install as root. (Odd, isn't it, the docs at > http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl_Installation > don't make this explicit?) Yes, I always think that, but many of the Open Source packages neglect to mention this point every time it might be mentioned. I think authors expect it to be either very obvious or else perhaps unnecessary - some operating systems don't have a Unix-like permisisons system. > > Did you build your own Perl? > > Yes, 5.8.0 Good. You might want to try 5.8.1 soon, but I don't think that's a problem here. > > Have you cleaned up any old Apaches and mod_perls? > > No. There are probably hordes of perls and hpptds and mod_perls > running amok on the box throwing wild parties; I don't know. Argh. The Apache2/modperl2 that comes with RH9 is junk. Get rid of it all. Use 'ps' to see what processes you have running and stop any httpd processes that you don't think you started. RH will start an Apache when it boots if you let it, I wish they wouldn't do that. Read 'man chkconfig'. Go into /etc/rc.d and look at the startup scripts. Use chkconfig to prevent Apache being started at boot so you can start it manually when you've built it. When you're happy that it's all as you wnt it, you might want to use chkconfig to set it up to start at boot again. > I think my next step should be to start over fresh. > Again. :) > [1] How do I find *everything* on the box related to > perl / apache / mod_perl, both 1 and 2, both the RH > install and from my own ftp / tar / make fumblings? > [2] How do I uninstall everything from [1], so I can > start fresh? Well RH should let you uninstall packages with rpm, but I don't use rpm and I tend to avoid RedHat so I don't know exactly how you'd do it. My preference would be to look in /usr/local/ and /var/lib to see if there are any apache things such as /usr/local/apache, and if so go in there as root and rm -rf the entire apache directory. That will perhaps throw away config files etc. you've been working on, you might want to make backups. When you've done that you might want to use slocate to build a database of filenames on your filesystem, then use it to search for any httpd or apachectl files that escaped. If so there'll probably be truckloads of files in there with them. Nukem. The source trees in your home directory don't matter. Nuke them too. You won't need to do anything about Perl on your system if you really did compile it from source yourself. > [3] I'd prefer to use modperl 2 and apache 2, as that is what my ISP > is using. And I think I'd prefer to use RH rpm to install them, as > again, that is what my ISP did. (Want my dev box to match the > outside box as much as possible). This newsgroup keeps mentioning > "build from sources," will I be going astray trying the rpm route? I hate RPMs. For Apache2/modperl2 you would be better off going to the CVS sources unless you can get hold of a very recent RPM, things are changing really fast in the mod_perl version 2 codebase. True, it could be important for your dev box to match your prod box, but when you figure out what's going on it will probably matter less - until you start doing really fancy stuff, when it will start to matter again. > [4] Is a full uninstall enough, or should I reinstall RH itself? No, don't reinstall the entire OS. Get used to what your system feels like and eventually you'll know what to leave alone and what to change. > mysteries to a newcomer. FWIW you sound like you're picking it up quickly. 73, Ged.
Re: Skipped Tests (was: handler help)
Hi there, On Fri, 1 Aug 2003, Tofu Optimist wrote: > Exactly HOW do I change the locale? http://twiki.org/cgi-bin/view/Codev/UsingPerl58OnRedHat8 about half a dozen messages down. See also http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=87682 > make && make install > > again, yes? Better start with % cd /home/directory/src (or whatever your home directory is) and then % rm -rf apache_1.3.28 % rm -rf mod_perl-1.28 % tar xzvf apache_1.3.28.tgz % tar xzvf mod_perl-1.28 % perl Makefile.PL and I would suggest that in future instead of % make && make install that you do these steps as separate commands % make % make test % su Password: # make install # exit % which will give you the opportunity to abandon ship at any point before the install. Finally if you do % script before you start the 'perl Makefile.PL' step then everything you see on the screen will be logged to a file so you can peruse it later if you feel the need. It will help you to become familiar with build the process. It looks a lot more complicated than it is. Really. % man script for more details. I'd use 'less -S' to look at the scriptfile. In fact I always alias 'less -S' to 'li' in my login scripts... :) 73, Ged.
Re: Skipped Tests (was: handler help)
Hello again, On Fri, 1 Aug 2003, Tofu Optimist wrote: > To recap: I freshly installed RedHat 9 on a box, > then used RPM to remove modules involving httpd. > (See notes below). Then I built perl 5.8.0 from > source, first doing a "export LANG=C" why not LANG=en_US ? > Then as root I used CPAN to install > Bundle::WWW, LWP, and HTML::Parser. > Had some troubles, used the force option, Oooohhh. Don't do that... We're getting out of my area of experience here, I don't use mod_perl2, but I hear there are recent changes to CGI.pm. Did you install the latest CGI.pm? You should. 73, Ged.
Re: mod perl issues/ cpan won't make properly
Hello there, On Mon, 4 Aug 2003, Hodge, Jeff F (ECIII) wrote: > Here's how I installed mod_perl/apache: > > cd apache_1.3.28 > ./configure --enable-module=so > cd mod_perl_1.28 I don't like the look of that. Please send *exactly* what you did. Have you got the mod_perl directory inside the apache directory? Your directories should be somethign like this: /dloads/apache_mod_perl/apache_1.3.28/ /dloads/apache_mod_perl/mod_perl-1.28/ > perl Makefile.PL APACHE_SRC= /dloads/apache_mod_perl/apache_1.3.28/src > DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACHE_PREFIX=/usr/local/httpd_perl > make && make test && make install What is the user that's running this? Don't do the first three steps as root, only do the 'make install' as root: % perl Makefile.PL APACHE_SRC= /dloads/apache_mod_perl/apache_1.3.28/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACHE_PREFIX=/usr/local/httpd_perl % make % make test % su Password: # make install # exit % That backslash on the first line is important. If you've done everything as root and if you have the mod_perl directory inside the apache one, then it's best to remove the directories and start again. > So using Cpan I tried to install the Bundle::Apache...which bombs out Don't worry about it for now, you don't need it for your mod_perl Apache. > ALSO here is perl -V > > Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: > [snip] > ccversion='', gccversion='2.95.3 20010315 (SuSE)', > [snip] > gnulibc_version='2.2.5' > [snip] > Characteristics of this binary (from libperl): > Compile-time options: USE_LARGE_FILES > Built under linux > Compiled at Aug 2 2003 13:09:23 > [snip] Looks like you compiled this Perl yourself using gcc 2.95.3 a couple of days ago, is that right? Did the Perl tests all pass OK? 73, Ged.
Re: [mp2] ModPerl::Test::read_post destructive?
Hi there, On Sun, 10 Aug 2003, Michael Maciag wrote: > Is the read_post in ModPerl::Test destructive in some way? If so, could > someone point me in the right direction I might take to modify it to be > non-destructive? I think you'll find that reading POST data has always been destructive. If you want to read it more than once you have to save it somewhere. Check the archives for more information. 73, Ged.
Re: Threading issue in 5.6 and 5.8
Hi there, On Thu, 7 Aug 2003, Mustafa Tan wrote: > script's name is A, and I execute the same script 20 > times subsequently there is no problem. But if I > execute B after A, and then execute A again, then I > have a problem and the problem is that there is a > socket error. This happens only on Windows machines. I > learnt that this is a common problem and that it is > because of threads. Making number of threads on apache > 1 solves the problem Sorry I know prcatically nothing about running Apache on Windows. Seems strange to me that anyone would do it... :) > Ok, here is the real question. Should I move to 5.8 > and if I should, what are the general issues that I > have to be careful about. One more thing is that, can > I run perl 5.8 with mod_perl 1.0? Is that possible, or > do I also have to move to mod_perl 2 and apache 2? You can run 5.8.x with mod_perl 1.x, the issue you will most likely meet involves character encoding. Check the archives of this List for more information. Look for "UTF-8" and/or "locale". Version 2 of Apache/mod_perl might enable you to address some of your threading problems on Windows, hopefully others will be able to tell you more than I can. 73, Ged.
RE: mod perl issues/ cpan won't make properly
Hello again, On Tue, 5 Aug 2003, Hodge, Jeff F (ECIII) wrote: > My directories look exactly like that. :) > First I went to the apache directory and ran the configure to enable DSO. Do you have any particular reason for using DSO? IMHO it's usually more trouble than it's worth. I always build static if I can. Also I like a file 'makepl_arg.mod_perl' in the mod_perl source directory to supply the configuration. Sample attached. Then you just have to say perl Makefile.PL in the mod_perl directory and everything is set up for you. Then you can repeat it whenever you like: just remove the source directories, extract the sources fresh, copy the makepl_args.mod_perl file, and issue the perl Makefile.PL command again. > How does root user affect things? People have had problems with permissions getting a little screwy, and it's safest to do builds as non-root in case there's an accident. > I need Apache::request and DBD::mysql rsn Get Apache and mod_perl running first. There shouldn't be any problemn with the rest. > I repeated my build/install steps interesting. its failing a > test; output: (I'm fairly sure this wasn't the result the other day): > Failed 1 test script out of 667, 99.85% okay. It could be worth following the instructions to try to pin that down. > btw - what is 73? Morse code shorthand. Long time ago. It means "best wishes." 73, Ged.
Re: Odd Reload Behavior
Hi there, On Fri, 15 Aug 2003, Cory 'G' Watson wrote: > It looks as though this works during the first 'load' that Apache does, > which I'm assuming is the phase that checks for errors. The second > phase seems to cause my global hash to get undef'ed, even though the > loadPages() method works properly. I'm not entirely convinced of the explanation, but have you tried testing the value of $Apache::Server::ReStarting in the code that fills the hash? It's in the Guide. Your message was a bit cavalier about what's a hash and what's a hashref, are you sure you aren't just missing a dereference somewhere? Have you got 'use strict' and warnings on? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
Hello again,
On Fri, 15 Aug 2003, Cory 'G' Watson wrote:
> PerlVar app blah
>
> App->loadApp("blah", "/usr/local/blah/lib");
>
> [snip]
> Ignore syntax errors and lack of declarations, as I just threw that
> together from memory
The guesswork would be a lot easier if it didn't involve so much guesswork. :)
Have you read
http://perl.apache.org/docs/1.0/guide/config.html#PerlSetVar_and_PerlAddVar
and
http://perl.apache.org/docs/1.0/guide/config.html#Apache_Configuration_in_Perl
?
73,
Ged.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
Hi there, On Sat, 16 Aug 2003, Cory 'G' Watson wrote: > started flipping switches and localized it to PerlFreshRestart being on. Have you read http://perl.apache.org/docs/1.0/guide/troubleshooting.html#Evil_things_might_happen_when_using_PerlFreshRestart > When I turn it off, the eval() happens _before_ my startup.pl use() > and subsequence call to App->load(). So is it working now? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Installation/test problems - mod_perl-1.27
Hi there, On Tue, 26 Aug 2003, Patrick West wrote: > I've installed apache_1.3.27 and mod_perl-1.27. When I go to run the > tests in mod_perl-1.27/t (just running the first one), first it > complains that it couldn't start the server. But the server is > actually running. Are you sure you have the right server running? Did you check that there were no httpd processes running before you started the test? You might want to check which ports 80, 8080, 8259... are being used as this might lead you to the answer. Have you checked the error_log files for the server(s)? Pay particular attention to dates and times, both when you give the commands to start servers, run tests etc. and also when you look in the log files. This may help you to understand what happened and when. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Installation problem
Hello there, On Mon, 25 Aug 2003, Alan Rafagudinov wrote: > I've downloaded apache_1.3.28.tar.gz & mod_perl-1.28.tar.gz > and unarchive it to /usr/src/httpd_perl for back-end server > > then when I make > > perl Makefile.PL APACHE_SRC=../apache_1.3.28/src/ DO_HTTPD=1 USE_APACI=1 > EVERYTHING=1 APACI_ARGS='- > -prefix=/usr/local/httpd_perl' > > [snip] > modules/psections...ok > modules/request.Use of uninitialized value in numeric eq (==) at > modules/request.t line 147. > Use of uninitialized value in concatenation (.) at modules/request.t line 147. > [snip] Can you tell us a bit more about your system? The documentation gives you information about what information you need to give... What compiler was used to build your Perl, and was it the same compiler that you used to build mod_perl and Apache? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Installation/test problems - mod_perl-1.27
Hi there On Tue, 26 Aug 2003, Patrick West wrote: > Apparently $net::httpserver is set incorrectly, > [snip] > So ... where is $net::httpserver being set? t/net/config.pl 73, Ged. PS: Please keep it on the list... :) -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and staticfrontend
Hi there, On Wed, 27 Aug 2003, Charlie Garrison wrote: > Do you also write the apache module for the frontend server? I'm very > competent at perl, but not competent enough to write an apache module. It's not so hard. There's a skeleton module in the Apache sources for you to start with, take a look at it. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1.0] Installation problem
Hi there, On Wed, 27 Aug 2003, Alan Rafagudinov wrote: > I've downloaded apache_1.3.28.tar.gz & mod_perl-1.28.tar.gz > [snip] > tests failed: > [snip] > Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: > Platform: > osname=linux, osvers=2.2.16-22smp, archname=i386-linux Upgrade Perl (and your operating system?:). that might help, and version 5.6.0 of Perl is a disaster just waiting to happen anyway. You should be OK with 5.6.1 but I would think 5.8.1 might be better. > [snip] > Compiler: > cc='gcc', optimize='-O2 -march=i386 -mcpu=i686', gccversion=2.96 2731 > (ASPLinux 7.0 2.96-79) Please post the output of gcc -v on your system. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Re[2]: [mp1.0] Installation problem
Hello again, On Wed, 27 Aug 2003, Alan Rafagudinov wrote: > GH> Please post the output of > GH> gcc -v > > Reading specs from /usr/lib/gcc-lib/i386-asplinux-linux/2.96/specs > gcc version 2.96 2731 (ASPLinux 7.1 2.96-85.asp) Make sure to use that compiler to build Perl, mod_perl and Apache. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
=?x-unknown?q?Re=3A_=5Bmp1=5D_Can=B4t_compile_mp1=2E28_-_work?==?x-unknown?q?ed_with_1=2E27?=
Hi there, On Wed, 27 Aug 2003, Bernd Kuhls wrote: > I am trying to compile mod_perl-1.28 without luck. > SUSE 5.3 (I know it´s old) > gcc version 2.7.2.1 =:0 > Perl-5.8.0, Apache-1.3.28 & mod_perl-1.28 from source. > With Apache-1.3.27 and mod_perl-1.27 I could compile using the same > Perl-installation. You mean using Perl 5.8.0? > ** Error: Cannot build mod_include with Perl support (USE_PERL_SSI) ** > ** when mod_perl is compiled as DSO because of cross-module calls. ** > ** Ignoring PERL_SSI flag now. ** Have you tried it without "EVERYTHING=1"? > With 1.27 it worked with DSO, what has changed? Er, have you checked the CHANGELOG? > Compiler: > cc='cc', ccflags ='-I/usr/include -D_LARGEFILE_SOURCE - > D_FILE_OFFSET_BITS=64', > optimize='-O2', > cppflags='-I/usr/include -I/usr/include -D_LARGEFILE_SOURCE - > D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - > D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - > D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - > D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - > D_FILE_OFFSET_BITS=64' This doesn't look good at all. Try without LARGEFILE support? > osname=linux, osvers=2.0.35, archname=i686-linux Does that say 2.0.35 or do I need new glasses? > For all programs I used the same compiler and as I stated with the > earlier versions compiling never was a problem. I'm surprised you got away with it for so long really. Your OS and compiler are very old. What version of the C libraries are you using? The link you mentioned does say that the error you get when building static is a symptom of a broken Perl. Did you run the Perl testsuite when you built your Perl, and if so what failed? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOAP::Lite in mod_perl...
Hi guys, On Thu, 28 Aug 2003, Perrin Harkins wrote: > simran wrote: > > The above code works perfectly on: > > > > * On dev server in a standalone script > > * On our dev server under: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.6c > > DAV/1.0.3 mod_perl/1.27 > > * Our live server as a standalong script > > > > The code does not work on our live server under: > > > > * Live Server: Apache/1.3.28 (Unix) mod_ssl/2.8.15 OpenSSL/0.9.6c DAV/1.0.3 > > mod_perl/1.28 Have you mentioned this to Philippe Chiasson? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOAP::Lite in mod_perl...
Hi Stas, On Fri, 29 Aug 2003, Stas Bekman wrote: > Ged Haywood wrote: > > Have you mentioned this to Philippe Chiasson? > > Beg your pardon, Ged? What this has to do with Philippe? Wasn't he organising the release of mod_perl 1.28? If people are moving to a 1.3.28/1.28 combination, I would expect his mailbox to start filling up... 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Memory issues with DSO
Hi there, On Fri, 29 Aug 2003, Stathy G. Touloumis wrote: > should building a DSO in mod_perl 1.x versions just be avoided? I think so, and so I think does Randal. This was discussed briefly here not long ago in a couple of threads, check the archives. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: collecting unique client (computer) specific info? [OT]
Hi there, On Wed, 3 Sep 2003, kfr wrote: > Anyone know how to capture the UUID from a request? What makes you think there'll be one in there? > I've been looking all over the place and cant seem to find any > reference to it anywhere ... Try Google? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: collecting unique client (computer) specific info? [OT]
Hi there, On Wed, 3 Sep 2003, kfr wrote: > had to re-compile my server with mod_ssl :) > the hardware address is really what I'm after. What hardware? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: collecting unique client (computer) specific info? [OT][x-adr][x-bayes]
Hi there, On Wed, 3 Sep 2003, kfr wrote: > http://www.webdav.org/specs/draft-leach-uuids-guids-01.txt > > from section 3.5 ... I was assuming there was some way to parse and decrypt > the mac address from: > > > "The following is an example of the string representation of a UUID: > f81d4fae-7dec-11d0-a765-00a0c91e6bf6" > > the 00a0c91e6bf6 > > being the mac address of the computer. You don't even know there is a MAC address. And if there is, it can easily be spoofed. Forget it. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: porting from mod_perl1 to mod_perl2
Hi there, On Sat, 6 Sep 2003, Bart Terryn wrote: > Hi, > > I have an application running under apache > 1.37(win32)/mod_perl1.27_01-dev/perl5.6 build 633 > > I am trying to move this application to apache > 2.0.47(win32)/mod_perl1.99_10-dev/perl 5.8 > > However I run into a problem with character encoding. Have you checked perldoc perllocale ? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: AIX perfomance
Hi there, On Fri, 12 Sep 2003, Rafael Garcia-Suarez wrote: > we're porting on AIX (4.3.3 and 5.2.0). The AIX boxes are > supposed to be more powerful than their Linux equivalents, > however the application is strangely slow on AIX You don't give much to go on. Are they really more powerful? What does 'powerful' mean anyway? What discs do you have and what interfaces do they use, how much memory, what processors, speeds, how many mod_perl processes, how big are they, are you getting into swap, etc...? Have you benchmarked some simple things on the boxes? > So I'm asking for the common wisdom about performance issues on AIX. I don't know anything worth writing about AIX but I'd look a little deeper into what you're doing before you start blaming the OS. > Currently the perl I use is built with gcc and default > settings. Should I set -Dusemymalloc=y ? Should I use the xlC or > vac compilers ? Should I port everything to mod_perl 2 ? To all those questions at this stage, my answer would be 'I doubt it'. Find out about your systems first. There are lots of tools to help you do that. Start by checking the relevant sections of the Guide for more information about performance and benchmarking. (Or look at the little disc activity light. :) 73, Ged.
Re: AIX perfomance
Hi there,
On Fri, 12 Sep 2003, Rafael Garcia-Suarez wrote:
> Benchmarking simple CPU-intensive perl scripts shows that they
> tend to be consistently slower in user time on AIX.
Assuming that the boxes aren't otherwise heavily loaded, I wonder
about the options used to compile your Perl. For x86 architecture,
things like -mcpu=i386 will make a binary that you could run on a
steam engine but it won't be able to take advantage of the richer
instruction set on newer processors. I don't have a great deal of
experience with other modern processors, but from the gcc 3.2.3
documentation:
"GCC defaults to `-maix32'"
and there's a '-maix64' that may be worth a look, along with the rest
of the section ('info gcc' if you have it).
Optimisation may also be an issue, but use caution. Many packages
(e.g. the Linux kernel sources :) warn against anything more than
using -O2 with gcc for example.
73,
Ged.
Re: AIX perfomance
Hi there, On Fri, 12 Sep 2003, William McCabe wrote: > I've got a lot of experience with mod_perl on both linux and AIX and > can state categorically that there are no typical conditions which > would cause AIX run "strangely slowly" compared to linux on > comparable hardware. That's useful information, thanks Bill. We don't see much about AIX here but it seems to me that it's been becoming more common recently. Roughly what hardware setups do you generally work with, and what differences are notable between Linux and AIX when running mod_perl servers? (If that's not too long a piece of string to measure:). Are there situations where you'd prefer one or the other, if so why? 73, Ged.
Re: Summary: identifiying unique users
Hi all, On Tue, 16 Sep 2003, Frank Maas wrote: > | How to avoid multiple logins? > | > | The short answer is: you can't. Sure you can. Charge $10 per login. 73, Ged.
Re: Sleeping sessions
Hi there, On Wed, 17 Sep 2003, Andrey A. Kudrin wrote: > I've compiled apache 1.3.28 + mod_perl 1.28 + mod_ssl 2.8.15. > Before that all was ok, Before what? Before mod_ssl? Try it without. Have you checked in the documentation that the version of mod_ssl is suitable for your purposes? > but at the moment all httpd session freezing in memory and turning > to sleeping, 30-40 min and server is overloaded. You must send more information. Read the documentation on the mod_perl site to find out what you need to send. 73, Ged.
Re: upgrading to apache 2
Hello there, On Wed, 17 Sep 2003, Malka Cymbalista wrote: > I am currently running apache 1.3.26 with mod_perl 1.36 and Perl > 5.6.1 on my web server which is a Sun Solaris machine ... > I would like to install Apache 2, mod_perl 2, and Perl 5.8. While Apache version 2 is stable, mod_perl version 2 is not yet. If you are prepared to accept some of the issues which arise during the early stages of software development then by all means try mod_perl version 2. If not, then stay with the latest version 1, which means you must also use a version 1 Apache. There have been several issues with Perl 5.8.0, and although I have had no problems with 5.8.0 on my own development boxes, in either case I would wait for Perl 5.8.1 before release into a user environment - and I would test that for a couple of months first. As far as I can tell Perl 5.6.1 is as good a release of Perl as any. 73, Ged.
Re: message type 0x49 arrived from server while idle
Hi there, On Fri, 19 Sep 2003, Tobias Kremer wrote: > I have developed an application based on Apache 1.3.27, > mod_perl 1.27, Postgres 7.3.2, Class::DBI 0.94 (utilizes > Ima::DBI) on SuSE Linux 7.0 with a 2.4.20 kernel. > > The problem is that everytime more than one request at > a time is made to the server I find the following error message > in my logs and from then on apache seems to be stalled and is > unable to process any further requests: > "message type 0x49 arrived from server while idle" > > Nobody seems to have seen this error message before (I grep'd > through my perl lib dir and found nothing). I think it's from Postgres, not Perl. Try Googling for "message type" "arrived from server while idle" > It seems to have got something to do with many apache children > accessing the postgres database I'm sure that's right, I think you're confusing Postgres somehow. There are suspicions about threads in some of the messages that Google found with the query above. I've never used Postgres so I wouldn't know where to point you, but have you checked the Postgres docs for that message? There are a few references such as this http://developer.postgresql.org/docs/pgsql/src/interfaces/libpq/fe-protocol3.c fairly late on in the Google results. > The solution David and others found is not applicable to my problem > because I'm already running apache 1.3.27 (not 1.3.28 which seems to > be causing this trouble) I'm not sure I understand what you're saying here. At the beginning of your message it looked like you were using 1.3.27, not 1.3.28. Are you saying that the problem is present with a 1.3.27 Apache but not with 1.3.28? If so then could you not simply stay with 1.3.27? 73, Ged.
Re: segfaulting upon request
Hi there, On Mon, 4 Mar 2002, Steev Hise wrote: > I'm having trouble with the latest version of mod_perl and apache. > (version 1.26 with apache 1.3.23) > > upon startup there's a segmentation fault upon any http request. > i'd be grateful for any assistance. [snip] > i built modperl and apache like this: [snip] > here's details of the machine: -- > on redhat 7.0 linux i686, kernel 2.2.19-7.0.1smp -- > perl -V > Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: > Platform: -- > osname=linux, osvers=2.2.16-22smp, archname=i686-linux -- Hmmm. That's interesting... do I smell RPMs? 73, Ged.
Re: segfaulting upon request
Hi there, On Thu, 7 Mar 2002, Steev Hise wrote: > On Thu, 7 Mar 2002, Ged Haywood wrote: > > ->> on redhat 7.0 linux i686, kernel 2.2.19-7.0.1smp > ->-- > ->> perl -V > ->> Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: > ->> Platform: > ->-- > ->> osname=linux, osvers=2.2.16-22smp, archname=i686-linux > ->-- > -> > ->Hmmm. That's interesting... do I smell RPMs? > > i didnt use any rpms when i built apache, modssl, php, and modperl. > i'm not sure what you mean or how your comment is intended to help. I apologize if my message was not clear. Did you build your own Perl? 73, Ged.
Re: Simple configuration question
Hi there, On Fri, 8 Mar 2002, Kirk Rogers wrote: > now I'd like to add SSL capabilities and dont want to clobber my > existing system How can I add SSL to my existing distribution > without overwriting any of my current configuration and files? Go ahead and rebuild with the latest sources in a new directory. None of your existing files will be touched until you do '#make install' and your existing configuration files in .../apache/conf won't be overwritten at all. Of course you have backups anyway, don't you? 73, Ged.
RE: Simple configuration question
Hi again, On Fri, 8 Mar 2002, Kirk Rogers wrote: > if I add "APACHE_PREFIX=/usr/local/apache_ssl" it shouldn't even touch anything > I have in my original installation at "/usr/local/apache". Is this correct? > > Then I can slowly migrate my configuration file over to the new installation > directories? Yes, and yes. This is how you would for example set up the light/heavy server system where you have two copies of Apache running at the same time: a non-modperl server listening on port 80 serves requests for static pages itself, while passing requests for dynamic pages to a modperl server listening on a different port. It's in the Guide: http://perl.apache.org/guide. Don't try to run both Apaches at the same time on the same socket! 73, Ged.
Re: About Apache::DBI
On Sat, 9 Mar 2002, Axel Andersson wrote: > Okay, so I read up on Apache::DBI, but I still have a question or two. > > Specifically, am I supposed to keep my "use DBI", "DBI->connect()", and > everything DBI related and not change a single thing in my source What did you read? Here are the first six lines from 'perldoc Apache::DBI.pm': Apache::DBI - Initiate a persistent database connection # Configuration in httpd.conf or startup.pl: PerlModule Apache::DBI # this comes before all other modules using DBI Do NOT change anything in your scripts. The usage of this module is absolutely transparent ! 73, Ged.
Re: Hi........
Hi all, On Sat, 9 Mar 2002, Mark Fowler wrote: > On Sat, 9 Mar 2002, Balaji_Mahalingam wrote: > > > Can any one send me the installing and configuring > > details of mod_perl-1.26 > > There's installation instructions in the Guide: >http://perl.apache.org/guide/install.html Not to mention in the tarball itself... $ ls -l ~/mod_perl-1.25 total 552 drwxr-xr-x2 ged ged 4096 Apr 24 2001 Apache -rw-r--r--1 ged ged 10894 Dec 22 1998 CREDITS -rw-r--r--1 ged ged133135 Jan 30 2001 Changes drwxr-xr-x2 ged ged 4096 Apr 24 2001 Connection drwxr-xr-x2 ged ged 4096 Apr 24 2001 Constants drwxr-xr-x2 ged ged 4096 Apr 24 2001 File -rw-r--r--1 ged ged 10776 Apr 3 2000 INSTALL -rw-r--r--1 ged ged 10332 Jan 26 2000 INSTALL.apaci -rw-r--r--1 ged ged 1658 Jul 10 2000 INSTALL.raven -rw-r--r--1 ged ged 456 Oct 1 1999 INSTALL.simple -rw-r--r--1 ged ged 681 Oct 1 1998 INSTALL.simple.mod_ssl -rw-r--r--1 ged ged 713 May 12 1998 INSTALL.simple.ssl -rw-r--r--1 ged ged 632 May 15 1998 INSTALL.simple.stronghold -rw-r--r--1 ged ged 4300 Dec 31 2000 INSTALL.win32 ... ... 73, Ged.
Re: SSL Installation Questions - Help
Hi there, On Sat, 9 Mar 2002, Kirk Rogers wrote: > I've acquired: > mod_perl-1.26.tar.gz > openssl-0.9.6c.tar.gz > apache_1.3.22.tar.gz > apache_1.3.22+ssl_1.47.tar.gz I use mod_ssl with no problems, you could try that. 73, Ged.
RE: Newbie install problems
Hi there, On Mon, 11 Mar 2002, Nicolai Schlenzig (DXD) wrote: > After updating my FreeBSD 4.5-STABLE I got installed perl 5.6.0 on > top of my 5.00503 and it was all dandy... until I updated a CPAN > module which wanted to install 5.6.1 on top again. Why not set the CPAN configuration file so that it asks you whether or not to update your files? 73, Ged.
Re: where should the handler sript be kept
Hi there, On Mon, 11 Mar 2002, Rizwan Majeed wrote: > I am trying to invoke a handler script. I have set the location tag > in httpd.conf I dont know where to place the script so that Apachi > picks it up at run-time. Have a look in the Guide: http://perl.apache.org/guide and the Eagle Book: "Writing Apache Modules with Perl and C", ISBN 1-56592-567-X 73, Ged.
Re: Tie hashes in DBIx::Recordset [OT]
Hi there,
On Wed, 13 Mar 2002, Marcus Claesson wrote:
> How do I succesfully preserve the column order (''$fields'=>
> $joined_col') in my array-of-hashes generated using DBIx::Recordset?
Check out a Perl tutorial or the Camel book. Perl's hashes do their own
thing with ordering, so unless you do something like (sort keys %hash)
you will get what you get. Arrays can preserve sequences but involve
you in more coding much of the time.
73,
Ged.
Re: Blank Pages ( Revisited ) [Semi-OT]
Hi there, On Wed, 13 Mar 2002 [EMAIL PROTECTED] wrote: > However, when I do a "random" query I get some blank pages. I traced this to > the DBI Log using the "DBH->Trace(2, /tmp/DBI.log)". I found that sometimes > the "execute()" returns "0E0". Does anybody knows why?? It probably means zero multiplied by ten to the power zero, or to put it another way, zero. 73, Ged.
Re: query
Hi there, On Wed, 13 Mar 2002, Parag R Naik wrote: > We have installed perl 5.6 Make sure you get 5.6.1 not 5.6.0 which is buggy. 73, Ged.
Re: problem in recompiling
Hi there, On Thu, 14 Mar 2002, Parag R Naik wrote: > Hi all, > I am having a problem compiling mod_perl 1.26 src with apache 1.3.22 src. > The problem on running make occur at the following command > > gcc -c -I../.. -I/usr/local/ActivePerl-5.6/lib/5.6.1/i686-linux-thread-multi/COR ActivePerl ? I don't understand. Tell me all about that. 73, Ged.
Re: problem in recompiling
Hi there, On Thu, 14 Mar 2002, Parag R Naik wrote: > I am using ActivePerl 5.6 . I had executed the Makefile.PL with Active > Perl hence the Makefile created contain the activeperl entry .. I don't know anything about ActivePerl. I think that its use might be the cause of your problem. Can you perhaps install Perl from the source tarball at www.perl.com/CPAN/src/stable.tar.gz ? Then you should recompile Apache and mod_perl following the instructions supplied with the packages. Please keep your replies on the list, that way everyone can see that this issue is being investigated. 73, Ged.
Re: [ANNOUNCE] The New "mod_perl" logo - results now in...
Hi there, On Fri, 15 Mar 2002, David Ranney wrote: > I really like the new logo, and in fact I voted for it. However, I just > realized that the logo uses "modperl", whereas mod_perl's name is > "mod_perl", with the underscore. Does anyone else see this as a problem? > I've always been annoyed at how often the spelling gets modified, and it > seems that the logo as it is now would add to the confusion. Am I just > picking nits? You are quite right. It's definitely not picking nits, it's important. 73, Ged.
RE: loss of shared memory in parent httpd
Hi all, On Sat, 16 Mar 2002, Bill Marrs wrote: > leads ones to wonder if some of our assumptions or tools used to > monitor memory are inaccurate or we're misinterpreting them. Well 'top' on Linux is rubbish for sure. 73, Ged.
Re: Trouble w/ LWP during mod_perl install
Hi there, On Sun, 17 Mar 2002, John Kolvereid wrote: > I got your name from the mod_perl mailing list, Please post to the list, not to an individual member, unless you are replying to a message from that member on the list - in which case you should normally cc the list. (You will find more help about this kind of thing in http://perl.apache.org/email-etiquette and there are some links in there to other documents you should also read... :) > I am trying to install mod_perl-1.26 on Linux RedHat 6.2 w/ > Apache-1.3.22. I am using the following build file: > perl Makefile.PL \ > APACHE_PREFIX=/usr/local/apache \ > APACHE_SRC=/home/ssl/apache_1.3.22 \ > DO_HTTPD=1 \ > USE_APACI=1 \ > EVERYTHING=1 > > I get a lot of messages, That's normal. You haven't said where you have put the mod_perl source, can I assume that it is "/home/ssl/mod_perl-1.26"? > then I run 'make', and 'make test'. > Problem is that make test complains that it cannot find LWP. It isn't absolutely necessary but it's a good idea to get 'make test' to run successfully, which needs LWP. > I downloaded and installed (I think) libwww-perl-5.64. How did you do that? It's probably easiest to use CPAN.pm: perl -MCPAN -eshell > Unfortunately, it didn't seem to resolve my LWP problem. When I do > a 'make install' nothing seems to change. H. You aren't helping me very much there. Are you following all the instructions carefully? What happens? 'make install' doesn't rely on LWP. You probably need to be root to 'make install'. Do you think you have successfully compiled a binary after the 'make' step? It will be called 'httpd'. Check the date and time of the binary to make sure it's the one you've built and not just one that was lying around in there from an old installation. Can you run it with 'httpd -l' and post the result? 73, Ged.
Re: Trouble w/ LWP during mod_perl install
Hi there, On Sun, 17 Mar 2002, John Kolvereid wrote: > In order to try and install mod_perl-1.26 in RedHat > 6.2 w/ Apache 1.3.22 I, as ROOT, run the following > in my /home/ssl/mod_perl-1.26: > perl Makefile.PL \ [snip] [snip] > Then I try running > /usr/local/apache/bin/apachectl startssl I think you're getting confused with too many Apache modules. Try to build without ssl to begin with, so that you can check that what you're doing for mod_perl is OK. Please read the installation section of the Guide and follow the instructions carefully. You will see that it suggests that you do the 'make' and 'make test' steps NOT as root, then 'make install' as root. It's not unknown for things to get a little screwy if you try to build as root, and especially if sometimes you're logged in as root and sometimes you're not. It might be best if you delete the source trees in /home/ssl/mod_perl-1.26 and /home/ssl/apache_1.3.22 and start again, or start again in a new directory, say something like this: $ cd /home/fred/src/apache_1.3.22/ $ tar xzvf .../apache_1.3.22.tar.gz $ cd /home/fred/src/mod_perl-1.26/ $ tar xzvf .../mod_perl-1.26.tar.gz $ cp makepl_args.mod_perl . $ perl Makefile.PL $ make $ su # make install # ls -l /usr/local/sbin/httpd ... (Check here that the date and time of the binary look sensible:) # /usr/local/sbin/httpd -f /usr/local/apache/conf/httpd.conf # tail /usr/local/apache/logs/error_log ... (Check that Apache started and that it says it's a mod_perl Apache:) The file makepl_args.mod_perl is below, and there is a sample in the mod_perl/eg directory too. You might want to adjust these a little to suit your needs. You can also put the file in the home directory of the user who does 'make' but then you need to prefix the filename with a dot, i.e. ".makepl_args.mod_perl". > Invalid command 'LoadModule', perhaps mis-spelled or > defined by a module not included in the server > configuration > could not locate Module SSL (line 206 httpd.conf) > > My only recourse is then to rebuild Apache w/o mod_perl. This error has nothing to do with mod_perl. You have a 'loadmodule' directive in httpd.conf but you don't have mod_so.c compiled into the Apache which you are trying to start using that httpd.conf - as you will see if you will get the output of 'httpd -l' as I asked you to do in my previous message. Try to understand what you're doing, it's not really that complicated if you are methodical. You are going to build a binary called 'httpd' and you can run it without 'apachectl'. This is a script that does some other stuff too. You can try for example 'apachectl configtest'. 'apachectl' is created by 'make install'. You need to check that it is starting the right Apache, i.e. the one you just built! Be careful, there may be several of them (both httpd and apachectl) kicking around if you have been trying lots of builds in desperation... > I am having a great deal of difficulty installing mod_perl. I am > not sure it is worth it. It's worth it but you will have to do quite a bit of reading and it won't all happen overnight. Your difficulties at the moment do not seem to stem primarily from mod_perl itself. > I have been reading installation excerpts frm various sources ...and then you have to do what it says in the things you've read. :) > w/ Perl and C', and the internet CPAN sites. My build in ? Your message seems to have been truncated here. 73, Ged. 8<-- USE_APACI=1 APACHE_PREFIX=/usr/local APACHE_SRC=../apache_1.3.12/src DO_HTTPD=1 EVERYTHING=1 ALL_HOOKS=1 PERL_SSI=1 PERL_SECTIONS=1 APACI_ARGS=--sbindir=/usr/local/sbin/ APACI_ARGS=--sysconfdir=/usr/local/apache/conf APACI_ARGS=--runtimedir=/usr/local/apache/run APACI_ARGS=--logfiledir=/usr/local/apache/logs 8<--
Re: Trouble w/ LWP during mod_perl install
Hi John, On Sun, 17 Mar 2002, John Kolvereid wrote: > Thanks for sticking in there w/ me. :) > There are a great many options and the number > of combinations is awesome. True, but there's no point worrying about the number of combinations, you need to worry about setting things up the way you want them. > Only 1 is correct, It's not really like that. (You just have to decide how you want things to be set up...:) > I ran the build again for the mod_perl and apache using > APACHE_PREFIX and APACHE_SRC and SSL_BASE. When finished I tried > the apachectl startssl and got the same LoadModule error as before. I really think you should forget ssl for the moment until you get a grip on compiling and configuring Apache and mod_perl. And PLEASE don't run apachectl until you know what it's going to do. You can start Apache without using a script. > I tried the httpd -l and mod_so.c WAS present. To be certain I did > a 'which httpd'. It was using the one in /usr/sbin but that's not > new, it is dated Oct 19 2000. That's not the one you're running. 'which' tells you what will be used if you call the binary directly without giving the full path to the binary, but if you try to run it with 'apachectl' then you could be using a different one. Why not just delete it, or rename it if you want to keep it? Keep a notebook to record the changes you make so that you don't forget what you've changed. In my last message I asked you to run the binary by calling it with the full path name. Don't rely on the path in your environment by running a binary without the full path name at this stage, you'll only confuse yourself even more. > Moreover, the httpd.conf in the conf directory is dated Mar 4. When you do 'make install' the scripts won't overwrite your existing configuration. If you delete, rename or move the conf directory and then re-install you'll get a new httpd.conf. > There is one dated Mar 17 (today) named httpd.conf.default but it > does not include any reference to mod_perl. If you compile mod_perl in statically it doesn't have to have a loadmodule directive for mod_perl - in fact it shouldn't have one. You need a completely new httpd.conf which is installed at the time you build Apache and mod_perl. But do please read it when you've finally made it, because there are as you have said lots of things you need to think about. > What should I try next. All the things I've said in my last three messages. They *will* work if you clean everything up like I said, RedHat 6.2 really has no problems with Apache and mod_perl. 73, Ged.
Re: Subroutines taking time to return..
Hi there, On Wed, 20 Mar 2002, David Brown wrote: > I've been profiling my MySQL driven Mod_Perl website [snip] > (using Time::HiRes) [snip] > I expected all the complicated DB access stuff to make up the time MySQL is pretty quick. :) > instead it seems to be consuming 0.005 in returning from the subroutine to > the main script. > > What's that all about ? [snip] > > It SEEMS the subroutine is taking an inordinate amount of time returning to > the main procedure.. why would this be ? What else is the machine doing? Is it reapeatable (i.e. not just OS timeslices or something)? Post the code? 73, Ged.
RE: CGI.pm and POST requests
Hi there, On Wed, 20 Mar 2002, Vuillemot, Ward W wrote: > > On Tue, 19 Mar 2002 14:06:15 -0800 Vuillemot, Ward W wrote: > > > why would it work for cgi and not mod_perl? > > > > > From: Ged Haywood [Replying privately because of large attachment] > > Does the attached version of CGI.pm help? (I have added a few 'print' > > statements, they are flagged by --GWH-- for you to find them easily.) > > > > Run it and then look in the error_log... > > I have the latest version of CGI. But I am not using it to read in > sent data anymore. Since my scripts that use CGI versus Apache::Request > are identical except one is run in cgi space versus mod_perl space, one > would expect everything to be hunky dory. My point was not that you don't have the latest bersion of CGI.pm. I sent you CGI.pm with some debugging information which will allow you easily to see why things don't do what you expect. > It would seem my httpd.conf file is off. No, I don't think that's the problem. Like I said, if you run your scripts with the CGI.pm that I sent you may see something interesting. (I don't want to do the whole thing for you...:) 73, Ged.
RE: 0 being appended to non mod_perl scripts.
Hi there, On Thu, 21 Mar 2002, Mike Wille wrote: [snip,snip] > I checked to see if mod_perl was handling the scripts that sent the '0' but > perl is indeed handling them and not httpd. I'm not sure I understand what you're saying here. > The server is running Apache 1.3.20. I'm not sure how to find the version > of mod_perl... Does this mean you'vve *never* looked in the error_log??? 73, Ged.
Re: Subroutines taking time to return..
Hi there, On Thu, 21 Mar 2002, Perrin Harkins wrote: > When you call the script, do you get segfaults in the error log? Coming into this thread a little late, so sorry if you already said, what version of Perl are you using? I had problems with Devel::Dprof and dprofpp on 5.7.1 which were fixed by upgrading to 5.7.2 although Dprof itself didn't change at all. 73, Ged.
Re: Subroutines taking time to return..
Hi again, On Thu, 21 Mar 2002, David Brown wrote: > OK, I have it working now. Guess I shold read ALL my mail before replying to any of it... 73, Ged.
Re: Off topic question & a little worried
Hi there, On Thu, 21 Mar 2002, John Michael wrote: > Any idea as to how it got on my server. Nope. There are a thousand ways it could have been done if your server is not carefully secured. Do waht Perrin said - take it offline, it can't be trusted - and read the CERT stuff that you've been pointed to by another useful reply. The server probably has a dozen back-doors in it now so it would be irresponsible to leave it on line. Unless you *really* know what you are doing from a security point of view (and without meaning to be offensive it sounds vey much like you don't) you should wipe the discs and reinstall the OS and server(s) from scratch. Then do some serious reading about securing your server. Don't run any daemons you don't have to run, especially ftp and sendmail, if you aren't sure of them. 73, Ged.
Re: modperl and SQL db select
Hi all, On Thu, 21 Mar 2002, Perrin Harkins wrote: > > Please, please, please KILL THIS THREAD! I second that. It's all been done before guys. 73, Ged.
Re: Apache and Perl with Virtual Host
Hi there, On Fri, 22 Mar 2002, Matt Phelps wrote: [snip,snip] > Okay, this is still giving me problems. Here is my config. I've > tried several things and still nothing. For some reason I can't get > cgi scripts to run under any virtual webs, but the default web. What's a 'web'? I think you mean 'host'. (It helps if we all speak the same language, especially if we are using a search engine... :) > I do have mod_perl installed. Oh, all right then... :) > I'm sure it's got to be something so simple. I think it's called 'reading the documentation'... :) > > DocumentRoot /var/www/html > ServerName www2.zeetec.net > Options +ExecCGI > Alias /host/ /webhome/host/ > Alias /cgi-bin/ /var/www/cgi-bin/ > ScriptAlias /cgi-bin/ /var/www/cgi-bin > > SetHandler perl-script > PerlHandler Apache::Registry > PerlSendHeader On > Options +ExecCGI > > > AllowOverride None > Options None <--- This removes 'ExecCGI' from your Options > Order allow,deny > Allow from all > > Check the Apache docs about the behaviour of the 'Options' directive. 73, Ged.
Re: Problems installing on Solaris 8
Hi there, On 23 Mar 2002, Wayne Pascoe wrote: > Why does mod_perl need ssl and crypto ? Just curious... It doesn't. Have you tried sompiling static instead of DSO? There have been DSO problems on Solaris (and elsewhere :) in the past but I thought they were mostly put to bed now. 73, Ged.
Re: Apache and Perl with Virtual Host [OT]
Hi again, Oh, rats, I'm sorry, I shouldn't have sent that. I'm not sure that it's your 'Options' settings at all. Have you got the right execute permisions on the directories/files that you're trying to get Apache to search and/or execute? Have you got anything in the error_log? By way of further apology, if you'd care to reply to me privately we'll get it running for you off-list as it's not a mod_perl issue. 73, Ged. ---------- On Sat, 23 Mar 2002, Ged Haywood wrote: > Hi there, > > On Fri, 22 Mar 2002, Matt Phelps wrote: > > [snip,snip] > > Okay, this is still giving me problems. Here is my config. I've > > tried several things and still nothing. For some reason I can't get > > cgi scripts to run under any virtual webs, but the default web. > > What's a 'web'? I think you mean 'host'. (It helps if we all speak > the same language, especially if we are using a search engine... :) > > > I do have mod_perl installed. > > Oh, all right then... :) > > > I'm sure it's got to be something so simple. > > I think it's called 'reading the documentation'... :) > > > > > DocumentRoot /var/www/html > > ServerName www2.zeetec.net > > Options +ExecCGI > > Alias /host/ /webhome/host/ > > Alias /cgi-bin/ /var/www/cgi-bin/ > > ScriptAlias /cgi-bin/ /var/www/cgi-bin > > > > SetHandler perl-script > > PerlHandler Apache::Registry > > PerlSendHeader On > > Options +ExecCGI > > > > > > AllowOverride None > > Options None <--- This removes 'ExecCGI' from your Options > > Order allow,deny > > Allow from all > > > > > > Check the Apache docs about the behaviour of the 'Options' directive. > > 73, > Ged. > >
Re: Problems installing on Solaris 8
Hi there, On 23 Mar 2002, Wayne Pascoe wrote: > Ged Haywood <[EMAIL PROTECTED]> writes: > > > Have you tried sompiling static instead of DSO? > > This is a static build. Sorry, I've deleted the original message. Why did I think it wasn't? I must be having a very bad day today. > if I compile Apache with mod_perl, then mod_auth_db, mod_proxy and > mod_negotiation all stop working. If I compile Apache without > mod_perl then they continue to work just fine. Something very wrong there. Do you have squeaky clean source trees? I'd be tempted to erase the lot and start again. What's the compiler? Post your httpd.conf? Have you built other (older) versions of Apache and mod_perl on the same OS? 73, Ged.
Re: Problems installing on Solaris 8
Hi all, Wayne Pascoe <[EMAIL PROTECTED]> writes: > > [8:37am]# httpd -l > > Compiled-in modules: > > http_core.c > > mod_so.c > > mod_perl.c > > suexec: disabled; invalid wrapper /usr/local/apache/bin/suexec I didn't think I'd been dreaming. > As a matter of principle, I tend not to mix static and dynamic. Me too. > where I'm unsure, I go all static and build distinct binaries. Me too. But if you go all dynamic it's quicker to pull modules out, and you can change the order they're loaded which is important in some cases. Pity my Solaris box isn't with me (1,000 miles away) or I'd ask you to send me your config. and try to repeat your problem. Come to think of it I did ask, anyway... On 23 Mar 2002, Dave Hodgkinson wrote: > Wayne Pascoe <[EMAIL PROTECTED]> writes: > > Dave Hodgkinson <[EMAIL PROTECTED]> writes: > > > Ged Haywood <[EMAIL PROTECTED]> writes: > > > > Post your httpd.conf? 73, Ged.
Re: AddModule mod_perl.c
Hi there, On Sat, 23 Mar 2002, John Kolvereid wrote: >I am trying to install/configure mod_perl. I think > it is installed but not quite sure. It's in the Guide. (How do I know if mod_perl is installed?) > According to the mod_perl Reference Guide the line > AddModule mod_perl.c > should be added to my httpd.conf, otherwise mod_perl > is not activated. I think you'd better have a more careful look at that Guide. You only need that in your config if you have mod_perl built as a DSO (Dynamic Shared Object) which means that Apache starts without trhe mod_perl module and then loads it later when it reads the line AddModule mod_perl.c in httpd.conf. > when I include the line and try > to load any page into my browser I get the msg: > The document contained no data Something isn't working right. :) Could be all sorts of things. Read the file mod_perl/SUPPORT to begin with. Post the information requested in there. 73, Ged.
Re: AddModule mod_perl.c
Hi there, On Sat, 23 Mar 2002, John Kolvereid wrote: > Which Guide? Please advise. http://perl.apache.org/guide Did you read any of the other documentation? Please let me know why you did not know about the Guide, we have obviously failed you. 73, Ged.
Re: Be carefull with apache 1.3.24
Hi Pedro, On Sun, 24 Mar 2002, Pedro Melo Cunha wrote: [snip,snip] > Looking at the change log, they mention a bug that multiple set-cookie's > will fail (only the last one will be sent to the client, the proxy will > "eat" the others). And it was true... The problem is that 1.3.24 final > also has that bug: only the last set-cookie will reach your browser. > > This was a show-stopper for my application. So I sat down, read the > proxy code, and made a patch to solve the bug. [snip] > > Anyway, I attached here. Maybe someone here can push it into apache for > the next release, and in the meantime you can use it, if you want. > > I also attach a cgi that set's two cookies, to demonstrate the problem. Pedro, thanks a real bunch! You just saved me a load of work! If we ever meet, I'll buy you a beer, I promise! 73, Ged.
Re: Problems installing on Solaris 8
Hi there, On 23 Mar 2002, Wayne Pascoe wrote: > "Angel R. Rivera" <[EMAIL PROTECTED]> writes: > > > Sorry to come in late into this. I had the same problems and spent a > > while getting it all to build right. I am running on an Ultra class > > [snip] > > I built it DSO. > > I was hoping to get away with it compiled in as static. I've heard > fearful tales of memory leaks and other problems when using it as a > DSO. Are these still present ? Argh. :) 73, Ged. -- >From [EMAIL PROTECTED] Mon Mar 25 10:42:35 2002 Date: Sat, 23 Mar 2002 08:24:16 + (GMT) From: Ged Haywood <[EMAIL PROTECTED]> To: Wayne Pascoe <[EMAIL PROTECTED]> Cc: mod_perl Mailing List <[EMAIL PROTECTED]> Subject: Re: Problems installing on Solaris 8 Hi there, On 23 Mar 2002, Wayne Pascoe wrote: > Why does mod_perl need ssl and crypto ? Just curious... It doesn't. Have you tried sompiling static instead of DSO? There have been DSO problems on Solaris (and elsewhere :) in the past but I thought they were mostly put to bed now. 73, Ged.
Re: mod_perl on Mac OSX?
On Sun, 24 Mar 2002 [EMAIL PROTECTED] wrote: > Can anyone help point me in the right direction for installing mod_perl for > Apache on Mac OSX? Try searching the archives, a list of them appears on the mod_perl home page at http://perl.apache.org. I found this one... [EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/fermkhiwhand/[EMAIL PROTECTED] But be preapared for at least some pain. ( I've never done it :). 73, Ged.
Re: [OT] Replacing reverse squid with mod_proxy
Hi there, On Mon, 25 Mar 2002, Hans Juergen von Lengerke wrote: > I am looking into replacing the squid with apache+mod_proxy. I don't know if it will do what you need, but you might want to have a look at mod_accel. If this URI is broken mail dapimailru for the information. http://dapi.chaz.ru/articles/mod_accel.xml?lang=en 73, Ged.
Re: AddModule mod_perl.c
Hi Perrin, On Wed, 27 Mar 2002, Perrin Harkins wrote: > Stas Bekman wrote: > > Arh, I mean to use the hints how to get the core dump backtrace. > > Hang on, this guy is just trying to do an install. He shouldn't need > to troubleshoot at that low a level. Quite right Perrin, but I'm afraid we're having a little trouble communicating with Mr. Kolvereid. Here is one of several messages which I sent to him last week. 73, Ged. -- >From [EMAIL PROTECTED] Wed Mar 27 19:51:14 2002 Date: Mon, 18 Mar 2002 00:45:49 + (GMT) From: Ged Haywood <[EMAIL PROTECTED]> To: John Kolvereid <[EMAIL PROTECTED]> Cc: mod_perl Mailing List <[EMAIL PROTECTED]> Subject: Re: Trouble w/ LWP during mod_perl install Hi there, On Sun, 17 Mar 2002, John Kolvereid wrote: > In order to try and install mod_perl-1.26 in RedHat > 6.2 w/ Apache 1.3.22 I, as ROOT, run the following > in my /home/ssl/mod_perl-1.26: > perl Makefile.PL \ [snip] [snip] > Then I try running > /usr/local/apache/bin/apachectl startssl I think you're getting confused with too many Apache modules. Try to build without ssl to begin with, so that you can check that what you're doing for mod_perl is OK. Please read the installation section of the Guide and follow the instructions carefully. You will see that it suggests that you do the 'make' and 'make test' steps NOT as root, then 'make install' as root. It's not unknown for things to get a little screwy if you try to build as root, and especially if sometimes you're logged in as root and sometimes you're not. It might be best if you delete the source trees in /home/ssl/mod_perl-1.26 and /home/ssl/apache_1.3.22 and start again, or start again in a new directory, say something like this: $ cd /home/fred/src/apache_1.3.22/ $ tar xzvf .../apache_1.3.22.tar.gz $ cd /home/fred/src/mod_perl-1.26/ $ tar xzvf .../mod_perl-1.26.tar.gz $ cp makepl_args.mod_perl . $ perl Makefile.PL $ make $ su # make install # ls -l /usr/local/sbin/httpd ... (Check here that the date and time of the binary look sensible:) # /usr/local/sbin/httpd -f /usr/local/apache/conf/httpd.conf # tail /usr/local/apache/logs/error_log ... (Check that Apache started and that it says it's a mod_perl Apache:) The file makepl_args.mod_perl is below, and there is a sample in the mod_perl/eg directory too. You might want to adjust these a little to suit your needs. You can also put the file in the home directory of the user who does 'make' but then you need to prefix the filename with a dot, i.e. ".makepl_args.mod_perl". > Invalid command 'LoadModule', perhaps mis-spelled or > defined by a module not included in the server > configuration > could not locate Module SSL (line 206 httpd.conf) > > My only recourse is then to rebuild Apache w/o mod_perl. This error has nothing to do with mod_perl. You have a 'loadmodule' directive in httpd.conf but you don't have mod_so.c compiled into the Apache which you are trying to start using that httpd.conf - as you will see if you will get the output of 'httpd -l' as I asked you to do in my previous message. Try to understand what you're doing, it's not really that complicated if you are methodical. You are going to build a binary called 'httpd' and you can run it without 'apachectl'. This is a script that does some other stuff too. You can try for example 'apachectl configtest'. 'apachectl' is created by 'make install'. You need to check that it is starting the right Apache, i.e. the one you just built! Be careful, there may be several of them (both httpd and apachectl) kicking around if you have been trying lots of builds in desperation... > I am having a great deal of difficulty installing mod_perl. I am > not sure it is worth it. It's worth it but you will have to do quite a bit of reading and it won't all happen overnight. Your difficulties at the moment do not seem to stem primarily from mod_perl itself. > I have been reading installation excerpts frm various sources ...and then you have to do what it says in the things you've read. :) > w/ Perl and C', and the internet CPAN sites. My build in ? Your message seems to have been truncated here. 73, Ged. 8<-- USE_APACI=1 APACHE_PREFIX=/usr/local APACHE_SRC=../apache_1.3.12/src DO_HTTPD=1 EVERYTHING=1 ALL_HOOKS=1 PERL_SSI=1 PERL_SECTIONS=1 APACI_ARGS=--sbindir=/usr/local/sbin/ APACI_ARGS=--sysconfdir=/usr/local/apache/conf APACI_ARGS=--runtimedir=/usr/local/apache/run APACI_ARGS=--logfiledir=/usr/local/apache/logs 8<--
Re: odd ld error
Hi there, On Thu, 28 Mar 2002, Kreimendahl, Chad J wrote: > > all of this is on Solaris 8 (Netra T1)... any help would be much appreciated > > [error] install_driver(Oracle) failed: Can't load > '/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/DBD/Oracle/Oracle.so [snip] > Permission denied [snip] Looks like there's no permission to read the file. 73, Ged. PS: You can remove that "old_mod_perl" address now
Re: AddModule mod_perl.c
Hi all, On Sat, 30 Mar 2002, Per Einar Ellefsen wrote: > >It just doesn't work w/ mod_perl. I am stumped and am > >probably going to give up shortly - thank anyways. > > That's because you haven't compiled it statically. Try starting with a > clean build: only mod_perl, build it statically, add only minimal extra > configuration, and test that. Which is what I told him nearly two weeks ago. I am probably going to give up shortly too. 73, Ged.
Re: Astronomical Information [OT]
Hi there, On 2 Apr 2002, simran wrote: > I have (for weeks) been trying to find a Perl Module (preferablly > one that works under mod_perl) that does various astronomical > calculations - in particular i want to be able to work out the > distance of a planet (in our solar system) on a given date. If you need only approximate answers then you can assume that the planets are all in the same plane, and use Kepler's laws (very simple geometry) to calculate the positions based on a known set of initial positions at a given date and time. You could modify your inital conditions occasionally to maintain reasonable accuracy. Please contact me privately if you wish to pursue the idea, this is way Off Topic for this list. 73, Ged.
