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: 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-
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: How to restart the root server from within modperl?
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. Dirk
Can't locate object method header_in via package Apache::Compress
Hi,
I get the following error sporadically on modperl 1.27 and apache
1.3.26 and Apache::Compress 1.003 either under RH7.x or Solaris 7:
Can't locate object method header_in via package Apache::Compress
(perhaps you forgot to load Apache::Compress?) at
/u1/lib/perl5/site_perl/5.6.1/Apache/Compress.pm line 14.
This is the handler from Apache::Compress.pm:
use strict;
use Compress::Zlib 1.0;
use Apache::File;
use Apache::Constants qw(:common);
use vars qw($VERSION);
sub handler {
my $r = shift;
my $can_gzip = $r-header_in('Accept-Encoding') =~ /gzip/; # line 14
my $filter = lc $r-dir_config('Filter') eq 'on';
#warn can_gzip=$can_gzip, filter=$filter;
return DECLINED unless $can_gzip or $filter;
...
}
I have observed this more often on our solaris platform than on linux.
Any ideas?
Dirk
Re: Apache::Compress and Apache::Filter
Ken Williams writes:
Hi JR,
I've been avoiding this bug to my peril. Does the following patch fix it?
=
--- Filter.pm 2000/12/20 03:43:44 1.16
+++ Filter.pm 2001/04/06 05:05:24
@@ -120,8 +120,8 @@
sub send_fd {
my $self = shift;
- if ($self-is_last_filter) {
+ if ($self-is_last_filter and !Universal::isa($_[0], ref $self)) {
$self-SUPER::send_fd(@_);
} else {
my $fd = shift;
=
The bug occurs when the client doesn't support gzip, and you're using
Apache::Filter, and Apache::Compress is the final filter in the chain.
Ken, would you mind to put a new version onto cpan if it works. I had
the problem myself sometime ago but hadn't fixed it the way you
proposed but patched Apache::Compress not to use send_fd but using a
while loop.
Dirk
Re: Apache::Session::Postgres error
Hi, I would just like to tune in here. I am using Apache::Session 1.53 also with postgres and have the problem that sessions are not closed in any case. I am also using Embperl 1.3.0 but maintaining the session variable on my own. The effect is that when apache is restarted everything works fine but after some time (or heavy load) some sessions start not to store modification anymore. This culminates after a while into an usable system which needs a restart. The application code needs very careful examination for closing the session in all cases. To find out if it is the application that is not closing the session or if there is a problem in Apache::Session or in the database is very hard to track down. I checked all the application code and using vanilla Apache::Session::Store::Postgres with FOR UPDATE, ie. using locks on the session table. I would appreciate any suggestion on how to debug/find unclosed sessions on a high volume site. Eg. one could work with timeouts, this is when a session is not closed after some period of time a warning would be issued. This would help much to find out who is not closing the session. Regards, Dirk
Perl/Embperl jobs in Berlin, Germany
Sorry guys and gals the rest is in german: Wir suchen professionelle Perl-Entwickler in Berlin zur Unterstuetzung der Weiterentwicklung eines HTML-basierten Kommunikationssystems fuer die Bauindustrie. Wir haben beste Kundenkontakte und sind z.B. beim Umbau des Olympia-Stadions in Berlin (ein 700 MDM Projekt) beauftragt. Interessenten sollten mehrjaehrige Perl-, HTML- und UNIX-Erfahrung haben. Wir setzen auf Modperl, Embperl und Postgresql unter Linux und Solaris. Auf der Applikationsebene laeuft unser System ausschliesslich unter Perl. Aktuelle Themen sind XML, UTF, Adobe FDF, LDAP, Testsuites, Help System, Load Balancing, Security. Eine Demo ist freigeschaltet unter http://www.aeccom.com Wir sind ein unabhaengiges, junges und hochmotiviertes Unternehmen im Umfeld internationaler Bau-Konzerne. Alle Zeichen stehen auf Wachstum. Kontakt: Dirk Lutzebaeck AEC/communications GmbH, Berlin Email: [EMAIL PROTECTED] Tel: +49-30-639267-23 Fax: +49-30-639267-21 Web: http://www.aeccom.com
Re: User-Agent: contype
Alan Sparks writes: My tests show that it often (can't be sure of always) occurs with a PDF file. BUT, it doesn't happen with NS Communicator and Acrobat Reader... only the combo of IE and Acroread. I've long suspected that it had something to do with IE sniffing the data stream to figure out the data type. There's an old bug against IE that mentioned that IE does sniff the data stream and use its own ideas in deference to the stated MIME types and content dispositions sometimes. I've always wondered if that ties into this. I would agree to this. I have also seen that for the Autodesk Whip! Viewer. You need to give MSIE using the PDF plugin a filename ending with .pdf whatsoever. It seems not sufficient to supply the content-type and leave the URL to something like /files?give_me_my_pdf (what I was doing with Apache::File). MSIE (or the PDF plugin, I don't know) then tries to find out the content type by itself using the agent 'contype' and then issues a third request. All that seems have nothing to do with Accept-Ranges and the like. It's really a drag... Dirk
can't get unbuffered output to work
Hi, unbuffered output in a handler just doesn't work for me:
Location /unbuffered
Options ExecCGI
SetHandler perl-script
PerlHandler My::Handler
/Location
package My::Handler;
sub handler {
my $r = shift;
$r-content_type('text/html');
$r-send_http_header;
while(1) {
$r-print("bhi/b\n");
$r-rflush;
sleep(1);
}
}
If I 'GET /unbuffered' in Netscape nothing is printed until I stop the
server. Setting $|++ does not help. Something is still buffering. This
is modperl 1.21 and Apache 1.3.12.
Any clues?
Dirk
Re: can't get unbuffered output to work
Steve van der Burg writes: Hi, unbuffered output in a handler just doesn't work for me: [ details of setup and handler snipped ] If I 'GET /unbuffered' in Netscape nothing is printed until I stop the server. Setting $|++ does not help. Something is still buffering. This is modperl 1.21 and Apache 1.3.12. Any clues? Netscape is waiting for an HTML visual break of some kind before showing any output - if you modify your test handler to spew "bHello!/bp" before sleeping, you should see it. No, sorry Steve, this doesn't help. I've also tried BR and text/plain. MSIE is no different. Dirk
Re: can't get unbuffered output to work
Eric Cholet writes: Steve van der Burg writes: Hi, unbuffered output in a handler just doesn't work for me: [ details of setup and handler snipped ] If I 'GET /unbuffered' in Netscape nothing is printed until I stop the server. Setting $|++ does not help. Something is still buffering. This is modperl 1.21 and Apache 1.3.12. Any clues? Netscape is waiting for an HTML visual break of some kind before showing any output - if you modify your test handler to spew "bHello!/bp" before sleeping, you should see it. No, sorry Steve, this doesn't help. I've also tried BR and text/plain. MSIE is no different. I've noticed that MSIE doesn't start displaying stuff until it has a certain amount, say a few hundred bytes. After that it displays just fine. No, doesn't seem to matter in my case. Is there any place I can verify that Apache has sent some data to the client? Dirk
Re: can't get unbuffered output to work
Chip Turner writes: Dirk Lutzebaeck [EMAIL PROTECTED] writes: I've noticed that MSIE doesn't start displaying stuff until it has a certain amount, say a few hundred bytes. After that it displays just fine. No, doesn't seem to matter in my case. Is there any place I can verify that Apache has sent some data to the client? You can always use the definitive test of tcpdump on the client machine. Something like (on linux): /usr/sbin/tcpdump -s 4096 -w packets.out src (host) and port 80 Then examine packets.out for what data is returned in which packets. With a large enough sleep in the modperl code, it should come pretty much in its own packet. This will pretty much give you complete certainty on what the client receives and when the client receives it. Ok, I'll check this. Umm, I forget to say that I'm using mod_ssl, ie. it is an SSL-request. Maybe it buffers something? Dirk
RE: unbuffered proxying [was: can't get unbuffered output to work]
Sheth, Niraj writes: I also had the same problem, but withouth ssl. i could think of two solution. 1. Modify front end apache's source code manually( i guess default is HUGE_STRING_LEN (8k)), but it sounds little scary .. so i opted for second choice ... 2. in your perl script ... print "something ...\n"; my $lines = "\n" x 4096; print $lines; # now proxy server is happy at this point. Yes, thanks I just tried it, it works! The only drawback is that I have to send always 4k possibly over slow lines to get some timely messages across... Dirk
Re: Solution for: Re: $ENV{PATH} set by mod_perl script affects mod_cgi scripts
Ben Cohen writes:
Go to the line that reads:
eval { {$cv}($r, @_) } if $r-seqno;
I love perl :)
Dirk
Re: Security in displaying arbitrary HTML
Matt Sergeant writes: Unfortunately there's also a browser bug to contend with. They treat \x8b (I think that's the right code) as and there's a similar code for . Since most web developers are just doing s//lt;/g; they are open to attacks based on character sets like this. Sad, but true. Even our loved CGI.pm was (is?) open to this bug - I think Lincoln has fixed the HTMLEncode function now though. Gerald, what about Embperl, does it escape \x8b? Dirk
Re: Security in displaying arbitrary HTML
Matt Sergeant writes: Unfortunately there's also a browser bug to contend with. They treat \x8b (I think that's the right code) as and there's a similar code for . Since most web developers are just doing s//lt;/g; they are open to attacks based on character sets like this. Sad, but true. Even our loved CGI.pm was (is?) open to this bug - I think Lincoln has fixed the HTMLEncode function now though. Gerald, what about Embperl, does it escape \x8b? Dirk
Embperl 1.2b9: [error] Modification of a read-only value attempted
Totally weird. Suddenly I get the following error message after
uploading a file:
[error] Modification of a read-only value attempted a
t /local/lib/perl5/site_perl/5.005/i386-linux/HTML/Embperl.pm
I think I haven't changed a thing but maybe I'm just stoned...
This is on Embperl 1.2b9 apache 1.3.9 which works flawlessly for
months...
The offending line in Embperl.pm is
if (ref($fdat{$_}) eq 'Fh')
{
${${$fdat{$_}}} = $cgi - uploadInfo($fdat{$_}) ;
}
}
I turned on embperl debugging but I don't know what went wrong.
The HTML code is trivial:
p file is [+ $fdat{'fn'} +]
form
input type=file name="file_name" size=40
input type=submit
/form
Embperl debug says:
[5488]REQ: Embperl 1.2b9 starting... Fri Feb 4 16:38:04 2000
[5488]REQ: No Safe Eval All Opcode allowed mode = mod_perl (3)
[5488]REQ: Package = HTML::Embperl::DOC::_4
[5488]FORM: file_name=2001_3000_5.csv
And then stops...
Gerald, do you have any opinion on this?
Dirk
Re: can't download file with MSIE 5 using modperl
Matt Arnold writes: I have written an Apache::Registry script which uses CGI.pm to accomplish the same thing. And I'm shocked and amazed that setting the Content-Disposition actually works -- even for IE5. Given how little attention Content-Disposition seems to get, I'm afraid that my users will want to run a browser where it doesn't work. Have you run into troubles with weird browsers not understanding the Content-Disposition header? Anyway, sorry I can't offer any insights as to why it doesn't work for you. The only thing that I'm doing differently is not setting the content-length. Matt, I think I have resolved the issue now by using $r-cgi_header_out and $r-send_cgi_header. I'll have to see what they are doing exactly but Content-disposition seems to work for NS 4.6, MSIE 4.0 and MSIE 5.0 Dirk
can't download file with MSIE 5 using modperl
Hi,
I have a script to allow dynamic downloading of files which works for
netscape and MSIE 4 but not for MSIE 5:
DOCDIR/PERL/file.pl:
use Apache::Constants;
$r = Apache-request;
open(FILE, "/tmp/o.pdf");
$r-status(OK);
$r-header_out("Content-Disposition", "attachment; filename=\"o.pdf\"");
$r-header_out("Content-Length", 6247);
$r-content_type("application/pdf");
$r-send_http_header;
$r-send_fd(FILE);
close(FILE);
in httpd.conf:
Location /PERL
Options ExecCGI
SetHandler perl-script
PerlHandler Apache::Registry
PerlAuthenHandler CS::Cookie-authen
PerlAuthzHandler CS::Cookie-authz
PerlSetVar CookieAuthPath /
PerlSetVar CookieAuthLoginScript /login/index.html
AuthType CS
AuthName CookieAuth
require valid-user
/Location
Hitting the link on a href="/PERL/file.pl"file/a gives an error on
MSIE5 saying the page couldn't be opened. This works perfectly on
netscape and MSIE 4...
Any clues?
Dirk
