perl xml api's
thanks matt, i'll get it(XML::LibXML) andgiveit a go. __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
Re: perl xml api's
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 22 June 2002 12:57 am, [EMAIL PROTECTED] wrote: > Hi, My Mission(must accept it) is to retrieve xml-formatted mail, parse > thru char-sets in msg-body, if chars out of ascii range: generate err msg. > > While I wade thru the apis could any one suggest which modules would fit > this task? Will XML::Parser retrieve a doc from a url or must the doc be > retrived and handed to it? tips appreciated. md An XML parser will croak anyway if the chars are out of range. XML::LibXML has a built in ftp and http client for retrieving external URLs. Just pass a URI to the parse_file() method. - -- <:->get a SMart net -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9FCB2VBc71ct6OywRAl7mAKDPXzPGGOlCmIkTSYKArMfYuDnVaQCglGkM 5QlI1xWhyUJUl+BGW3ZYa90= =QNP1 -END PGP SIGNATURE-
Re: Knowing your limitation - was Re: [JOB] Crack OOP Perl whitebox tester wanted
I agree with Tom but for different reasons. I would almost never accept a
telecommuter I didn't know and that may even be if he or she came recommended.
Everyone has different personalities and cultures and it takes time to
really get to know how to effectively communicate with someone because
everyone has different "vocabulary" even coming from the same country. And
vice versa. Every person is an individual and it's really tough to find out
the individual way someone needs to be managed over long distances.
Face to face communication is the quickest most efficient way to learn how
best to communicate (and hence manage) with most people and vice versa.
eg You need to learn to read between the lines of how someone writes. One
person's friendly sarcasm may be another person's insult. Without figuring
these things out in person first, frictions can result at worst and usually
at best, there will be inefficiency in communication ("o, THAT'S what
you meant...").
We have accepted some of our employees telecommuting from the other side of
the world but our best success has come from people who have been in our
office physically for 3 months at minimum and then go back to where they
came from to work. But people who we don't know their work habits... that
is much more difficult to manage.
For someone who wants to telecommute from the other side of the world,
bringing them here for 3 months and housing them and then topping it up
with long distance bills... makes it a lot less financially attractive than
simply hiring someone straight out who is a local where you just pay them a
salary that covers how they live rather than having to pay the same salary
plus all the other expenses and the additional effort for communicating
with the telecommuter from dealing with timezone differences to not being
able to "whiteboard" in real time without either learning a new tool or
paying for an electronic whiteboard (yet another expense) on both sides of
the telecommute boundary.
In any case, if telecommuting was easy to manage, then a lot more
programming jobs would be outsourced successfully to places like India,
Malaysia, Singapore, Philippines, Russia etc.
There is a place for telecommuting. We do accept it -- but it's never
"easy" even for us even if we get good results.
But I think it is a bit insulting when someone presumes that all businesses
and management teams are equiped to deal with telecommuting and should just
be able to have an empty office and if they aren't that they are "bad" or
somehow incompetent at communication or that they are "close minded" and
not considering the possibilities.
Many times, management teams think a great deal about how to make their
employees happy given the resource constraints of an organization.
Maintaining that balance can be very hard.
In most cases, the informal form of management is best for small teams
(most efficient use of money) instead of having to deal with excessive
documentation and communication and coordination issues over long distances.
At 05:38 AM 6/22/2002, Tom Mornini wrote:
>Thanks for your response, Zac.
>
>Our tech team is very small. I'm the manager of the group, and my
>management style would best be described as lackadaisical. :-)
>
>So, you're right, this requirement is based upon management weakness. I
>knew that when I posted the job offer. In fact, I even told that to the
>employee who was leaving for Washington D.C. as the reason why I couldn't
>keep him on. He understood completely, having worked with me. :-)
>
>While I agree that it would be ideal to simply pick the best person for
>the job, this obviously isn't completely realistic. For instance, we have
>a certain pay range that we can afford, and that will artificially limit
>who we can consider. Other people won't even know we have an opening.
>Others still might have a language or communications barrier that makes it
>impossible for us to work with them. Notice that this is not actually his
>deficiency, but ours. If we could just speak (insert language here).
>
>I just don't see adding one additional limitation to that by wanting
>someone to come to the office as all that big a deal. Many people prefer
>it, and in this economy, help is not scarce and people are willing to go
>the extra mile. After all, it's not about getting the best person, it's
>about getting the best work done. If I know that I can't effectively
>remote manage somebody so it would be silly for me to attempt this in vain.
>
>On Friday, June 21, 2002, at 08:30 AM, Zac Morris wrote:
>
>>Old fashioned is right, and disregarding "telecommuters" is also
>>extreemly short sighted and ultimaty limits your ability to provide the
>>most quality solution...
>>
>>I work for Cisco Systems in our RTP (NC) office. I work with two
>>different groups, one based in San Jose and the other based in Ontario,
>>as a "virtual team member" (what we call our telecommuter positions).
Re: Fascinating segfault at Apache startup
I got this error and spent a bit of time trying to figure it out. The reason I was getting it was that I had started with a RedHat 7.2 system which comes with Perl 5.6.0 and upgraded to 5.6.1 using RH 7.3 RPMS. I then compiled mod_perl against 5.6.1. Each time I started up I got the absurdfork error. I found 5.6.1 RPMS for RH 7.2 and everything worked fine. --eric Jeremy Weatherford wrote: > Hello, > > I'm trying to build a minimal Apache+mod_perl, sort of a 'Perl-Server', as > mentioned in the mod_perl guide. > > Here's the end result: > > [root@omics root]# cd /usr/local/apache-perl/bin > [root@omics bin]# ./httpd > () gets absurdforkSegmentation fault > [root@omics bin]# > > I'll start trying to debug this, but I'm not too confident in my ability > to gather any more useful information, so I thought I'd ask if anybody has > seen this before. I can't find any references to this message on the web > (always scary), but maybe someone knows what's going on here. > > My configuration so far: > > perl-5.6.1-34.99.6 RPM from RedHat 7.2 > > # perl -V > Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: > Platform: > osname=linux, osvers=2.4.17-0.13smp, archname=i386-linux > uname='linux daffy.perf.redhat.com 2.4.17-0.13smp #1 smp fri feb 1 10:30:48 est >2002 i686 unknown ' > config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc -Dcf_by=Red >Hat, Inc. -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux >-Dvendorprefix=/usr -Dsiteprefix=/usr -Uusethreads -Uuseithreads -Uuselargefiles >-Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm -Di_gdbm -Di_shadow -Di_syslog >-Dman3ext=3pm' > hint=recommended, useposix=true, d_sigaction=define > usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef > useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef > use64bitint=undef use64bitall=undef uselongdouble=undef > Compiler: > cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include', > optimize='-O2 -march=i386 -mcpu=i686', > cppflags='-fno-strict-aliasing -I/usr/local/include' > ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.2 2.96-109)', >gccosandvers='' > intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 > ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 > alignbytes=4, usemymalloc=n, prototype=define > Linker and Libraries: > ld='gcc', ldflags =' -L/usr/local/lib' > libpth=/usr/local/lib /lib /usr/lib > libs=-lnsl -ldl -lm -lc -lcrypt -lutil > perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil > libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' > cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' > > > Characteristics of this binary (from libperl): > Compile-time options: > Built under linux > Compiled at Apr 1 2002 12:23:22 > @INC: > /usr/lib/perl5/5.6.1/i386-linux > /usr/lib/perl5/5.6.1 > /usr/lib/perl5/site_perl/5.6.1/i386-linux > /usr/lib/perl5/site_perl/5.6.1 > /usr/lib/perl5/site_perl/5.6.0/i386-linux > /usr/lib/perl5/site_perl/5.6.0 > /usr/lib/perl5/site_perl > /usr/lib/perl5/vendor_perl/5.6.1/i386-linux > /usr/lib/perl5/vendor_perl/5.6.1 > /usr/lib/perl5/vendor_perl > . > > apache-1.3.24, mod_perl-1.27 > cd /usr/src/mod_perl-1.27 > perl Makefile.PL \ > APACHE_SRC=../apache-perl-1.3.24/src \ > NO_HTTPD=1 USE_APACI=1 PREP_HTTPD=1 \ > EVERYTHING=1 > make && make install && cd ../apache-perl-1.3.24 > ./configure --prefix=/usr/local/apache-perl \ > --disable-module=autoindex \ > --disable-module=imap \ > --disable-module=include \ > --disable-module=log_config \ > --disable-module=alias \ > --disable-module=auth \ > --disable-module=cgi \ > --disable-module=env \ > --disable-module=userdir \ > --activate-module=src/modules/perl/libperl.a > make && make install > src/httpd -l > http_core.c mod_mime.c mod_negotiation.c mod_status.c mod_dir.c > mod_asis.c mod_actions.c mod_access.c mod_setenvif.c mod_perl.c > > Any help would be appreciated... > > Thanks, > Jeremy Weatherford > [EMAIL PROTECTED] > http://xidus.net >
[GUIDE] Installing Apache with mod_accel, mod_deflate
For those of you who have mod_accel and mod_deflate and need to upgrade your Apache version due to the security exploit, I wrote a document that tells exactly what to do from start to finish. I wrote this because I was tired of having to dig up old mailing list posts to figure out how to install these every time I upgrade my Apache. It should make upgrading less painful. Installing Apache 1.3.x with mod_accel, mod_deflate and mod_php http://www.aaanime.net/pmak/apache/mod_accel/
perl xml api's
Hi, My Mission(must accept it) is to retrieve xml-formatted mail, parse thru char-sets in msg-body, if chars out of ascii range: generate err msg. While I wade thru the apis could any one suggest which modules would fit this task? Will XML::Parser retrieve a doc from a url or must the doc be retrived and handed to it? tips appreciated. md __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
[ANNOUNCE] mod_perl-1.99_04
The URL
http://perl.apache.org/dist/mod_perl-1.99_04.tar.gz
has entered CPAN as
file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.99_04.tar.gz
size: 396779 bytes
md5: 6d573b4de6a90246154bfc436da4fced
note: 1.99_04+ is required to compile with 5.8.0-RC2
note: 1.99_04+ will no longer compile with 5.8.0-RC1
Changes since 1.99_03:
various APR PerlIO updates [Stas Bekman]
stop using an apr_pool_t to allocate items for the interpreter pool,
safer for threaded MPMs and prevents "leaks" when interpreters are
removed from due to PerlInterpMax{Requests,Spare}
implement modperl_sys_dlclose() to avoid apr/pool overhead/thread issues
get the -DPERL_CORE optimization working again
PERL_SET_CONTEXT to the parent interpreter when cloning interpreters at
request time, else dTHX might be NULL during clone in the given thread,
which would crash the server.
---
Enjoy,
-Doug
Knowing your limitation - was Re: [JOB] Crack OOP Perl whitebox tester wanted
Thanks for your response, Zac. Our tech team is very small. I'm the manager of the group, and my management style would best be described as lackadaisical. :-) So, you're right, this requirement is based upon management weakness. I knew that when I posted the job offer. In fact, I even told that to the employee who was leaving for Washington D.C. as the reason why I couldn't keep him on. He understood completely, having worked with me. :-) While I agree that it would be ideal to simply pick the best person for the job, this obviously isn't completely realistic. For instance, we have a certain pay range that we can afford, and that will artificially limit who we can consider. Other people won't even know we have an opening. Others still might have a language or communications barrier that makes it impossible for us to work with them. Notice that this is not actually his deficiency, but ours. If we could just speak (insert language here). I just don't see adding one additional limitation to that by wanting someone to come to the office as all that big a deal. Many people prefer it, and in this economy, help is not scarce and people are willing to go the extra mile. After all, it's not about getting the best person, it's about getting the best work done. If I know that I can't effectively remote manage somebody so it would be silly for me to attempt this in vain. On Friday, June 21, 2002, at 08:30 AM, Zac Morris wrote: Old fashioned is right, and disregarding "telecommuters" is also extreemly short sighted and ultimaty limits your ability to provide the most quality solution... I work for Cisco Systems in our RTP (NC) office. I work with two different groups, one based in San Jose and the other based in Ontario, as a "virtual team member" (what we call our telecommuter positions). I only bring all this up because I'm in exactly the role you've outlined here, and to be honest I don't think I would BE as successful as I am if I were located directly with either of these teams. The need to have everyone "all together" is usually indicative of a larger problem in team dynamics, and communications. It usually represents a team in which "charasmatic" leadership is more important than technical know how or ability to get a job done. Now don't get me wrong, for a person to BE a successful "virtual team member" they have to have great communication skills, and be open to working with others in multiple formats to enable the best level of teamwork and participation. With all this said, and based on my own personal experience in this role, I can tell you that what you're asking for here is a person to walk a VERY shape edge between the need to bring the best and brightest from people, without making it seem "personal". Actually having this role as an "outsider" to the day to day politics and interpersonal sabatoge of most bay area offices (yeah I lived there five years during the "boom") , gives a layer of abstraction that makes the job easier to perform. When someone is questioning things like style, or code effeciency it comes across MUCH easier (more acadimic) when that person is a "talking head", an IM box, or a voice on the telephone. It becomes less "personalized" and easier to "pick and choose" the best componants into a greater whole. It also isolates the individual who may end up doing a lot of refactoring to present the final solution. Just something to consider. Open youself to the best people in the world and don't accept just the best you can find in your area, and you'll find that you solutions aren't also as limited... -Zac Morris - Original Message - From: Tom Mornini To: [EMAIL PROTECTED] Sent: Thursday, June 20, 2002 11:30 PM Subject: [JOB] Crack OOP Perl whitebox tester wanted We're 1 year into development of a system that is OO Perl, mod_perl, DBI and DBD::Oracle on Linux. We've spent a lot of energy doing it right and writing tests as we go. This has given us huge benefits in the life of the project, but our current whitebox tester has decided to move to Washington, D.C. so we need somebody to fill his large shoes. If you're a good Perl programmer who has a strong sense of "the way it should be" and can be simultaneously mean, nasty, angry, distrustful and unforgiving to Perl code and the opposite to people then we'd like to talk to you. This person doesn't do new development, per se, but he is responsible for making things better via testing, fixing, documentation and refactoring. This is a full time job at an office in the South Park area of San Francisco, California, USA. Telecommuters are NOT what we have in mind. Call us old fashioned that way. :-) Pay and benefits are good, though it's no longer 1998. :-) Best benefit is working with a small group of people that are highly motivated by doing it right. -- -- Tom Mornini -- eWingz Systems, Inc. -- -- ICQ: 113526784, AOL, Yahoo, MSN and Jabber: tmornini
Re: [OT] Re: Apache Web Server vulnerability
At 20:06 21.06.2002, Philip Mak wrote: >On Fri, Jun 21, 2002 at 05:31:00AM -0700, Ask Bjoern Hansen wrote: > > 64bit binaries are exploitable. There are also exploits for several > > 32bit systems. > >Does anyone know if Red Hat Linux 7.2 on i686 is vulnerable to the >remote shell (not the DoS) exploit? I suggest bringing this up on the appropriate httpd lists instead. This thread has gone far enough IMO. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: [OT] Re: Apache Web Server vulnerability
> On Fri, 21 Jun 2002 14:06:45 -0400, Philip Mak <[EMAIL PROTECTED]> said: PM> On Fri, Jun 21, 2002 at 05:31:00AM -0700, Ask Bjoern Hansen wrote: >> 64bit binaries are exploitable. There are also exploits for several >> 32bit systems. PM> Does anyone know if Red Hat Linux 7.2 on i686 is vulnerable to the PM> remote shell (not the DoS) exploit? Very likely. While most advisories claimed that it is imposible to exploit it on 32bit architectures later there was posted working exploit for x86 port of OpenBSD. Author of exploit claimed that he have been able to exploit Linux, FreeBSD and Solaris too. Though exploits for these platforms have not been published (yet). -- Ilya Martynov (http://martynov.org/)
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)
At 19:46 21.06.2002, Stas Bekman wrote: >Per Einar Ellefsen wrote: >>At 18:26 21.06.2002, Zac Morris wrote: >> >>>I actually have a question along these lines >>> >>>I'm new to mod_perl myself, and I've just installed a new setup with Apache2 >>>and the mod_perl2 beta. >>> >>>That's all working well and my old cgi-bin type stuff works under mod_perl >>>great. >>> >>>Now I'm trying to get more into the mod_perl specific stuff and when I: use >>>Apache::DBI I'm getting a can't find Apache.pm >>> >>>To use Apache::DBI do I need the old mod_perl 1 also installed running some >>>kind of "dual mode"? Or is that not even an option since I'm running >>>Apache2. I'm learning quick so if this is covered someplace just give me a >>>quick pointer. >> >>As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: >>1) make sure you are using the prefork MPM for Apache (as Stas said, >>Apache::DBI can only work with that one) >>2) You will probably need to run mod_perl 2.0 in compat mode: put >> PerlModule Apache::compat > >but first you need: > >PerlModule Apache2 > >or 'use Apache2' in startup.pl. see: >http://perl.apache.org/release/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_Modules Nope, he did a "clean" mod_perl 2 install, without MP_INST_APACHE2 I think... so doesn't have an Apache.pm because mod_perl 1 wasn't installed before. -- Per Einar Ellefsen [EMAIL PROTECTED]
[OT] Re: Apache Web Server vulnerability
On Fri, Jun 21, 2002 at 05:31:00AM -0700, Ask Bjoern Hansen wrote: > 64bit binaries are exploitable. There are also exploits for several > 32bit systems. Does anyone know if Red Hat Linux 7.2 on i686 is vulnerable to the remote shell (not the DoS) exploit?
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI0.89)
>> but first you need: >> >> PerlModule Apache2 >> >> or 'use Apache2' in startup.pl. see: >> >http://perl.apache.org/release/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_Modules > >> > > > Nope, he did a "clean" mod_perl 2 install, without MP_INST_APACHE2 I > think... so doesn't have an Apache.pm because mod_perl 1 wasn't > installed before. ah, ok then, but most likely MP_INST_APACHE2 is going to be the default, so if later you need to install mod_perl 1.0 you don't have to wipe your 2.0 install first. so better start getting used to it :) -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache vulnerability: update of uwinnipeg win32 packages planned?
On Fri, 21 Jun 2002, Alessandro Forghieri wrote: > Greetings. > > I was wondering wether Randy is planning an update for his (great) archives > on uwinnipeg. > > Cheers, > alf The mod_perl ppms (both for mod_perl-1 and mod_perl-2) have been updated to the new apache versions, as has the Apache2.tar.gz and perl-5.8-win32-bin.tar.gz binary packages (I'll update the latter to RC2 this weekend). There is still some demand for the all-inclusive apache/perl/mod_perl perl-win32-bin-x.x.exe binary packages we have, but I wasn't planning on making a new one of those until perl-5.8 is officially released. best regards, randy
Apache Web Server vulnerability the full monte
June 21, 2002 High Risk Apache Exploit Circulating By Ryan Naraine The Apache Foundation has issued a warning that exploits to its chunk handling vulnerability are circulating on the Internet, putting users of its open-source server at high risk. The vulnerability, which Apache now says affects both 64-bit platforms and 32-bit platforms alike, could cause denial-of-service attacks or allow a attacker to take remote control of a server. "Though we previously reported that 32-bit platforms were not remotely exploitable, it has since been proven (that certain conditions allowing exploitation do exist)," Apache warned, urging users upgrade to versions 1.3.26 and 2.0.39 to apply a comprehensive fix. "Due to the existence of exploits circulating in the wild for some platforms, the risk is considered high...All users are urged to upgrade immediately," the Foundation said. Apache updated its security bulletin to warn that exploitation of the chunk handling bug could lead to the further exploitation of vulnerabilities unrelated to Apache on the local system, potentially allowing the intruder root access. "Note that early patches for this issue released by ISS and others do not address its full scope," Apache said, referring to a patch that was issued by the Internet Security Systems (IIS) that did not offer a comprehensive fix. The existence of the Apache exploit made the rounds on the popular Bugtraq security e-mail list. Posts to the list include this warning that the Apache exploit tool was "./friendly," meaning anyone with basic scripting capabilities "should be able to run it without any trouble." The release of the source code for the Apache exploit adds new fuel to the controversy over how the bug announcement was handled. The original warning was first reported by the ISS, causing friction between the security outfit and the Apache Foundation. Apache officials were upset they weren't first notified before the ISS issued its advisory and patch, a normal procedure when bugs are detected. The Apache Foundation said the bug affected versions of its Web server up to and including 1.3.24 and 2.0 up to and including 2.0.36 and 2.0.36-dev, warning that it could be triggered remotely by sending a carefully crafted invalid request, which is enabled by default. "In most cases the outcome of the invalid request is that the child process dealing with the request will terminate. At the least, this could help a remote attacker launch a denial of service attack as the parent process will eventually have to replace the terminated child process and starting new children uses non-trivial amounts of resources," Apache said. Because Apache servers on the Windows and Netware platforms runs one multithreaded child process to service requests, the Foundation said the teardown and subsequent setup time to replace the lost child process presents a significant interruption of service. "As the Windows and Netware ports create a new process and reread the configuration, rather than fork a child process, this delay is much more pronounced than on other platforms," it explained. In the Apache 2.0 version, it said the error condition is correctly detected and would not allow an attacker to execute code on the server. In Apache 1.3, it said the issue causes a stack overflow. The Foundation again warned that vendor patches should be used to correct the vulnerability as a matter of urgency. http://www.apache.org/dist/httpd/Announcement.html Since I do not use mod_proxy anyone know why the default is not minimalistic adding just enough functionality as req? Seems to me enabling rather than disabling is better. TIA This is now way OT AFAIK. Best Regards, [EMAIL PROTECTED] -- /* Security is a work in progress - dreamwvr */ # # Note: To begin Journey type man afterboot,man help,man hier[.] # // "Who's Afraid of Schrodinger's Cat?" /var/(.)?mail/me \? ;-]
Re: Compiling mod_perl 1.27 on Win32
On Fri, 21 Jun 2002, Vladimir Goncharov wrote: > Hello All, I am failed to compile mod_perl on Win32 using > "Apache mod_perl-1.xx installation instructions for Win32" > from http://perl.apache.org/win32_compile.html > > Used software : > Apache 1.3.26 + mod_ssl 2.8.9 > mod_perl 1.27 > ActivePerl -5.6.1.631-MSWin32-x86 > MS VC++ 6.0 > Win2k prof SP2 > > I could compile mod_perl.so using "Building with MS Developer > Studio" instructions only with three additional steps. > > First, after > > perl Makefile.PL > nmake install > I need to add this lines to Makefile > > ModuleConfig :: > > cd src/modules/perl > > $(PERL) -I$(PERL_ARCHLIB) -I$(PERL_LIB) $(XSUBPP) > $(XSPROTOARG) $(XSUBPPARGS) $*.xs > $*.xsc && $(MV) $*.xsc > $*.c > > == > and then run "nmake ModuleConfig" to get ModuleConfig.c which > is missing without this step. Thanks for pointing that out ... ModuleConfig builds when using the 'perl Makefile.PL APACHE_SRC=...' method, described later on in the page, so something seems missing when using the Developer Studio method. I'll look into that > Second, I need to select "Show directories for: [Include > files]", and add > > driveletter:\somewhere\APACHE_1.3.26\SRC\OS\WIN32 This is mentioned in the docs, but very briefly - perhaps it could be given more prominence > Third, for Apache compiled with mod_ssl, I need to add /D > "EAPI" in Project/Settings/[C/C++]/"Project Options" This is missing in the Developer Studio docs, and should be added (it is available in the 'perl Makefile.PL EAPI=1' way of building). I'll add it to the docs. > Question: Is there mistakes in instructions on > http://perl.apache.org/win32_compile.html or I did something > wrong? As long as 'nmake test' passes all tests, things are probably fine ... I'll look into the issues above - thanks. best regards, randy kobes
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI0.89)
Per Einar Ellefsen wrote: > At 18:26 21.06.2002, Zac Morris wrote: > >> I actually have a question along these lines >> >> I'm new to mod_perl myself, and I've just installed a new setup with >> Apache2 >> and the mod_perl2 beta. >> >> That's all working well and my old cgi-bin type stuff works under >> mod_perl >> great. >> >> Now I'm trying to get more into the mod_perl specific stuff and when >> I: use >> Apache::DBI I'm getting a can't find Apache.pm >> >> To use Apache::DBI do I need the old mod_perl 1 also installed running >> some >> kind of "dual mode"? Or is that not even an option since I'm running >> Apache2. I'm learning quick so if this is covered someplace just give >> me a >> quick pointer. > > > As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: > 1) make sure you are using the prefork MPM for Apache (as Stas said, > Apache::DBI can only work with that one) > 2) You will probably need to run mod_perl 2.0 in compat mode: put > PerlModule Apache::compat but first you need: PerlModule Apache2 or 'use Apache2' in startup.pl. see: http://perl.apache.org/release/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_Modules > in your httpd.conf, before loading other modules (like Apache::DBI). > > You will probably also want to see the 2.0 docs at > http://perl.apache.org/release/docs/ start here: http://perl.apache.org/release/docs/2.0/user/intro/start_fast.html but since it seems that you've it installed already, proceed here: http://perl.apache.org/release/docs/2.0/user/config/config.html#Enabling_mod_perl though I haven't tried, you should be able to use Apache::DBI with the compat layer and preforked mpm/ __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache Web Server vulnerability
On Fri, Jun 21, 2002 at 05:31:00AM -0700, Ask Bjoern Hansen wrote: > On Wed, 19 Jun 2002, dreamwvr wrote: > > > "my comments FWIW" > > This means thus far does not impact as_seriously little endian NIX > > based architectures. The reason being? That Apache spawns a pool of > > child processes to serve requests. Therefore a DoS kills the child serving > [...] > > This doesn't make much sense at all. To elaborate this opinion was based on the conclusions of one of the advisories .. > 64bit binaries are exploitable. There are also exploits for several > 32bit systems. well I did not say that x86 was not exploitable. However nix based archs were more difficult. This due to spawning ps rather than as windows and novell using a single process and many threads. That was directly from an advisory.. actually. && in reference to the SEGVs .. directly. > If done "right" these will give the attacker shell access to the > server. Your comments about threaded vs "multi processed" are only > relevant when the exploit is not "done right" (when the server > SEGVs). True; ( && that is what exactly I was referring to.. :) well any exploit "if_done_right" can expand into a full blown remote exploit for example. Once someone is local then basically it is only a matter of time. IMHO. OR if you like sooner or later. Best Regards, [EMAIL PROTECTED] -- /* Security is a work in progress - dreamwvr */ # # Note: To begin Journey type man afterboot,man help,man hier[.] # // "Who's Afraid of Schrodinger's Cat?" /var/(.)?mail/me \? ;-]
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)
At 18:26 21.06.2002, Zac Morris wrote: >I actually have a question along these lines > >I'm new to mod_perl myself, and I've just installed a new setup with Apache2 >and the mod_perl2 beta. > >That's all working well and my old cgi-bin type stuff works under mod_perl >great. > >Now I'm trying to get more into the mod_perl specific stuff and when I: use >Apache::DBI I'm getting a can't find Apache.pm > >To use Apache::DBI do I need the old mod_perl 1 also installed running some >kind of "dual mode"? Or is that not even an option since I'm running >Apache2. I'm learning quick so if this is covered someplace just give me a >quick pointer. As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat in your httpd.conf, before loading other modules (like Apache::DBI). You will probably also want to see the 2.0 docs at http://perl.apache.org/release/docs/ Good luck! -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: [ANNOUNCE] Apache::DBI 0.89
I actually have a question along these lines I'm new to mod_perl myself, and I've just installed a new setup with Apache2 and the mod_perl2 beta. That's all working well and my old cgi-bin type stuff works under mod_perl great. Now I'm trying to get more into the mod_perl specific stuff and when I: use Apache::DBI I'm getting a can't find Apache.pm To use Apache::DBI do I need the old mod_perl 1 also installed running some kind of "dual mode"? Or is that not even an option since I'm running Apache2. I'm learning quick so if this is covered someplace just give me a quick pointer. Thanks! -Zac Morris http://www.zacwolf.com - Original Message - From: "Stas Bekman" <[EMAIL PROTECTED]> To: "Perrin Harkins" <[EMAIL PROTECTED]> Cc: "Ask Bjoern Hansen" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, June 21, 2002 12:03 PM Subject: Re: [ANNOUNCE] Apache::DBI 0.89 > Perrin Harkins wrote: > > Ask Bjoern Hansen wrote: > > > >> In the last almost 3 years only two bugs has been found. Edmund no > >> longer has time to make releases and such, so I fixed the last bug > >> and made a new release which is available on CPAN. > > > > > > Thanks for taking over maintenance on this. Any thoughts about how to > > add support for threading in perl 5.8/mod_perl 2 to this? It might be > > premature, since the DBI/DBD modules are not necessarilly thread safe. > > the preforked mpm will use the same old Apache::DBI > > the threaded mpms will need a new version/mode of Apache::DBI using > threads::shared, currently available only for 5.8.0-tobe, unless things > will get backported to 5.6.2. Currently it seems that the threaded mpms > will be safe to use only with 5.8.0, unless again things will get > backported. Otherwise chances are that 5.8.0 will be a requirement. > > Originally Doug was planning on Apache::DBIPool described in his 2.0 > overview: > http://perl.apache.org/release/docs/2.0/user/overview/overview.html#Apache__ DBIPool > but since we now have threads::shared it's not needed anymore. > > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com >
Fwd: Perl 5.8.0 Release Candidate 2
[a note from me: This is probably the last RC before 5.8.0-final is released. So test your code now or don't complain later that something breaks.] Date: Fri, 21 Jun 2002 17:59:55 +0300 From: Jarkko Hietaniemi <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Perl 5.8.0 Release Candidate 2 =head1 Perl 5.8.0 Release Candidate 2 The Perl 5 developer team is pleased to announce the Release Candidate 2 (RC2) of Perl 5.8.0. The RC2 includes changes made by the Perl 5 development team since RC1 (released 2002-06-01) If you had problems with RC1, please retry now. If you hadn't, please check that we didn't break anything. Please test extensively. Your help in testing the upcoming perl 5.8.0 is much appreciated. This is a source code release, not a binary release. You will need a C development environment. Please note that Perl 5.8.0 is a major new release of Perl containing many new features, enhancements to existing features and bug fixes. This version is "Release Candidate 2"; the purpose of this version is to permit and encourage the Perl community to conduct extensive testing and to report problems so that we, and the owners of affected Perl packages, have an opportunity to correct them. Because the process of testing the vast quantity of Perl software will take time, and because issues uncovered by this testing may result in further changes or corrections to Perl 5.8.0 and the various Perl packages, WE DO NOT RECOMMEND USING RELEASE CANDIDATE 2 IN A PRODUCTION ENVIRONMENT. Please wait for the final version of Perl 5.8.0 for production use. As always, you should conduct an appropriate level of testing before using any new product in your production environment. As specified in the licenses for Perl (see the files named Artistic or Copying), THIS PACKAGE IS PROVIDED WITH ABSOLUTELY NO WARRANTY. New Release Candidates will come out about every few weeks until we are satisfied with the results, at which point the final 5.8.0 will be released. =head1 Where To Get It The 5.8.0 RC2 is now available at http://mirrors.kernel.org/cpan/src/perl-5.8.0-RC2.tgz http://cpan.valueclick.com/src/perl-5.8.0-RC2.tgz ftp://ftp.leo.org/pub/CPAN/src/perl-5.8.0-RC2.tgz ftp://ftp.funet.fi/pub/CPAN/src/perl-5.8.0-RC2.tgz and as the CPAN mirrors catch up, in the src/ subdirectory of your nearest friendly CPAN mirror. The size of the file is 10975492 bytes and the MD5 checksum for the file is 8921b99874bf4b1daba7daba3ff70e4a perl-5.8.0-RC2.tgz This release should work in all UNIX/Linux and Microsoft environments, and in other environments which have POSIX/UNIX interfaces, such as BeOS, Cygwin, MPE/iX, NetWare, OS/2, QNX, VMS, VOS, and z/OS, and the appropriate C compilation environment. Mac OS Classic port of 5.8.0 is available separately, follow http://dev.macperl.org/ =head1 Why To Get It For the list of changes in 5.8.0 see the pod/perldelta.pod, available separately online at http://mirrors.kernel.org/cpan/doc/perldelta.pod http://cpan.valuelick.com/doc/perldelta.pod ftp://ftp.leo.org/pub/CPAN/doc/perldelta.pod ftp://ftp.funet.fi/pub/CPAN/doc/perldelta.pod (and again, eventually at all CPAN mirrors-- note, though, that these URLs are not permanent, they will be removed when the final 5.8.0 is released) The .tgz file will unpack into a directory called "perl-5.8.0-RC2". =head1 How To Do It You will configure, build, and test Perl. Below is a short summary, for the full story read the "INSTALL" file. =head2 Configuring If you are in a UNIX-like system, you can setup Perl for compilation by changing into the "perl-5.8.0-RC2" directory and issuing the following command: sh Configure -des This will simply select all the defaults for your system, INCLUDING defaulting to install in the usual location for production software. (So don't run make install if you run Configure this way!) If you are not in a UNIX-like system (say, Win32), please read the "INSTALL" file and any possible platform specific README files for further instructions, and skip the parts below that don't apply to your platform. If you want to go through Configure interactively (for example to change the default installation directories), do just sh Configure =head2 Building To build Perl issue the command make all Note that the build times can vary considerably. Perl 5.8.0 is about twice the size of 5.6.1, and some source code files are quite large, so your compiler might have hard time processing them. On a fast modern system with lots of CPU and memory the build can be a matter of ten minutes, but on slower/older/more heavily loaded systems it can take up to eight hours, while half an hour to an hour being common. =head2 Testing After the build has finished, it's time to test the build. make test Again, testing times vary a lot. Perl 5.8.0 has more than five times the tests of Perl 5.6.1. Fifteen minutes to half a
Re: [ANNOUNCE] Apache::DBI 0.89
Stas Bekman wrote: > the threaded mpms will need a new version/mode of Apache::DBI using > threads::shared, currently available only for 5.8.0-tobe, unless things > will get backported to 5.6.2. Currently it seems that the threaded mpms > will be safe to use only with 5.8.0, unless again things will get > backported. Otherwise chances are that 5.8.0 will be a requirement. I saw that message, which is why I mentioned 5.8, but I was wondering if anyone has seen discussion of whether or not DBI will be safe to use with 5.8 threads. Does anyone know? - Perrin
Re: [ANNOUNCE] Apache::DBI 0.89
Perrin Harkins wrote: > Ask Bjoern Hansen wrote: > >> In the last almost 3 years only two bugs has been found. Edmund no >> longer has time to make releases and such, so I fixed the last bug >> and made a new release which is available on CPAN. > > > Thanks for taking over maintenance on this. Any thoughts about how to > add support for threading in perl 5.8/mod_perl 2 to this? It might be > premature, since the DBI/DBD modules are not necessarilly thread safe. the preforked mpm will use the same old Apache::DBI the threaded mpms will need a new version/mode of Apache::DBI using threads::shared, currently available only for 5.8.0-tobe, unless things will get backported to 5.6.2. Currently it seems that the threaded mpms will be safe to use only with 5.8.0, unless again things will get backported. Otherwise chances are that 5.8.0 will be a requirement. Originally Doug was planning on Apache::DBIPool described in his 2.0 overview: http://perl.apache.org/release/docs/2.0/user/overview/overview.html#Apache__DBIPool but since we now have threads::shared it's not needed anymore. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::LightBackhand
Ricardo Basto wrote: > For example, the other modules try to interpret the response code of the > request before forwarding it back. My module tries the opposite: the > only case it will fake a response code different from what it got is > when the LWP request times out. Every 404, 500, 302 etc. will just be > passed back to the client. This I think is something original to my > module. In general, the only reason people would use mod_perl for this kind of thing is so that they can modify the returned content in some way, or provide additional access control. Transparent reverse proxying is more efficiently done with mod_proxy and mod_rewrite. See this, for example: http://www.engelschall.com/pw/apache/rewriteguide/#ToC27 > And I'm neither sure if that is the best name for my module, but I think > it's target is much more people googling for "backhand" than for > "proxy". Well, mod_backhand is a load-balancer, not a proxy. It uses some proxying ability to accomplish it's goal, but it's really not about proxying. You module seems like a proxy module to me. In addition to the Apache::ReverseProxy, it looks like Apache::ProxyPass and Apache::ProxyRewrite all do essentially the same thing. Maybe you could fold your ideas into one of those. - Perrin
Re: [ANNOUNCE] Apache::DBI 0.89
Ask Bjoern Hansen wrote: > In the last almost 3 years only two bugs has been found. Edmund no > longer has time to make releases and such, so I fixed the last bug > and made a new release which is available on CPAN. Thanks for taking over maintenance on this. Any thoughts about how to add support for threading in perl 5.8/mod_perl 2 to this? It might be premature, since the DBI/DBD modules are not necessarilly thread safe. - Perrin
Re: apache 1.3.24 mod_perl 1.27 perl 5.6.1 segv
PLEASE upgrade to apache 1.3.26, especially if you're rebuilding now anyway. There are root exploits circulating for apache 1.3.24 and below. Wes Sheldahl John Saylor <[EMAIL PROTECTED]> on 06/21/2002 11:18:06 AM To: [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: apache 1.3.24 mod_perl 1.27 perl 5.6.1 segv Hi Try as I might, I cannot get apache to run. It just keeps segv-ing. When I run it with -X I can see the failure [with gdb's help] #0 0x401aac25 in __libc_free (mem=0x4039c778) at malloc.c:3155 #1 0x403472c4 in Perl_sv_clear () from /opt/webtree/ww/modules/libperl.so #2 0x403474d5 in Perl_sv_free () from /opt/webtree/ww/modules/libperl.so #3 0x40341a08 in S_visit () from /opt/webtree/ww/modules/libperl.so #4 0x40341a7f in Perl_sv_clean_all () from /opt/webtree/ww/modules/libperl.so #5 0x402fc2ae in perl_destruct () from /opt/webtree/ww/modules/libperl.so #6 0x402dd63a in perl_shutdown () from /opt/webtree/ww/modules/libperl.so #7 0x402dda89 in mp_dso_unload () from /opt/webtree/ww/modules/libperl.so #8 0x08051490 in run_cleanups () at eval.c:41 #9 0x0804fd42 in ap_clear_pool () at eval.c:41 #10 0x08061044 in standalone_main () at eval.c:41 #11 0x08061a13 in main () at eval.c:41 #12 0x40146507 in __libc_start_main (main=0x8061660 , argc=4, ubp_av=0xb874, init=0x804ebd0 <_init>, fini=0x8080d00 <_fini>, rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xb86c) at ../sysdeps/generic/libc-start.c:129 I thought it was related to filesizes [-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64] but I don't think that's it anymore since they all match. Any help or suggestions are welcome. -- \js "If that makes any sense to you, you have a big problem." -- C. Durance, Computer Science 234
Re: [JOB] Crack OOP Perl whitebox tester wanted
Old fashioned is right, and disregarding "telecommuters" is also extreemly short sighted and ultimaty limits your ability to provide the most quality solution... I work for Cisco Systems in our RTP (NC) office. I work with two different groups, one based in San Jose and the other based in Ontario, as a "virtual team member" (what we call our telecommuter positions). I only bring all this up because I'm in exactly the role you've outlined here, and to be honest I don't think I would BE as successful as I am if I were located directly with either of these teams. The need to have everyone "all together" is usually indicative of a larger problem in team dynamics, and communications. It usually represents a team in which "charasmatic" leadership is more important than technical know how or ability to get a job done. Now don't get me wrong, for a person to BE a successful "virtual team member" they have to have great communication skills, and be open to working with others in multiple formats to enable the best level of teamwork and participation. With all this said, and based on my own personal experience in this role, I can tell you that what you're asking for here is a person to walk a VERY shape edge between the need to bring the best and brightest from people, without making it seem "personal". Actually having this role as an "outsider" to the day to day politics and interpersonal sabatoge of most bay area offices (yeah I lived there five years during the "boom") , gives a layer of abstraction that makes the job easier to perform. When someone is questioning things like style, or code effeciency it comes across MUCH easier (more acadimic) when that person is a "talking head", an IM box, or a voice on the telephone. It becomes less "personalized" and easier to "pick and choose" the best componants into a greater whole. It also isolates the individual who may end up doing a lot of refactoring to present the final solution. Just something to consider. Open youself to the best people in the world and don't accept just the best you can find in your area, and you'll find that you solutions aren't also as limited... -Zac Morris - Original Message - From: Tom Mornini To: [EMAIL PROTECTED] Sent: Thursday, June 20, 2002 11:30 PM Subject: [JOB] Crack OOP Perl whitebox tester wanted We're 1 year into development of a system that is OO Perl, mod_perl,DBI and DBD::Oracle on Linux.We've spent a lot of energy doing it right and writing tests as we go.This has given us huge benefits in the life of the project, but our currentwhitebox tester has decided to move to Washington, D.C. so we needsomebody to fill his large shoes.If you're a good Perl programmer who has a strong sense of "the way itshould be" and can be simultaneously mean, nasty, angry, distrustful andunforgiving to Perl code and the opposite to people then we'd like totalk to you.This person doesn't do new development, per se, but he is responsiblefor making things better via testing, fixing, documentation and refactoring.This is a full time job at an office in the South Park area of San Francisco,California, USA. Telecommuters are NOT what we have in mind. Call usold fashioned that way. :-)Pay and benefits are good, though it's no longer 1998. :-) Best benefitis working with a small group of people that are highly motivated bydoing it right.-- -- Tom Mornini-- eWingz Systems, Inc. ICQ: 113526784, AOL, Yahoo, MSN and Jabber: tmornini
apache 1.3.24 mod_perl 1.27 perl 5.6.1 segv
Hi Try as I might, I cannot get apache to run. It just keeps segv-ing. When I run it with -X I can see the failure [with gdb's help] #0 0x401aac25 in __libc_free (mem=0x4039c778) at malloc.c:3155 #1 0x403472c4 in Perl_sv_clear () from /opt/webtree/ww/modules/libperl.so #2 0x403474d5 in Perl_sv_free () from /opt/webtree/ww/modules/libperl.so #3 0x40341a08 in S_visit () from /opt/webtree/ww/modules/libperl.so #4 0x40341a7f in Perl_sv_clean_all () from /opt/webtree/ww/modules/libperl.so #5 0x402fc2ae in perl_destruct () from /opt/webtree/ww/modules/libperl.so #6 0x402dd63a in perl_shutdown () from /opt/webtree/ww/modules/libperl.so #7 0x402dda89 in mp_dso_unload () from /opt/webtree/ww/modules/libperl.so #8 0x08051490 in run_cleanups () at eval.c:41 #9 0x0804fd42 in ap_clear_pool () at eval.c:41 #10 0x08061044 in standalone_main () at eval.c:41 #11 0x08061a13 in main () at eval.c:41 #12 0x40146507 in __libc_start_main (main=0x8061660 , argc=4, ubp_av=0xb874, init=0x804ebd0 <_init>, fini=0x8080d00 <_fini>, rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xb86c) at ../sysdeps/generic/libc-start.c:129 I thought it was related to filesizes [-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64] but I don't think that's it anymore since they all match. Any help or suggestions are welcome. -- \js "If that makes any sense to you, you have a big problem." -- C. Durance, Computer Science 234
Compiling mod_perl 1.27 on Win32
Hello All, I am failed to compile mod_perl on Win32 using "Apache mod_perl-1.xx installation instructions for Win32" from http://perl.apache.org/win32_compile.html Used software : Apache 1.3.26 + mod_ssl 2.8.9 mod_perl 1.27 ActivePerl -5.6.1.631-MSWin32-x86 MS VC++ 6.0 Win2k prof SP2 I could compile mod_perl.so using "Building with MS Developer Studio" instructions only with three additional steps. First, after perl Makefile.PL nmake install I need to add this lines to Makefile ModuleConfig :: cd src/modules/perl $(PERL) -I$(PERL_ARCHLIB) -I$(PERL_LIB) $(XSUBPP) $(XSPROTOARG) $(XSUBPPARGS) $*.xs > $*.xsc && $(MV) $*.xsc $*.c == and then run "nmake ModuleConfig" to get ModuleConfig.c which is missing without this step. Second, I need to select "Show directories for: [Include files]", and add driveletter:\somewhere\APACHE_1.3.26\SRC\OS\WIN32 Third, for Apache compiled with mod_ssl, I need to add /D "EAPI" in Project/Settings/[C/C++]/"Project Options" Question: Is there mistakes in instructions on http://perl.apache.org/win32_compile.html or I did something wrong? Thanks, Vladimir
Re: [apache-ssl] Porblems marrying Apache 1.3.26, pache-ssl 1.48 and mod_perl 1.27
On Fri, Jun 21, 2002 at 12:18:37PM +0100, Ben Laurie wrote: > The Doctor wrote: > > It has been a long time since what I have described happened. > ... > > /tmp: Permission denied > > > > assertion "0" failed: file "apache_ssl.c", line 1616 > > This is gcache failing to start (mental note: must make diagnostic more > informative). The line before is perror(cmd), so it looks like you claim > the gcache executable is /tmp in your configuration! > Where is the fault? > Cheers, > > Ben. > > -- > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff > > > --- > to unsubscribe, send a blank email to: [EMAIL PROTECTED] > -- Member - Liberal International On 11 Sept 2001 the WORLD was violated. This is [EMAIL PROTECTED] Ici [EMAIL PROTECTED] Society MUST be saved! Extremists must dissolve. Beware of defining as intelligent only those who share your opinions
[ANNOUNCE] Apache::DBI 0.89
Since early 1997 Edmund Mergl has been developing and maintaining Apache::DBI. I would think that it's now one of the most used Apache related modules (and one of the most stable!) In the last almost 3 years only two bugs has been found. Edmund no longer has time to make releases and such, so I fixed the last bug and made a new release which is available on CPAN. Download here: http://www.cpan.org/authors/id/ABH/Apache-DBI-0.89.tar.gz Change file here; http://cvs.perl.org/cvsweb/Apache/DBI/Changes?rev=1.2&content-type=text/x-cvsweb-markup CVS instructions here: http://cvs.perl.org/info?module=Apache/DBI - ask -- ask bjoern hansen, http://askbjoernhansen.com/ !try; do();
Re: Question about Work Wanted ads
On Wed, 19 Jun 2002, southernstar wrote: > I was aware that on occasion individuals are welcome to post work > wanted ads, but I have some specific questions about how I can > actually get some short contract work here and there, since: [...] Get involved with some of the open source projects; that's always good to put on your resume. - ask -- ask bjoern hansen, http://askbjoernhansen.com/ !try; do();
Re: [JOB WANTED] Seeking additional Perl/Mod_perl work...
On Thu, 20 Jun 2002, Stas Bekman wrote: [...] > That's a sensitive issue. We were always welcoming posts from > individuals looking for jobs, and companies looking to hire (in the > mod_perl area of course). Though I tend to agree with Gunther that such > posts from for-profit companies looking for projects is a bit unfair, > especially if it's going to escalate into a high traffic of irrelevant > posts (with or without special subject tags). It's important to give > hand to individuals who don't have the power/resources for-profit > companies have, and I believe that's where the distinction lays. Uh, most working individuals are "for-profit" too. I don't see a big problem with companies posting about availability as long as they keep it as a rare thing (every 18 months?) and it doesn't escalate. If it does I am sure we can figure out to make it stop. :-) Posting both jobs and availability at the urls you posted sure sounds like a better idea though. -- ask bjoern hansen, http://askbjoernhansen.com/ !try; do();
Re: Apache Web Server vulnerability
On Fri, 21 Jun 2002, Ask Bjoern Hansen wrote: > On Thu, 20 Jun 2002, Lupe Christoph wrote: > > [...] > > Sorry that is not the answer to my question - the question is if my > > code gets a chance to do *anything*, or will the httpd code just > > crash at a later time? It does not crash like a non-mod_perl httpd. > > I believe it only crashes when using the default handler. Don't > count on it though; there is plenty of obscure ways this issues has > been biting us already. I think not only default handler. If you return 404 or some another error and keepalive is enabled then Apache calls ap_discard_request_body() and start to read chunked body. Second way is to send wrong 'Expect' header - Apache again calls ap_discard_request_body(). Igor Sysoev http://sysoev.ru
Re: Apache Web Server vulnerability
On Wed, 19 Jun 2002, dreamwvr wrote: > "my comments FWIW" > This means thus far does not impact as_seriously little endian NIX > based architectures. The reason being? That Apache spawns a pool of > child processes to serve requests. Therefore a DoS kills the child serving [...] This doesn't make much sense at all. 64bit binaries are exploitable. There are also exploits for several 32bit systems. If done "right" these will give the attacker shell access to the server. Your comments about threaded vs "multi processed" are only relevant when the exploit is not "done right" (when the server SEGVs). - ask -- ask bjoern hansen, http://askbjoernhansen.com/ !try; do();
Re: Apache Web Server vulnerability
On Thu, 20 Jun 2002, Lupe Christoph wrote: [...] > Sorry that is not the answer to my question - the question is if my > code gets a chance to do *anything*, or will the httpd code just > crash at a later time? It does not crash like a non-mod_perl httpd. I believe it only crashes when using the default handler. Don't count on it though; there is plenty of obscure ways this issues has been biting us already. - ask -- ask bjoern hansen, http://askbjoernhansen.com/ !try; do();
Re: [JOB] Crack OOP Perl whitebox tester wanted
On 21/6/02 at 17:58, [EMAIL PROTECTED] (Stas Bekman) wrote: > > Phil Dobbin wrote: > > On 20/6/02 at 20:30, [EMAIL PROTECTED] (Tom Mornini) wrote: > > >>If you're a good Perl programmer who has a strong sense of "the way > it > >>should be" and can be simultaneously mean, nasty, angry, distrustful > >>and > > [...] > > > Sorry if I haven't kept up with this thread but, is this really the > > way the mod_perl list is going to go? > > > > Any clarification appreciated :-) > > Yes Phil, this is how it was since the beginning (1996) and the > majority > seems to be happy about this trend [...] Hi, Stas. Thanks for the clarification. Much obliged :-) Regards, Phil.
Apache vulnerability: update of uwinnipeg win32 packages planned?
Greetings. I was wondering wether Randy is planning an update for his (great) archives on uwinnipeg. Cheers, alf
Re: Apache Web Server vulnerability
On Fri, 21 Jun 2002, Richard [utf-8] Čepas wrote: > On Wed Jun 19 17:54:02 2002 +0400 Igor Sysoev wrote: > > >On 19 Jun 2002, Ilya Martynov wrote: > > > >> If you still do not know about it: > >> > >> http://httpd.apache.org/info/security_bulletin_20020617.txt > >> > >> Now mod_perl question. mod_perl servers often are used as backend > >> servers. I.e. they are not accessed directly but they are accessed > >> either via fronted Apache or via proxy (like squid or oops) in > >> accelerated mode. As I understand advisory in this case backend > >> mod_perl server is not vulnerable since attacker do not have direct > >> access to it. > >> > >> Can anybody confirm it? > > > >If your backend is proxied via mod_proxy or mod_accel then backend is not > >vulnerable because both modules do not accept client's chunked body at all. > >I can not say anything about Squid and Oops. > > > > They have in the changelog for 1.3.26: > * A large number of fixes in mod_proxy including: adding support >for dechunking chunked responses, correcting a timeout problem > <...> > > Does this change anything? I.e. backend is still safe? In 1.3.24 mod_proxy try to support chunked responses that go from servers. It never supports client's chunked body. As far as I know now there are no browsers that send chunked body. Igor Sysoev http://sysoev.ru
Re: Apache Web Server vulnerability
On Thu, 20 Jun 2002, Lupe Christoph wrote: > On Thursday, 2002-06-20 at 18:22:10 +0400, Igor Sysoev wrote: > > On Thu, 20 Jun 2002, Lupe Christoph wrote: > > > > > and the mod_perl module seems to prevent the crash: > > > > > > > telnet proxy.customer.de 80 > > > > Trying 213.155.64.138... > > > > Connected to proxy.customer.de. > > > > Escape character is '^]'. > > > > POST /x.html HTTP/1.1 > > > > Host: proxy.customer.de > > > > Transfer-Encoding: chunked > > > > > > > > 8000 > > > > Rapid 7 > > > > 0 > > > > > > > > > > > > ^] > > > > telnet> Connection closed. > > > > > > Does mod_perl do it's own de-chunking? > > > So mod_perl does not return any response ? > > > There are two ways to prevent crush with particular URI: > > 1. return 411 error if client send chunked body (standard mod_proxy, > >mod_cgi and mod_isapi do it); > > 2. ignore body at all. > > > I suspect second in your case. > > Sorry that is not the answer to my question - the question is if my > code gets a chance to do *anything*, or will the httpd code just > crash at a later time? It does not crash like a non-mod_perl httpd. I think if you Apache does not send any response then it vulnerable with this particular URI. I've tried you request with plain Apache - one process starting to eat CPU without faults. Igor Sysoev http://sysoev.ru
Re: [JOB] Crack OOP Perl whitebox tester wanted
Phil Dobbin wrote: > On 20/6/02 at 20:30, [EMAIL PROTECTED] (Tom Mornini) wrote: >>If you're a good Perl programmer who has a strong sense of "the way it >>should be" and can be simultaneously mean, nasty, angry, distrustful >>and [...] > Sorry if I haven't kept up with this thread but, is this really the way the mod_perl >list is going to go? > > Any clarification appreciated :-) Yes Phil, this is how it was since the beginning (1996) and the majority seems to be happy about this trend. If you want more info please read the archives, where this thread has been discussed to death many times. For those who are still confused here is a short summary: OK: - *mod_perl* job offers posts - *mod_perl* job seekers posts both using the [JOB] or similar tag, so those uninterested can skip it. See: http://perl.apache.org/release/maillist/email-etiquette.html#Tags NOT OK: - non-mod_perl offers/seekers posts - companies looking for projects posts - posts from the OK group without proper subject tags Though if you are a company providing a commercial *mod_perl* support, do submit the relevant URL for inclusion at this page: http://perl.apache.org/release/help/commercial.html Hope this explains all the confusions and keeps everybody happy. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [JOB] Crack OOP Perl whitebox tester wanted
Phil Dobbin <[EMAIL PROTECTED]> writes: > Sorry if I haven't kept up with this thread but, is this really the > way the mod_perl list is going to go? I hope so. All these job postings are making me feel warm and fuzzy for the future. -- Dave Hodgkinson, Wizard for Hire http://www.davehodgkinson.com Editor-in-chief, The Highway Starhttp://www.thehighwaystar.com Interim Technical Director, Web Architecture Consultant for hire
Re: Apache Web Server vulnerability
On Wed Jun 19 17:54:02 2002 +0400 Igor Sysoev wrote: >On 19 Jun 2002, Ilya Martynov wrote: > >> If you still do not know about it: >> >> http://httpd.apache.org/info/security_bulletin_20020617.txt >> >> Now mod_perl question. mod_perl servers often are used as backend >> servers. I.e. they are not accessed directly but they are accessed >> either via fronted Apache or via proxy (like squid or oops) in >> accelerated mode. As I understand advisory in this case backend >> mod_perl server is not vulnerable since attacker do not have direct >> access to it. >> >> Can anybody confirm it? > >If your backend is proxied via mod_proxy or mod_accel then backend is not >vulnerable because both modules do not accept client's chunked body at all. >I can not say anything about Squid and Oops. > They have in the changelog for 1.3.26: * A large number of fixes in mod_proxy including: adding support for dechunking chunked responses, correcting a timeout problem <...> Does this change anything? I.e. backend is still safe? -- ☻ Ričardas Čepas ☺
Re: [JOB] Crack OOP Perl whitebox tester wanted
On 20/6/02 at 20:30, [EMAIL PROTECTED] (Tom Mornini) wrote: > We're 1 year into development of a system that is OO Perl, mod_perl, > DBI and DBD::Oracle on Linux. > > We've spent a lot of energy doing it right and writing tests as we go. > This has given us huge benefits in the life of the project, but our > current > whitebox tester has decided to move to Washington, D.C. so we need > somebody to fill his large shoes. > > If you're a good Perl programmer who has a strong sense of "the way it > should be" and can be simultaneously mean, nasty, angry, distrustful > and [snip] Sorry if I haven't kept up with this thread but, is this really the way the mod_perl list is going to go? Any clarification appreciated :-) Regards, Phil.
