Apache::Site [WAS] Re: Segmentation fault
We already did this! The question is - with 2 apache config, proxy-front-end apache logs every request, even if power apache daemon crushed with segfault, simple-proxy daemon logs request with URI and 502 status. We know time of segfault and can find 502 request in access logs with such time, and we can find out a request, wich causes seg fault. All right. It's working for 2 apache config. If we use simple 1 apache daemon, I think, we will have in logs segfault message only. Is there way to find out segfault request for simple configuration ? Provide a custom loghandler, which runs before the content generation phase or whichever phase the segfault happens at. Though you won't know the status, but there is nothing you can do after segfault. Or I can think of two steps handler, which let's say logs something before the potentially segfaulting handler and the status after the handler is run. So in case of segfaults the status will be missing. (First of all, sorry for gruesome english) Thank you for response. As I understand, with simple configuration we should assign global URI translation (for instance) handler where we will log request's URI. After segfault we can find (via awk or other text processor) logged URI without status. Right? Huh... I think installation of mod_accel or mod_proxy front-end is simpler solution. Thank you again and I will be happy to hear some feedback from mod_perl guru about module, which was developed by my team. It's another framework and Matt Sergeant compared it with Mason although it is much simpler and we purposed other aims. Our target was to ease implementing web application as Apache handler, because, we consider web site not a collection of html generating page-scripts, (Apache::Registry, ASP and many other technix way), but whole application with one entry point - Apache handler. We think that URI processing and translating is a task of application, at any case for projects such large e-shop or central online information portal of region. Another aim was to integrate TemplateToolkit usage as standart output technique - it is excellent app, although descendant from our module can return another status (redirect and others) or generate output via another way freely. Our module helps to maintain high performance web application as pure Apache handler is fast and easy and programmer focuses on business tasks of site only. I put part of our programmer's letter below and ask - is there future for such module? | We develope the Module that will be capable of: | * use simple interface for dynamic site creating (and dynamic parts for | any almost static site); | * use simple urls with no query strings at all; | * use smart templates (standard header and footer, for example). | | That very early beta works on: | * http://www.neftechimia.ru/en/ -- business site | * http://review.samara.ru/ -- newspaper site | | Note that the module is filter-aware and on Neftechimia there is AxKit | postprocessing | (that slowers down overall request performance six(!!!) times (I think this | may be changed | with new AxKit's Provider) but simplifies site supporting for | non-professional webmaster | -- all templates may be changed through the web-interface) | | III. THE FUTURE | | Though we need some advices: | * is there any need for such thing? | * if so, which name we should choose (it's Apache::Site for now)? | * what features must it also have? | * what do you think about it? | | IV. THE CODE | | As I said above it is very early beta. No POD, Comments only. | * http://www.webzavod.ru/software/Apache-Site.tar.gz | | V. THE AUTHOR | | Gregory Grishace [gree-shah-s] Belenky | WebZavod (http://www.webzavod.ru/) programmer | Sergey Polyakov aka BeerBong Chief of WebZavod http://www.webzavod.ru Tel. +7 (8462) 43-93-85 | +7 (8462) 43-93-86 mailto:[EMAIL PROTECTED]
Re: [OT-ish] Session refresh philosophy
You've addressed the issue of someone submitting a form with altered fields to attack the server, and pointed out some more advantages, but I don't think you've addressed the issue of protecting the hidden cleartext data from others on the client side. True. But to tackle these concerns, SSL looks like a better approach to me. If the client doesn't do any math/crypto/secret stuff at all, an attacker that is on the same subnet can both spy on secrets (egress passwords or private data, ingress session IDs or cookies) and take over sessions (just by changing IPs - no need to even hijack TCP connections since they are short-lived in HTTP) - and then there is nothing that the victim could do that the attacker cannot. The point is, secrets pass over the wire in the clear at a moment or another, so encrypting them for all transfers but the first one only earns a marginal amount of security. This is not to say I don't enjoy using the various state storage mechanisms described in the thread. They are highly useful but I think that the encryption part of them only addresses problems on the server side and are useless under certain forms of site design. -- Dominique QUATRAVAUX Ingénieur développeur sénior 01 44 42 00 35 IDEALX
Re: Use of uninitialized value. with no line number in error log
perl sighandlers require the signal as their first argument. so i assume
that it may not be a good idea to call Carp::cluck(), as any of the Carp
methods expect strings. try typing as follows:
$SIG{WARN} = sub { Carp::cluck (received signal shift() at
line.__LINE__) };
martin
Tim Noll wrote:
Stas Bekman wrote:
I know this is a pretty generic question, but if nobody knows a quick
answer, I can get more specific in a later post. Under Apache 1.3.22 /
mod_perl 1.26, even while using $SIG{__WARN__} = \Carp::cluck, I keep
getting Use of uninitialized value. in the Apache error log, with
absolutely no line number or back trace or anything else. Does anybody
know
what might cause this? Thanks.
Where did you set $SIG{__WARN__}? Try in startup.pl as early as possible.
It's set in startup.pl, which is basically a modified version of the example
from perl.apache.org/guide. It works beautifully for every other error I've
come across, which is why this one is so curious. As I mention in my earlier
follow-up to my own post, I eventually traced the problem to an incorrect
driver string in DBI-connect. However, that doesn't explain (to me anyway)
why I wasn't getting more detail in the error log. Perhaps I'll delve into
DBI.pm, unless someone can explain this to me beforehand.
-Tim
--
http://www.meome.de
--
Martin Haase-Thomas | Tel.: 030 43730-558
meOme AG| Fax.: 030 43730-555
Software Development| [EMAIL PROTECTED]
--
Re: Anyone for JavaScript question
The simple onUnload() construction will not work. You will have to open a new browser window on unload displaying the output of your server program. martin Medi Montaseri wrote: I know this is off topic, but I thought someone could use a break... Given a page called xyz.html, I want to measure the amount of time a user spent on this screen (or page) along with other usability metrics. So I figured I'll use JavaScript since its running the entire time the page is up. Then I decided to use onload() and onunload() events to determine start and end of the session. The onload() part is easy. However when onunload() event happens, I need to execute a server side program and feed it the data that was collected. So I figured I setup a dumy form and invoke form.submit() onUnload. Would this work or is there a better method. I also thought about a redirect followed by another rediect to where the user wanted to go, but that gets too browser dependent and I don't like it when others hijak my browser. -- - Medi Montaseri [EMAIL PROTECTED] Unix Distributed Systems EngineerHTTP://www.CyberShell.com CyberShell Engineering - -- http://www.meome.de -- Martin Haase-Thomas | Tel.: 030 43730-558 meOme AG| Fax.: 030 43730-555 Software Development| [EMAIL PROTECTED] --
Re: [OT] Re: Anyone for JavaScript question
hi nigel, i never tried aou JSRS before, so i can't judge about it. but posting the data to a hidden frame might not work on an unload event. imagine the user types in another url and löeaves the whole frameset. but now we're running far WOT ... :) martin Nigel Hamilton wrote: Hi Martin, You could try posting the form to a hidden frame or you could use Javascript remote scripting (JSRS) to communicate the onUnload event to your server. Nigel -- http://www.meome.de --- Martin Haase-Thomas | Tel.: 030 43730-558 meOme AG| Fax.: 030 43730-555 Software Development| [EMAIL PROTECTED] ---
Re: Use of uninitialized value. with no line number in error log
Martin Haase-Thomas wrote:
perl sighandlers require the signal as their first argument. so i assume
that it may not be a good idea to call Carp::cluck(), as any of the Carp
methods expect strings. try typing as follows:
$SIG{WARN} = sub { Carp::cluck (received signal shift() at
line.__LINE__) };
Sorry Martin, but this is incorrect. There is no signal SIGWARN.
$SIG{__WARN__} and $SIG{__DIE__} are special perl signal handlers,
which accept the string as the first argument (actually expect a list).
This has no effect:
perl -MCarp -le '$SIG{WARN} = sub { Carp::cluck (received signal
shift() at line.__LINE__) }; warn doh, doh'
dohdoh at -e line 1.
While this does:
perl -MCarp -le '$SIG{__WARN__} = sub { Carp::cluck (received signal
shift() at line.__LINE__) }; warn doh, doh'
received signal shift() at line1 at -e line 1
main::__ANON__('dohdoh at -e line 1.^J') called at -e line 1
The Carp::cluck trick is correct, unless someone somewhere redefines
$SIG{__WARN__}.
martin
Tim Noll wrote:
Stas Bekman wrote:
I know this is a pretty generic question, but if nobody knows a quick
answer, I can get more specific in a later post. Under Apache 1.3.22 /
mod_perl 1.26, even while using $SIG{__WARN__} = \Carp::cluck, I keep
getting Use of uninitialized value. in the Apache error log, with
absolutely no line number or back trace or anything else. Does anybody
know
what might cause this? Thanks.
Where did you set $SIG{__WARN__}? Try in startup.pl as early as
possible.
It's set in startup.pl, which is basically a modified version of the
example
from perl.apache.org/guide. It works beautifully for every other error
I've
come across, which is why this one is so curious. As I mention in my
earlier
follow-up to my own post, I eventually traced the problem to an incorrect
driver string in DBI-connect. However, that doesn't explain (to me
anyway)
why I wasn't getting more detail in the error log. Perhaps I'll delve
into
DBI.pm, unless someone can explain this to me beforehand.
-Tim
--
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Use of uninitialized value. with no line number in error log
you're right, i forgot about those two perl signals.
ashamed
martin
Stas Bekman wrote:
Martin Haase-Thomas wrote:
perl sighandlers require the signal as their first argument. so i
assume that it may not be a good idea to call Carp::cluck(), as any
of the Carp methods expect strings. try typing as follows:
$SIG{WARN} = sub { Carp::cluck (received signal shift() at
line.__LINE__) };
Sorry Martin, but this is incorrect. There is no signal SIGWARN.
$SIG{__WARN__} and $SIG{__DIE__} are special perl signal handlers,
which accept the string as the first argument (actually expect a
list). This has no effect:
perl -MCarp -le '$SIG{WARN} = sub { Carp::cluck (received signal
shift() at line.__LINE__) }; warn doh, doh'
dohdoh at -e line 1.
While this does:
perl -MCarp -le '$SIG{__WARN__} = sub { Carp::cluck (received signal
shift() at line.__LINE__) }; warn doh, doh'
received signal shift() at line1 at -e line 1
main::__ANON__('dohdoh at -e line 1.^J') called at -e line 1
The Carp::cluck trick is correct, unless someone somewhere redefines
$SIG{__WARN__}.
martin
Tim Noll wrote:
Stas Bekman wrote:
I know this is a pretty generic question, but if nobody knows a quick
answer, I can get more specific in a later post. Under Apache
1.3.22 /
mod_perl 1.26, even while using $SIG{__WARN__} = \Carp::cluck, I
keep
getting Use of uninitialized value. in the Apache error log, with
absolutely no line number or back trace or anything else. Does
anybody
know
what might cause this? Thanks.
Where did you set $SIG{__WARN__}? Try in startup.pl as early as
possible.
It's set in startup.pl, which is basically a modified version of the
example
from perl.apache.org/guide. It works beautifully for every other
error I've
come across, which is why this one is so curious. As I mention in my
earlier
follow-up to my own post, I eventually traced the problem to an
incorrect
driver string in DBI-connect. However, that doesn't explain (to me
anyway)
why I wasn't getting more detail in the error log. Perhaps I'll
delve into
DBI.pm, unless someone can explain this to me beforehand.
-Tim
--
http://www.meome.de
---
Martin Haase-Thomas | Tel.: 030 43730-558
meOme AG| Fax.: 030 43730-555
Software Development| [EMAIL PROTECTED]
---
LDAP authentication
Hi! I have SunOS 5.8 machine and apache 1.3.22 with mod_perl 1.26 on it. Now I'm trying to install in apache authentication against LDAP server. So I installed AuthenLDAP module. But when I try to go to the directory in browser, apache says - Internal Server Error, and in error.log file I see Undefined subroutine Apache::AuthenLDAP::handler called. OK. I try to investigate the problem and add 'PerlModule Apache::AuthenLDAP' in httpd.conf And now when making 'apachectl configtest' I get this error ': -- Syntax error on line 348 of /usr/local/apache/conf/httpd.conf: Can't load '/usr/local/lib/perl5/5.6.1/sun4-solaris/auto/IO/IO.so' for module IO : ld.so.1: /usr/local/apache/bin/httpd: fatal: relocation error: file /usr/local/lib/perl5/5.6.1/sun4-solaris/auto/IO/IO.so: symbol main: referenced symbol not found at /usr/local/lib/perl5/5.6.1/sun4-solaris/XSLoader.pm line 75. at /usr/local/lib/perl5/5.6.1/sun4-solaris/IO.pm line 9 Compilation failed in require at /usr/local/lib/perl5/5.6.1/sun4-solaris/IO/Handle.pm line 256. BEGIN failed--compilation aborted at /usr/local/lib/perl5/5.6.1/sun4-solaris/IO/Handle.pm line 256. Compilation failed in require at /usr/local/lib/perl5/5.6.1/sun4-solaris/IO/Socket.pm line 11. BEGIN failed--compilation aborted at /usr/local/lib/perl5/5.6.1/sun4-solaris/IO/Socket.pm line 11. Compilation failed in require at /usr/local/lib/perl5/site_perl/5.6.1/Net/LDAP.pm line 8. BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.6.1/Net/LDAP.pm line 8. Compilation failed in require at /usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenLDAP.pm line 269. BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenLDAP.pm line 269. Compilation failed in require at (eval 3) line 3. -- What may be the problem in? -- Andrew.
Apache::TaintRequest article on perl.com
not sure if everyone here pays attention to perl.com on a daily basis, but Paul Lindner's article on Apache::TaintRequest showed up yesterday... from the perl.com email newsletter... Cross-site scripting attacks are a surprisingly little-known and surprisingly dangerous problem for anyone writing dynamic web content. Paul Lindner, author of the mod_perl Cookbook tells us what cross-site scripting is all about, and how we can use a little bit of mod_perl magic to avoid it. http://www.perl.com/pub/a/2002/02/20/css.html --Geoff
Apache::Subprocess availability
After compiling and installing mod_perl 1.26 I do not see Apache::Subprocess anywhere. Is it a separate module ? If so how do you get it; http://perl.apache.org/dist/contrib/ did not have it either. Thanks for the insight, Balazs
Re: Apache::Subprocess availability
On Thu, 21 Feb 2002, Balazs Rauznitz wrote: Date: Thu, 21 Feb 2002 08:52:54 -0500 From: Balazs Rauznitz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Balazs Rauznitz [EMAIL PROTECTED] Subject: Apache::Subprocess availability After compiling and installing mod_perl 1.26 I do not see Apache::Subprocess anywhere. Is it a separate module ? If so how do you get it; http://perl.apache.org/dist/contrib/ did not have it either. Thanks for the insight, Balazs Balazs, First, it's Apache::SubProcess (with a capital P), and it's not installed by default. You can snag it from CPAN in the /modules/by-module/Apache/ directory (or use the CPAN shell [as root]: perl -MCPAN -e 'install Apache::SubProcess' ky
ANNOUNCE Bricolage-Devel 1.3.0
Announcing the release of Bricolage 1.3.0. This is a development release for the forthcoming 1.4.0 release. It features many bug fixes planned for the forthcoming 1.2.1 release, as well as a new feature: A SOAP server. The SOAP server will enable automatic publishing of content, as well as importing and exporting assets. Here's a brief description of Bricolage: Bricolage is a full-featured, opne-source, enterprise-class content management system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete programming \ language support for flexibility, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository. More information on Bricolage can be found on its home page. http://bricolage.thepirtgroup.com/ And it can be downloaded from SourceForge. http://sourceforge.net/project/showfiles.php?group_id=34789 Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.(sm)
[JOB] Web Site Development in Downtown Toronto
Novator Systems LTD http://www.novator.com/, founded in 1994, is looking for two Perl zealots to start immediately. - Apache, mod_perl, embperl, XML/XSLT, Linux, Solaris; - High up time, high volume, production environment; - Internal framework development; - Small teams; - Agile (XP-ish) development style; - Lots of new projects; - Casual atmosphere; Send resumes and salary expectations to Tara Lampert, [EMAIL PROTECTED] = Reginald Braithwaite-Lee http://www.braithwaite-lee.com/ __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com
Apologyze, Please delete my last message
Please delete my last message I apologyze because i make a mistake in my last message. I was sending an internal mail and the To field was with mod_perl and i put the real destinations in the CC section. Sorry Again. Hans Poo
Re: method handlers and push_handlers / set_handlers
Stas Bekman wrote:
Tim Noll wrote:
Is there a proper way to call a method handler using either
push_handlers or
set_handlers? They both appear to call all handler refs just like normal
subs, with no class name passed in. It appears that enclosing the
handler in
an anonymous sub is a workaround, but I was wondering if there was a
better
solution.
# does not call handler as a method
$r-push_handlers( PerlHandler = \Apache::Test::handler );
# does call handler as a method
$r-push_handlers( PerlHandler = sub { Apache::Test-handler } );
See
http://perl.apache.org/guide/config.html#Perl_Method_Handlers, the eagle
and cookbook books.
PERL_METHOD_HANDLERS=1 + $$ prototype for Apache::Test::handler
My question was really about the proper way to call method handlers from
either push_handlers or set_handlers since the normal technique (first
example above) calls them as normal subs, i.e. the first parameter is not
the class name. The second example, however, seems to do the trick. I just
wanted to know whether there was a better technique and/or any pitfalls to
this technique. While searching around the web a bit more today, I came
across the example below from the mod_perl_method_handlers man page, which
seems to be similar, so I guess I'm on the right track. However, any
comments would still be appreciated.
snip
$r-push_handlers(PerlHandler =
sub {
my $r = shift;
$self-perl_handler_method($r);
}
);
/snip
-Tim
Re: method handlers and push_handlers / set_handlers
My question was really about the proper way to call method handlers from
either push_handlers or set_handlers since the normal technique (first
example above) calls them as normal subs, i.e. the first parameter is not
the class name. The second example, however, seems to do the trick. I just
wanted to know whether there was a better technique and/or any pitfalls to
this technique. While searching around the web a bit more today, I came
across the example below from the mod_perl_method_handlers man page, which
seems to be similar, so I guess I'm on the right track. However, any
comments would still be appreciated.
snip
$r-push_handlers(PerlHandler =
sub {
my $r = shift;
$self-perl_handler_method($r);
}
);
/snip
you need to push the handler by name
$r-push_handlers(PerlHandler = 'My::Handler');
at least until this patch makes it into mod_perl core...
http://marc.theaimsgroup.com/?l=apache-modperl-devm=101164617829467w=2
(though I forgot what the patch was for :)
at any rate, see the latter part of recipe 10.3 :)
--Geoff
Re: When handlers misfire
On Wednesday 20 February 2002 07:55 pm, Geoffrey Young wrote: If the redirected request needs that session data, there's a small chance it won't be there yet. have you seen this? I don't recall this ever coming up before (which doesn't mean it can't happen :) Yes, I have seen it happen. Quite frequently in fact. My investigation into the problem is how I discovered the cleanup handler wasn't doing its job in time. perhaps your post-content code in a PerlLogHandler instead of a PerlCleanupHandler might help if you are running into problems. the browser isn't released from the current connection until logging is complete, so there wouldn't be the chance that a redirect would be processed before the session is created. I moved the session cleanup phase to a PerlLogHandler and it seems to be working, except for one small issue. Request URIs for directories (i.e. no filename specified) don't seem to trigger the log handler. I put some warnings in the code to trace its execution. The following is a dump of my logs following a test run: [Thu Feb 21 15:02:46 2002] [warn] SessionPrepare called for GET /iddb/target/index.pl [Thu Feb 21 15:02:46 2002] [warn] SessionPrepare called for GET /iddb/target/index.pl [Thu Feb 21 15:03:15 2002] [warn] SessionPrepare called for POST /iddb/target/login.pl [Thu Feb 21 15:03:15 2002] [warn] SessionCleanup called for POST /iddb/target/login.pl [Thu Feb 21 15:03:15 2002] [warn] SessionPrepare called for GET /iddb/target/list-portals.pl [Thu Feb 21 15:03:16 2002] [warn] SessionCleanup called for GET /iddb/target/list-portals.pl [Thu Feb 21 15:03:18 2002] [warn] SessionPrepare called for GET /iddb/target/index.pl [Thu Feb 21 15:03:18 2002] [warn] SessionPrepare called for GET /iddb/target/index.pl [Thu Feb 21 15:03:18 2002] [warn] SessionPrepare called for GET /iddb/target/list-portals.pl [Thu Feb 21 15:03:19 2002] [warn] SessionCleanup called for GET /iddb/target/list-portals.pl [Thu Feb 21 15:04:36 2002] [warn] SessionPrepare called for GET /iddb/target/index.pl [Thu Feb 21 15:04:37 2002] [warn] SessionCleanup called for GET /iddb/target/index.pl [Thu Feb 21 15:04:37 2002] [warn] SessionPrepare called for GET /iddb/target/list-portals.pl [Thu Feb 21 15:04:38 2002] [warn] SessionCleanup called for GET /iddb/target/list-portals.pl The first two lines are the browser's initial request for /iddb/target and the subsequent redirect by Apache to /iddb/target/ and ultimately translated to /iddb/target/index.pl. Notice that the fixup handler fires for both, but the log handler doesn't. In lines seven and eight, I re-issued the initial request and received the same result -- no log handler. However, in lines 11 and 12, I manually entered /iddb/target/index.pl into the browser's address line. This time the log handler was called. Bug or feature? -- Milo Hyson CyberLife Labs, LLC
[OT] New mod_perl logo (revisited)
I apologise in advance to those of you who receive multiple copies of this email due to my cross-posting. Due to the instability of its previous host, I have moved the mod_perl logo entries to my new Linux box (my apologies to those who were unable to review the images previously due to the inordinate down-time). The images are now available at http://beverley2.digital-word.com/mod_perl/ Also, I have now added html pages to each directory with the images displayed inline - thanks to Stas Bekman (stas[at]stason.org) who contributed his ls2html Perl script for that purpose. I am still soliciting entries for the new logo (send to mod_perl[at]digital-word.com)... so please keep those images coming. Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/
Re: [OT] New mod_perl logo (revisited)
Jonathan M. Hollin wrote: I apologise in advance to those of you who receive multiple copies of this email due to my cross-posting. Due to the instability of its previous host, I have moved the mod_perl logo entries to my new Linux box (my apologies to those who were unable to review the images previously due to the inordinate down-time). The images are now available at http://beverley2.digital-word.com/mod_perl/ Also, I have now added html pages to each directory with the images displayed inline - thanks to Stas Bekman (stas[at]stason.org) who contributed his ls2html Perl script for that purpose. I am still soliciting entries for the new logo (send to mod_perl[at]digital-word.com)... so please keep those images coming. Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/ personally id have to say i like this one the best louise_bramald_1.jpg id love to see it with the camel a bit bigger
Re: When handlers misfire
I moved the session cleanup phase to a PerlLogHandler and it seems to be working, except for one small issue. Request URIs for directories (i.e. no filename specified) don't seem to trigger the log handler. I put some warnings in the code to trace its execution. The following is a dump of my logs following a test run: [Thu Feb 21 15:02:46 2002] [warn] SessionPrepare called for GET /iddb/target/index.pl [Thu Feb 21 15:02:46 2002] [warn] SessionPrepare called for GET [snip] The first two lines are the browser's initial request for /iddb/target and the subsequent redirect by Apache to /iddb/target/ and ultimately translated to /iddb/target/index.pl. Notice that the fixup handler fires for both, but the log handler doesn't. In lines seven and eight, I re-issued the initial request and received the same result -- no log handler. However, in lines 11 and 12, I manually entered /iddb/target/index.pl into the browser's address line. This time the log handler was called. Bug or feature? ok, I'd have to analyze this further, but here's what pops in my head... mod_dir is calling ap_internal_redirect for the /iddb/target - /iddb/target/ transition. the way the request cycle seems to work is that the post-read request handler phase through the content-generation phase are handled by ap_process_request_internal (which is called by ap_internal_redirect), while the logging phase is actually handled by ap_process_request, which only happens for client initiated requests... so, my theory is that the bulk of the request will run for requests handled by internal redirects _except_ for the logging phase, which only happens for the main request. this can be easily verified by creating a PerlHandler that only calls $r-internal_redirect and returns OK, and seeing whether the Fixup phase runs twice and the Log phase once. now that I think about it, this _may_ be buried somewhere in some documentation (it sounds vaguely familiar)... or I could be totally off the wall. they are both equal at this point I think. anyway, if my theory is correct, though, you may be able to solve your problem by doing return DECLINED unless $r-is_initial_req; in your fixup handler, which would keep it from running twice. this is only untested theory at this point, and I'm rather tired. I'll investigate more in the morning if things don't work out for you... HTH --Geoff
Re: When handlers misfire
On Feb 21, 2002 at 15:23:04 -0800, Milo Hyson wrote: On Wednesday 20 February 2002 07:55 pm, Geoffrey Young wrote: If the redirected request needs that session data, there's a small chance it won't be there yet. have you seen this? I don't recall this ever coming up before (which doesn't mean it can't happen :) Yes, I have seen it happen. Quite frequently in fact. My investigation into the problem is how I discovered the cleanup handler wasn't doing its job in time. Want to see something even more interesting? Let your debugging warnings mention the pid that caused the log entry and let it run a while on a production server. I see stuff like... (12345) NEW REQUEST (12345) NEW REQUEST (12345) NEW REQUEST (12345) CLEANUP DONE (12345) CLEANUP DONE (12345) CLEANUP DONE ...often enough to have noticed. If I grep around a bit I can find many instances of this sort of thing. In one case I saw page hits that also warned other info with timestamps. The first four requests were timestamped, the fifth wasn't, the sixth was, and the seventh wasn't. At the end of the seventh all seven cleanups fired off. The difference in time between the first and last timestamps was almost four *minutes*. --rick
Re: ANNOUNCE Bricolage-Devel 1.3.0
David Wheeler wrote: Announcing the release of Bricolage 1.3.0. This is a development release for the forthcoming 1.4.0 release. It features many bug fixes planned for the forthcoming 1.2.1 release, as well as a new feature: A SOAP server. The SOAP server will enable automatic publishing of content, as well as importing and exporting assets. Here's a brief description of Bricolage: Bricolage is a full-featured, opne-source, enterprise-class content management system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete programming \ language support for flexibility, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository. More information on Bricolage can be found on its home page. http://bricolage.thepirtgroup.com/ And it can be downloaded from SourceForge. http://sourceforge.net/project/showfiles.php?group_id=34789 I've added the description at http://perl.apache.org/#appservers Thanks David! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: ANNOUNCE Bricolage-Devel 1.3.0
On Thu, 2002-02-21 at 20:38, Stas Bekman wrote: I've added the description at http://perl.apache.org/#appservers Thanks David! Cool -- thanks Stas. Although I might want to send a slightly longer description for inclusion there soon... Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: [OT] New mod_perl logo (revisited)
On Thu, 21 Feb 2002 23:35:18 -, Jonathan M. Hollin [EMAIL PROTECTED] said: I am still soliciting entries for the new logo (send to mod_perl[at]digital-word.com)... so please keep those images coming. What about entering the old logo as a competitor as well? I think I'd vote for it. Or is there any reason why there must be a new logo? -- andreas
Re: [OT] New mod_perl logo (revisited)
Andreas J. Koenig wrote: On Thu, 21 Feb 2002 23:35:18 -, Jonathan M. Hollin [EMAIL PROTECTED] said: I am still soliciting entries for the new logo (send to mod_perl[at]digital-word.com)... so please keep those images coming. What about entering the old logo as a competitor as well? I think I'd vote for it. Or is there any reason why there must be a new logo? Andreas, all the logos from the first contest are in the competition. The ones we use now are there too: http://beverley2.digital-word.com/mod_perl/logos/raul_a_ligad_1.jpg http://beverley2.digital-word.com/mod_perl/buttons/juergen_specht.gif On the other hand is there a deadline for this contest? Would be nice to decide on the logo(s) before we finish the new site, which should be very soon now. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [Samba authorization]
Carlos Ramirez wrote:
Here are some fixes I incorporated into my private copy of
Authen::Smb and Apache::AuthenSmb modules. These changes
are based on some discussion I found in the modperl
mailing list posted on Thu, 16 Sep 1999 by Matt Arnold. I
basically copied Matt's suggestions and added them in.
I was getting the same error messages but after I
incorporated theses changes, it to fixed the problem on
SUN Sparc Solaris 2.5.1..2.8.
=Begin Snippet from mailing list
The resulting additions to Authen::Smb look like this:
use Fcntl qw(:flock);
...
open S, /full/path/to/AuthenSmb.lck or die Can't open
AuthenSmb.lck: $!\n;
flock S, LOCK_EX;
my $res = Valid_User($username, $password, $server, $backup, $domain);
close S;
In short, I ended up adding
the following two lines to Apache::AuthenSmb.
use Memoize;
memoize('Authen::Smb::authen');
=End of Snippet
I contacted the author of Apache::AuthenSmb (a long time
ago) and asked him if he could add these changes into
the module. He stated he no longer has access to machines
where he can test his module and asked me to post
it in the modperl mailing list (which I never did).
I used this module extensively in our environment and
have also added some other nice features. Anyhow, if
the author can no longer maintain it, i'd be glad ty
update it ;)
Since, this fix also requires that Authen::Smb to be
modified, maybe the author of the cool Authen::Smb module
add some option to allow a lock file or force it to use a
lock file (??).
Something along the lines:
sub authen {
my @args = @_;
# Truncate everything to length 80 to avoid poor coding practices in the
# smbvalid.a (buffer overflows) PMK--fixme in smbvalid.a when possible.
for my $i ( 0..$#args ) {
$args[$i] = substr($args[$i], 0, 80);
}
my($username, $password, $server, $backup, $domain, $lockfile) = @args;
my $res;
if ($lockfile) {
open L, $lockfile or die Can't open AuthenSmb.lck: $!\n;
flock L, LOCK_EX;
$res = Valid_User($username, $password, $server, $backup, $domain);
close L;
}
else {
$res = Valid_User($username, $password, $server, $backup, $domain);
}
return $res;
}
Anyhow, hope this helps.
Please, let's continue discussing my problem. Remind you, that I
installed mod_perl, Authen-Smb-0.91 and Apache-AuthenSmb-0.60 for
authorization in apache against NT server. And I get this error in
apache error.log file:
Undefined subroutine Apache::AuthenSmb::handler called.
In discussion we stopped at the point that I have wrong Smb.so file,
because when I put PerlModule Apache::AuthenSmb in my httpd.conf file
I get
--
Syntax error on line 346 of /usr/local/apache/conf/httpd.conf:
Can't load
'/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/Authen/Smb/Smb.so'
for
module Authen::Smb: ld.so.1: /usr/local/apache/bin/httpd: fatal:
relocation error: file
/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/Authen/Smb/Smb.so:
symbol main: referenced symbol not found at
/usr/local/lib/perl5/5.6.1/sun4-solaris/DynaLoader.pm line 206.
at /usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenSmb.pm line 5
Compilation failed in require at
/usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenSmb.pm line 5.
BEGIN failed--compilation aborted at
/usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenSmb.pm line 5.
Compilation failed in require at (eval 3) line 3.
--
when making 'apachectl configtest'. I tried to reinstall AuthenSmb with
its default options (default Makefile.PL), - no success.
Maybe I must install it with some different from default options? Who
knows what are such options? What is configurable there? Or what may be
done with my Smb.so in oder Authen:Smb to understand it?
Hi!
I did suggested changes:
In Authen::Smb added lines 'use Fcntl qw(:flock);' and
--
open S, /usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/Authen/AuthenSmb.lck
or die Can't open AuthenSmb.lck: $!\n;
flock S, LOCK_EX;
my $res = Valid_User($username, $password, $server, $backup, $domain);
close S;
--
Replaced subroutine 'authen' as shown above.
In Apache::AuthenSmb added
--
use Memoize;
memoize('Authen::Smb::authen');
--
And now I get this error when making 'apachectl configtest':
--
Syntax error on line 346 of /usr/local/apache/conf/httpd.conf:
Can't load '/usr/local/lib/perl5/5.6.1/sun4-solaris/auto/Fcntl/Fcntl.so' for
module Fcntl: ld.so.1: /usr/local/apache/bin/httpd: fatal: relocation error: file
/usr/local/lib/perl5/5.6.1/sun4-solaris/auto/Fcntl/Fcntl.so: symbol main:
referenced symbol not found at /usr/local/lib/perl5/5.6.1/sun4-solaris/XSLoader.pm
line 75.
at /usr/local/lib/perl5/5.6.1/sun4-solaris/Fcntl.pm line 220
Compilation failed in require at
/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/Authen/Smb.pm line 6.
BEGIN failed--compilation
Re: [OT] New mod_perl logo (revisited)
On Fri, 22 Feb 2002 14:51:23 +0800, Stas Bekman [EMAIL PROTECTED] said: Andreas, all the logos from the first contest are in the competition. blush Sorry I missed it. Thanks for bearing with me. -- andreas
cvs commit: modperl-site index.html
stas02/02/21 20:35:25 Modified:.index.html Log: - add a ref/desc of Bricolage Revision ChangesPath 1.99 +11 -0 modperl-site/index.html Index: index.html === RCS file: /home/cvs/modperl-site/index.html,v retrieving revision 1.98 retrieving revision 1.99 diff -u -r1.98 -r1.99 --- index.html29 Jan 2002 04:30:10 - 1.98 +++ index.html22 Feb 2002 04:35:25 - 1.99 @@ -1197,6 +1197,17 @@ /li + li + a href=http://bricolage.thepirtgroup.com/;Bricolage/a + is a full-featured, open-source, enterprise-class + content management system. It offers a browser-based + interface for ease-of use, a full-fledged templating + system with complete programming language support + for flexibility, and many other features. It + operates in an Apache/mod_perl environment, and uses + the PostgreSQL RDBMS for its repository. + /li + li a
