Re: module to hit back at default.ida atack ?
Anybody know of any module I can use to hit back at these default.ida bozos (i.e. keep them away from my IP addresses ?). I'm running apache/modperl on Win32. [snip] ::grin:: In the post he mentioned about trashing the kernel on NT so this might be kinda fun... Well you might think it's fun but there are those who'd say it's criminal. Sorry, you're right. I meant fun in the same way that Looney Toons and Wilie Coyote. Funny to watch a cartoon fall off a cliff, but not necessarily funny in life. Please don't promote irresponsible ideas on the mod_perl List. My bad script kiddies, go away, grow up, be responsible, and look to other security oriented lists such as incidents and bugtraq for bad ideas. -sc PS line type=fine personal_opinion=trueBad ideas aren't bad, execution of bad ideas is bad./line -- Sean Chittenden PGP signature
Weird IE cookie behaviour
Hello, I've gotten Apache::AuthCookie to run against Netscape and Mozilla browsers. However, when I try to get it to work with IE with prompting enabled for accepting cookies, I never get prompted to accept a cookie, so it appears that the browser is refusing to acknowlegde that the cookie was received. I've looked high and low for resources on this. So far I've rewritten my AuthCookie subclass to use CGI::Cookie, and added a ton more debug statements, with no effect or light on the problem. I _must_ get this working with IE. Does anyone have a clue stick for me? --Christopher
Re: Module to catch (and warn about) Code Red
On Sun, 5 Aug 2001, Les Mikesell wrote: The descriptions I've seen indicate that it has a flaw in the attempt to pick random targets. That was only the first version of Code Red I, Code Red II (which is the one that is scanning in your neighborhood (close netblocks)) doesn't have that flaw. http://www.unixwiz.net/techtips/CodeRedII.html http://braddock.com/cr2.html Whatever OS you are running, make sure to install those patches! - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than 100M impressions per day, http://valueclick.com
Re: Weird IE cookie behaviour
On Mon, 6 Aug 2001, Christopher L. Everett wrote: I _must_ get this working with IE. Does anyone have a clue stick for me? try posting the Set-Cookie: line that you are sending to the browsers. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than 100M impressions per day, http://valueclick.com
Re: [Fwd: Help with @ISA]
Hi all, Don't we need to load the module before using it? With: PerlModule My::Module::Name Location /foo SetHandler perl-script PerlHandler My::Module::Name /Location ## OR Location /foo SetHandler perl-script PerlHandler +My::Module::Name /Location # Stas Bekman wrote: I don't understand why have sent your email as an attachement... how do you want us to quote it? Anyway: Location /foo SetHandler perl-script PerlHandler my::foo-cookie_check() /Location s/my::foo-cookie_check/my::foo::cookie_check/ - since it's not a method, $r is merely passed to the handler. And read the eagle book about stacked handlers if that's what you want. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.orghttp://perlmonth.com/ -- My mother always used to tell me, The early bird gets the worm. The message seemed pretty clear to me: If you sleep late, you're a lot less likely to be killed by a bird. -- Elliott Downing
Re: module to hit back at default.ida atack ?
Perhaps we should just keep a central database of where the attempts are coming from. We could even extend it to work like the RBL - connects are not allowed from IP's that have attempted the exploit (an explanation page appears instead of the requested page) and are listed in our blacklist. That might force ISP's to kick the k1dd13z off their system. We could host the db on a webpage (searchable) and make it available for download by the script that does the banning on a daily/hourly basis. We could probably extend this to cover a few other exploits if this works. Would anyone use this? Sean Chittenden wrote: Anybody know of any module I can use to hit back at these default.ida bozos (i.e. keep them away from my IP addresses ?). I'm running apache/modperl on Win32. [snip] ::grin:: In the post he mentioned about trashing the kernel on NT so this might be kinda fun... Well you might think it's fun but there are those who'd say it's criminal. Sorry, you're right. I meant fun in the same way that Looney Toons and Wilie Coyote. Funny to watch a cartoon fall off a cliff, but not necessarily funny in life. Please don't promote irresponsible ideas on the mod_perl List. My bad script kiddies, go away, grow up, be responsible, and look to other security oriented lists such as incidents and bugtraq for bad ideas. -sc PS line type=fine personal_opinion=trueBad ideas aren't bad, execution of bad ideas is bad./line -- Sean Chittenden Part 1.2Type: application/pgp-signature -- Mark Maunder Senior Architect SwiftCamel Software http://www.swiftcamel.com mailto:[EMAIL PROTECTED]
Re: Weird IE cookie behaviour [OT]
Hi there, On Mon, 6 Aug 2001, Christopher L. Everett wrote: I _must_ get this working with IE. Does anyone have a clue stick for me? There is IE and there is IE, the versions don't all behave the same (for just about anything you can think of. :) Which version(s) of IE are you using? Have you tried more than one version? Have you tried searching with the Microsoft knowledge base search engine? It's not easy for me to admit this, but I've found it rather good. 73, Ged.
Re: [Fwd: Help with @ISA]
On Mon, 6 Aug 2001, Nouguier Olivier wrote: Hi all, Don't we need to load the module before using it? that's right, I assumed that it was preloaded already :) thanks for this note. With: PerlModule My::Module::Name Location /foo SetHandler perl-script PerlHandler My::Module::Name /Location ## OR Location /foo SetHandler perl-script PerlHandler +My::Module::Name /Location # Stas Bekman wrote: I don't understand why have sent your email as an attachement... how do you want us to quote it? Anyway: Location /foo SetHandler perl-script PerlHandler my::foo-cookie_check() /Location s/my::foo-cookie_check/my::foo::cookie_check/ - since it's not a method, $r is merely passed to the handler. And read the eagle book about stacked handlers if that's what you want. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.orghttp://perlmonth.com/ -- My mother always used to tell me, The early bird gets the worm. The message seemed pretty clear to me: If you sleep late, you're a lot less likely to be killed by a bird. -- Elliott Downing _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: compiling troubles on Solaris 8
Hi there, On Mon, 6 Aug 2001, Alan Burlison wrote: Please note that the same compiler must be used to build Perl and mod_perl, Not so. gcc should work just fine. The problem is that when perl is configured and built, it saves the compiler name and flags in Config.pm. Well OK, read What Compiler Should Be Used to Build mod_perl? in the install section of Stas' new book if you want to use different compilers - but don't say I didn't warn you! :) 73, Ged.
Re: compiling troubles on Solaris 8
Ged Haywood wrote: Well OK, read What Compiler Should Be Used to Build mod_perl? in the install section of Stas' new book if you want to use different compilers - but don't say I didn't warn you! :) By all means, please feel free to buy our compiler. Alan Burlison
RE: compiling troubles on Solaris 8
-Original Message- From: Alan Burlison [mailto:[EMAIL PROTECTED]] Sent: Monday, August 06, 2001 4:54 AM To: Ged Haywood Cc: Bryan McGuire; Paul Phillips; [EMAIL PROTECTED] Subject: Re: compiling troubles on Solaris 8 [snip] As an aside, Solaris 8 comes with prebuilt versions of Apache and mod_perl, does anyone familiar with HP-UX, AIX, or IRIX know whether this is true of these platforms as well? Whether they are DSO mod_perl or not would also be helpful. thanks --Geoff
Re: compiling troubles on Solaris 8
Geoffrey Young wrote: As an aside, Solaris 8 comes with prebuilt versions of Apache and mod_perl, does anyone familiar with HP-UX, AIX, or IRIX know whether this is true of these platforms as well? Whether they are DSO mod_perl or not would also be helpful. On Solaris it is built as a DSO. -- Alan Burlison Solaris Kernel Development, Sun Microsystems
[DIGEST] mod_perl digest 2001/08/04
-- mod_perl digest July 29, 2001 - August 4, 2001 -- Recent happenings in the mod_perl world... Features o mod_perl status o mailing list highlights o links mod_perl status o mod_perl - stable: 1.26 (released July 11, 2001) [1] - development: 1.26_01-dev [2] o Apache - stable: 1.3.20 (released May 15, 2001) [3] - development: 1.3.21-dev [4] o Perl - stable: 5.6.1 (released April 9, 2001) [5] - development: 5.7.2 [6] mailing list highlights o Seems we are limited by the Apache API to a 'text/html' content-type when returning SERVER_ERROR [7] o For those who were not able to attend the conference, here is a running list of those mod_perl speakers who chose to have their material available online - Choosing a Templating System (Perrin Harkins) [8] - The Matt Sergeant Channel (Matt Sergeant) [9] - Automatic Document Categorization (Ken Williams) [10] - Getting Started with mod_perl (Stas Bekman) [11] - Wombat: Servlets for Perl (Brian Moseley) [12] - Transitioning to mod_perl Handlers (Geoff Young) [13] My apologies if I left anyone out, but many others can be found at the official conference repository [14] o The CodeRed worm is getting lots of attention on the list lately [15] o Yet another flame war - this time it's embedding SQL (or not) [16] o Stas offered an RFC for the mod_perl 2.0 documentation project [17] links o The Apache/Perl Integration Project [18] o mod_perl documentation [19] o mod_perl modules on CPAN [20] o mod_perl homepage [21] o mod_perl news and advocacy [22] o mod_perl list archives - modperl@ [23] [24] - dev@ [25] happy mod_perling... --Geoff [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://perl.apache.org/from-cvs/modperl/ [3] http://www.apache.org/dist/httpd/ [4] http://dev.apache.org/from-cvs/apache-1.3/ [5] http://www.cpan.org/src/stable.tar.gz [6] http://www.cpan.org/src/devel.tar.gz [7] http://forum.swarthmore.edu/epigone/modperl/phumskunthe [8] http://perl.apache.org/features/tmpl-cmp.html [9] http://axkit.org/docs/presentations/tpc2001/ [10] http://mathforum.com/~ken/categorize/001.html [11] http://www.stason.org/talks/ [12] http://wombat.sourceforge.net/osc-2001/index_files/v3_document.htm [13] http://www.modperlcookbook.org/~geoff/slides/TPC5.ppt [14] ftp://ftp.oreilly.com/pub/conference/os2001/ [15] http://forum.swarthmore.edu/epigone/modperl/wanyahgly [16] http://forum.swarthmore.edu/epigone/modperl/pralplandsay [17] http://forum.swarthmore.edu/epigone/modperl/ginthandswang [18] http://perl.apache.org [19] http://perl.apache.org/#docs [20] http://www.cpan.org/modules/by-module/Apache/ [21] http://www.modperl.com [22] http://www.take23.org [23] http://forum.swarthmore.edu/epigone/modperl/ [24] http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2 [25] http://marc.theaimsgroup.com/?l=apache-modperl-devr=1w=2
Antwort: [OT] Inspired by closing comments from the UBB thread.
Hi, our code contains exactly one SQL-Statement: our $getSQL = 'select SQLSTMT, INPARAM, OUTPARAM from SQLSTMT where ID=?'; but I think it would even be cleaner to use a PerlSetVar for that... cu Michael Datum: 01.08.2001 17:14 An:[EMAIL PROTECTED] Betreff: [OT] Inspired by closing comments from the UBB thread. Nachrichtentext: All, In his closing comments about UBB Kyle Dawkins made a statement that got me wondering. He said there's SQL embedded all throughout the Perl everywhere (who does this?! oh my god, are they on crack?). This comment got me wondering about alternatives to embedding SQL in to the code of a program. Alternatives I see are to use stored procedures which would limit one to using a certain DB server (or to be proficient in many servers and write stored procedures for all server flavors which would mean one is a very busy Perl and SQL guru) or possibly storing the embedded SQL in some sort of external file structure accessible via storable, XML::Simple or some other means. It would be interesting to know how other people have solved that problem. Currently, we are essentially using embedded SQL in our apps. Thanks in advance. --Joe Breeden --
Re: Module to catch (and warn about) Code Red
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 4:17 PM -0500 8/5/01, Les Mikesell wrote: The descriptions I've seen indicate that it has a flaw in the attempt to pick random targets. It always uses the same seed so every instance runs through the same addresses in the same order. That means you will get hit by the same That was version 1. Version 2 (during the first attack) fixed that. And we are now at a completely new generation of the worm which uses the same basic method, but has much deadlier payloads. More to the point, the people who are running vulnerable servers are very likely (an some tests have verified this) to be vulnerable to other attacks--so they definitely need a wakeup call. - -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -BEGIN PGP SIGNATURE- Version: PGP Personal Security 7.0.3 iQA/AwUBO26PjCZsPfdw+r2CEQLuAwCgr32ufjACaRBILNFnpQMAAv2RDOYAmQEJ e/zI1wtQn/Ik0OE2YcFyfZ++ =Hyi4 -END PGP SIGNATURE-
Revised CodeRed.pm
I've modified CodeRed.pm again, such that it now (a) writes better log messages and (b) sends an automatic message to the SecurityFocus team, in the format that they specified. Rather than blast the source code across this mailing list repeatedly, I've put it up at http://reuven.lerner.co.il/projects/CodeRed.pm. I expect to write some POD, rewrite a bunch of the comments, re-indent the source a bit, and other such fun things. But for the most part, it appears to work. Thanks for the feedback that I've received so far! Reuven
Re: module to hit back at default.ida atack ?
From: Mark Maunder [EMAIL PROTECTED] Perhaps we should just keep a central database of where the attempts are coming from. We could even extend it to work like the RBL - connects are not allowed from IP's that have attempted the exploit Would that really help anything? The traffic would still be reaching your server and clogging up the net, the only difference is that you'd be returning an access denied response rather than a 404. What would really help is if all the ISPs out there put filters on their routers to catch these requests as close to their source as possible.
Re: Apache::Upload and Image::Magick problems
Jeffrey Hartmann [EMAIL PROTECTED] writes:
2). Apache::Upload seams to delete it's temp file, however when I run df
the memory that file used is still allocated but there are no files in the
/tmp dir. I've commented out all of the Image::Magick code in that block so
that Image::Magick never uses or accesses the file and the allocated memory
problem still exists. So this means that I end up with 100 meg of used
space with only half that showing up as files in the dir. I can delete all
the Image::Magick files in the dir, but that's only half of the space used.
Now I used to use a normal /tmp dir for this, and I still had the
Image::Magick problem, but I never noticed the Apache::Upload one until now.
So I don't know if this problem exists without with tmpfs. Also if I
restart/graceful Apache it seems to release the disk space that it's
holding.
It sounds like the apreq? file in /tmp is remove()d at the end of the
request, but the file somehow stays open until the process exits. Using
lsof or running a stack trace on httpd -X should tell you if this is
the case. The relevant cleanup code is the remove_tmpfile() function in
c/apache_request.c. If the ap_pfclose() call is failing, it should show
up in your apache logs.
If that's not the problem, maybe there's a persistent Apache::Upload
object somewhere in your code?
[...]
foreach my $file (@upload)
{
my $i = Image::Magick-new(magick=$type);
$err = $i-ReadImage(file=$$fh);
$i-Set(magick=$type);
$err = $i-WriteImage(filename=$filename));
warn $err if $err;
undef $i;
}
Try appending
undef @upload;
to make sure there are no Apache::Upload objects still floating
around when your handler exits.
HTH
--
Joe Schaefer
Re: module to hit back at default.ida atack ?
AFAIK most large backbone routers out there dont support application layer filtering e.g. filtering based on what type of http request it is, or what is requested. Too much CPU overhead methinks. Some examples: In the case of the user having a dynamically assigned IP address, the next person assigned that IP who hits any site subscribing to the realtime web blackhole list (Lets call it RWBL) will see a polite message saying this IP has been used for a hack attempt (with explanation on how to get it unblocked) and will hopefully report it to their ISP. In the case of the user having a static IP - well either their server was hacked, or they are the hacker, in which case the effect will be similar - user will either stop hacking (or patch their server) or risk being permanently banned from surfing any site subscribing to the RWBL. To get off the black-hole list is a similar process to getting off the current mail RBL list. Send a request explaining the cause of the hack-attempt and assurances that a remedy is in place, or will be shortly. Any suggestions on where to implement this in the server to ensure minimal reconfiguration and impact to existing mod_perl handlers? It needs to be able to block a request based on the contents of a text file or type of request and chuck out an explanation page. Also needs to be able to append hack attempts into the text file when the IP is not listed. The text file can be stored in the server root somewhere (like robots.txt) and is gathered once daily by the central system. The logic that will be used in the central system to ban IP's can be something like 'if more than X number of hack attempts have been logged by different servers from a particular IP, it's banned'. Perhaps X can be 7. Also a list of banned request URI's can be made available for download for use by the RWBL checker running on each server out there. That will allow us to adapt to different worms or exploits. David Young wrote: From: Mark Maunder [EMAIL PROTECTED] Perhaps we should just keep a central database of where the attempts are coming from. We could even extend it to work like the RBL - connects are not allowed from IP's that have attempted the exploit Would that really help anything? The traffic would still be reaching your server and clogging up the net, the only difference is that you'd be returning an access denied response rather than a 404. What would really help is if all the ISPs out there put filters on their routers to catch these requests as close to their source as possible. -- Mark Maunder Senior Architect SwiftCamel Software http://www.swiftcamel.com mailto:[EMAIL PROTECTED]
Re: Revised CodeRed.pm - Wish List
It looks like the latest CodeRed III compromises a server by putting a backdoor in place, such that a GET /scripts/root.exe will give anyone a shell on the infected machine. Could the code be added to to add a GET /scripts.root.exe and then generate a pop-up screen on the infected host warning the owner/administrator. And then maybe shutdown IIS CodeRed? Just my $.02 -- Danny Aldham Providing Certified Internetworking Solutions to Business www.postino.com E-Mail, Web Servers, Web Databases, SQL PHP Perl I've modified CodeRed.pm again, such that it now (a) writes better log messages and (b) sends an automatic message to the SecurityFocus team, in the format that they specified. Rather than blast the source code across this mailing list repeatedly, I've put it up at http://reuven.lerner.co.il/projects/CodeRed.pm. I expect to write some POD, rewrite a bunch of the comments, re-indent the source a bit, and other such fun things. But for the most part, it appears to work. Thanks for the feedback that I've received so far! Reuven
Re: Revised CodeRed.pm - Wish List
Daniel Aldham writes: Daniel Could the code be added to to add a GET /scripts.root.exe Daniel and then generate a pop-up screen on the infected host Daniel warning the owner/administrator. And then maybe shutdown IIS Daniel CodeRed? Yes, I'm sure that we *could* add code to CodeRed.pm that does everything you suggest, and more. But I think that it would be a really bad idea. Even if your intentions are pure, the authorities won't look kindly on attempts to run administrative tasks on someone else's computer. And besides, what happens if something goes wrong? (Sorry, we were just trying to help; we didn't mean to reboot your system while you were synchronizing databases.) Reuven
Problems running modperl under apache
Recently i transfered over my company's existing websiste from winnt 4 server with iis 4 to redhat 7.0 with apache 1.3.12/mod_perl 1.24. The majority of the site is done in perl and there are perl scripts in almost every directory. But apache cant seem to run them, my main site page is a perl file (index.pl) and it just gives me an ok error saying that there could be misconfiguration error. Besides having to go into the perl scrips themselves and editing them, is there anything that im missing?Btw... the perl scripts make references to sub routines located in a .lib file that placed in to my /usr/local/lib/perl5/site_perl diretory, but mod_perl still gives me errors saying that the subroutines are undefined. I have mod_perl configured this way: ifModule mod_perl.c Directory /var/www SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI /Directory Alias /cgi-bin /var/www/cgi-bin Location /cgi-bin SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI /Location Files *.pl SetHandler perl-script PerlHandler Apache::Registry ### PerlSendHeader On --this doesnt work under the Files directive i guess Options +ExecCGI /Files
Code for Mason HQ released
The source behind www.masonhq.com, the official Mason web site, is now available via anonymous CVS. As you might guess, Mason components and Perl libraries comprise the bulk of the code. For new Mason users, this gives you a large and (relatively :]) clean example site to learn from. For more experienced Mason developers, this gives you a chance to borrow Mason HQ features or to develop on Mason HQ itself. See http://www.masonhq.com/code/site_source.html for information. Cheers Jon
Re: Problems running modperl under apache
On Mon, 6 Aug 2001, Mark Vazquez wrote: Hi, Recently i transfered over my company's existing websiste from winnt 4 server with iis 4 to redhat 7.0 with apache 1.3.12/mod_perl 1.24. The majority of the site is done in perl and there are perl scripts in almost every directory. But apache cant seem to run them, my main site page is a perl file (index.pl) and it just gives me an ok error saying that there could be misconfiguration error. Besides having to go into the perl scrips themselves and editing them, is there anything that im missing?Btw... the perl scripts make references to sub routines located in a .lib file that placed in to my /usr/local/lib/perl5/site_perl diretory, but mod_perl still gives me errors saying that the subroutines are undefined. I have mod_perl configured this way: ifModule mod_perl.c Directory /var/www SetHandler perl-script This will set mod_perl to handle all requests within the dir... AFAIK this disables your DirectoryIndex directive. You probably want the AddHandler perl-script .pl to handle all .pl files instead, with a DirectoryIndex index.pl in front. See: http://httpd.apache.org/docs/mod/mod_mime.html#addhandler PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI /Directory Alias /cgi-bin /var/www/cgi-bin Location /cgi-bin SetHandler perl-script idem dito PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI /Location Files *.pl SetHandler perl-script and one more :-) PerlHandler Apache::Registry ### PerlSendHeader On --this doesnt work under the Files directive i guess I thought this would just work... Options +ExecCGI /Files Hope this helps, Remco
RE: Problems running modperl under apache
Seems to have helped out a lot, thanks for pointing out those small changes.
Re: module to hit back at default.ida atack ?
What would really help is if all the ISPs out there put filters on their routers to catch these requests as close to their source as possible. Hey. Real quick, this discussion is getting a tad off topic, but, in terms of security, the ideal way to handle this is and prevent future spread of such worms for all of the IIS users in the crowd: * setup a bank of webservers * setup your scripts to use a proxy server * put a firewall before your webservers and proxy servers * deny all traffic FROM your webservers to port 80 and 443 * allow all traffic from your proxy server Cheers. Now can we get back to mod_perl? -sc -- Sean Chittenden PGP signature
Backing out a mod_perl install
I'm upgrading mod_perl on a Solaris 2.6 production machine. Although a little downtime on this machine won't be a big issue, I'm wondering about backup plans. I've got mod_perl ready for make install (I'm currently using a PERL5LIB environment to test mod_perl on a high port from the blib). So I was just going to bring down the server, make install, and then startup the new server. But, I'd like to be able to back out, just in case. I was thinking about tar'ing up the Apache name space, and Apache.pm to backout the Perl modules so I could run the old httpd, if needed. Is that a reasonable thing to do, and if so, is there anything else you would suggest? Thanks, Bill Moseley mailto:[EMAIL PROTECTED]
RE: Backing out a mod_perl install
-Original Message- From: Bill Moseley [mailto:[EMAIL PROTECTED]] Sent: Monday, August 06, 2001 3:18 PM To: [EMAIL PROTECTED] Subject: Backing out a mod_perl install I'm upgrading mod_perl on a Solaris 2.6 production machine. Although a little downtime on this machine won't be a big issue, I'm wondering about backup plans. I've got mod_perl ready for make install (I'm currently using a PERL5LIB environment to test mod_perl on a high port from the blib). So I was just going to bring down the server, make install, and then startup the new server. But, I'd like to be able to back out, just in case. I was thinking about tar'ing up the Apache name space, and Apache.pm to backout the Perl modules so I could run the old httpd, if needed. you can try the tar_Apache and offsite_tar arguments to make and see if they wrap up everything you need... HTH --Geoff
RE: Backing out a mod_perl install
someone please correct me but: I believe that make install will only overwrite httpd (the executable binary). Any other files that already exist will not be touched. Last time I did something like this, I simply made a copy of my httpd binary and everything else was in my system backups. -Original Message- From: Geoffrey Young [mailto:[EMAIL PROTECTED]] Sent: Monday, August 06, 2001 3:21 PM To: 'Bill Moseley'; [EMAIL PROTECTED] Subject: RE: Backing out a mod_perl install -Original Message- From: Bill Moseley [mailto:[EMAIL PROTECTED]] Sent: Monday, August 06, 2001 3:18 PM To: [EMAIL PROTECTED] Subject: Backing out a mod_perl install I'm upgrading mod_perl on a Solaris 2.6 production machine. Although a little downtime on this machine won't be a big issue, I'm wondering about backup plans. I've got mod_perl ready for make install (I'm currently using a PERL5LIB environment to test mod_perl on a high port from the blib). So I was just going to bring down the server, make install, and then startup the new server. But, I'd like to be able to back out, just in case. I was thinking about tar'ing up the Apache name space, and Apache.pm to backout the Perl modules so I could run the old httpd, if needed. you can try the tar_Apache and offsite_tar arguments to make and see if they wrap up everything you need... HTH --Geoff
RE: Backing out a mod_perl install
At 03:21 PM 08/06/01 -0400, Geoffrey Young wrote: to backout the Perl modules so I could run the old httpd, if needed. you can try the tar_Apache and offsite_tar arguments to make and see if they wrap up everything you need... Ok, thanks tar_Apache should include all that I need, thanks. I don't see the need for offsite_tar in my case, since I already have mod_perl built and ready for install in the target machine. No need to run make install on the httpd side, right? I can just copy the httpd binary (I'll be using the same ServerRoot as the existing 1.3.12 server), so I'm assuming all my icons and mime.types files from 1.3.12 will be just fine. Bill Moseley mailto:[EMAIL PROTECTED]
Re: module to hit back at default.ida atack ?
I have a test system up and running. Anyone want to write a mod_perl handler to redirect to a warning page if the clients IP is in the list? I'm not really sure which phase would be the least intrusive into existing applications. telnet www.swiftcamel.com Then hit enter and you'll see the latest list of servers that have attempted the hack including the number of attempts per IP address (comma seperated). I only list servers if we've received more than 1 attempt on different web servers. I've used our logs to compile the initial list. (quite scary how many machines out there are infected.) You can also dump a list of IP addresses once you connect (one per line) and they will be added into the database. Blank line ends reception. Optionally you can add the requested URI after the IP address on the same line seperated by a comma and it too will be logged. I'm working on a web interface to search the list of IP's. grep default.ida access_log | mail -s 'codered' [EMAIL PROTECTED] and we'll add the IP's you logged to the system. Jim Smith wrote: On Mon, Aug 06, 2001 at 02:46:54PM +0100, Mark Maunder wrote: AFAIK most large backbone routers out there dont support application layer filtering e.g. filtering based on what type of http request it is, or what is requested. Too much CPU overhead methinks. Of course, for those of us in state universities, content filtering makes us uneasy wrt first amendment rights, besides the CPU overhead. Losing legitemate content is too much a risk. It is far easier to cut the infected machines off the network until they are fixed. Some examples: In the case of the user having a dynamically assigned IP address, the next person assigned that IP who hits any site subscribing to the realtime web blackhole list (Lets call it RWBL) will see a polite message saying this IP has been used for a hack attempt (with explanation on how to get it unblocked) and will hopefully report it to their ISP. In the case of the user having a static IP - well either their server was hacked, or they are the hacker, in which case the effect will be similar - user will either stop hacking (or patch their server) or risk being permanently banned from surfing any site subscribing to the RWBL. [snip] Any suggestions on where to implement this in the server to ensure minimal reconfiguration and impact to existing mod_perl handlers? It needs to be able to block a request based on the contents of a text file or type of request and chuck out an explanation page. Also needs to be able to append hack attempts into the text file when the IP is not listed. The text file can be stored in the server root somewhere (like robots.txt) and is gathered once daily by the central system. The logic that will be used in the central system to ban IP's can be something like 'if more than X number of hack attempts have been logged by different servers from a particular IP, it's banned'. Perhaps X can be 7. If based on IP, use DNS - that's how the email RBLs are implemented. Makes a central database easy to maintain. Take a look at the Sendmail rulesets for the RBLS. :) --jim -- Mark Maunder Senior Architect SwiftCamel Software http://www.swiftcamel.com mailto:[EMAIL PROTECTED]
Apache::Cookie
Hello, Is there a bug in Apache::Cookie? I am trying to set a cookie using: $webuname = Apache::Cookie-new( $r, -name = 'randh_webuname', -value =$user, -domain ='.rhythm.com', -expires ='+24h',-path ='/' ); $webuname-bake(); But the cookie never gets set? Can any one tell me what am I doing wrong? I have read the documentation for the Apache::Cookie but I can not set the cookie... Help :( Thanks in advance... -r
PERL5LIB perl section
In a previous post today I mentioned how I was running mod_perl from the build directory by setting a PERL5LIB. I seem to need to add: perl /perl at the top of httpd.conf. Otherwise I get: Apache.pm version 1.27 required! /usr/local/lib/perl5/site_perl/5.005/sun4-solaris/Apache.pm is version 1.26 I use perl sections farther down in httpd.conf, but I seem to need it at the very top. If a PerlTaintCheck On comes before the perl/perl then I get that error. Why is that? Bill Moseley mailto:[EMAIL PROTECTED]
Re: module to hit back at default.ida atack ?
On Mon, 6 Aug 2001, Mark Maunder wrote: I have a test system up and running. Anyone want to write a mod_perl handler to redirect to a warning page if the clients IP is in the list? I'm not really sure which phase would be the least intrusive into existing applications. telnet www.swiftcamel.com Then hit enter and you'll see the latest list of servers that have attempted the hack including the number of attempts per IP address (comma seperated). So what your saying is that you have a list of potentially rooted machines that you are making publically available... Doesn't sound like such a good idea to me... Cees
Re: module to hit back at default.ida atack ?
On Tue, Aug 07, 2001 at 08:18:18PM +1000, Cees Hek wrote: So what your saying is that you have a list of potentially rooted machines that you are making publically available... Doesn't sound like such a good idea to me... So *that's* why Reuven has CodeRed.pm CC him on the warning emails. And I thought he was just nuts. ;) -DeWitt
Re: Apache::Upload and Image::Magick problems
Thanks Joe!!
Well that was exactly right. The Apache::Upload temp file is still open (or
mmap'd) after it's unlinked and ImageMagick just doesn't delete it's file.
I don't have the problem with Image Magick with small files because it
doesn't create temporary files for small images. I also checked the trace
and ImageMagick makes no attempt to delete it's temporary file. In fact it
seems to use 2 temporary files (which means I need filesize * 2 space to
upload an image) and it deletes one and not the other. Apache::Upload
unlinks the the file and un-mmaps it but it just doesn't seem to do the
trick.
I've tried using this with and without the TMPFS and I get the same result
either way.
However now I really don't know what to do. I was hoping that it was some
bonehead error in my code that could easily be fixed. Maybe it is... but it
doesn't seem like it now.
-Jeff Hartmann
Note: I have it upload five files at a time.
- lsof ---
COMMANDPID USER FD TYPE DEVICESIZE NODE NAME
httpd 1660 root5u REG0,6 9449700 28525
/tmp/apreqT2TdFO (deleted)
httpd 1660 root6u REG0,6 0 28526
/tmp/apreqDUBnju (deleted)
httpd 1660 root7u REG0,6 0 28527
/tmp/apreqB3QPJb (deleted)
httpd 1660 root8u REG0,6 0 28528
/tmp/apreqf8YOdT (deleted)
httpd 1660 root9u REG0,6 0 28529
/tmp/apreqpXsJPC (deleted)
--- strace httpd -X -
close(36) = 0
munmap(0x403a9000, 4096)= 0
rmdir(/tmp/apreqpXsJPC) = -1 ENOTDIR (Not a directory)
unlink(/tmp/apreqpXsJPC) = 0
close(36) = -1 EBADF (Bad file descriptor)
close(35) = 0
munmap(0x403a2000, 4096)= 0
rmdir(/tmp/apreqf8YOdT) = -1 ENOTDIR (Not a directory)
unlink(/tmp/apreqf8YOdT) = 0
close(35) = -1 EBADF (Bad file descriptor)
close(34) = 0
munmap(0x403a1000, 4096)= 0
rmdir(/tmp/apreqB3QPJb) = -1 ENOTDIR (Not a directory)
unlink(/tmp/apreqB3QPJb) = 0
close(34) = -1 EBADF (Bad file descriptor)
close(33) = 0
munmap(0x403a, 4096)= 0
rmdir(/tmp/apreqDUBnju) = -1 ENOTDIR (Not a directory)
unlink(/tmp/apreqDUBnju) = 0
close(33) = -1 EBADF (Bad file descriptor)
close(32) = 0
munmap(0x4039f000, 4096)= 0
rmdir(/tmp/apreqT2TdFO) = -1 ENOTDIR (Not a directory)
unlink(/tmp/apreqT2TdFO) = 0
close(32) = -1 EBADF (Bad file descriptor)
- END OF PROGRAM OUTPUT ---
- Original Message -
From: Joe Schaefer [EMAIL PROTECTED]
To: Jeffrey Hartmann [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, August 06, 2001 7:38 AM
Subject: Re: Apache::Upload and Image::Magick problems
Jeffrey Hartmann [EMAIL PROTECTED] writes:
2). Apache::Upload seams to delete it's temp file, however when I run
df
the memory that file used is still allocated but there are no files in
the
/tmp dir. I've commented out all of the Image::Magick code in that
block so
that Image::Magick never uses or accesses the file and the allocated
memory
problem still exists. So this means that I end up with 100 meg of used
space with only half that showing up as files in the dir. I can delete
all
the Image::Magick files in the dir, but that's only half of the space
used.
Now I used to use a normal /tmp dir for this, and I still had the
Image::Magick problem, but I never noticed the Apache::Upload one until
now.
So I don't know if this problem exists without with tmpfs. Also if I
restart/graceful Apache it seems to release the disk space that it's
holding.
It sounds like the apreq? file in /tmp is remove()d at the end of the
request, but the file somehow stays open until the process exits. Using
lsof or running a stack trace on httpd -X should tell you if this is
the case. The relevant cleanup code is the remove_tmpfile() function in
c/apache_request.c. If the ap_pfclose() call is failing, it should show
up in your apache logs.
If that's not the problem, maybe there's a persistent Apache::Upload
object somewhere in your code?
[...]
foreach my $file (@upload)
{
my $i = Image::Magick-new(magick=$type);
$err = $i-ReadImage(file=$$fh);
$i-Set(magick=$type);
$err = $i-WriteImage(filename=$filename));
warn $err if $err;
undef $i;
}
Try appending
undef @upload;
to make sure there are no Apache::Upload objects still floating
around when your handler exits.
HTH
--
Joe
PerlRequire/PerlModule and %INC
There have been some messages on the Mason list about people experiencing startup.pl being loaded twice, even without PerlFreshRestart on. I know the server restarts during startup, but PerlRequire and PerlModule are both supposed to obey the laws of %INC, right? I seem to remember some discussion about this before, but I can't remember what the outcome was and I can't find it in the archive. - Perrin
Re: module to hit back at default.ida atack ?
how about a way to tell it not to report an ip?? i just reported on myself. :) At 07:32 PM 8/6/2001 -0400, DeWitt Clinton wrote: On Tue, Aug 07, 2001 at 08:18:18PM +1000, Cees Hek wrote: So what your saying is that you have a list of potentially rooted machines that you are making publically available... Doesn't sound like such a good idea to me... So *that's* why Reuven has CodeRed.pm CC him on the warning emails. And I thought he was just nuts. ;) -DeWitt Angel R. Rivera, [EMAIL PROTECTED] - The Home of the Original Brotherhood/Sisterhood of the Wolf http://www.wolf.com/botw-sotw/ -
2 problems with mod_perl/Apache::DBI
uwb-02-chroot# uname -a FreeBSD uwb-02.cdsnet.net 4.3-STABLE FreeBSD 4.3-STABLE #0: Fri Aug 3 11:43:20 PDT 200 uwb-02-chroot# perl -v This is perl, v5.6.1 built for i386-freebsd uwb-02-chroot# cat /usr/local/etc/apache/startup.pl #!/usr/bin/perl use Apache; use Apache::Status; use Apache::DBI; use Apache::DBILogger; 1; uwb-02-chroot# ./startup.pl Can't locate object method module via package Apache (perhaps you forgot to load Apache?) at /usr/local/lib/perl5/site_perl/5.6.1/Apache/DBI.pm line 202. Compilation failed in require at ./startup.pl line 5. BEGIN failed--compilation aborted at ./startup.pl line 5. So if I comment out the Apache-module(Apache::Status) temporarily, it runs from the command prompt. However, when run under Apache PerlRequire /usr/local/etc/apache/startup.pl [Mon Aug 6 17:33:09 2001] [error] Can't load '/usr/local/lib/perl5/site_perl/5.6.1/i386-freebsd/auto/DBI/DBI.so' for module DBI: /usr/local/lib/perl5/site_perl/5.6.1/i386-freebsd/auto/DBI/DBI.so: Undefined symbol PL_dowarn at /usr/local/lib/perl5/5.6.1/i386-freebsd/DynaLoader.pm line 206. at /usr/local/lib/perl5/site_perl/5.6.1/i386-freebsd/DBI.pm line 185 BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.6.1/i386-freebsd/DBI.pm line 185. Compilation failed in require at /usr/local/lib/perl5/site_perl/5.6.1/Apache/DBI.pm line 4. BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.6.1/Apache/DBI.pm line 4. Compilation failed in require at /usr/local/etc/apache/startup.pl line 5. BEGIN failed--compilation aborted at /usr/local/etc/apache/startup.pl line 5. Compilation failed in require at (eval 1) line 1. Not sure what's up.
Re: 2 problems with mod_perl/Apache::DBI
startup.pl cannot be run from the command line when it contains apache server specific modules. Jaye Mathisen wrote: uwb-02-chroot# uname -a FreeBSD uwb-02.cdsnet.net 4.3-STABLE FreeBSD 4.3-STABLE #0: Fri Aug 3 11:43:20 PDT 200 uwb-02-chroot# perl -v This is perl, v5.6.1 built for i386-freebsd uwb-02-chroot# cat /usr/local/etc/apache/startup.pl #!/usr/bin/perl use Apache; use Apache::Status; use Apache::DBI; use Apache::DBILogger; 1; uwb-02-chroot# ./startup.pl Can't locate object method module via package Apache (perhaps you forgot to load Apache?) at /usr/local/lib/perl5/site_perl/5.6.1/Apache/DBI.pm line 202. Compilation failed in require at ./startup.pl line 5. BEGIN failed--compilation aborted at ./startup.pl line 5. So if I comment out the Apache-module(Apache::Status) temporarily, it runs from the command prompt. However, when run under Apache PerlRequire /usr/local/etc/apache/startup.pl [Mon Aug 6 17:33:09 2001] [error] Can't load '/usr/local/lib/perl5/site_perl/5.6.1/i386-freebsd/auto/DBI/DBI.so' for module DBI: /usr/local/lib/perl5/site_perl/5.6.1/i386-freebsd/auto/DBI/DBI.so: Undefined symbol PL_dowarn at Not sure what's up. -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
Re: Weird IE cookie behaviour
Hello, CEI've gotten Apache::AuthCookie to run against Netscape CEand Mozilla browsers. However, when I try to get it CEto work with IE with prompting enabled for accepting CEcookies, I never get prompted to accept a cookie, so CEit appears that the browser is refusing to acknowlegde CEthat the cookie was received. Check to make sure the domain of your cookie has a leading dot. I seem to dimly recall that sometimes Netscape would accept a domain without a leading dot (e.g. ceverett.com) whereas IE would not accept it unless it had a leading dot (e.g. .ceverett.com). Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: PERL5LIB perl section
On Mon, 6 Aug 2001, Bill Moseley wrote:
In a previous post today I mentioned how I was running mod_perl from the
build directory by setting a PERL5LIB.
I seem to need to add:
perl
/perl
at the top of httpd.conf. Otherwise I get:
Apache.pm version 1.27 required!
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris/Apache.pm is version 1.26
I use perl sections farther down in httpd.conf, but I seem to need it at
the very top. If a PerlTaintCheck On comes before the perl/perl then I
get that error.
Why is that?
According to perlrun manpage, PERL5LIB and PERLLIB vars are ignored when
the taint mode is enabled. This is not the situation with mod_perl, where
the two vars do take an effect.
However it's possible (I didn't look at the code) that during the config
processing normal Perl rules still apply, and therefore PERL5LIB gets
ignored if PerlTaintCheck is set to On.
Your solution worked because perl/perl loads Apache.pm before the
tainting is enabled.
I think you just need to adjust your startup.pl to put the local libs
(from the mod_perl build) first (assuming that your startup.pl is loaded
as early as possible).
If you want your code to be copy and paste ready, what you can do is to
create:
test-startup.pl:
use lib qw( local libs here);
and in your production startup.pl:
eval { require test-startup.pl; }
so if the file is not there, it'll be just ignored. Now you keep this file
only around your test dir, without putting it into CVS (assuming that you
use CVS ;).
Hope this helps to resolve the issue.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: PerlRequire/PerlModule and %INC
On Mon, 6 Aug 2001, Perrin Harkins wrote: There have been some messages on the Mason list about people experiencing startup.pl being loaded twice, even without PerlFreshRestart on. I know the server restarts during startup, but PerlRequire and PerlModule are both supposed to obey the laws of %INC, right? I seem to remember some discussion about this before, but I can't remember what the outcome was and I can't find it in the archive. The discussion is here: http://forum.swarthmore.edu/epigone/modperl/lelswyskix The patch is here: [EMAIL PROTECTED]">http://forum.swarthmore.edu/epigone/modperl/lelswyskix/[EMAIL PROTECTED] it's already fixed in 1.26. I've tested again just in case, it works properly 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://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: RFC: mod_perl 2.0 documentation project
On Mon, 6 Aug 2001, Jim Smith wrote: On Sat, Aug 04, 2001 at 08:12:25PM +0800, Stas Bekman wrote: This is a proposal for the mod_perl 2.0 documentation project. Sounds good. + each project will have its pumpkin which will make sure that all chapters of the project adher to the same style, avoid duplication, etc. + inside each project, every chapter will have its own pumpkin, whose responsibility will be to maintain the documentation of the given chapter. Other contributors will delegate their patches to the chapter pumpkins and the latter will incorporate the changes into the document. + I'll start as the doc pumkin for the whole project and all sub-projects and will seek to delegate the sub-projects to other folks, as I won't be able to cope with such a big beast anymore. I think we might need a pumpkin that can cross-reference sections. For example, Session management under Mason might go under Mason or Session management. Whichever part doesn't have the text needs a reference to the one that does. (A topic that came up recently on the Mason list.) This is more of a benefit to people that are not familiar with the mod_perl universe and can cut down on fruitless searching. If it isn't cross-referenced, it probably is either not there, or hidden so deeply that it needs to be pointed out by someone. Basically, this would be someone responsible for the `See Also's at the end of each section, article, or what-not. That way, the chapter and project pumpkins can concentrate on their parts of the whole and not feel that they have to constantly be watching everything else. Sure. The intention for the guides to deploy hypertext features, and do lots of internal linking inside every guide and between the guides. This of course makes it hard to read the printed material, but I don't think we can do much about this. Unless we decide to build a fully fledged publishing system, without adding a huge overhead of using TeX or similar things used in real publishing. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: Segfaults
[CC'ing back to the list for archival and possibly interesting followup discussion] On Mon, 6 Aug 2001, Kyle Oppenheim wrote: Here's another method to generate a core on Solaris that you may want to add to the guide. (I hope I'm not repeating something already in the guide!) 1. Use truss(1) as root to stop a process on a segfault: truss -f -l -t \!all -s \!SIGALRM -S SIGSEGV -p pid or, to monitor all httpd processes (from bash): for pid in `ps -eaf -o pid,comm | fgrep httpd | cut -d'/' -f1`; do truss -f -l -t \!all -s \!SIGALRM -S SIGSEGV -p $pid 21 done what happens to the newly spawned processes? what happens if the process segfaults immediately after it starts. You don't have enough time to get its PID. 2. Watch the server error_log for reaped processes 3. Use gcore to get a core of stopped process or attach gdb. 4. kill -9 the stopped process. Since I don't have an access to a Solaris system, is it possible for you to take the example code I've supplied below and apply these steps to it? So we can get a fully working example? Thanks a lot! (for example I'm not familiar with gcore... is it Solaris specific thing?) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Stas Bekman Sent: Friday, August 03, 2001 7:53 PM To: Andrei A. Voropaev Cc: [EMAIL PROTECTED] Subject: Re: Segfaults On Fri, 3 Aug 2001, Andrei A. Voropaev wrote: Hi! The problem with Apache/mod_perl children segfaulting is pretty old. Unfortunately this does not leave any core dump that would help in tracing the problem. All it leaves is messages in error log [Fri Aug 3 05:39:28 2001] [notice] child pid 446 exit signal Segmentation fault (11) And quite a lot of them. The more we use mod_perl the more messages like this. A year ago we had only authentication in mod_perl and these message showed up 5-6 times a day. Now we run Mason (v 0.89) and the messages show up 2-3 times a minute. (This has nothing to do with increased usage) The problem has survived 3 upgrades (we started with mod_perl/1.21) So my question is - is there any way to force coredumps? :) This is an excerpt from the upcoming book (which we will finish at some point :) =head2 Getting the core File Dumped Now let's get the Icore file dumped from within the mod_perl server. Sometimes the program aborts abnormally via the SIGSEGV signal (ISegmentation Fault), but no Icore file is dumped. And without the Icore file it's hard to find the cause of the problem, unless you run the program inside Cgdb or another debugger in first place. In order to get the Icore file, the application has to: =over =item * have the effective UID the same as real UID (the same goes for GID). Which is the case of mod_perl unless you modify these settings in the program. =item * be running from a directory which at the moment of the ISegmentation fault is writable by the process. Notice that the program might change its current directory during its run, so it's possible that the Icore file will need to be dumped in a different directory from the one the program was started from. For example when mod_perl runs an CApache::Registry script it changes its directory to the one in which the script source is located. =item * be started from a shell process with sufficient resource allocations for the Icore file to be dumped. You can override the default setting from within a shell script if the process is not started manually. In addition you can use CBSD::Resource to manipulate the setting from within the code as well. You can use Culimit for Cbash and Climit for Ccsh to check and adjust the resource allocation. For example inside Cbash, you may set the core file size to unlimited: panic% ulimit -c unlimited For example you can set an upper limit on the Icore file size to 8MB with: panic% ulimit -c 8388608 So if the core file is bigger than 8MB it will be not created. =item * Of course you have to make sure that you have enough disk space to create a big core file (mod_perl Icore files tend to be of a few MB in size). =back Note that when you are running the program under a debugger like Cgdb, which traps the CSIGSEGV signal, the Icore file will not be dumped. Instead it allows you to examine the program stack and other things without having the Icore file. So let's write a simple script that uses CBad::Segv: core_dump.pl use strict; use Bad::Segv (); use Cwd() my $r = shift; $r-send_http_header(text/plain); my $dir = getcwd; $r-print(The core should be found at $dir/core\n); Bad::Segv::segv(); In this script we load the CBad::Segv and CCwd modules. After that we acquire the request object and send the HTTP header. Now we come to the real part--we get the current working directory, print out the location of the Icore file that we are about to dump and finally we call
RE: Segfaults
what happens to the newly spawned processes? The -f tells truss to follow forks. For completeness... The -l (that's an el) includes the thread-id and the pid (the pid is what we want). The -t specifies the syscalls to trace, and the !all turns them all off. The -s specifies signals to trace and the !SIGALRM turns off the numerous alarms Apache creates. The -S specifies signals that stop the process. Obviously, -p is used to specify the pid. what happens if the process segfaults immediately after it starts. You don't have enough time to get its PID. I suppose you could be less lazy than I and edit apachectl to call truss instead of using the -p option. :-) truss -f -l -t \!all -s \!SIGALRM -S SIGSEGV /usr/local/bin/httpd -f httpd.conf 21 Since I don't have an access to a Solaris system, is it possible for you to take the example code I've supplied below and apply these steps to it? So we can get a fully working example? Thanks a lot! (for example I'm not familiar with gcore... is it Solaris specific thing?) gcore(1) will get a core image of a running process. Therefore, you can put the core where you want it and have permission to write it. I assume it's a Solaris goodie. I don't have the pointer to the Bad::Segv module, but here's an example run. To get the messages from truss, you need to keep your tty open. Otherwise, redirect stdout/stderr somewhere else. $ apachetl start $ for pid in `ps -ef -o pid,comm | fgrep httpd | cut -d'/' -f1`; do truss -f -l -t \!all -s \!SIGALRM -S SIGSEGV -p $pid 21 done [1] 23353 [2] 23354 -- I'm only running one child for this example $ kill -SEGV 662 -- faking Bad::Segv (662 is the child pid) 662/1: Received signal #11, SIGSEGV, in accept() [caught] 662/1:siginfo: SIGSEGV pid=23306 uid=0 $ gcore 662 gcore: core.662 dumped $ kill -9 662 -- clean up the stopped process (at this point, Apache forked a new child and truss is hooked on that one too) $ pkill truss -- clean up the other truss processes that are still running $ gdb /usr/local/bin/httpd (gdb) core-file core.662 ... #0 0xdfae4d2c in _so_accept () from /usr/lib/libc.so.1 (gdb) Obviously, this isn't great to be doing on a production system since truss stops the process after it dumps core and prevents Apache from reaping it. So, you could use up a bunch of scoreboard slots and perhaps force httpd to hit MaxClients if you segfault a lot. -- Kyle Oppenheim Tellme Networks, Inc. http://www.tellme.com -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, August 06, 2001 8:33 PM To: Kyle Oppenheim Cc: mod_perl list Subject: RE: Segfaults [CC'ing back to the list for archival and possibly interesting followup discussion] On Mon, 6 Aug 2001, Kyle Oppenheim wrote: Here's another method to generate a core on Solaris that you may want to add to the guide. (I hope I'm not repeating something already in the guide!) 1. Use truss(1) as root to stop a process on a segfault: truss -f -l -t \!all -s \!SIGALRM -S SIGSEGV -p pid or, to monitor all httpd processes (from bash): for pid in `ps -eaf -o pid,comm | fgrep httpd | cut -d'/' -f1`; do truss -f -l -t \!all -s \!SIGALRM -S SIGSEGV -p $pid 21 done what happens to the newly spawned processes? what happens if the process segfaults immediately after it starts. You don't have enough time to get its PID. 2. Watch the server error_log for reaped processes 3. Use gcore to get a core of stopped process or attach gdb. 4. kill -9 the stopped process. Since I don't have an access to a Solaris system, is it possible for you to take the example code I've supplied below and apply these steps to it? So we can get a fully working example? Thanks a lot! (for example I'm not familiar with gcore... is it Solaris specific thing?)
