[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: [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.
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
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: [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: 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: 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 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 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: [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: 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();
[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.2content-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: [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
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
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 main, 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 providethe mostquality 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 effeciencyit 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
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: [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
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 an hour is
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
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: 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::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: 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
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 \? ;-]
[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 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
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::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]
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: [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]
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: 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
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). I only bring all this up because I'm in exactly the
cvs commit: modperl-2.0/xs/APR/PerlIO apr_perlio.c apr_perlio.h
stas2002/06/21 08:28:44
Modified:t/response/TestAPR perlio.pm
xs/APR/PerlIO apr_perlio.c apr_perlio.h
Log:
APR PerlIO updates:
- make the apr layer independent from PerlIOBuf
- sync with the latest PerlIO API changes
- cleanup
- add a new test for buffered write
- prepare for the future possible LARGE_FILES_CONFLICT constant, for seek
tests
Revision ChangesPath
1.11 +20 -8 modperl-2.0/t/response/TestAPR/perlio.pm
Index: perlio.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestAPR/perlio.pm,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- perlio.pm 15 Jun 2002 23:48:58 - 1.10
+++ perlio.pm 21 Jun 2002 15:28:43 - 1.11
-12,6 +12,10
use Apache::Const -compile = 'OK';
use constant HAVE_PERLIO = eval { require APR::PerlIO };
+#XXX: feel free to enable if largefile support is not enabled in Perl
+#XXX: APR::LARGE_FILES_CONFLICT constant?
+use constant LARGE_FILES_CONFLICT = 1;
+
sub handler {
my $r = shift;
-22,10 +26,10
return Apache::OK;
}
-my $tests = 2; #XXX 11;
+my $tests = 12;
my $lfs_tests = 3;
-#$tests += $lfs_tests if USE_LARGE_FILES; #XXX
+$tests += $lfs_tests unless LARGE_FILES_CONFLICT;
plan $r, tests = $tests, have_perl 'iolayers';
-36,6 +40,7
my $sep = -- sep --\n;
my lines = (This is a test: $$\n, test line --sep two\n);
+
my $expected = $lines[0];
my $expected_all = join $sep, lines;
-66,10 +71,9
expected failure);
}
}
-return Apache::OK; #XXX remove when perlio issues are sorted out
+
# seek/tell() tests
-#XXX: feel free to enable if largefile support is not enabled in Perl
-if (0) {
+unless (LARGE_FILES_CONFLICT) {
open my $fh, :APR, $file, $r
or die Cannot open $file for reading: $!;
-132,7 +136,7
my expect = ($lines[0] . $sep, $lines[1]);
ok t_cmp(\@expect,
\@got_lines,
- adjusted input record sep read);
+ custom complex input record sep read);
close $fh;
}
-179,17 +183,25
{
open my $wfh, :APR, $file, $r
or die Cannot open $file for writing: $!;
+open my $rfh, :APR, $file, $r
+or die Cannot open $file for reading: $!;
my $expected = This is an un buffering write test;
# unbuffer
my $oldfh = select($wfh); $| = 1; select($oldfh);
print $wfh $expected; # must be flushed to disk immediately
-open my $rfh, :APR, $file, $r
-or die Cannot open $file for reading: $!;
ok t_cmp($expected,
scalar($rfh),
file unbuffered write);
+
+# buffer up
+$oldfh = select($wfh); $| = 0; select($oldfh);
+print $wfh $expected; # must be flushed to disk immediately
+
+ok t_cmp(undef,
+ scalar($rfh),
+ file buffered write);
close $wfh;
close $rfh;
1.16 +102 -47 modperl-2.0/xs/APR/PerlIO/apr_perlio.c
Index: apr_perlio.c
===
RCS file: /home/cvs/modperl-2.0/xs/APR/PerlIO/apr_perlio.c,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- apr_perlio.c 21 Jun 2002 02:06:48 - 1.15
+++ apr_perlio.c 21 Jun 2002 15:28:43 - 1.16
-10,23 +10,37
* The PerlIO API is documented in perliol.pod.
**/
+/*
+ * APR::PerlIO implements a PerlIO layer using apr_file_io as the core.
+ */
+
+/*
+ * XXX: Since we cannot snoop on the internal apr_file_io buffer
+ * currently the IO is not buffered on the Perl side so every read
+ * requests a char at a time, which is slow. Consider copying the
+ * relevant code from PerlIOBuf to implement our own buffer, similar
+ * to what PerlIOBuf does or push :perlio layer on top of this layer
+ */
+
typedef struct {
-PerlIOBuf base;/* PerlIOBuf stuff */
+struct _PerlIO base;
apr_file_t *file;
apr_pool_t *pool;
} PerlIOAPR;
-/* clean up any structures linked from PerlIOAPR. a layer can be
- * popped without being closed if the program is dynamically managing
- * layers on the stream.
- */
-static IV PerlIOAPR_popped(pTHX_ PerlIO *f)
-{
-/* PerlIOAPR *st = PerlIOSelf(f, PerlIOAPR); */
-return 0;
+static IV PerlIOAPR_pushed(pTHX_ PerlIO *f, const char *mode, SV *arg)
+{
+IV code = PerlIOBase_pushed(aTHX_ f, mode, arg);
+if
cvs commit: modperl-2.0/t/response/TestAPR perlio.pm
stas2002/06/21 08:45:06
Modified:t/response/TestAPR perlio.pm
Log:
only a comments fixes
Revision ChangesPath
1.12 +2 -2 modperl-2.0/t/response/TestAPR/perlio.pm
Index: perlio.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestAPR/perlio.pm,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- perlio.pm 21 Jun 2002 15:28:43 - 1.11
+++ perlio.pm 21 Jun 2002 15:45:06 - 1.12
-12,8 +12,8
use Apache::Const -compile = 'OK';
use constant HAVE_PERLIO = eval { require APR::PerlIO };
-#XXX: feel free to enable if largefile support is not enabled in Perl
#XXX: APR::LARGE_FILES_CONFLICT constant?
+#XXX: you can set to zero if largefile support is not enabled in Perl
use constant LARGE_FILES_CONFLICT = 1;
sub handler {
-197,7 +197,7
# buffer up
$oldfh = select($wfh); $| = 0; select($oldfh);
-print $wfh $expected; # must be flushed to disk immediately
+print $wfh $expected; # should be buffered up and not flushed
ok t_cmp(undef,
scalar($rfh),
cvs commit: modperl-2.0/xs/APR/PerlIO apr_perlio.c
stas2002/06/21 08:53:40
Modified:xs/APR/PerlIO apr_perlio.c
Log:
a few minor fixes and cleanups
Revision ChangesPath
1.17 +3 -7 modperl-2.0/xs/APR/PerlIO/apr_perlio.c
Index: apr_perlio.c
===
RCS file: /home/cvs/modperl-2.0/xs/APR/PerlIO/apr_perlio.c,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- apr_perlio.c 21 Jun 2002 15:28:43 - 1.16
+++ apr_perlio.c 21 Jun 2002 15:53:40 - 1.17
-28,7 +28,6
apr_pool_t *pool;
} PerlIOAPR;
-
static IV PerlIOAPR_pushed(pTHX_ PerlIO *f, const char *mode, SV *arg)
{
IV code = PerlIOBase_pushed(aTHX_ f, mode, arg);
-40,7 +39,6
return code;
}
-
static PerlIO *PerlIOAPR_open(pTHX_ PerlIO_funcs *self,
PerlIO_list_t *layers, IV n,
const char *mode, int fd, int imode,
-147,7 +145,6
return NULL;
}
-
static SSize_t PerlIOAPR_read(pTHX_ PerlIO *f, void *vbuf, Size_t count)
{
PerlIOAPR *st = PerlIOSelf(f, PerlIOAPR);
-159,8 +156,8
return count;
}
else if (rc != APR_SUCCESS) {
-char errbuf[120];
#ifdef PERLIO_APR_DEBUG
+char errbuf[120];
/* XXX: need to figure way to map APR errno to normal errno,
* so we can use SETERRNO to make the apr errors available to
* Perl's $! */
-203,6 +200,7
return 0;
}
+PerlIOBase(f)-flags |= PERLIO_F_ERROR;
return -1;
}
-225,7 +223,7
/* Flush the fill buffer */
if (PerlIO_flush(f) != 0) {
- return -1;
+return -1;
}
switch(whence) {
-366,8 +364,6
return -1;
}
-
-
static PerlIO_funcs PerlIO_APR = {
APR,
cvs commit: modperl-2.0 Changes
dougm 2002/06/21 09:39:44
Modified:.Changes
Log:
update Changes
Revision ChangesPath
1.27 +10 -0 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- Changes 17 Jun 2002 20:00:44 - 1.26
+++ Changes 21 Jun 2002 16:39:44 - 1.27
-10,6 +10,16
=item 1.99_04-dev
+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.
cvs commit: modperl-2.0/xs/APR/PerlIO apr_perlio.c
stas2002/06/21 10:37:38
Modified:xs/APR/PerlIO apr_perlio.c
Log:
adjust for PerlIO bleedperl changes
Revision ChangesPath
1.18 +3 -2 modperl-2.0/xs/APR/PerlIO/apr_perlio.c
Index: apr_perlio.c
===
RCS file: /home/cvs/modperl-2.0/xs/APR/PerlIO/apr_perlio.c,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- apr_perlio.c 21 Jun 2002 15:53:40 - 1.17
+++ apr_perlio.c 21 Jun 2002 17:37:38 - 1.18
-28,9 +28,9
apr_pool_t *pool;
} PerlIOAPR;
-static IV PerlIOAPR_pushed(pTHX_ PerlIO *f, const char *mode, SV *arg)
+static IV PerlIOAPR_pushed(pTHX_ PerlIO *f, const char *mode, SV *arg, PerlIO_funcs
*tab)
{
-IV code = PerlIOBase_pushed(aTHX_ f, mode, arg);
+IV code = PerlIOBase_pushed(aTHX_ f, mode, arg, tab);
if (*PerlIONext(f)) {
/* XXX: not sure if we can do anything here, but see
* PerlIOUnix_pushed for things that it does
-366,6 +366,7
}
static PerlIO_funcs PerlIO_APR = {
+sizeof(PerlIO_funcs),
APR,
sizeof(PerlIOAPR),
PERLIO_K_MULTIARG,
cvs commit: modperl-2.0/xs/APR/PerlIO apr_perlio.c
stas2002/06/21 10:40:18
Modified:xs/APR/PerlIO apr_perlio.c
Log:
wrap the long args line
Revision ChangesPath
1.19 +2 -1 modperl-2.0/xs/APR/PerlIO/apr_perlio.c
Index: apr_perlio.c
===
RCS file: /home/cvs/modperl-2.0/xs/APR/PerlIO/apr_perlio.c,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- apr_perlio.c 21 Jun 2002 17:37:38 - 1.18
+++ apr_perlio.c 21 Jun 2002 17:40:18 - 1.19
-28,7 +28,8
apr_pool_t *pool;
} PerlIOAPR;
-static IV PerlIOAPR_pushed(pTHX_ PerlIO *f, const char *mode, SV *arg, PerlIO_funcs
*tab)
+static IV PerlIOAPR_pushed(pTHX_ PerlIO *f, const char *mode,
+ SV *arg, PerlIO_funcs *tab)
{
IV code = PerlIOBase_pushed(aTHX_ f, mode, arg, tab);
if (*PerlIONext(f)) {
cvs commit: modperl-2.0/src/modules/perl modperl_log.c modperl_log.h
dougm 2002/06/21 13:30:27
Modified:src/modules/perl modperl_log.c modperl_log.h
Log:
modperl_trace needs to use const for the function name (gcc3.1 warns)
Revision ChangesPath
1.7 +1 -1 modperl-2.0/src/modules/perl/modperl_log.c
Index: modperl_log.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_log.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- modperl_log.c 12 May 2002 23:01:32 - 1.6
+++ modperl_log.c 21 Jun 2002 20:30:27 - 1.7
-19,7 +19,7
return debug_level;
}
-void modperl_trace(char *func, const char *fmt, ...)
+void modperl_trace(const char *func, const char *fmt, ...)
{
char vstr[8192];
apr_size_t vstr_len = 0;
1.9 +1 -1 modperl-2.0/src/modules/perl/modperl_log.h
Index: modperl_log.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_log.h,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- modperl_log.h 12 May 2002 23:01:32 - 1.8
+++ modperl_log.h 21 Jun 2002 20:30:27 - 1.9
-34,7 +34,7
extern unsigned long MP_debug_level;
#endif
-void modperl_trace(char *func, const char *fmt, ...);
+void modperl_trace(const char *func, const char *fmt, ...);
void modperl_trace_level_set(server_rec *s, const char *level);
cvs commit: modperl-2.0/lib mod_perl.pm
dougm 2002/06/21 15:35:49
Modified:.Changes
lib mod_perl.pm
Log:
bump version
Revision ChangesPath
1.29 +2 -0 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- Changes 21 Jun 2002 22:25:48 - 1.28
+++ Changes 21 Jun 2002 22:35:49 - 1.29
-8,6 +8,8
=over 3
+=item 1.99_05-dev
+
=item 1.99_04 - June 21, 2002
various APR PerlIO updates [Stas Bekman]
1.5 +1 -1 modperl-2.0/lib/mod_perl.pm
Index: mod_perl.pm
===
RCS file: /home/cvs/modperl-2.0/lib/mod_perl.pm,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- mod_perl.pm 16 Jun 2002 00:02:58 - 1.4
+++ mod_perl.pm 21 Jun 2002 22:35:49 - 1.5
-4,7 +4,7
use strict;
BEGIN {
-our $VERSION = 1.9904;
+our $VERSION = 1.9905;
}
1;
