Detecting and linking to Apache::Status
For the next release of my RPC::XML package, I plan to roll out a status tracker akin to Apache::Status in mod_perl, only to monitor/examine the RPC servers being managed by the mod_perl-ennabled Apache server. I would like to have the main page of this Apache::RPC::Status system offer a link to /perl-status, or whatever the correct URI is, if Apache::Status is available. Is there a way to detect whether Apache::Status is assigned to a location as a handler, and if so, what the URI for this handler is? On a related note, how much information is available to me at run-time about other locations? Is it possible to tell things like authorization settings, etc., about a URI from within a running mod_perl? Randy -- --- Randy J. Ray | Men occasionally stumble over the truth, but most of them [EMAIL PROTECTED] | pick themselves up and hurry off as if nothing had happened. +1 408 543-9482 | -- Sir Winston Churchill
Re: Detecting and linking to Apache::Status
Randy J. Ray wrote: For the next release of my RPC::XML package, I plan to roll out a status tracker akin to Apache::Status in mod_perl, only to monitor/examine the RPC servers being managed by the mod_perl-ennabled Apache server. I would like to have the main page of this Apache::RPC::Status system offer a link to /perl-status, or whatever the correct URI is, if Apache::Status is available. I would go the other way - add your handler right to Apache::Status. so, basically /perl-status would have Perl Configuration ... Apache::RPC Status of course, the cookbook has a recipe on how to do this, but you can find the relevant info in the Apache::Status manpage :) Is there a way to detect whether Apache::Status is assigned to a location as a handler, and if so, what the URI for this handler is? not really, but you won't need to know this if you hang your routine off of Apache::Status directly. On a related note, how much information is available to me at run-time about other locations? Is it possible to tell things like authorization settings, etc., about a URI from within a running mod_perl? look into subrequests... --Geoff
Re: PerlWarn and syslog
Since this section ss probably going away, here it is:
The syslog solution can be implemented using the following
configuration:
LogFormat %h %l %u %t \%r\ %s %b common
CustomLog | /usr/local/apache/bin/syslogger.pl hostnameX common
where a simple Isyslogger.pl can look like this:
syslogger.pl
#!/usr/bin/perl
use Sys::Syslog qw(:DEFAULT setlogsock);
my $hostname = shift || 'localhost';
my $priority = 'ndelay'; # open the connection immediately
my $facility = 'local0'; # one of local0..local7
my $priority = 'info'; # debug|info|notice|warning|err...
setlogsock 'unix';
openlog $hostname, $priority, $facility;
while () {
chomp;
syslog $priority, $_;
}
closelog;
[snip]
Hmm. Why is priority redefined? Seems like you'll lose your ndelay param. I
think you mean to do something like:
my $hostname = shift || 'localhost';
my $options = 'ndelay'; # open the connection immediately
my $facility = 'local0'; # one of local0..local7
my $priority = 'info'; # debug|info|notice|warning|err...
setlogsock 'unix';
openlog $hostname, $options, $facility;
while () {
chomp;
syslog $severity, $_;
}
closelog;
The problem with this solution is all logs from apache will now have the
same priority, and they were made up by me. I'd like to keep the same
priority which apache set.
Thanks for all the help so far. I appreciate the quick responses.
-Lance
[JOB] web/systems programming position at TAMU
Texas AM University just opened a position for a software applications developer. You would be working (most likely) with me developing web applications and other code to enable system functions. You would need to relocate to the Bryan/College Station area. Notice of vacancy: http://cis.tamu.edu/about/jobs/positions/241.html Job Title: Software Applications Developer Department: Computing and Information Services Salary: $36,250 - $40,250 (negotiable based on qualifications and experience) Start Date: ASAP Security Sensitive: No Major/essential duties of job: Function as a software applications developer on complex network-based projects. Provide consulting, technical support, and training to users of custom application software and technical staff. Develop interfaces to systems applications such as e-mail and directory services. Develop web-based applications that operate in large, multi-user environments. Occasional duties: Provide technical support to other CIS groups in areas of expertise. Develop and maintain documentation for applications including e-mail and directory services systems. Educational qualifications: Bachelor's degree or any equivalent combination of education and relevant experience (1 yr experience equals 1 yr education). Work experience: Two (2) years of software applications development. Experience programming in UNIX and web environments using Perl, C, C++, PHP (the more, the merrier). System administration experience is a plus. See http://cis.tamu.edu/about/jobs/ for links to Human Resources, etc. If you are interested in the job, please submit your resume and application to HR with a reference to the job number (020427). About the group: Homepage for my group: http://cis.tamu.edu/systems/opensystems/ We are a very open and affirming group about many things, including the use of open source software. Several people regularly attend LISA and other similar events. We do make use of commercial products when it seems prudent. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Apache::Filter Help Please!!
Please see if you notice anything glaringly wrong in what I'm doing.
Basically my problem is that my filter isn't passing data along, eg what I
print in filter1 isn't getting output, even though filter2 get's the
filehandle and loops over it. My setup is pretty akin to what the docs offer
in the synopsis.
in httpd.conf
--
PerlModule Apache::Filter
Files support
SetHandler perl-script
PerlSendHeader ON
PerlSetVar Filter On
PerlHandler Filter1 Filter2
/Files
in the filters
---
sub handler
{
my $r = shift;
$r = $r-filter_register();
my ($fh, $status) = $r-filter_input();
return $status unless $status == OK;
while($fh)
{
print;
}
print Filter 2; #filter 1 has filter1, obviously
return OK;
}
now, according to what I've read, this should print out the Filter 1Filter
2, which is what I need to let me get real work done, but all I get is
Filter 2. So all powerful list, WTF am I missing (it's gotta be something
obvious, it always is).
--
Jayce^
Re: Apache::Filter Help Please!!
I tried out your config and handlers pretty much verbatim and got them to work just fine. the only real change was that I needed to comment out return $status unless $status == OK; from filter one, since $fh is $r-filename for the first filter, which brings up 404 when the file is not found. that said, yes I see the same thing, but only for 404s. I think the problem is that you need to deal with your error code properly. now, according to what I've read, this should print out the Filter 1Filter 2, which is what I need to let me get real work done, but all I get is Filter 2. So all powerful list, WTF am I missing (it's gotta be something obvious, it always is). $fh is $r-filename for the first filter in the chain. if $r-filename does not exist, you need to handle this. $status is one way of handling it. checking for $fh (which will be undef if $r-filename does not exist) is another. basically, you definitely don't want to read from $fh if $fh is not defined :) this situation should probably be protected against in Apache::Filter better, but it basically looks like it is a problem with your logic. HTH --Geoff
Re: Apache::Filter Help Please!!
ok, that make sense, so I modified my filter1 to just register the filter, print out some text, and return ok, that's it. and it still doesn't print anything if filter2 comes after it? Does that sound wrong to anybody but me? On Friday 07 December 2001 12:47 pm, you wrote: I tried out your config and handlers pretty much verbatim and got them to work just fine. the only real change was that I needed to comment out return $status unless $status == OK; from filter one, since $fh is $r-filename for the first filter, which brings up 404 when the file is not found. that said, yes I see the same thing, but only for 404s. I think the problem is that you need to deal with your error code properly. now, according to what I've read, this should print out the Filter 1Filter 2, which is what I need to let me get real work done, but all I get is Filter 2. So all powerful list, WTF am I missing (it's gotta be something obvious, it always is). $fh is $r-filename for the first filter in the chain. if $r-filename does not exist, you need to handle this. $status is one way of handling it. checking for $fh (which will be undef if $r-filename does not exist) is another. basically, you definitely don't want to read from $fh if $fh is not defined :) this situation should probably be protected against in Apache::Filter better, but it basically looks like it is a problem with your logic. HTH --Geoff -- Jayce^
Re: Apache::Filter Help Please!!
Jason Hall wrote:
ok, that make sense, so I modified my filter1 to just register the filter,
print out some text, and return ok, that's it. and it still doesn't print
anything if filter2 comes after it? Does that sound wrong to anybody but me?
try this:
package One;
use Apache::Constants qw(OK);
use strict;
sub handler {
my $r = shift;
$r = $r-filter_register();
print Filter 1;
return OK;
}
1;
package Two;
use Apache::Constants qw(OK);
use strict;
sub handler {
my $r = shift;
$r = $r-filter_register();
my ($fh, $status) = $r-filter_input();
return $status unless $status == OK;
$r-send_http_header('text/plain');
while($fh) {
print;
}
print Filter 2;
return OK;
}
1;
looks like if you don't send your headers things go slightly amuck.
--Geoff
Re: Apache::Filter Help Please!!
AHAH!!! I found it.. thanks, your example showed the difference.
What it was is that I was sending my header before my final filter, which as
I now am guessing, maps STDOUT, which this needs. I'm recommending to the
author to put a note in about where the headers should be printed.
Thanks for your help, definately made the difference
On Friday 07 December 2001 01:10 pm, you wrote:
Jason Hall wrote:
ok, that make sense, so I modified my filter1 to just register the
filter, print out some text, and return ok, that's it. and it still
doesn't print anything if filter2 comes after it? Does that sound wrong
to anybody but me?
try this:
package One;
use Apache::Constants qw(OK);
use strict;
sub handler {
my $r = shift;
$r = $r-filter_register();
print Filter 1;
return OK;
}
1;
package Two;
use Apache::Constants qw(OK);
use strict;
sub handler {
my $r = shift;
$r = $r-filter_register();
my ($fh, $status) = $r-filter_input();
return $status unless $status == OK;
$r-send_http_header('text/plain');
while($fh) {
print;
}
print Filter 2;
return OK;
}
1;
looks like if you don't send your headers things go slightly amuck.
--Geoff
--
Jayce^
Re: Apache::Filter Help Please!!
Jason Hall wrote:
AHAH!!! I found it.. thanks, your example showed the difference.
What it was is that I was sending my header before my final filter, which as
I now am guessing, maps STDOUT, which this needs.
well, you should be able to print your headers from any filter in the
chain - they are a no-op for all but the final filter.
package One;
use Apache::Constants qw(OK);
use strict;
sub handler {
my $r = shift;
$r = $r-filter_register();
$r-send_http_header('text/plain');
print Filter 1;
return OK;
}
1;
should work just as well...
I'm recommending to the
author to put a note in about where the headers should be printed.
Thanks for your help, definately made the difference
no problem :)
--Geoff
cvs commit: modperl-2.0/ModPerl-Registry TODO
stas01/12/07 10:12:17 Modified:ModPerl-Registry TODO Log: - todo: need to properly handle HEAD requests Revision ChangesPath 1.7 +2 -0 modperl-2.0/ModPerl-Registry/TODO Index: TODO === RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/TODO,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- TODO 2001/11/23 16:26:31 1.6 +++ TODO 2001/12/07 18:12:17 1.7 @@ -13,6 +13,8 @@ ### missing features ### +- need to properly handle HEAD requests + - need to port $Apache::__T, to test against when user supplies -T flag. - port Apache::PerlRunXS
