Re: unsetting PerlTransHandler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 14 August 2003 12:34, Frank Maas wrote:
and want to unset the TransHandler inside the Location.
How to do that?
AFAIK: not. The TransHandler is the first to be called and cannot appear
inside a container (ref. ModPerl cookbook). The only thing I can think of,
and in fact implemented this, to make the TransHandler URI-aware and
return immediately if the uri is something you do not want to be touched
by the TransHandler.
Yes, I've implemented it also that way. But I thought Location acts on the
URI and in principle there can be a Location-specific transhandler. I'm
wondering why it is impossible?
For now I have implemented that particular case by
PerlTransHandler MyPackage::transhandler
Location ...
PerlHandler MyPackage::handler
/Location
package MyPackage;
sub transhandler {
...
return DECLINED
if(grep {$_ eq __PACKAGE__.'::handler'} @{$r-get_handlers('PerlHandler')});
...
}
i.e. if my handler is installed return DECLINED.
Torsten
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/O2e0wicyCTir8T4RAjpXAKC8qRHIrQXxIA3O1RP3BnC40LcVqgCgy+eS
c+edNr0sMUM+tq0jmICq39Q=
=PnAk
-END PGP SIGNATURE-
Re: unsetting PerlTransHandler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 14 August 2003 13:48, Frank Maas wrote: |Location ... | PerlSetVar SkipTransHandler 1 |/Location I don't want to make it configurable. Torsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/O54ywicyCTir8T4RAss0AJ4rNMkqyKC0Tlh8tPZF5XbGc4GSeQCgjwto CvsUie4PVYy1QQ/MfsywCtI= =npMM -END PGP SIGNATURE-
Re: Apache::AuthenNTLM module with HP/Apache
Antony Batten wrote: Randy, OK thanks, I'll give that a try. I think we can compile the module against 5.6.1 It's just that we can't change the 5.6.1 install as it would break our support agreement with HP (so I am told) ... I presume we just have to 'install' the module in a different place after compiling it... Thanks v. much to all for helping me with this. Rgds, Antony -Original Message- From: Randy Kobes [mailto:[EMAIL PROTECTED] Sent: 14 August 2003 07:23 To: Antony Batten Cc: 'Shannon Eric Peevey'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Apache::AuthenNTLM module with HP/Apache On Wed, 13 Aug 2003, Antony Batten wrote: Shannon, Thanks very much for the quick response. Here's the info you wanted (I hope): HP-UX_Apache-based_Web_Server/2.0.46 (Unix) mod_perl/1.99_09 Perl/v5.6.1 DAV/2 configured Can my career be saved? ;0) Thanks again, Antony. -Original Message- From: Shannon Eric Peevey [mailto:[EMAIL PROTECTED] Sent: 13 August 2003 14:41 To: Antony Batten Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Apache::AuthenNTLM module with HP/Apache Antony Batten wrote: [ .. ] We are trying to use the Apache::AuthenNTLM perl module with HP/Apache and mod_perl. We have prevented mod_perl from running our cgi-perl scripts (by using Apache directives to only use mod_perl for *PL files), as we want to use 5.8 for this, and the HP-supplied mod_perl is tied to 5.6.1 Everything installs ok the server starts ok. However, we get the following errors in the errorlog: [Fri Aug 08 13:39:47 2003] [error] failed to resolve handler `Apache::AuthenNTLM' [Fri Aug 08 13:39:47 2003] [error] [client 30.254.43.59] Can't find 'boot_Authen__Smb' symbol in /opt/perl5.8/lib/site_perl/5.8.0/ PA-RISC1.1/auto/Authen/Smb/Smb.sl Compilation failed in require at /opt/perl5.8/lib/site_perl/5.8.0/PA-RISC1.1/Apache/AuthenNTLM.pm line 29. BEGIN failed--compilation aborted at /opt/perl5.8/lib/site_perl/5.8.0/PA-RISC1.1/Apache/AuthenNTLM.pm line 29. Compilation failed in require at (eval 5) line 3. I'm not sure I'm following your setup - is the mod_perl you're trying to use here compiled under Perl 5.6.1? And Apache::AuthenNTLM was compiled under Perl 5.8.0? That combination probably won't work in principle, as 5.6.1 and 5.8.0 are binary incompatible. If you're tied to mod_perl compiled under 5.6.1, try compiling and using an Apache::AuthenNTLM compiled under 5.6.1. Thanks, Randy! (I just woke up in the middle of the night with the same answer :)) ) Yes, use the perl binary that points to 5.6.1 when you run /path/to/perl5.6.1 Makefile.PL. (Running the rest of the install as normal, of course ;) ) This will place the module in the appropriate location for your mod_perl, that apache is using, to find it. speeves cws
Re: Apache::Session
Hi I might be missing the point but if you already are tracking with Apache::Session why not encrypt the session id before giving it to the user in the first place. You could store a public 'key' for the encryption in a cookie on the users machine. That way only that user can give you the right info to decode the session. If this sounds reasonable, you may want to check out Paul DuBois book MySQL and Perl for the Web ISBN 0-7357-1054-6. He outlines a method to encrypt the apache::session id. Mike - Original Message - From: Aleksandr Guidrevitch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: August 14, 2003 6:54 AM Subject: Apache::Session Hi, All Sorry, this post might be out of scope of this particular list, but still... don't punch me heavily :) I just think the people here might have met this problem while deploying big public applications. I use Apache::Session to identify logged in users. However, the users are allowed to post html (obviously with javascript) messages viewable by others. That could create an XSS vulnerability and allow to steal the sessions (cookies) from other users. Is it possible to uniquely identify the user by some attributes ? The only thing I consider now is IP, but what about proxies and NATs ? User Agent string could also be stolen via javascript. That means I tend to make stolen session ids non-reusable. Any thoughts ? Sincerely, Aleksandr Guidrevitch
Re: Apache::Session
Aleksandr, we had our own stripping methods. Just get the source for slashcode http://slashcode.com and look for Slash/Display/Display.pm: strip_paramattr = \strip_paramattr, Slash/Display/Display.pm: strip_urlattr = \strip_urlattr, Slash/Display/Display.pm: strip_anchor= \strip_anchor, Slash/Display/Display.pm: strip_attribute = \strip_attribute, Slash/Display/Display.pm: strip_code = \strip_code, Slash/Display/Display.pm: strip_extrans = \strip_extrans, Slash/Display/Display.pm: strip_html = \strip_html, Slash/Display/Display.pm: strip_literal = \strip_literal, Slash/Display/Display.pm: strip_nohtml= \strip_nohtml, Slash/Display/Display.pm: strip_notags= \strip_notags, Slash/Display/Display.pm: strip_plaintext = \strip_plaintext, and this'll give you an idea of what slashcode does to deal with it. Hope this helps, Patrick Aleksandr Guidrevitch wrote: Hi, All What have you used to stip out that stuff ? I've reviewied HTML::StripScripts, but it seems to be very slow. I've also considered HTML::Filter to do that but I'm also affraid that HTML::Parser is not the fastest thing on the earth, even though it will be invoked once during initial submission. Could you also advise on this safe subset of html you use ? Sincerely, Alex Patrick Galbraith wrote: Strip out stuff that could be problematic. This is what we did with Slash. We strip out javascript or any tag that can be problematic, or be used even to break the layout of the page. It'll make you're life much easier ;) Take this from someone who coded tons of features to ward off trolls! -- -- Patrick Galbraith Senior Software Developer [EMAIL PROTECTED] [EMAIL PROTECTED] 206.719.2461
Re: Problem reloading modules
On Thu, 2003-08-14 at 14:04, Jean-Sebastien Guay wrote: Try doing a fully-qualified sub call instead of importing. Err, that would actually be a pretty massive change to my codebase. Changing all the somesub calls to Hybride::Module::somesub would be a pain, not to mention too much typing. There has to be another solution, isn't there? I'm asking you to try it and see if it works. A possible solution if that is the problem is to make all the modules that import it reload as well. You can do that with a touch file. - Perrin
Re: Problem reloading modules
Perrin, use Hybride::Projects qw(getImage other imports); I think that's the problem. You are creating an alias to the sub here, and when it gets reloaded the alias is still pointing to an old version. Actually, I just saw that the sub is exported in the EXPORT section of the Projects module, not the EXPORT_OK section, and is imported with use Hybride::Projects; Sorry about that, my mistake... But the sub is still not getting reloaded. Try doing a fully-qualified sub call instead of importing. Err, that would actually be a pretty massive change to my codebase. Changing all the somesub calls to Hybride::Module::somesub would be a pain, not to mention too much typing. There has to be another solution, isn't there? Thanks, J-S
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
Bill Marrs wrote: Please report to the list the bug id so we can document this issue for those who have the same problem with older httpds. Thanks. OK, I've posted it. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22259 Thanks for the fix! For the archives: This bug has been fixed in the current httpd-2.0 cvs, and will be also in the soon to be released 2.0.48. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problem reloading modules
On Thu, 2003-08-14 at 13:41, Jean-Sebastien Guay wrote: Is there anything unusual about the way you call this sub (AUTOLOAD, function ref, etc.)? Not at all. It is imported with use Hybride::Projects qw(getImage other imports); I think that's the problem. You are creating an alias to the sub here, and when it gets reloaded the alias is still pointing to an old version. Try doing a fully-qualified sub call instead of importing. - Perrin
Re: Apache::Session
Hi, All What have you used to stip out that stuff ? I've reviewied HTML::StripScripts, but it seems to be very slow. I've also considered HTML::Filter to do that but I'm also affraid that HTML::Parser is not the fastest thing on the earth, even though it will be invoked once during initial submission. Could you also advise on this safe subset of html you use ? Sincerely, Alex Patrick Galbraith wrote: Strip out stuff that could be problematic. This is what we did with Slash. We strip out javascript or any tag that can be problematic, or be used even to break the layout of the page. It'll make you're life much easier ;) Take this from someone who coded tons of features to ward off trolls!
Re: [mp2] Child process exited
I said, in my last message: I'll try removing modules from my startup.pl as Randy Kobes suggested, see if that changes anything. It doesn't. I removed Apache::Reload from my httpd.conf, and put an empty startup.pl instead of my real one (this one just returns 1; nothing else) and it still crashes. J-S ___ Jean-Sébastien Guay [EMAIL PROTECTED] Software Developer, Hybride http://www.hybride.com Piedmont, Québec, Canada
Problem reloading modules
Hello, I know this has been discussed before, but I can't seem to find the information I need to solve my problem. I'm using Apache::Reload, and I can see that my modified module is getting reloaded (with ReloadDebug On), but the program still uses the old code. I have read http://perl.apache.org/docs/2.0/api/Apache/Reload.html#Problems_With_Reloading_Modules_Which_Do_Not_Declare_Their_Package_Name but all my modules declare their package names. I have also checked, using the perl-status Apache module, and all my modules are in %INC with absolute paths, not relative ones. I have also checked, and nothing in http://perl.apache.org/docs/1.0/guide/porting.html#Using_Apache__Reload seems to resolve the problem. What else should I check? Thanks in advance, J-S ___ Jean-Sébastien Guay [EMAIL PROTECTED] Software Developer, Hybride http://www.hybride.com Piedmont, Québec, Canada
Re: [mp2] Child process exited
Steve, I found that almost whatever I removed from the template -- not just the nobr tag -- fixed it, and I began to wonder about the *size* of the template. That's what I was wondering too when I reported that just adding 3 line breaks somewhere in the file broke it, and removing them fixed it. I would never have thought that such a small template would break based on size, though, since I have much larger templates in production using normal CGI, which work fine. (the largest template is ~20k and the average is ~6k). Again, I'll have to remind myself to never assume... I kept on telling myself, Nah, it can't be the size of the template file Thanks a lot for your troubleshooting, Steve. So a temporary fix would appear to be to not use the INTERPOLATE option if you can manage without it. Good call, that's what I'll do for now. Most of my templates don't need it. I'll start with that. I might have to leave it to Randy for a fuller explanation of where the 612 bytes limit is creeping in. Looking forward to that. J-S ___ Jean-Sébastien Guay [EMAIL PROTECTED] Software Developer, Hybride http://www.hybride.com Piedmont, Québec, Canada
Re: unsetting PerlTransHandler
Frank Maas wrote: On Thu, Aug 14, 2003 at 11:07:13AM -0400, Geoffrey Young wrote: There is actually a Location/LocationMatch sequence performed just before the name translation phase (where Aliases and DocumentRoots are used to map URLs to filenames). The results of this sequence are completely thrown away after the translation has completed. which is what you found in the code - note the completely thrown away part. in essence, this means that the results of the Location config merging are discarded prior to translation, after which Location merging is done again. Ehm... considering both solutions worked and the quoted paragraph, shouldn't we read it as 'the results of this sequence can be used during the translation phase, but are thrown away after the translation has completed'. This would mean that the results are not discarded prior to translation, but after translation and that would also explain why the two solutions work... well, they can only be used during translation if the URI is unaltered. for instance, given the example we've seen already PerlTransHandler MyPackage::transhandler Location ... PerlHandler MyPackage::handler /Location checking get_handlers() in transhandler() only works because the initial merge (which is thrown away) ends up being the same merge as after translation. if any (other) trans handlers meddle with $r-uri (which is perfectly valid) then the initial get_handlers() call will report settings completely different than the end Location that is finally applied to the URL. so, I guess Location-specific settings can be used during translation, much in the same way that you can break encapsulation in Perl by simply accessing the object via its underlying hash - the feature works currently due to the way things are implemented, but using it is not guaranteed to work in the future (apache 2.0?), and may have unintended consequences in the present. in other words, it's a bad idea and people who know better certainly don't rely on it. --Geoff
Re: Problem reloading modules
On Thu, 2003-08-14 at 11:43, Jean-Sebastien Guay wrote: And I can see in the error_log that $image is still the absolute path (D:/htdocs/images/project/prefix/bob.jpg in our example) even after the change. I don't see anything wrong with that chunk of code. If you restart the server, does it pick up the change? Is there anything unusual about the way you call this sub (AUTOLOAD, function ref, etc.)? Reloading modules is not foolproof. Perl doesn't actually support it, so things like Apache::Reload fake it by removing the module from %INC and making it get compiled again. This usually works for things in the symbol table, but people have reported problems in the past with things that keep references to lexicals (closures) and other somewhat magical features. However, your code here looks pretty vanilla and seems like it should be working fine with Reload. - Perrin
Re: [mp2] Child process exited
Jean-Sebastien Guay wrote: Stas, I just checked, and when the Apache crash occurs, nothing gets written to access_log. It would seem that the crash happens before the request is logged. That's possible, but at least you can see that it's not IE that generates some followup request that causes the crash, but the original one. Now you need to get the crash backtrace. You probably need to start the server under debugger and get the backtrace from there. (don't ask me how to do that on win32 ;) b) why my warnings don't show up in the error_log. I just moved my mod_perl config from httpd.conf to another file, mod_perl.conf, and Include that in httpd.conf. (I did that so that I don't have to comment the whole section for mod_perl when I want to deactivate it, I just have to comment the Include line). Now, magically, the warnings and the Apache::Reload debug messages show up in my error_log! The only other thing I changed between now and before is that I added the PerlSwitches -Id:/htdocs directive. But that should have no influence on whether warnings are written to the error_log or not... What's happening? Is my whole Apache setup whacked? Maybe I should reinstall Apache and mod_perl? I can't tell, may be you have cleaned up some things on the way. e.g. you could do something that would cause the logs to be written into a different log file. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
request for help with reproducing problem
Recently I have found myself spending most of the time trying to reproduce reported bugs (and non-bugs), instead of resolving the already known bugs. Often times it takes a long time and multiple emails to get all the required information from the user reporting the problem to be able to reproduce the problem or to prove it to be a problem in the user code, and many times I can't reproduce problems on linux and my guess-work is not always successful. It'd be very helpful if folks gave us help to reproduce problems, so we can concentrate on fixing them. You don't have to understand mod_perl internals or to know C to reproduce problems. Just read the report, see if you can reproduce it, ask the person about the missing details (mostly listed here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems) and see if you can help the reporter to get a better bug report. The preferred way to help developers reproduce problems is to write a new test (or modify an existing test) for the mod_perl test suite, which when you run fails. or at least write a simple very short script/handler that can be converted into a test. But you really want to learn how to write tests with Apache::Test if you do any serious mod_perl development, so there is no excuse not to learn Apache::Test, not talking about the fact that there are hundreds of existing tests as examples, the tutorial http://perl.apache.org/docs/general/testing/testing.html and the slowly growing manpages. If you have any questions don't hesitate to ask here or on the test-dev list. Also please notice that some bug reports are posted to the dev list http://perl.apache.org/maillist/dev.html so monitoring both lists is a good idea. Thanks for your help. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: HTTP POST: parameters empty when using ModPerl::Registry(okay when using ModPerl:PerlRun)...
Perrin,
Thanks for your response...my replies below:
--
Steve Bannerman
[EMAIL PROTECTED]
44.(0)1865.273866
-Original Message-
From: Perrin Harkins [mailto:[EMAIL PROTECTED]
Sent: 06 August 2003 20:40
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: HTTP POST: parameters empty when using
ModPerl::Registry(okay when using ModPerl:PerlRun)...
...snip...
I believe I see the source of your troubles in the code that you
posted. You are creating a closure by using a lexical variable and then
accessing it from within a sub. This is a no-no with any long-running
system like mod_perl. You can get away with it in a standard CGI
environment (or PerlRun) because it just exits after each request
instead of running the same code again.
Here is the offending section:
my $cgi = new CGI;
saveFile();
sub saveFile {
my $inputfile = $cgi-param('file');
... etc ...
}
Change it to this:
my $cgi = new CGI;
saveFile($cgi);
sub saveFile {
my $cgi = shift;
my $inputfile = $cgi-param('file');
... etc ...
}
I think that will do it.
You're correct...that made it work.
So with respect to your explanation about the long running perl system, am
I to understand that the old version of the saveFile() subroutine uses a
reference to a different $cgi instance that the $cgi instance in the main
body of the script?
As I said, I'm new to perl but that seems to be an awfully strange behavior
of the language...if true, shouldn't the compilation (of the subroutine)
fail because it references an undeclared variable ($cgi)?
Cheers
- Perrin
Re: rflush() not working as documented?
On Wed, Aug 06, 2003 at 07:33:49AM -0700, Stas Bekman wrote:
Martin Wickman wrote:
[...]
oops, sorry. Can you try with the latest cvs?
Not at the moment. But I'll try in a few days.
Your particular problem report was fine, what you have missed is the output
of t/REPORT which tells us things about your environment. I can't see it
here
http://marc.theaimsgroup.com/?l=apache-modperlm=105968263417468w=2
Sorry, my deb package dont have the t/ stuff.
[...]
In any case, have you tried using the snooping filter I was talking about
in my previous reply? It shows you exactly what's going on inside.
It confirms my problems. Here is output:
connection output filter
o bucket 1: FLUSH []
connection output filter
o bucket 1: FLUSH []
connection output filter
o bucket 1: FLUSH []
connection output filter
o bucket 1: TRANSIENT
[htmlhead TITLE /headbody BODY/html]
And here is the code that generates this:
sub handler {
my $r = shift;
$r-content_type('text/html');
$r-print (htmlhead TITLE /head);
$r-rflush();
$r-print (bo);
$r-rflush();
$r-print (dy BODY);
$r-rflush();
$r-print (/html);
return Apache::OK;
}
1;
For the record, I am able to cut up a stream nicely using mod_cutup
[1]. This results in something like:
connection output filter
o bucket 1: TRANSIENT
[htmlfoo]
o bucket 2: TRANSIENT
[headbody]
o bucket 3: TRANSIENT
[
!-- sd]
o bucket 4: TRANSIENT
[sd --
[...]
Which at least proves that the snoop filter is working as expected :-)
Anyway, I'll try with the latest mod_perl version as soon as time
allows and post my results later.
[1] http://projects.standblue.net/markive/message.moto?list=apachemodulesID=771
Re[2]: Multiple select
Perrin Harkins On Tue, 2003-08-05 at 12:34, Alan Rafagudinov wrote: Hello! I have the next html code: select name=sel_name multiple option Smth_1 ... option Smth_n /select User is able to select many values in the list, how can I get all of them in my mod_perl script? Perrin Harkins Use Apache::Request or CGI.pm. Please small example of using Apache::Request. $r-content; $r = Apache-request; does not work :-(
Re: Problem reloading modules
I'm asking you to try it and see if it works. Ok, I tried it and it works. A possible solution if that is the problem is to make all the modules that import it reload as well. You can do that with a touch file. The file that imports it is not a module, it's the actual script. No other file (that is running currently) needs that sub. Can I get Apache::Reload to reload the script itself? Thanks for your help, J-S
Re: help on setting up a PerlFixupHandler
Xavier Noria wrote:
[EMAIL PROTECTED] wrote:
It seems to me that $r-content-type is for what your server sends to the
client, which is probably undef in the Fixup stage, where you test it.
You probaly meant to test for the
$ct = $r-header_in(Content-type)
if you wanted to see whats requested from the client.
Content-Type is an entity header, so it can apply to both incoming and
outgoing headers. however, it's more generally seen as an outgoing header
for normal web activity, leaving headers_in empty.
But then, there are examples in the books that use that method that way.
For instance, in recipe 14.1 of the Cookbook, which is about how to
disable a configured mod_perl PerlHandler, the Technique section says:
Set the handler back to the default Apache content handler from a
PerlFixupHandler.
# Only run the PerlHandler for HTML.
# For everything else, run the default Apache content handler.
$r-handler('default-handler') unless $r-content_type eq 'text/html';
I think in the Eagle book there is some code like that as well, cannot
check it right now however.
So, looks like that test makes sense, or can make sense, in that handler.
$r-content_type is generally set by mod_mime, during the mime-type phase,
according to it's rules. for most setups, it should be set to something by
fixup, but I guess it's dependent on your particular settings.
--Geoff
Re: $r-headers_out Location and Set-Cookie
gerard uolaquetalestem [EMAIL PROTECTED] writes: [...] But exactly what's the difference between err_headers_out and headers_out? I understand that the first is related with an error message sended by headers, but i mean, really what does apache make different? Here's a straightforward explanation of the difference- http://ken.coar.org/burrow/index?month=2003-07#511 -- Joe Schaefer
How to pass parameters from the UNIX command line ?
Dear List, It seems a silly one, anyway I'm somewhat confused about how to pass parameters from the UNIX command line: Suppose I have my working PERL script and passed parameter on an URL as: http://server.domain.com/cgi-bin/MyProcedure.pl?cust_id=x I'd like to make a cron job to source the above PERL script as from the command line to resemble something like: perl /usr/local/apache/cgi-bin/MyProcedure.plneed to pass the parameter here as cust_id=x How can I tell the procedure to consider cust_id=x as it's input ? Many thanks indeed for your patiente. Fabian.
RE: HTTP POST: parameters empty when usingModPerl::Registry(okay when using ModPerl:PerlRun)...
Perrin, Thanks...your explanation makes sense. I was thinking of the subroutine as a method on a class and that the objects in the class had a cgi instance associated with them. I was thinking in the object paradigm rather than in the procedural paradigm. Cheers -- Steve Bannerman [EMAIL PROTECTED] 44.(0)1865.273866 -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED] Sent: 07 August 2003 19:10 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: HTTP POST: parameters empty when usingModPerl::Registry(okay when using ModPerl:PerlRun)... On Thu, 2003-08-07 at 03:36, Steve Bannerman wrote: So with respect to your explanation about the long running perl system, am I to understand that the old version of the saveFile() subroutine uses a reference to a different $cgi instance that the $cgi instance in the main body of the script? It uses a reference to the $cgi variable that was in scope when saveFile() was compiled. As I said, I'm new to perl but that seems to be an awfully strange behavior of the language...if true, shouldn't the compilation (of the subroutine) fail because it references an undeclared variable ($cgi)? But it doesn't reference an undeclared variable; it references the original $cgi that was available when the sub was compiled. Closures are a feature of Perl. You can read about them in general in perlfaq7 and the perlref man page: http://www.perldoc.com/perl5.8.0/pod/perlfaq7.html#What's-a-closure- http://www.perldoc.com/perl5.8.0/pod/perlref.html Note that those both talk a lot about anonymous subs, but any sub can be a closure if it refers to a lexical variable defined in an enclosing scope. There is some mod_perl specific stuff on this here: http://perl.apache.org/docs/general/perl_reference/perl_reference. html#my___Scoped_Variable_in_Nested_Subroutines If you had warnings on, you would have received a message about $cgi not staying shared. In brief terms, what happens is that your program creates a lexical called $cgi, then saveFile() refers to it, locking in that variable as the $cgi that will always be referenced by saveFile(). At the end of the script $cgi goes out of scope and disappears, but saveFile() keeps referencing it. In a CGI program this is not a problem, because Perl exits and the process quits. In mod_perl, the code gets run again and saveFile() still refers to the original $cgi. There are a number of ways to solve this problem, but I prefer the one I showed you. Explicitly passing all arguments to subs is well established as a best practice in programming. What you were doing with $cgi before is basically treating it as a global. So, I'd suggest you turn on warnings, turn on strict, and embrace the good practice of passing variables to your subs. - Perrin
Mod_perl how to include the result of mod_autoindex?
I am writing a mod_perl script using CGI.pm and Apache 1.3.28/Linux. I am trying to figure out how to use Apache's mod_autoindex to display a directories contents within the output the CGI. Apache is configured correctly, I am not asking for Apache help. The end user will submit a form. One of the values in that form will be a path on the local web server. So in the return of the CGI, I want to include the results of Apache's autoindex. I cannot figure out how to do it. If I could pass a variable from a CGI to an SSI, the problem would be solved, but I do not believe that it is possible. I have been looking at Apache::SSI and Apache::AutoIndex but I don't think I can get them to do what I need. Does anyone have any suggestions or recommendations? Anything will be much appreciated. Thanks, Matt __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Apache::Reload and INC path partialy working
Ugh! Not use to lists that reply to author. Okay to resay what I sent to Geoffrey. using the -I switch in the config file works, unlike the PerlSetEnv PERL5LIBGeoffrey Young [EMAIL PROTECTED] wrote: Here's my perl.conf (sourced by httpd.conf) start LoadModule perl_module modules/mod_perl.so PerlSetEnv PERL5LIB /home/bruce/public_html/ffball/myffon second thought, tryPerlSwitches -I/home/bruce/public_html/ffball/myfforPerlSwitches -Mlib=/home/bruce/public_html/ffball/myffinstead of PERL5LIB--Geoffwww.bluewolverine.com Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: rflush() not working as documented?
Stas Bekman wrote: Geoffrey Young wrote: Martin Wickman wrote: Martin Wickman wrote: According to docs[1], $r-rflush() should create a new brigade with data. It does not. I've seen this also, but was never able to isolate a cause. rflush() works fine, it's possible that the issue with the streaming filter or some other upstream filter that ignores the flush buckets. I doubt that, no other external filter is in use. Are you using the latest mod_perl 2.0? Nope. I am using 1.99_07. (Btw, that information _was_ included in my report, but you trimmed it away:) This is with: Apache/2.0.47 (Debian GNU/Linux) mod_perl/1.99_07-dev Perl/v5.8.0 It's much appreciated when bug reports are written using the following guidelines: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems Pardon me, but I do believe I supplied enough and accurate information -- including relevant, trimmed code snippets and excerpts from apache logs in my report. Except from the fact that I did not build mod_perl myself, I can't really see what I missed to include? Martin, please check the mod_perl 2.0 test suite, it has plenty of examples where it used exactly for the reason you've described. Ok, thanks I'll check it out. I'm guessing that my mod_perl is too old, I like to stay with the prebuilt packages (debian) if possible. But if needed, I'll build the latest version and test it. Just thought that someone would know, thats all.
Re: How to restart the root server from within modperl?
On Tue, Aug 12, 2003 at 11:50:01AM +0200, Dirk Lutzebaeck wrote: Dennis Stout writes: On a whim, I would try writing a second script to do the actual shutdown and restart of Apache. Then have your mod_perl program either run it in the background (with a ) or fork it into another process. Did exactly that but is has the effect that when the parent (root) apache is killed it kills all children including the script itself. So the server wont start again. Since you are talking about a management tool via http, you might consider using a second server process for this. If you select the 'restart link' then under water you need to (a) startup a server on a different port, (b) redirect to a URI on that server, (c) make it that that URI restarts the main server as you would normally do, (d) clean up the second server as soon as the main server restarts. You can do this in a sophisticated manner by creating a httpd config on the fly, using a unique restart-URI, thus avoiding the most obvious security risks. Might work... --Frank
Re: Problem reloading modules
On Thu, 2003-08-14 at 14:29, Jean-Sebastien Guay wrote: I'm asking you to try it and see if it works. Ok, I tried it and it works. I guess we need to add this to the docs: Apache::Reload will have problems if you import subs from a module you are trying to reload. The file that imports it is not a module, it's the actual script. Apache::Registry? Just do a touch on the script file and Registry will reload it. You could hack your own Apache::RegistryNG subclass that would just reload everything when Apache::Reload triggers, but it's probably not worth it. - Perrin
Re: help on setting up a PerlFixupHandler
sub handler {
my $r = shift;
return DECLINED if $r-content_type ne 'text/html';
return SERVER_ERROR unless $r-can_stack_handlers;
$r-set_handlers(PerlHandler = ['ContentHandler']);
return OK;
}
What am I missing?
unlike the other phases of the request cycle, for the content phase you need
to do two things - tell apache that mod_perl is in charge, and tell mod_perl
which Perl handler it should use. you've done the latter. for the former,
use $r-handler('perl-script'), which is analogous to SetHandler perl-script
that you would ordinarily see for a mod_perl setup.
HTH
--Geoff
Re: Threading issue in 5.6 and 5.8
Ged Haywood wrote: 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 I doubt this has anything to do with threads, because they are serialized in mod_perl 1.0 on windows. Do you use mod_perl 2.0? Most likely your problem is the usual one: global variables persist under mod_perl and you have to reset them before using. For more information see: http://perl.apache.org/docs/1.0/guide/porting.html#Global_Variables_Persistence In any case when reporting problems you should at least copy-n-paste the exact error. And follow the guidelines: mp1: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems mp2: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems Sorry I know prcatically nothing about running Apache on Windows. Seems strange to me that anyone would do it... :) This is correct for mod_perl 1.0, because threads are serialized to make things thread-safe. But this is no longer valid for mod_perl 2.0. mod_perl 2.0 on windows should be as good as on any other system. 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. This is correct only for several RedHat linux versions. it should be fixed in RH9.1: http://archive.develooper.com/[EMAIL PROTECTED]/msg97360.html 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. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: help on setting up a PerlFixupHandler
On Wednesday 06 August 2003 20:26, Christopher Grau wrote: On Wed, Aug 06, 2003 at 08:24:30PM +0200, Xavier Noria wrote: To fix that, is it safe to change the test to defined $r-content_type and $r-content_type ne 'text/html'; or is there a better way? I usually don't concern myself with the previous content type when writing Location-based content handlers. My output is always text/html anyway. Would it be safe in your application to just leave it out completely? Hmmm, you are right, now that I think about it /admin will only serve HTML and since I don't understand that undef I'll remove that line altogether, the test is performed by Location anyway. Now that I understand what happens I will try to figure out in the docs when $r-content_type returns something. Thank you very much to all, I was somewhat stuck with this. -- fxn
Re: Q: How do I upgrade Perl w/mod_perl?
Tim Howell wrote: I'm currently using mod_perl 1.2.7 with Perl 5.8.0. If I want to test Perl 5.8.1 RC4, how do I recompile Perl and mod_perl without having to make other changes? Is there a simple way to do this upgrade? http://perl.apache.org/docs/1.0/guide/install.html#Should_I_Rebuild_mod_perl_if_I_have_Upgraded_Perl_ You have to rebuild perl, and then mod_perl, the same way you build them in first place, it's relatively simply. If mod_perl 1.0 is already installed, just running 'perl Makefile.PL' should pick the previously used configuration directives, by internally using Apache::MyConfig. If you use an RPM based system, you may find available RPMs: http://www.rpmfind.net/linux/rpm2html/search.php?query=mod_perlsubmit=Search+... http://www.rpmfind.net/linux/rpm2html/search.php?query=perlsubmit=Search+...system=arch= Though I'd suggest to download src.rpm of each and rebuild them locally. Notice that these packages may have a long pre-requisite list. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problem reloading modules
Perrin Harkins wrote: On Thu, 2003-08-14 at 14:29, Jean-Sebastien Guay wrote: I'm asking you to try it and see if it works. Ok, I tried it and it works. I guess we need to add this to the docs: Apache::Reload will have problems if you import subs from a module you are trying to reload. The problem is described here (and one of the solutions is to touch the file as Perrin has mentioned the other is covered in that URL) http://marc.theaimsgroup.com/?l=apache-modperlm=105330639304103w=2 I think I have planned to add this to the docs, but didn't get to it yet, I'll try to do that shortly. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: rflush() not working as documented?
On Thu, Aug 07, 2003 at 04:46:51PM -0700, Stas Bekman wrote: Please try the latest mp2 cvs, I've added a new test t/api/rflush.t, it tests rflush explicitly (even though it's already used for exactly this purpose in several other tests). [...] does it work for you? I tried the latest CVS (modperl-2.0_20030810101543) and my code now works as expected, ie rflush() splits correctly into brigades. The t/api/rflush.t works as well btw. Excellent! Is it any different from your code? Your test-code is essentially the same as my code. I guess my modperl version had a broken rflush() implementation. /Thank you!
Re: rflush() not working as documented?
Martin Wickman wrote: Stas Bekman wrote: Geoffrey Young wrote: Martin Wickman wrote: Martin Wickman wrote: According to docs[1], $r-rflush() should create a new brigade with data. It does not. I've seen this also, but was never able to isolate a cause. rflush() works fine, it's possible that the issue with the streaming filter or some other upstream filter that ignores the flush buckets. I doubt that, no other external filter is in use. Are you using the latest mod_perl 2.0? Nope. I am using 1.99_07. (Btw, that information _was_ included in my report, but you trimmed it away:) oops, sorry. Can you try with the latest cvs? This is with: Apache/2.0.47 (Debian GNU/Linux) mod_perl/1.99_07-dev Perl/v5.8.0 It's much appreciated when bug reports are written using the following guidelines: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems Pardon me, but I do believe I supplied enough and accurate information -- including relevant, trimmed code snippets and excerpts from apache logs in my report. Except from the fact that I did not build mod_perl myself, I can't really see what I missed to include? Your particular problem report was fine, what you have missed is the output of t/REPORT which tells us things about your environment. I can't see it here http://marc.theaimsgroup.com/?l=apache-modperlm=105968263417468w=2 Martin, please check the mod_perl 2.0 test suite, it has plenty of examples where it used exactly for the reason you've described. Ok, thanks I'll check it out. I'm guessing that my mod_perl is too old, I like to stay with the prebuilt packages (debian) if possible. But if needed, I'll build the latest version and test it. Just thought that someone would know, thats all. Sure, we just need to know your build env so we can try to reproduce the problem with a similar one. In any case, have you tried using the snooping filter I was talking about in my previous reply? It shows you exactly what's going on inside. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: PerlModule options?
Hi again Stas Perrin, So, its a no-can-do then. I'll keep putting the use in every module to import the symbols in the proper namespace. Alternatively I guess I could probably use the functions with fully qualfied name Apache::ReadConfig::myFunction(), however this would add extra typing and this is exactly what I was trying to escape from. Thanks everyone for your time and kind answers. Cheers, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 7:08 PM To: Mike P. Mikhailov Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: PerlModule options? Mike P. Mikhailov wrote: Hello [EMAIL PROTECTED], Tuesday, August 05, 2003, 2:55:52 PM, you wrote: cfr Hi list, cfr One questions for the braves ;-) cfr As I understand, the directive cfr PerlModule Foo::Bar cfr loads the module but doesn't import the symbols since it is equivalent to cfr the use Foo::Bar (). Therefore I should use use Foo::Bar in each program cfr only to make the import. cfr Is there other way to load the module and import the symobols specified in cfr @EXPORT at mod_perl reloading time, without adding a special line in each cfr and every script using them? cfr Perhaps some options passed to PerlModule though adding (...) doesn't help cfr since PerlModule expects a list of modules. I think this will work perl use Foo::Bar qw ( ... whatever you want to import ... ); /perl I think Lian was asking how to import symbols into his scripts/handlers at the server startup. Lian, you *must* put the special line in each and every script you want the symbols to be exported to, because exporting happens inside the script's namespace, which is no main:: under Apache::Registry, but special for each script. You can preload registry scripts using Apache::RegistryLoader, but this doesn't remove the need for an explicit import. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: PerlModule options?
Mike P. Mikhailov wrote: Hello [EMAIL PROTECTED], Tuesday, August 05, 2003, 2:55:52 PM, you wrote: cfr Hi list, cfr One questions for the braves ;-) cfr As I understand, the directive cfr PerlModule Foo::Bar cfr loads the module but doesn't import the symbols since it is equivalent to cfr the use Foo::Bar (). Therefore I should use use Foo::Bar in each program cfr only to make the import. cfr Is there other way to load the module and import the symobols specified in cfr @EXPORT at mod_perl reloading time, without adding a special line in each cfr and every script using them? cfr Perhaps some options passed to PerlModule though adding (...) doesn't help cfr since PerlModule expects a list of modules. I think this will work perl use Foo::Bar qw ( ... whatever you want to import ... ); /perl I think Lian was asking how to import symbols into his scripts/handlers at the server startup. Lian, you *must* put the special line in each and every script you want the symbols to be exported to, because exporting happens inside the script's namespace, which is no main:: under Apache::Registry, but special for each script. You can preload registry scripts using Apache::RegistryLoader, but this doesn't remove the need for an explicit import. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [Slightly OT] Port forwarding (Was: How to restart the rootserverfrom within modperl?)
When moving a server from MN to VA I used port forwarding to make the
transition totally seamless. This includes DNS.
I wanted to make sure all my services worked in both places, and I didn't
want to have split systems. That would have been a nightmare for services
like e-mail where a message to one server and the user getting mail from
the other server would have been possible.
I used xinetd and it's built in port forwarding capabilities to migrate
one service at a time from MN to VA. Once the service was running in VA,
I'd disable the service on the MN server and forward all traffic to VA.
Went through each service (email, pop, imap, http, etc. etc. etc.) that I
had active this way. Finally, the only thing running in MN was xinetd on
all my active service ports.
Worked beautifully. Users never knew about the server relocation and
absolutely no disruption to services or missed/interrupted mail. Just the
way I like things.
Greg
On Wed, 13 Aug 2003, Craig Edwards wrote:
Hi,
I once saw an example of port forwarding using netcat and inetd, i think it involved
setting up a listening netcat as the application, using inetd to bind it to a
specific port and then forwarding the connection onwards to the ip and/or port where
you want it to go, something like this:
service geofwd
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/bin/nc
server_args = 192.168.124.38 1005
log_on_failure += USERID
}
not sure if this is what you want :-)
Craig
Hello,
MLIf you absolutely need to be in port 80, either setup a simple
MLlightweight apache on port 80 as a reverse proxy (see the mod_perl
MLguide) or, even simpler, do some port forwarding from port 80 to your
MLhigh port of choice.
Has anybody had very good experiences using a simple port forwarder in a
production setup? We had a somewhat bad experience with using portfwd
under Solaris (images and other binary data got randomly corrupted, and we
never got around to figuring out why), and I'm wondering what others use
instead. It seems like the port forwarder involved would also be important
performance wise.
The applications I am typically interested in are forwarding ports on the
same interface (like the port 80 example here) as well as between
interfaces (or between external interfaces and loopback).
Humbly,
Andrew
--
Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED]
Engineer1-800-555-TELL Voice 650-930-9062
Tellme Networks, Inc. Fax 650-930-9101
--
Re: [mp2] Child process exited
Jean-Sebastien Guay wrote:
Steve,
and the good news for you is that I've reproduced your problem.
GREAT! Thank you so much for persevering through this! So do you have a
traceback or some info that the developers might be able to use to track
this down?
Not sure how to get a stack backtrace on Windows. I don't even get the
Application Error popup window with a Debug button inviting me to have
go :-(
However, I have massively simplified the test program that reproduces
the problem.
I've moved the template itself in-core rather than processing an
external file and removed everything else that I could without the
problem going away. I found that almost whatever I removed from the
template -- not just the nobr tag -- fixed it, and I began to wonder
about the *size* of the template.
So then I replaced the HTML page content with loads of dots, and sure
enough, the problem goes away if you reduce the number of dots
sufficiently. It seems that the program breaks if the template size is
612 bytes, and works if it is = 612 bytes! (Try changing $size from
613 to 612 in getTemplate() to fix it!)
Template-Toolkit's Template::Manual::Config manpage says that Perl will
segfault using the INTERPOLATE option with templates 32 kB due to
limitations in Perl's regex engine, and sure enough another way to fix
the attached program is to change INTERPOLATE = 1 to INTERPOLATE = 0.
I don't know where the 612 byte limit comes from, but it's certainly not
Perl itself that has such a small limit -- the program runs fine in CGI
and mod_perl 1 environments with $size set way higher than 32 kB on my
machine.
So a temporary fix would appear to be to not use the INTERPOLATE option
if you can manage without it.
I might have to leave it to Randy for a fuller explanation of where the
612 bytes limit is creeping in.
Steve
#!perl
use strict;
use warnings;
use Template;
MAIN: {
print qq[Content-Type: text/html\n\n];
processTemplate();
}
sub processTemplate {
my $template = Template-new({ INTERPOLATE = 1 });
my $t_text = getTemplate();
$template-process($t_text)
or die(Error processing template: . $template-error());
}
sub getTemplate {
my $size = 612;
my $header = 'htmlbody';
my $footer = '/body/html';
my $centre = '.' x ($size - length($header) - length($footer));
my $t_text = $header . $centre . $footer;
return \$t_text;
}
RE: ModPerl - CGI in the same request phase
Hi, I'm in the happy position of finding myself a solution to my problem. Here it is for anyone interested ... PerlModule MyModules::Module1 Directory /usr/local/apache1/protected SetHandler perl-script PerlHandler MyModules::Module1 PerlSendHeader Off /Directory PerlModule Apache::PerlRun Directory /usr/local/apache1/protected/admin/ SetHandler perl-script PerlHandler MyModules::Module1 Apache::PerlRun Options +ExecCGI /Directory And then, inside my handler, when I decide the users are alowed to run scripts from the /admin directory I let them through by returning DECLINE, if not I print an error page and return DONE to skip the second handler in this phase. Thanks anyway, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 2:33 PM To: [EMAIL PROTECTED] Subject: ModPerl - CGI in the same request phase Hi again everybody, I have the following interesting (I hope ;-) requirement. Sorry for this rather long posting. (mod_perl 1, Apache 1.3.27) I have a custom authentication authorization handler of mine which is the king in a protected directory (and its subdirectories): PerlModule MyModules::Module1 Directory /usr/local/apache1/protected SetHandler perl-script PerlHandler MyModules::Module1 PerlSendHeader Off /Directory Then, for some users that I authenticate as SuperUsers, I should allow the execution of the administrative .cgi scripts in a subdir of this dir(/usr/local/apache1/ssl/protected/admin). (One solution would be to integrate the cgi-s logic into my handler but let's say want to leave them as simple CGI scripts.) I tried to use the Apache::PerlRun in the subdir like this: PerlModule Apache::PerlRun Directory /usr/local/apache1/protected/admin SetHandler perl-script PerlHandler Apache::PerlRun PerlSendHeader On Options ExecCGI /Directory I tried also: Directory /usr/local/apache1/ssl/protected/admin SetHandler cgi-script Options +ExecCGI /Directory The problem is it allows anybody to execute the cgi's since it's not going through my handler anymore (a warn ... statement inserted in my handler shows it's not executed when requesting /protected/admin/* files.) More generally: how can I dynamically change a directory's handler during the same phase I was thinking about using dynamic stacked handlers, something like: if the user is allowed in the admin section, my handler should push the cgi-script handler in the line of execution. However, the documentation says about stacking more custom created handlers and not those coming with Apache so I'm not sure how to do it. Thanks for your time, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net
Re: unsetting PerlTransHandler
Yes, I've implemented it also that way. But I thought Location acts on the
URI and in principle there can be a Location-specific transhandler. I'm
wondering why it is impossible?
trans handlers are used to map the URI to a filename, the result of which
lets Apache know to which Directory the URI belongs to. it can also
affect which Location the URI belongs to if that Location is paired with
an Alias directive. trying to make a trans handler Location specific
doesn't really make sense - if you are already in a Location section then
you should already know which file (or lack thereof) you want to serve.
that's just how Apache works.
For now I have implemented that particular case by
PerlTransHandler MyPackage::transhandler
Location ...
PerlHandler MyPackage::handler
/Location
package MyPackage;
sub transhandler {
...
return DECLINED
if(grep {$_ eq __PACKAGE__.'::handler'} @{$r-get_handlers('PerlHandler')});
...
}
i.e. if my handler is installed return DECLINED.
I don't think that will work the way you desire - the PerlHandler directive
should not be merged into the current configuration for the request until
after the trans handler runs, so I wouldn't expect it to be present in
get_handlers() yet.
a better way is probably to let your PerlTransHandler run always. then, for
requests to Location use a PerlHeaderParserHandler to unset $r-filename.
HTH
--Geoff
Apache::Reload and INC path partialy working
I'm trying to do some development work with mod_perl and find restarting the server a pain. So I setup Apache::Reload, but it doesn't seem to want to see my local devel directory all the time.Here's my settingsApache/2.0.40mod_perl-1.99_7Linux 2.4.20-8 (RedHat9 I think)Here's my perl.conf (sourced by httpd.conf)startLoadModule perl_module modules/mod_perl.soPerlSetEnv PERL5LIB /home/bruce/public_html/ffball/myffPerlSetVar INC /home/bruce/public_html/ffball/myffPerlModule Apache2PerlModule Apache::ReloadPerlInitHandler Apache::ReloadPerlSetVar ReloadDebug On# PerlSetVar ReloadModules "FFMgr::*"# This will allow execution of mod_perl to compile your scripts to# subroutines which it will execute directly, avoiding the costly# compile process for most requests.#Alias /perl /var/www/perlDirectory /var/www/perl SetHandler perl-script PerlHandler ModPerl::Registry::handler PerlOptions +ParseHeaders Options +ExecCGI/DirectoryDirectory /home/bruce/public_html FilesMatch "\.(pl|pm|cgi)$" SetHandler perl-script PerlHandler ModPerl::Registry::handler PerlOptions +ParseHeaders Options +ExecCGI /FilesMatch/Directoryend---The PerlSetVar INC line was a futile test.Here's the problem. It seems that the reload module is finding the local modules okay as it shows up in the error_log as checking the mtime. But when they do change, it dies when it tries to reload them and says they aren't in the @INC path.So it's like it is half working.Has anyone else seen this problem and have a possible fix?Thanks-Brucewww.bluewolverine.com Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
RE: HTTP POST: parameters empty when usingModPerl::Registry(okaywhen using ModPerl:PerlRun)...
On Thu, 2003-08-07 at 23:56, Steve Bannerman wrote: I was thinking of the subroutine as a method on a class and that the objects in the class had a cgi instance associated with them. That's a good way of doing things, but you would have to structure your code a little differently. If that appeals to you, I recommend you take a look at CGI::Application. There's an article about it here: http://www.perl.com/pub/a/2001/06/05/cgi.html - Perrin
Re: Problem reloading modules
Perrin, Apache::Registry? Just do a touch on the script file and Registry will reload it. OK, thanks. You could hack your own Apache::RegistryNG subclass that would just reload everything when Apache::Reload triggers, but it's probably not worth it. Could something in Apache::Registry be implemented to integrate it better with Apache::Reload? Something along the lines of keeping track of which modules a certain script use()s, and at request time, checking if Apache::Reload has reloaded one of those since the last request and if so, reload the script itself? That would remove the confusion, and make Apache::Reload's work more transparent, IMO. Anyways, for now I will do it as you suggested. Once more, thanks for the help. J-S
Re: How to restart the root server from within modperl?
Martin Langhoff writes: how can I restart the root httpd server from within modperl? Use `at` to schedule it a minute in the future -- effectively forking it. Yes, also thought of that but the smallest unit of 'at' is minutes and I want to restart the server immediately. Note that normally apache starts as root and runs as an unprivileged user. If this is the case you _can_ achieve it using a suid wrapper or sudo, but you'll risk opening a very serious security hole in the system. So don't. Instead, run apache as a regular user, on a high port. I used sudo. Dirk
Re: mod_perl.c version for httpd 2.0.47
Stas Bekman wrote: 2. Having completed the first step of the build (perl Makefile.pl...) I am back to the second error as reported in my original post. It occurs in the test cycle of the make make test phase, as follows: /usr/local/apache2/bin/httpd -d /root/modperl-2.0/t -f /root/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS using Apache/2.0.47 (prefork MPM) waiting for server to start: .Syntax error on line 11 of /root/modperl-2.0/t/conf/httpd.conf: module access_module is built-in and can't be loaded !!! server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) make: *** [run_tests] Error 143 [EMAIL PROTECTED] modperl-2.0]# Before I start hacking at files used to generate the test conf, I need to understand what's up. Prior to running the make, I stopped my .45 version of httpd and removed the earlier mod_perl library. Am I running in to other modules that I need to remove before running make? What happens is that Apache::Test tries to inherit the configuration from the system-wide httpd.conf. So if you have any LoadModule directives, it'll move them to t/conf/httpd.conf that it generates. I think what happened in your case is that you previously has built httpd with shared objects (one of them was mod_access.c), so it created the global httpd.conf with directive 'LoadModule access_module mod_access.so', next you probably built httpd again but this time has compiled mod_access statically. However when you run 'make install', apache build system won't overwrite the existing httpd.conf file, so you have left with invalid directives in the file. I'm pretty sure that if you try to start httpd normally (without mod_perl) it'll fail with the same error. If that's the case, just nuke that global httpd.conf and run 'make install' from the httpd-2.0.47 directory again. then return to run 'make test' in the mod_perl directory. Meanwhile I'll patch Apache::Test to put LoadModule directives inside IfModule ... so this problem affect Apache::Test. The current cvs should now handle this user problem transparently __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: help on setting up a PerlFixupHandler
On Wed, Aug 06, 2003 at 08:24:30PM +0200, Xavier Noria wrote: To fix that, is it safe to change the test to defined $r-content_type and $r-content_type ne 'text/html'; or is there a better way? I usually don't concern myself with the previous content type when writing Location-based content handlers. My output is always text/html anyway. Would it be safe in your application to just leave it out completely? -chris
Re: $r-headers_out Location and Set-Cookie
Chris Faust wrote:
I haven't had any problems setting a cookie and redirecting on MP2 by using
the below
$r-err_headers_out-add('Set-Cookie' = $packed_cookie);
$r-header_out('Location' = $url);
$r-status(REDIRECT);
$r-send_http_header;
That's when you use Apache::compat, doing the mp1 syntax. In mp2-speak that
would be:
$r-err_headers_out-add('Set-Cookie' = $packed_cookie);
$r-headers_out-set('Location' = $url);
$r-status(REDIRECT);
notice that you don't need to call $r-send_http_header, it doesn't exist in mp2.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problem reloading modules
On Thu, 2003-08-14 at 15:01, Jean-Sebastien Guay wrote: Could something in Apache::Registry be implemented to integrate it better with Apache::Reload? Something along the lines of keeping track of which modules a certain script use()s, and at request time, checking if Apache::Reload has reloaded one of those since the last request and if so, reload the script itself? It's somewhat tricky to know what modules you've imported from. Maybe through overloading use(). The thing is, I don't use Registry or Apache::Reload so I don't have much motivation to do it. (I just restart my server, since it only takes a second.) If you're interested in working on it, we could discuss possible approaches on the list and review your patch. - Perrin
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: Working directory of script is / !
Ed Grimm wrote: On Wed, 30 Jul 2003, Stas Bekman wrote: Perrin Harkins wrote: On Tue, 2003-07-29 at 07:23, Stas Bekman wrote: That's correct. This is because $r-chdir_file in compat doesn't do anything. The reason is that under threaded mpm, chdir() affects all threads. Of course we could check whether the mpm is prefork and do things the old way, but that means that the same code won't work the same under threaded and non-threaded mpms. Hence the limbo. Still waiting for Arthur to finish porting safecwd package, which should resolve this problem. When he does finish it, won't we make the threaded MPM work just like this? It seems like it would be reasonable to get prefork working properly, even if the threaded MPM isn't ready yet. It's a tricky thing. If we do have a complete implementation then it's cool. If not then we have a problem with people testing their code on prefork mpm and then users getting the code malfunctioning on the threaded mpms. I think we could have a temporary subclass of the registry (e.g.: ModPerl::RegistryPrefork) which will be removed once the issue is resolved. At least it'll remind the developers that their code won't work on the threaded mpm setups. However if they make their code working without relying on chdir then they can use Modperl::Registry and the code will work everywhere. What's wrong with having the chdir code check for the threaded mpm, and, if it detects it, generate a warning that describes the situation? Admittedly, I have a difficult time understanding someone who tests under one mpm, and then releases under another mpm without testing. I realize there are people who do this sort of thing; I'm merely stating that I have difficulty understanding them. Here is an example: let's say that you are stuck with windows, so you can test only with 'winnt'. In any case, a simple subclass of the registry does the trick for those running with prefork mpm and wanting the mp1 behavior. So there is no problem, other than communicating the solution to those who need it. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: help on setting up a PerlFixupHandler
On Wednesday 06 August 2003 19:53, Christopher Grau wrote: Are you sure the content-type is text/html? Since you have your own Location handler, Apache is probably using the value from the DefaultType directive which, I think, defaults to text/plain when Apache is installed. That's it, $r-content_type ne 'text/html'; succeeds because $r-content_type is undef, so we return DECLINED and the default content handler is run AFAICT. DefaultType is text/plain in httpd.conf, why that method returns undef? To fix that, is it safe to change the test to defined $r-content_type and $r-content_type ne 'text/html'; or is there a better way? -- fxn
Re: [mp2] Child process exited
Jean-Sebastien Guay wrote: Hello, I think I've made good steps towards getting my scripts to work (Apache/2.0.47 (Win32) mod_perl/1.99_10-dev Perl/v5.8.0). However, now, when I try to reload one of the pages to test, IE tells me that The exception unknown software exception (0xc0fd) occured in the application at location 0x2805caa2. Click on OK to terminate the program, Click on CANCEL to debug the program How is it possible that IE pops this window, when Apache crashes? (in a dialog box with the big red X). This is what I get in my error_log: [Tue Aug 05 11:10:58 2003] [notice] Parent: child process exited with status 3221225725 -- Restarting. [Tue Aug 05 11:11:00 2003] [notice] Parent: Created child process 1360 What could I be doing that would make one of the Apache processes crash? Does anyone have an idea, or should I post code? The same thing happens when I try to telnet into the webserver's port 80 and type GET /filename.cgi HTTP/1.0. The specific CGI I want to test generates valid HTML if run from the command line. Any ideas? Thanks in advance, we need the core backtrace and/or a short script that Randy or someone else can reproduce the problem with on windows. I can try it on linux as well. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] Child process exited
Stas, Thanks for trying out my code. Jean-Sebastien, are you *sure* that what crashes is apache and not your client? it seems that you have the client crashing if removing nobr changes everything. What's your error_log says? My client is IE, and it stays open and responsive after the crash message. The crash message itself is a dialog box titled Apache.exe - Application Error... That's pretty much a dead giveaway that it isn't my client that's crashing. My error_log says: [Tue Aug 05 11:10:58 2003] [notice] Parent: child process exited with status 3221225725 -- Restarting. [Tue Aug 05 11:11:00 2003] [notice] Parent: Created child process 1360 so I'm pretty sure it's either Apache or the Perl instance started by Apache that's crashing. What's more, from the command line and from normal CGI, the same script (with identical output) runs without any crash - client or otherwise. BTW, I can't reproduce you problem. That's bad news. Of course, this may be platform-specific... Did you try on Win32? Where should I go from here? This is really preventing me from using mod_perl at all. As I said, the same things run without problems in normal CGI. You must run your code with warnings enabled, add to httpd.conf: PerlSwitches -wT and you will see: Variable $template will not stay shared at /tmp/CRUSH/index.cgi line 26. Variable $vars will not stay shared at /tmp/CRUSH/index.cgi line 26. which is probably unrelated to your problem, but it's very bad. Search perl.apache.org for hints how to resolve the latter. Thanks for the hint. I just modified my httpd.conf to include the PerlSwitches line, and I don't get the same warning messages you do... (actually I don't get any warning message) Is there a reason for this? So what do I do now? For now, I'm continuing development of my applications under normal CGI, but I'd really like to see them work under mod_perl... Anyways, thanks for you help. J-S ___ Jean-Sébastien Guay [EMAIL PROTECTED] Software Developer, Hybride http://www.hybride.com Piedmont, Québec, Canada
Re: PerlModule options?
On Tue, 2003-08-05 at 04:55, [EMAIL PROTECTED] wrote: loads the module but doesn't import the symbols since it is equivalent to the use Foo::Bar (). Therefore I should use use Foo::Bar in each program only to make the import. Correct. Is there other way to load the module and import the symobols specified in @EXPORT at mod_perl reloading time, without adding a special line in each and every script using them? No, that would be Bad. By putting a use Foo in each module that wants to import functions from Foo, you are explicitly saying please pollute my namespace to Foo. That sort of thing shouldn't happen unless you request it. Perhaps some options passed to PerlModule though adding (...) doesn't help since PerlModule expects a list of modules. There's no way it could since PerlModule has no way of knowing what namespaces you are going to want polluted. - Perrin
Re: [mp2] Child process exited
Sorry about the off-list reply Stas, I'm used to mailing lists that put their own address in the reply-to field of incoming mails... How is it possible that IE pops this window, when Apache crashes? OK, you got me, it isn't IE that pops the message, it only looked that way because it would appear directly over the IE window. Sorry for the mistake... we need the core backtrace and/or a short script that Randy or someone else can reproduce the problem with on windows. I can try it on linux as well. I'll try to make a small test case so you can try to repro. I think it's related to DBI (only a hunch), so I'll start there. Keep you posted... Thanks J-S - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Jean-Sebastien Guay [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 12:03 PM Subject: Re: [mp2] Child process exited Jean-Sebastien Guay wrote: Hello, I think I've made good steps towards getting my scripts to work (Apache/2.0.47 (Win32) mod_perl/1.99_10-dev Perl/v5.8.0). However, now, when I try to reload one of the pages to test, IE tells me that The exception unknown software exception (0xc0fd) occured in the application at location 0x2805caa2. Click on OK to terminate the program, Click on CANCEL to debug the program How is it possible that IE pops this window, when Apache crashes? (in a dialog box with the big red X). This is what I get in my error_log: [Tue Aug 05 11:10:58 2003] [notice] Parent: child process exited with status 3221225725 -- Restarting. [Tue Aug 05 11:11:00 2003] [notice] Parent: Created child process 1360 What could I be doing that would make one of the Apache processes crash? Does anyone have an idea, or should I post code? The same thing happens when I try to telnet into the webserver's port 80 and type GET /filename.cgi HTTP/1.0. The specific CGI I want to test generates valid HTML if run from the command line. Any ideas? Thanks in advance, we need the core backtrace and/or a short script that Randy or someone else can reproduce the problem with on windows. I can try it on linux as well. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Reload and INC path partialy working
Bruce Tennant wrote: I'm trying to do some development work with mod_perl and find restarting the server a pain. So I setup Apache::Reload, but it doesn't seem to want to see my local devel directory all the time. Here's my settings Apache/2.0.40 mod_perl-1.99_7 please upgrade to the latest CVS version and try again - 1.99_07 is very old. Linux 2.4.20-8 (RedHat9 I think) Here's my perl.conf (sourced by httpd.conf) start LoadModule perl_module modules/mod_perl.so PerlSetEnv PERL5LIB /home/bruce/public_html/ffball/myff Here's the problem. It seems that the reload module is finding the local modules okay as it shows up in the error_log as checking the mtime. But when they do change, it dies when it tries to reload them and says they aren't in the @INC path. ok. can you show us @INC before and after the reload attempt? I'm curious as to whether PERL5LIB is being properly added to @INC for the request time interpreters. also, does it fail if you reload modules that are not in @INC? for instance, try touching CGI.pm or something in your site_lib and watch the debug messages. So it's like it is half working. Has anyone ! else seen this problem and have a possible fix? we'll find a fix if we can isolate and reproduce the problem, don't worry :) --Geoff
Re: Mod_perl how to include the result of mod_autoindex?
It's not quite the truth... You can do all that staff on Apache 1.3 with appropriate skills. See LWP for example. Thanks, Slava On Mon, 2003-08-11 at 14:06, Thomas Klausner wrote: Hi! On Mon, Aug 11, 2003 at 08:37:19AM -0700, Coexec wrote: I am writing a mod_perl script using CGI.pm and Apache 1.3.28/Linux. I am trying to figure out how to use Apache's mod_autoindex to display a directories contents within the output the CGI. Apache is configured correctly, I am not asking for Apache help. This is not possible using Apache 1.3. What you want to do is called filtering and is available with Apache/mod_perl 2.0. http://perl.apache.org/docs/2.0/user/intro/overview.html#Integration_with_2_0_Filtering With Apache 1.3, you cannot (e.g.) generate content with mod_perl that includes Server-Side-Include directives. You also cannot get the content of mod_autoindex and further process this content using something. What does work is to use only mod_perl, as suggested by Christopher Grau
RE: HTTP POST: parameters empty when using ModPerl::Registry (okay when using ModPerl:PerlRun)...
Stas, Replies below: -- Steve Bannerman [EMAIL PROTECTED] 44.(0)1865.273866 -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: 05 August 2003 18:07 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: HTTP POST: parameters empty when using ModPerl::Registry (okay when using ModPerl:PerlRun)... ...snip... The docs need work, this is just a copy of mp1 registry docs, which need adjustments. However most things work the same way. The differences between Registry and PerlRun are easily summarizes with this diff: ModPerl-Registry diff -u lib/ModPerl/Registry.pm lib/ModPerl/PerlRun.pm --- lib/ModPerl/Registry.pm 2003-03-22 20:52:24.0 -0800 +++ lib/ModPerl/PerlRun.pm 2003-03-22 20:52:24.0 -0800 @@ -1,4 +1,4 @@ -package ModPerl::Registry; +package ModPerl::PerlRun; use strict; use warnings FATAL = 'all'; @@ -30,11 +30,11 @@ make_namespace = 'make_namespace', namespace_root = 'namespace_root', namespace_from = 'namespace_from_filename', -is_cached = 'is_cached', -should_compile = 'should_compile_if_modified', -flush_namespace = 'NOP', +is_cached = 'FALSE', +should_compile = 'TRUE', +flush_namespace = 'flush_namespace_normal', cache_table = 'cache_table_common', -cache_it= 'cache_it', +cache_it= 'NOP', read_script = 'read_script', rewrite_shebang = 'rewrite_shebang', set_script_name = 'set_script_name', @@ -53,17 +53,10 @@ PerlRun doesn't cache the script on each request and it flushes the script's namespace on each request. You can see the actual functions in lib/ModPerl/RegistryCooker.pm. Thanks, that's helpful...it shows me why PerlRun works. However, it doesn't really explain why the root problem exists. The way I think about it, the creation of a new CGI object should create a new set of slots for instance data. Then, each request's parameters would be stored in a slot of the new CGI instance rather than in the global set of slots for the class of CGI instances. Maybe I don't understand the object paradigm in perl correctly; however, I do understand it very well in general. Thus, it seems like a defect in either perl (the language) or CGI.pm. I'm guessing there's some justification for it in performance...however, it just doesn't seem right. Thoughts? If you can try to take it from here and see what the problem is (your code/registry?), that would be cool. Thanks. Unfortunately, I don't really know how to take it from here. I'm pretty new to perl and very new to mod_perl. Thus I'm reaching out to you guys to find out if anybody has solved this problem...unfortunately, Christopher's suggestion didn't work (unless I implemented it incorrectly). Also make sure you are using the latest CGI.pm (2.93 or higher is good). I'm using CGI.pm-2.98. Cheers __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::AuthenNTLM module with HP/Apache
Antony Batten wrote: Hi, Sorry to direct email you, but I am desperate, and was hoping the solution to the problem below would be a quick one from the people who wrote the module ;) Thanks, Antony. Appologies if this is no longer your domain, but [posted to comp.infosystems.www.servers.unix comp.lang.perl.modules] We are trying to use the Apache::AuthenNTLM perl module with HP/Apache and mod_perl. We have prevented mod_perl from running our cgi-perl scripts (by using Apache directives to only use mod_perl for *PL files), as we want to use 5.8 for this, and the HP-supplied mod_perl is tied to 5.6.1 Everything installs ok the server starts ok. However, we get the following errors in the errorlog: [Fri Aug 08 13:39:47 2003] [error] failed to resolve handler `Apache::AuthenNTLM' [Fri Aug 08 13:39:47 2003] [error] [client 30.254.43.59] Can't find 'boot_Authen__Smb' symbol in /opt/perl5.8/lib/site_perl/5.8.0/ PA-RISC1.1/auto/Authen/Smb/Smb.sl Compilation failed in require at /opt/perl5.8/lib/site_perl/5.8.0/PA-RISC1.1/Apache/AuthenNTLM.pm line 29. BEGIN failed--compilation aborted at /opt/perl5.8/lib/site_perl/5.8.0/PA-RISC1.1/Apache/AuthenNTLM.pm line 29. Compilation failed in require at (eval 5) line 3. Looks an odd error, as the symbol seems to be there (I am no programmer though :) [EMAIL PROTECTED] $ nm /opt/perl5.8/lib/site_perl/5.8.0/PA-RISC1.1/auto/Authen/Smb/Smb.sl | grep boot boot_Authen__Smb |30816|extern|entry | boot_Authen__Smb |30936|extern|code |$CODE$ Does anyone know what is causing the problem? We are really stumped here and I am up against a deadline to get this stuff working. All help greatly appreciated perl version 5.8.0 mod_perl version 5.6.1 Apache::AuthenNTLM version 2.04 Server version: HP Apache-based Web Server/2.0.43 Can you give us the correct version of mod_perl? (It should be 1.2x or 1.99x) thanks, speeves cws
Re: make test fails in building modperl2+apache2+perl5.8
gerard uolaquetalestem wrote: Hi everyone (my first message). The message is that there is a syntax error in line x of some conf file, the syntax error is that PerlSwitches is an unknown command. I am trying to compile modperl2 with perl 5.8 compiles with mpm and ithreads and with apache2 compiled not as a DSO module but as static part of the executable. But i get this error, what can it be? I'm using suse linux 8.0 Another thing is that i compiled perl with i686-linux, but i used to think i was i386, as i686 was the default i leave as it. Anyway i don't think it has any importance. Any idea? Static mod_perl build is not available at this moment. Patches to do the necessary work are welcome. In any case when reporting problems, please make sure to follow the guidelines: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems Extra info: I want to compile as static module because with DSO option #perl directive doesn't work. You are confusing mod_perl 1.0 and mod_perl 2.0, #perl doesn't work in the static build of mod_perl 1.0, not 2.0. Geoff, what the status of the SSI's port to mp2? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: unsetting PerlTransHandler
I'm wondering why it is impossible?
I am not exactly sure here, but I think this is because a TransHandler
is definitely not allowed inside a Directory or File container. And
since Apache does not make the distinction between containers (it uses
the constant RSRC_CONF to disallow a directive from being in (all)
containers) Location is the innocent victim here.
For now I have implemented that particular case by
Wouldn't this be simpler?
|PerlTransHandler MyPackage::transhandler
|Location ...
| PerlSetVar SkipTransHandler 1
|/Location
|
|package MyPackage;
|
|sub transhandler {
|...
|return DECLINED if $r-dir_config('SkipTransHandler');
|...
|}
--Frank
[ANNOUNCE] Apache::ASP v2.55 released
Hi, The latest version of Apache::ASP v2.55 has been released. The biggest improvement is no longer loading Apache::compat for running under mod_perl2. For the rest of the changes in this release, please see below. To get the latest, install from your local CPAN, and also: http://www.cpan.org/modules/by-module/Apache/ For more information on the Apache::ASP project, please see: http://www.apache-asp.org Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com $VERSION = 2.55; $DATE=08/09/2003 - Bug fixes for running on standalone CGI mode on Win32 submitted by Francesco Pasqualini + Added Apache::ASP::Request::BINMODE for binmode() being called on STDIN after STDIN is tied to $Request object + New RequestBinaryRead configuration created, may be turned off to prevent $Request object from reading POST data ++ mod_perl 2 optmizations, there was a large code impact on this, as much code was restructured to reduce the differences between mod_perl 1 and mod_perl 2, most importantly, Apache::compat is no longer used + preloaded CGI for file uploads in the mod_perl environment - When XSLT config is set, $Response-Redirect() should work now Thanks to Marcus Zoller for pointing problem out + Added CookieDomain setting, documented, and added test to cover it in t/cookies.t . Setting suggested by Uwe Riehm, who nicely submitted some code for this.
RE: How to restart the root server from within modperl?
In fact, I'm using 'killall httpd', which effectively kills every httpd process. The drawback is that you need /proc available and that it may kill httpd's belonging to another Apache. But afrer all, you can always write awk script that would parse ps output and do exactly what you want. Egor. One word of caution; killing just the parent httpd process will likely cause a lot of zombie processes since the parent process has died and will not be available to receive SIGCHLD. I don't have a solution, just thought I would offer a possible symptom to look out for. On Tue, 2003-08-12 at 12:38, Egor Shipovalov wrote: Why not start the Apache from a shell script that would always start it again if it dies? To restart the Apache then, you'd just kill the root httpd with apachectl. Killing the paernt shell script would terminate the whole operation. Egor. -Original Message- From: Dirk Lutzebaeck [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 1:17 To: [EMAIL PROTECTED] Subject: How to restart the root server from within modperl? Hi, how can I restart the root httpd server from within modperl? My problem is that when I call system() with say apachectl restart the father process is stopped killing the children including the apachectl itself. So it can't start of again. Can I call something like a reload of httpd.conf? Why I want to do this? I have a set of configurations and file links for different versions for my modperl application which I want to activate from the modperl application itself (having a HTML user interface). Thanks for help, Dirk --
Re: [mp2] Child process exited
Jean-Sebastien Guay wrote:
Stas,
Thanks for trying out my code.
Jean-Sebastien, are you *sure* that what crashes is apache and not
your
client? it seems that you have the client crashing if removing nobr
changes
everything. What's your error_log says?
My client is IE, and it stays open and responsive after the crash
message. The crash message itself is a dialog box titled Apache.exe -
Application Error... That's pretty much a dead giveaway that it isn't
my client that's crashing.
My error_log says:
[Tue Aug 05 11:10:58 2003] [notice] Parent: child process exited
with status 3221225725 -- Restarting.
[Tue Aug 05 11:11:00 2003] [notice] Parent: Created child process
1360
so I'm pretty sure it's either Apache or the Perl instance started by
Apache that's crashing. What's more, from the command line and from
normal CGI, the same script (with identical output) runs without any
crash - client or otherwise.
Good, just a sanity check. it sounds silly that changing an html will break
the server, but anything could happen. Is it possible that the broken(?) html
makes IE do silly things, that cause the server crash in the afteraction? e.g.
I'd check the access_log to see whether it issues only one request or more.
Also make sure to debug in the single process (thread?) mode (httpd -X)
BTW, I can't reproduce you problem.
That's bad news. Of course, this may be platform-specific... Did you try
on Win32?
I don't have win32.
Where should I go from here? This is really preventing me from using
mod_perl at all. As I said, the same things run without problems in
normal CGI.
I'm not a win32 person, so I'm not quite sure how you debug things there. But
what you need to do is to get the server dump the core file, which will tell
us where exactly it crushes.
Hopefully Randy will come back from vacation soon and will help you out. Or
may be someone else.
You must run your code with warnings
enabled, add to httpd.conf:
PerlSwitches -wT
and you will see:
Variable $template will not stay shared at /tmp/CRUSH/index.cgi line
26.
Variable $vars will not stay shared at /tmp/CRUSH/index.cgi line 26.
which is probably unrelated to your problem, but it's very bad. Search
perl.apache.org for hints how to resolve the latter.
Thanks for the hint. I just modified my httpd.conf to include the
PerlSwitches line, and I don't get the same warning messages you do...
(actually I don't get any warning message) Is there a reason for this?
It's possible that some of your code or the modules that you use either misuse
$^W or trap $SIG{__WARN__} which prevents from warnings to be printed. grep
for these two things.
whenever you override $^W, this must be done with:
local $^W = $whatever;
so it won't affect other code. same with $SIG{__WARN__} if possible.
I'd suggest that you first get these warnings working and reported, then you
fix your code to avoid these warnings (with the non-crashing version of the
template), then move to solve the original problem.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: unsetting PerlTransHandler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 14 August 2003 18:20, Geoffrey Young wrote:
Frank Maas wrote:
Ehm... considering both solutions worked and the quoted paragraph,
shouldn't we read it as 'the results of this sequence can be used during
the translation phase, but are thrown away after the translation has
completed'. This would mean that the results are not discarded prior to
translation, but after translation and that would also explain why the
two solutions work...
well, they can only be used during translation if the URI is unaltered.
for instance, given the example we've seen already
PerlTransHandler MyPackage::transhandler
Location ...
PerlHandler MyPackage::handler
/Location
checking get_handlers() in transhandler() only works because the initial
merge (which is thrown away) ends up being the same merge as after
translation. if any (other) trans handlers meddle with $r-uri (which is
perfectly valid) then the initial get_handlers() call will report settings
completely different than the end Location that is finally applied to the
URL.
well, if a transhandler alters the Uri than maybe MyPackage::handler will not
be called at all, yes. But from the point of view at start of the request it
would be called.
so, I guess Location-specific settings can be used during translation,
much in the same way that you can break encapsulation in Perl by simply
accessing the object via its underlying hash - the feature works
currently due to the way things are implemented, but using it is not
guaranteed to work in the future (apache 2.0?), and may have unintended
consequences in the present. in other words, it's a bad idea and people
who know better certainly don't rely on it.
I'm wondering then for what reason that initial merge is done at all if not to
be used during name translation?
well, a translation handler cannot be sure that the $r-dir_config it gets was
really caused by the $r-uri it sees. Further, other handlers in later phases
can get completely different settings.
I've searched the standard modules for /r-uri\s*=/ and found only one
occurence in mod_rewrite with the [PT] flag. I assume the right solution
would be to do another merge based on the new uri if someone alters the uri
during name translation and plans to return DECLINED.
And as for apache 2, there I have found these lines:
if ((access_status = ap_location_walk(r))) {
return access_status;
}
if ((access_status = ap_run_translate_name(r))) {
return decl_die(access_status, translate, r);
}
Torsten
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/O+VtwicyCTir8T4RAiiEAJ4rtu6tMCVrkho5eP3L3+Yz8NGQ9QCguIUb
oxm9P4ttWWeO0g7/BRb4raQ=
=iiYV
-END PGP SIGNATURE-
Re: Problem reloading modules
Hi Perrin, I don't see anything wrong with that chunk of code. If you restart the server, does it pick up the change? Yes. Is there anything unusual about the way you call this sub (AUTOLOAD, function ref, etc.)? Not at all. It is imported with use Hybride::Projects qw(getImage other imports); and the file in which the sub is located is called Projects.pm, in a directory Hybride, whose parent directory (D:/htdocs) is added to my @INC by using 'use libs qw(D:/htdocs)' in my startup.pl file AND 'PerlSwitches -ID:/htdocs' in my httpd.conf (I just wanted to make sure... :-). I can see with perl-status that my @INC is correctly set to pick up the module, and that the module itself is listed in %INC with its absolute path on my filesystem, so that should be right. I get this in my error_log when I refresh the page that runs the CGI script that uses the sub: Apache::Reload: Checking mtime of Hybride/Projects.pm Subroutine listProjects redefined at D:/htdocs/Hybride/Projects.pm line 33. Subroutine validProject redefined at D:/htdocs/Hybride/Projects.pm line 49. Subroutine getImage redefined at D:/htdocs/Hybride/Projects.pm line 68. Subroutine getProjectAbbreviation redefined at D:/htdocs/Hybride/Projects.pm line 92. Apache::Reload: process 2392 reloading Hybride/Projects.pm I believe those warnings are normal since the module is being reloaded and the subs are being replaced in memory, right? So that tells me that the module is reloaded. However, the old code is still being used. However, your code here looks pretty vanilla and seems like it should be working fine with Reload. I agree. Is there anything else I can check to make sure I'm not missing anything obvious? Thank you, J-S
Re: [mp2] Child process exited
Jean-Sebastien Guay wrote:
Steve,
How did you build Apache 2?
I downloaded the binaries... Sorry, can't help there.
Please keep me posted as to your progress.
OK, I've now got Apache 2 building (with a little off-list help from
Randy Kobes - the secret is to use the .zip sources rather than the
.tar.gz sources!), and I've built mod_perl 1.99_09 (not 1.99_10-dev as
your have) and the good news for you is that I've reproduced your problem.
The bads news is that I haven't solved it, but I'll keep trying and let
you know if/when I do.
I don't any Application Error popup window, but my NS7.1 browser says
The document contained no data, while IE6.0 gives the usual useless
The page cannot be displayed crap that it always does.
I also get nothing in the access.log.
The error.log contained this:
Variable $template will not stay shared at
C:/apache2/perl-bin/index.cgi line 26.
Variable $vars will not stay shared at C:/apache2/perl-bin/index.cgi
line 26.
[Thu Aug 14 10:37:04 2003] [notice] Parent: child process exited with
status 128 -- Restarting.
The variable will not stay shared error is a common problem with
mod_perl scripts that have file-scope lexical variables in them which
subroutines access. My usual solution is to put the main part of the
program into a block labelled MAIN:. That way they can't be shared
to start with, and I have to explicitly pass them into any subroutines
that require them. The attached new version of your index.cgi does
this, and makes these errors go away. I now have just this in the
error.log:
[Thu Aug 14 10:41:42 2003] [notice] Parent: child process exited with
status 128 -- Restarting.
The index.cgi program runs fine in a command prompt (with SCRIPT_ROOT
set in the environment), so its not an obvious TT error.
TTYL,
Steve
#!D:\perl\bin\perl -w
#---
use strict;
use warnings;
use Template;
MAIN: {
#---
my $vars = {
VERSION = 0.75,
};
# Template toolkit config.
my $config = {
INCLUDE_PATH = $ENV{SCRIPT_ROOT},
INTERPOLATE = 1, # expand $var in plain text
POST_CHOMP = 1, # cleanup whitespace
};
my $template = Template-new($config);
#---
print qq[Content-Type: text/html\n\n];
processTemplate($template, 'header.html.tmpl', $vars);
#print qq[htmlheadtitleApache should hopefully
crash.../title/headbody];
print plural('bottle', $_) . of beer on the wall, br .
plural('bottle', $_) . of beer, br .
Take one down and pass it around, br .
plural('bottle', $_ - 1) . of beer on the wall.brbr\n
foreach (reverse (1 .. 99));
print qq[/body/html];
}
#---
sub processTemplate {
my $template = shift;
my $t_file = shift;
my $vars = shift;
$template-process($t_file, $vars)
or die(Error pressing $t_file: . $template-error);
}
sub plural {
my ($word, $number) = @_;
return ($number == 0 ? 'no' : $number) .
$word .
($number == 1 ? '' : 's');
}
Re: Problem reloading modules
On Thu, 2003-08-14 at 15:33, Jean-Sebastien Guay wrote: In a week or so I'll have a bit more free time, and I might try implementing it. I'll start by reading up on mod_perl internals... :-) Actually, all you need to read is the code for Apache::Registry or ModPerl::Registry (depending on which you are using) and the code for Apache::Reload. These are all pure perl modules. However, there will always be things that Apache::Reload doesn't handle. For example, you might import functions from one module into another module, as opposed to importing into a Registry script. My advice is to avoid importing things at all, but I know that many people really love importing and will not want to give it up. - Perrin
Re: Apache::Session
Hi I do a few basic things that improve security - its still not strict security but What i do is store both the remote IP and the user agent HTTP parameters in the session when the session is created. Whenever a new request comes in with that session I check that those havent changed. If they havent I allow access and update the 'last access time' (for expiry) - if not they are logged out and the session closed. This means that any user disconnected from their ISP has to login again, which i consider acceptable. It also means that if they copy an url and paste it into another browser they will end up logged out, again it does not happen often and people should accept it as the price of security. It does mean that someone on the same proxy and using the same browser could still do something but that is already a lot fewer people. I also check referrer to make sure people are coming from a page that makes sense. If you wanted to be more sophisticated you could store where an user has been recently (the 5 last URLs maybe) and check that the referrer is one of them. If the referrer is not a page where the user has been then things are fishy and you log them out. If you need even better security there's ssl, or storing unique, random'challenge-response' style tokens into pages that have to be sent back on the next connection Probably many people on this list have more sophisticated systems in place. I'd be interested to know too :) Joelle Nebbe
Re: Apache::Session
Strip out stuff that could be problematic. This is what we did with Slash. We strip out javascript or any tag that can be problematic, or be used even to break the layout of the page. It'll make you're life much easier ;) Take this from someone who coded tons of features to ward off trolls! Aleksandr Guidrevitch wrote: Hi, All Sorry, this post might be out of scope of this particular list, but still... don't punch me heavily :) I just think the people here might have met this problem while deploying big public applications. I use Apache::Session to identify logged in users. However, the users are allowed to post html (obviously with javascript) messages viewable by others. That could create an XSS vulnerability and allow to steal the sessions (cookies) from other users. Is it possible to uniquely identify the user by some attributes ? The only thing I consider now is IP, but what about proxies and NATs ? User Agent string could also be stolen via javascript. That means I tend to make stolen session ids non-reusable. Any thoughts ? Sincerely, Aleksandr Guidrevitch -- -- Patrick Galbraith Senior Software Developer [EMAIL PROTECTED] [EMAIL PROTECTED] 206.719.2461
Re: [mp2] Child process exited
Jean-Sebastien Guay wrote: Stas, One of the following will work. PerlSwitches -Id:/htdocs or PerlSwitches -Mlib=d:/htdocs Thanks, I'll try those. But I still don't know a) why Apache crashes (I know you can't repro, maybe someone else on Win32 will, so this is stalled for now). b) why my warnings don't show up in the error_log. Do you have anything that could help me find the solution to b) ? I think Randy should be back soon. He will certainly help with win32. It would be really nice to have a few more folks helping mod_perl on win32, to get some load off Randy. win32 guys, please come out from the lurker shadows and try to give your fellas some help. As for the warnings, even though you can't see them you can fix them. You can't have lexical variables in registry scripts that are used in sub-routines defined in the same file. I gave you all the URLs to read more on the topic. the simplest solution is to turn them into globals (and make sure that they are always initialized, which you already do). if you run 5.6.0 and higher just s/my/our/; on all top level vars that are used in the subs defined in the same file. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] Child process exited
On Wed, 13 Aug 2003, Stas Bekman wrote: Jean-Sebastien Guay wrote: Stas, I just checked, and when the Apache crash occurs, nothing gets written to access_log. It would seem that the crash happens before the request is logged. That's possible, but at least you can see that it's not IE that generates some followup request that causes the crash, but the original one. Now you need to get the crash backtrace. You probably need to start the server under debugger and get the backtrace from there. (don't ask me how to do that on win32 ;) I'll be back next week, and I could take a look at it then ... One can get a (mod_perl) backtrace on Win32 by compiling it with MP_DEBUG=1, and when the crash happens, an option is presented to call up the debugger. I haven't been able to follow this in detail yet, but I noticed that Apache::Reload was being used. Does anything change if this (or any other non-essential modules) aren't used? In other words, can you pare things down to a working version, and then start adding things until a crash is invoked? -- best regards, randy
[ANNOUNCE] mp2: new porting assister package Apache::porting
Apache::porting tries to help you to do the porting to mod_perl 2.0. For more information please refer to: http://perl.apache.org/docs/2.0/api/Apache/porting.html It's a new module and didn't go through much testing. However make sure to check the known issues, before reporting problems: http://perl.apache.org/docs/2.0/api/Apache/porting.html#Culprits Finally, as of this writing you need to get the cvs version of mod_perl 2.0 to get it working. It'll be available in modperl-1.99_10, when it will be released. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Reload and INC path partialy working
Here's my perl.conf (sourced by httpd.conf) start LoadModule perl_module modules/mod_perl.so PerlSetEnv PERL5LIB /home/bruce/public_html/ffball/myff on second thought, try PerlSwitches -I/home/bruce/public_html/ffball/myff or PerlSwitches -Mlib=/home/bruce/public_html/ffball/myff instead of PERL5LIB --Geoff
Re: Problem reloading modules
Perrin Harkins wrote: If you're interested in working on it, we could discuss possible approaches on the list and review your patch. In a week or so I'll have a bit more free time, and I might try implementing it. I'll start by reading up on mod_perl internals... :-) I'd suggest a different approach. Write a subclass of the registry and if it gains popularity we will merge it in. And you don't really need to read on mod_perl internals to do that. Just learn the ModPerl/RegistryCooker guts ;) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problem reloading modules
On Thu, 2003-08-14 at 15:10, Stas Bekman wrote: OK, I've written a proper entry for the man page, Jean-Sebastien can you please verify that it all works, as I wrote it without testing. Thanks. http://perl.apache.org/docs/2.0/api/Apache/Reload.html#Problems_with_Scripts_Running_with_Registry_Handlers_that_Cache_the_Code Thanks Stas! I think you have a little mistake here: @EXPORT = qw(set_colour); That should be @EXPORT = qw(colour); - Perrin
Re: Set-Cookie2
On Tue, 5 Aug 2003, Stas Bekman wrote: Jie Gao wrote: Hi All, Any idea if Set-Cookie2: is going to be implemented in CGI.pm? Lincohn? Jie, AFAIK, this has nothing to do with mod_perl. See: http://stein.cshl.org/WWW/software/CGI/#bugs Sorry. Now let me ask a question that's related to mod_perl: does libapreq support Set-Cookie2? Regards, Jie
mod_perl.c version for httpd 2.0.47
I am installing Apache httpd 2.0.47 on my RH9 Intel Linux box. I get the following error when I start httpd: [EMAIL PROTECTED] init.d]# /usr/local/apache2/bin/apachectl start httpd: module mod_perl.c is not compatible with this version of Apache (found 20020628, need 20020903). Please contact the vendor for the correct version. [EMAIL PROTECTED] init.d]# I have been apache 2.0.45 successfully on this box since installing the OS and apache a couple of months ago. No other updates have been made to the apache install. I did make the instructed LoadModule perl_module modules/mod_perl.so to the httpd.conf file within ~/apache2. To create that file, as I was already running .45, I saved the new httpd.conf to another name, copied my working file from /etc/httpd/conf/httpd.conf to the appropriate directory in /usr/local/apache2, and made that change therein. I'm not sure why my .45 install is splattered around the machine. When I installed it, I took the defaults; but had never seen an install like that (i.e. files in /etc, binaries in the systems binaries directories -- I would have expected all of the apache stuff in /usr/local/apache, but it all worked nonetheless. (This background provided in the likely event that I'm causing my own problems, and I'm not experienced enough to see it!!!) Seeing the mod_perl.c version problem, I downloaded mod_perl-1.99.08 from the Apache site. I am not clear how the versions that apachectl asks for (above) correlate to the source on the site. The 2002... version references seem old and out of sync. Can anyone clarify? When I do the make make test part of the mod_perl installation, I get the following error: /usr/local/apache2/bin/httpd -d /root/mod_perl-1.99_08/t -f /root/mod_perl-1.99_08/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS using Apache/2.0.47 (prefork MPM) waiting for server to start: .Syntax error on line 11 of /root/mod_perl-1.99_08/t/conf/httpd.conf: module access_module is built-in and can't be loaded !!! server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) make: *** [run_tests] Error 143 [EMAIL PROTECTED] mod_perl-1.99_08]# Can anyone point me in the right direction? I don't believe that I'm solving the correct problem here - or at least, obviously, I'm not solving this problem correctly! Thank you for any guidance, Robert Shelton
Re: How to restart the root server from within modperl?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 12 August 2003 11:50, Dirk Lutzebaeck wrote:
Dennis Stout writes:
On a whim, I would try writing a second script to do the actual shutdown
and restart of Apache.
Then have your mod_perl program either run it in the background (with a
) or fork it into another process.
Did exactly that but is has the effect that when the parent (root)
apache is killed it kills all children including the script itself. So
the server wont start again.
I have done something like this several times. My code (it works since 1998 on
a highly used WEB Server with perl5.005_3) looks like that:
...
sub sysclose {
require 'syscall.ph';
syscall SYS_close, shift()+0;
}
sub RLIMIT_NOFILE {7;} # this is for LINUX
sub getrlimit {
require 'syscall.ph';
my $x=xx8; # result
syscall SYS_getrlimit, shift()+0, $x;
unpack ii, $x;
}
sub close_fd {
my @l=getrlimit( RLIMIT_NOFILE );
my $l;
for( $l=0; $l$l[0]; $l++ ) {
next if( $l==2 ); # close all file descriptors except of STDERR
sysclose $l;
}
}
sub disconnect_from_apache {
use POSIX qw/setsid/;
setsid;
close_fd;
}
...
my $child=fork;
unless( defined $child ) {
...
return OK;
}
if( $child ) {
my $child_status=0;
if( waitpid( $child, 0 )==$child ) {
$child_status=$?;
}
if( $child_status==0 ) {
...
return OK;
} else {
# The first fork succeeded but the second failed
...
return OK;
}
} else {
# Child process: fork again to detach from parent process
$child=fork;
CORE::exit( 0 ) if( $child ); # parent exits
unless( defined $child ) {
...
CORE::exit( 1 );
}
# Now we are the 2nd child process.
$self-disconnect_from_apache;
$self-doit( ... ); # == here comes the real code
CORE::exit( 0 );
}
...
$self-doit() is called in a separate process group and is not killed by a
signal sent to the apache process group. Further, all files save STDERR are
closed. This is needed since the code runs under mod_perl and the long
running child process inherits the open connection to the browser. If this
connection is not closed the browser shows an endless spinning globe or
something like that in the upper right corner.
Torsten
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/OSIAwicyCTir8T4RAv3RAKCXdpbHLQepeOZFCyXt1KkMVGnwPgCeNu7X
hlC1NSEv0NsA7LlM7lol7wI=
=xId6
-END PGP SIGNATURE-
Re: [MP1.28 + perl maint. 20512] Build failure due to error in Apache/ExtUtils.pm
Sreeji K Das wrote: I tried to compile mod_perl-1.28 with perl maint. 20512 (http://www.iki.fi/jhi/[EMAIL PROTECTED]). I had a build failure (different errors each time trying to build). Have you tried http://www.iki.fi/jhi/[EMAIL PROTECTED] ? That snapshot worked OK for me on WinXP. - Steve
Set-Cookie
Hi All, Any idea if Set-Cookie2: is going to be implemented in CGI.pm? Lincohn? Regards, Jie
Re: Problem reloading modules
Stas Bekman wrote: OK, I've written a proper entry for the man page, Jean-Sebastien can you please verify that it all works, as I wrote it without testing. Great work Stas, you're quick :-) Other than the little mistake Perrin pointed out, the suggested change works. Perrin Harkins wrote: If you're interested in working on it, we could discuss possible approaches on the list and review your patch. In a week or so I'll have a bit more free time, and I might try implementing it. I'll start by reading up on mod_perl internals... :-) Thanks for your help, J-S
Re: [ANNOUNCE] Apache::ASP v2.55 released
Perrin Harkins wrote: Josh Chamas wrote: The latest version of Apache::ASP v2.55 has been released. The biggest improvement is no longer loading Apache::compat for running under mod_perl2. Has this affected the performance measurements you made earlier in any way? Not really. I was working on the port away from Apache::compat during the benchmarking, so the results I posted before largely reflect the porting work. I do not believe there was much of a performance impact regardless, there is so much runtime overhead to Apache::ASP, that the difference was probably on the order of 5% or so if any. There might have also been a small amount of memory savings as well, but I remember it to be on the order of a 200-300K or so across 20 processes ( things preloaded as usual ). Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: Problem reloading modules
Perrin Harkins wrote: On Thu, 2003-08-14 at 15:10, Stas Bekman wrote: OK, I've written a proper entry for the man page, Jean-Sebastien can you please verify that it all works, as I wrote it without testing. Thanks. http://perl.apache.org/docs/2.0/api/Apache/Reload.html#Problems_with_Scripts_Running_with_Registry_Handlers_that_Cache_the_Code Thanks Stas! I think you have a little mistake here: @EXPORT = qw(set_colour); That should be @EXPORT = qw(colour); Thanks, committed! __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: Apache::AuthenNTLM module with HP/Apache
On Wed, 13 Aug 2003, Antony Batten wrote: Shannon, Thanks very much for the quick response. Here's the info you wanted (I hope): HP-UX_Apache-based_Web_Server/2.0.46 (Unix) mod_perl/1.99_09 Perl/v5.6.1 DAV/2 configured Can my career be saved? ;0) Thanks again, Antony. -Original Message- From: Shannon Eric Peevey [mailto:[EMAIL PROTECTED] Sent: 13 August 2003 14:41 To: Antony Batten Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Apache::AuthenNTLM module with HP/Apache Antony Batten wrote: [ .. ] We are trying to use the Apache::AuthenNTLM perl module with HP/Apache and mod_perl. We have prevented mod_perl from running our cgi-perl scripts (by using Apache directives to only use mod_perl for *PL files), as we want to use 5.8 for this, and the HP-supplied mod_perl is tied to 5.6.1 Everything installs ok the server starts ok. However, we get the following errors in the errorlog: [Fri Aug 08 13:39:47 2003] [error] failed to resolve handler `Apache::AuthenNTLM' [Fri Aug 08 13:39:47 2003] [error] [client 30.254.43.59] Can't find 'boot_Authen__Smb' symbol in /opt/perl5.8/lib/site_perl/5.8.0/ PA-RISC1.1/auto/Authen/Smb/Smb.sl Compilation failed in require at /opt/perl5.8/lib/site_perl/5.8.0/PA-RISC1.1/Apache/AuthenNTLM.pm line 29. BEGIN failed--compilation aborted at /opt/perl5.8/lib/site_perl/5.8.0/PA-RISC1.1/Apache/AuthenNTLM.pm line 29. Compilation failed in require at (eval 5) line 3. I'm not sure I'm following your setup - is the mod_perl you're trying to use here compiled under Perl 5.6.1? And Apache::AuthenNTLM was compiled under Perl 5.8.0? That combination probably won't work in principle, as 5.6.1 and 5.8.0 are binary incompatible. If you're tied to mod_perl compiled under 5.6.1, try compiling and using an Apache::AuthenNTLM compiled under 5.6.1. -- best regards, randy kobes
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
Try this patch: [...] Feel free to submit this bug report and the fix to httpd-dev. Please let me know if you do that, so I won't duplicate it. But I'd prefer that you do it so you can make sure that it gets fixed in the next release, since you need it working. I've just verified that your patch fixes my problem. I've never submitted a but report and fix to httpd-dev, but I'm willing to do it. How do I do it? -bill
[Slightly OT] Port forwarding (Was: How to restart the root serverfrom within modperl?)
Hello, MLIf you absolutely need to be in port 80, either setup a simple MLlightweight apache on port 80 as a reverse proxy (see the mod_perl MLguide) or, even simpler, do some port forwarding from port 80 to your MLhigh port of choice. Has anybody had very good experiences using a simple port forwarder in a production setup? We had a somewhat bad experience with using portfwd under Solaris (images and other binary data got randomly corrupted, and we never got around to figuring out why), and I'm wondering what others use instead. It seems like the port forwarder involved would also be important performance wise. The applications I am typically interested in are forwarding ports on the same interface (like the port 80 example here) as well as between interfaces (or between external interfaces and loopback). Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
Re: mp1 rflush() and buffer size
Douglas Theobald wrote:
I have a question concerning the proper behavior of rflush() with mp1. I'm
using Apache/1.3.28 and mod_perl/1.28 on OSX jaguar 10.2.6. Overall mp1
appears to work great. However, the following code does not work as
expected:
use CGI ();
my $r = shift;
my $q = new CGI;
print $q-header('text/html');
print $q-start_html;
print $q-p(Searching...Please wait);
$r-rflush;
# imitate a lengthy operation
for (1..3) {
sleep 1;
}
print $q-p(Done!);
The Searching...Please wait text does not display until the sleeps are
done. Adding $|=1; up top does not help. However, this code does work:
use CGI ();
my $r = shift;
my $q = new CGI;
print $q-header('text/html');
print $q-start_html;
for (1..263)
{
print $q-p(Searching...Please wait);
}
$r-rflush;
# imitate a lengthy operation
for (1..3) {
sleep 1;
}
print $q-p(Done!);
It appears that if I print out over 8k, the buffers flush. Less than that,
no flush. Is this proper behavior? And, if so, is there a parameter I can
change somewhere to lower the value or force a flush regardless of what's in
the buffer? I have tried very hard to find documentation or previous
discussion in this group to no avail.
Sounds like you have a buffering proxy in front of your mod_perl server. Test
it without any front-end proxy, accessing the back-end server directly.
If you don't believe that it works, you can run strace on the process, to see
it working correctly. You can see an example here:
http://perl.apache.org/docs/1.0/guide/debug.html#Detecting_Aborted_Connections
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Fwd: Re: Apache::Reload and INC path partialy working
Forwarding message as I didn't realize I was missing the list. Geoffrey Young [EMAIL PROTECTED] wrote: Date: Tue, 12 Aug 2003 14:18:37 -0400From: Geoffrey Young <[EMAIL PROTECTED]>To: Bruce Tennant <[EMAIL PROTECTED]>Subject: Re: Apache::Reload and INC path partialy workingok, I'll take a look at this.please repost to the list, though, so others can help and your results are recorded.and no, there is no rpm package for the latest CVS version that I know about - you'll need to compile it yourself (which is easy, don't worry :)--GeoffBruce Tennant wrote: The INC is correct (it has the new path in it). But if I touch a file in the added directory, it detects the file as being changed (uses proper INC), but seems to not find it when it is trying to reload it (sees base INC). I tried another thing, use a startup.pl file, it seems to work 90% of the time. Sometimes when a file is changed or reloaded, one of the sub httpd process will say it knows nothing about the reloaded module. But I can work w/this as a hitting reload on the browser fixes this. Here's the INC when no module is changed: /home/bruce/public_html/ffball/myff /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache2 /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl . Here's the INC after I touched Apache/DBI.pm in site_perl and it was reloaded (seen in log) /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache2 /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 . It would seem it dropped the perl5lib line. Oh also, if I remove the "use lib" line in my top file, none of my local modules will load. I though the PERL5LIB was suppose to add to the base INC and make it so you didn't need to use "use lib". Maybe this is the root of the problem. But as I mentioned, if using a startup script w/PerlRequire, the reloads seem to work. Do you know if there's a new rpm package for mod-perl (RH9)? */Geoffrey Young <[EMAIL PROTECTED]>/* wrote: Bruce Tennant wrote: I'm trying to do some development work with mod_perl and find restarting the server a pain. So I setup Apache::Reload, but it doesn't seem to want to see my local devel directory all the time. Here's my settings Apache/2.0.40 mod_perl-1.99_7 please upgrade to the latest CVS version and try again - 1.99_07 is very old.Linux 2.4.20-8 (RedHat9 I think)Here's my perl.conf (sourced by httpd.conf) start LoadModule perl_module modules/mod_perl.so PerlSetEnv PERL5LIB /home/bruce/public_html/ffball/myffHere's the problem. It seems that the reload module is finding the local modules okay as it shows up in the error_log as checking the mtime. But when th! ey do change, it dies when it tries to reload them and says they aren't in the @INC path. ok. can you show us @INC before and after the reload attempt? I'm curious as to whether PERL5LIB is being properly added to @INC for the request time interpreters. also, does it fail if you reload modules that are not in @INC? for instance, try touching CGI.pm or something in your site_lib and watch the debug messages.So it's like it is half working. Has anyone ! else seen this problem and have a possible fix? we'll find a fix if we can isolate and reproduce the problem, don't worry :) --Geoffwww.bluewolverine.com Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design softwarewww.bluewolverine.com Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: [mp2] Child process exited
Jean-Sebastien Guay wrote: I'll try to make a small test case so you can try to repro. I think it's related to DBI (only a hunch), so I'll start there. Ok, I've got it as simple as I can (I think - 25.1k zip). It isn't related to DBI, but to template toolkit. So to try my test case, you'll need that installed. 25k zip? that's a not quite a short test case ;) Can it possibly be 25 lines of code instead? Should I send the zip to the list or to your private address? I'll also include the short setup instructions. Most likely someone on win32 will have to try it. If you can put it online somewhere and post the URL to it, that will be the best. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] Child process exited
Jean-Sebastien Guay wrote: So, did anyone have time to check this out? This is pretty major for me, I can't implement mod_perl at my site until I find out what is causing this crash and fix it. And I really have no idea what could be causing it. I'm using CGI.pm 2.98, Template-Toolkit 2.10, Apache/2.0.47 (Win32) mod_perl/1.99_10-dev Perl/v5.8.0. So please, if someone on a similar setup could download the test case at http://pages.infinit.net/jeans13/ApacheCrash.zip and see if the crash happens for them too... Remember to read the README file first... Jean-Sebastien, are you *sure* that what crashes is apache and not your client? it seems that you have the client crashing if removing nobr changes everything. What's your error_log says? BTW, I can't reproduce you problem. You must run your code with warnings enabled, add to httpd.conf: PerlSwitches -wT and you will see: Variable $template will not stay shared at /tmp/CRUSH/index.cgi line 26. Variable $vars will not stay shared at /tmp/CRUSH/index.cgi line 26. which is probably unrelated to your problem, but it's very bad. Search perl.apache.org for hints how to resolve the latter. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl.c version for httpd 2.0.47
[moving this to the mod_perl list.if you aren't on the list please subscribe to it: http://perl.apache.org/maillist/modperl.html#Subscription_Information ] The MP_APXS option worked to get past the first error. Thanks. Good. I'll make sure that the error message will mention that. Two questions: 1. I read the manual page on apxs and tried a variety of options. After getting streams of errors, I moved on to the MP_APXS solution. I'm still curious to understand how apxs works. If the command line for creating mod_perl is not time consuming to reproduce, could you include those in your reply? I'd like to work backward to figure out how apxs used. Once I understand it in one area, I should be able to generalize to other uses. mod_perl queries apxs to get the information about the apache installation. For examples to figure out where apache .h files are it issues: apxs -q INCLUDEDIR Normally if you install httpd and all its files under one directory, providing the path to that directory via the MP_AP_PREFIX option is enough, since mod_perl finds apxs, apr-config and other things by itself. However when things are spread around the file system (don't live under the same tree), one has to explicitly tell the path to MP_APXS and sometimes for other things (like MP_APR_CONFIG). Eventually the build will be polished to get the error messages intuitive enough for users to proceed without reading any docs. If you can help to improve the diagnostics system that will help a lot. Hope that answers your question. 2. Having completed the first step of the build (perl Makefile.pl...) I am back to the second error as reported in my original post. It occurs in the test cycle of the make make test phase, as follows: /usr/local/apache2/bin/httpd -d /root/modperl-2.0/t -f /root/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS using Apache/2.0.47 (prefork MPM) waiting for server to start: .Syntax error on line 11 of /root/modperl-2.0/t/conf/httpd.conf: module access_module is built-in and can't be loaded !!! server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) make: *** [run_tests] Error 143 [EMAIL PROTECTED] modperl-2.0]# Before I start hacking at files used to generate the test conf, I need to understand what's up. Prior to running the make, I stopped my .45 version of httpd and removed the earlier mod_perl library. Am I running in to other modules that I need to remove before running make? What happens is that Apache::Test tries to inherit the configuration from the system-wide httpd.conf. So if you have any LoadModule directives, it'll move them to t/conf/httpd.conf that it generates. I think what happened in your case is that you previously has built httpd with shared objects (one of them was mod_access.c), so it created the global httpd.conf with directive 'LoadModule access_module mod_access.so', next you probably built httpd again but this time has compiled mod_access statically. However when you run 'make install', apache build system won't overwrite the existing httpd.conf file, so you have left with invalid directives in the file. I'm pretty sure that if you try to start httpd normally (without mod_perl) it'll fail with the same error. If that's the case, just nuke that global httpd.conf and run 'make install' from the httpd-2.0.47 directory again. then return to run 'make test' in the mod_perl directory. Meanwhile I'll patch Apache::Test to put LoadModule directives inside IfModule ... so this problem affect Apache::Test. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
HTTP POST: parameters empty when using ModPerl::Registry (okay when using ModPerl:PerlRun)...
All,
I apologize if this has already been covered...I looked at the archives
since May but couldn't see anything covering this (there were related items
but their solutions didn't solve this problem).
Here an explanation of the problem:
We want to post experiment results to an upload server which is running
Apache HTTP Server (2.0.46) and mod_perl (1.99_09). When we post a sequence
of files to the server, some of them are written to the local disk and some
are not. That is, the test fails when using ModPerl::Registry but it
succeeds when using ModPerl::PerlRun.
In analyzing which ones work and which ones do not, I wrote a quick test to
see why the transfer is not working. From the looks of the results, it
appears that the first request handled by a particular Apache process/thread
works and that any subsequent requests handled by that thread fail.
Works means that the file in the test gets saved to disk and fail means that
a file of size 0 gets written to disk.
Below are the httpd.conf segments (working and failing), the test client
(test_client.pl) and the test server (test_server.pl which is accessible
from the /cpdn/cgi-bin location).
Any suggestions? Thanks in advance...
Also, does it matter if I use ModPerl::PerlRun instead of ModPerl::Registry
(I have read some about this at
http://apache.perl.org/docs/2.0/api/ModPerl/Registry.html but the
documentation there is a little light).
--
Working httpd.conf
--
Location /cpdn/cgi-bin
AllowOverride None
SetHandler perl-script
PerlResponseHandler ModPerl::PerlRun
PerlOptions +ParseHeaders
Options +ExecCGI
Allow from All
/Location
--
Failing httpd.conf
--
Location /cpdn/cgi-bin
AllowOverride None
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
Allow from All
/Location
--
test_client.pl
--
#!/usr/bin/perl
use strict;
use LWP::UserAgent;
use HTTP::Request::Common;
my $postUrl = $ARGV[0];
my $file = $ARGV[1];
my $postType = 'form-data';
my $ua = new LWP::UserAgent;
my $req = POST($postUrl,
Content_Type = $postType,
Content = [ file = [$file] ]);
my $res = $ua-request($req);
if ($res-is_success()) {
print POST test successful\n;
print $res-content();
} else {
print STDERR POST test failed;
print STDERR code: . $res-code() . \n;
print STDERR message: . $res-message() . \n;
}
--
test_server.pl
--
use strict;
use CGI qw(:standard);
my $cgi = new CGI;
saveFile();
sub saveFile {
my $inputfile = $cgi-param('file');
my $outputfile = /tmp/file- . $$ . - . time();
open(FILE,$outputfile) || printError();
my $buffer;
while (read($inputfile,$buffer,2096)) {
print FILE $buffer;
}
close(FILE);
undef $buffer;
}
sub printError {
print header();
print Content-type: text/plain\n;
print Status: 500$\n;
print Message: Internal Error\n;
exit;
}
Cheers
--
Steve Bannerman
[EMAIL PROTECTED]
44.(0)1865.273866
RE: PerlModule options?
Hello Mike, Thanks for your answer, this should do it indeed. Super! Somehow I didn't think about perl sections... Thanks again, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net -Original Message- From: Mike P. Mikhailov [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 2:23 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: PerlModule options? Hello [EMAIL PROTECTED], Tuesday, August 05, 2003, 2:55:52 PM, you wrote: cfr Hi list, cfr One questions for the braves ;-) cfr As I understand, the directive cfr PerlModule Foo::Bar cfr loads the module but doesn't import the symbols since it is equivalent to cfr the use Foo::Bar (). Therefore I should use use Foo::Bar in each program cfr only to make the import. cfr Is there other way to load the module and import the symobols specified in cfr @EXPORT at mod_perl reloading time, without adding a special line in each cfr and every script using them? cfr Perhaps some options passed to PerlModule though adding (...) doesn't help cfr since PerlModule expects a list of modules. cfr Thanks a bunch, cfr Lian Sebe, M.Sc. cfr Freelance Analyst-Programmer cfr www.programEz.net I think this will work perl use Foo::Bar qw ( ... whatever you want to import ... ); /perl -- WBR, Mike P. Mikhailov mailto: [EMAIL PROTECTED] ICQ:280990142 I believe in God, only I spell it Nature.
Re: [mp2] Child process exited
Stas,
Thanks for the quick response.
You did load things in startup.pl, remember? some module could
override
$SIG{__WARN__}. Don't load those modules if you don't need them.
I very much doubt anything in my startup.pl would modify the signal
handlers. Here's my startup.pl, for reference:
use strict;
use warnings;
#---
# Default module inclusions as per the Apache
# mod_perl installation instructions
use Apache2 ();
use ModPerl::Util ();
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::Server ();
use Apache::ServerUtil ();
use Apache::Connection ();
use Apache::Log ();
use Apache::Const -compile = ':common';
use APR::Const -compile = ':common';
use APR::Table ();
use Apache::compat ();
use ModPerl::Registry ();
use CGI ();
#---
# General modules
use Time::localtime;
use Data::Dumper;
use Date::Calc qw(:all);
# Add the top-level directory for the modules into the module search
path.
use lib qw($ENV{SCRIPT_ROOT});
# Hybride:: modules commented out for now, until I resolve the crash
issue...
You could also try to reset it in your code:
Even with the BEGIN { ... code before anything else in my source, I
still get no warnings.
So if on your side there are warnings and not on my side, with the
same
code, then that's a problem too...
Yes, especially since you have a scoped warnings enabled explicitly in
your
file. Does you perl print this warnings when you run a test script
from the
above URL?
No. I just tried it. It does show the erroneous response (5^2 = 25 6^2 =
25) but no warnings. I also tried with the code to restore
SIG{__WARN__}, and it didn't change anything.
Apache::Reload didn't seem to want to reload my modules.
because it probably couldn't find them.
I had followed the instructions you stated before, and you can even see
my use libs in the startup.pl I included above. Let's say
$ENV{SCRIPT_ROOT} (as set in my httpd.conf with a PerlSetEnv) is set to
d:/htdocs, that means that a module being use()d as Hybride::Blah
would be found at d:/htdocs/Hybride/Blah.pm right? So Apache::Reload
should find it at the same place, since the use libs is in the startup
script.
But Apache::Reload still does not reload my modules... And as I said,
ReloadDebug On didn't even tell me if it was trying to reload them.
Nothing in my error_log, same as with the warnings.
So that's a bit weird.
Thanks,
J-S
Re: How to restart the root server from within modperl?
Thanks, I made it a bit more simple:
use POSIX;
if (! fork) { # child
setsid;
POSIX::close(0);
POSIX::close(1);
exec(restart-apache-command);
}
Works great!
Thanks,
Dirk
Torsten Foertsch writes:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 12 August 2003 11:50, Dirk Lutzebaeck wrote:
Dennis Stout writes:
On a whim, I would try writing a second script to do the actual shutdown
and restart of Apache.
Then have your mod_perl program either run it in the background (with a
) or fork it into another process.
Did exactly that but is has the effect that when the parent (root)
apache is killed it kills all children including the script itself. So
the server wont start again.
I have done something like this several times. My code (it works since 1998 on
a highly used WEB Server with perl5.005_3) looks like that:
...
sub sysclose {
require 'syscall.ph';
syscall SYS_close, shift()+0;
}
sub RLIMIT_NOFILE {7;} # this is for LINUX
sub getrlimit {
require 'syscall.ph';
my $x=xx8; # result
syscall SYS_getrlimit, shift()+0, $x;
unpack ii, $x;
}
sub close_fd {
my @l=getrlimit( RLIMIT_NOFILE );
my $l;
for( $l=0; $l$l[0]; $l++ ) {
next if( $l==2 );# close all file descriptors except of STDERR
sysclose $l;
}
}
sub disconnect_from_apache {
use POSIX qw/setsid/;
setsid;
close_fd;
}
...
my $child=fork;
unless( defined $child ) {
...
return OK;
}
if( $child ) {
my $child_status=0;
if( waitpid( $child, 0 )==$child ) {
$child_status=$?;
}
if( $child_status==0 ) {
...
return OK;
} else {
# The first fork succeeded but the second failed
...
return OK;
}
} else {
# Child process: fork again to detach from parent process
$child=fork;
CORE::exit( 0 ) if( $child ); # parent exits
unless( defined $child ) {
...
CORE::exit( 1 );
}
# Now we are the 2nd child process.
$self-disconnect_from_apache;
$self-doit( ... ); # == here comes the real code
CORE::exit( 0 );
}
...
$self-doit() is called in a separate process group and is not killed by a
signal sent to the apache process group. Further, all files save STDERR are
closed. This is needed since the code runs under mod_perl and the long
running child process inherits the open connection to the browser. If this
connection is not closed the browser shows an endless spinning globe or
something like that in the upper right corner.
Torsten
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/OSIAwicyCTir8T4RAv3RAKCXdpbHLQepeOZFCyXt1KkMVGnwPgCeNu7X
hlC1NSEv0NsA7LlM7lol7wI=
=xId6
-END PGP SIGNATURE-
Re: [JOB] Perl Web application development with small experiencedteam
Unfortunately I'm far too busy writing Webarchitects' web CMS which promotes accessibility, usability and W3C standards, (http://www.mkdoc.com/) to help. However we at webarchitects have been subcontracting various projects (both OSS and non-OSS) with Steve Purkis ([EMAIL PROTECTED]) through his London based company quiup. As an experienced Perl programmer, software engineer, and as a company director I can tell you he's good, very disciplined, and it's well worth sub-contracting with him. That is, if you want clean code, strong test suites, and projects on time. I've CCed him this reply since he might be interested. Cheers, Jean-Michel. On Tue, 2003-08-12 at 02:46, [EMAIL PROTECTED] wrote: FastMail.FM (http://www.fastmail.fm), one of the world's leading e-mail services, is hiring an expert Perl programmer to become a Web Application Developer. In this very attractive senior position, you can work flexible hours, telecommute, and develop your skills as part of a small but very experienced programming team. You will be primarily responsible for creating cool new stuff for the FastMail.FM web interface - no meetings with marketing to attend, no team building exercises to get dragged along to..., you'll be just *writing* *code* ! To join our team, you will need to be an expert in Perl, object-oriented programming, and Web development. Ideally, you will have substantial experience with mod_perl in a production environment. As a committed programmer, you should be able to show us an impressive portfolio of your work, such as in open source projects, contributing to the Perl community, or developing new frameworks in a commercial context. Since you will be telecommuting, geographic location is not important. However, you will need good written English skills to communicate with the team over IRC and email. You will also need to be able to demonstrate a high degree of discipline and commitment to complete projects on time. Salary is negotiable -- tell us what you think you're worth! Send your application to [EMAIL PROTECTED] Please send us your resume, examples of work that you have done, links to your involvement with programming communities, references (so that we can talk to people that you have worked with), and anything else that will make you stand out from the crowd. We will monitor the mailing list and answer any questions that come up of general interest. Looking forward to seeing your application, Jeremy and Rob
