RE: WindowsNT Explorer like look and feel??
Does anyone know of an easy way to get a WindowsNT explorer (expanding directory/folder) lokk and feel using modperl? I know this is off topic, but have a look at http://www.alchemy-computing.co.uk/joust/ which is a (free) javascript implementation that gives you more or less what you want (including expanding directory/folder). I have used it and used perl (HTML::Mason) to dynamically generate the structure, but of course you can use a modperl handler for that in order to make this message more on topic. Kees
Re: Implementing security in CGI
Hi, My question is much more basic than that. I wanted to validate my design ideas on a programmatic security. I would like somebody to go through the following and tell me that I'm on the right track. The idea I had was, at the time of login, I generate the session id which I write to the cookie. I have also tied to this session_id the user's login profile. Every other screen checks for the cookie's existence and reads back the session_id and gets the user's profile. I hope I'm right till then. When the user signs out then we can delete the tied file. Now any person who has access to the same browser will still have to login to get to the inner pages. If the browser is killed without sign-out from the system, even then there's no problem. Next person who gets access to the browser and tries to access any inner page will not be able to, because the cookie with the session-id does not exist. Am I right ??? Please help. Thanks, Murali -Original Message- From: Gunther Birznieks [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: 19 April 2000 18:44 Subject: Re: Implementing security in CGI Apache::Session could be useful. But the session key that is generated is arguable not necessarily the most secure that it could be. But it is pretty good. I'm probably opening up a can of worms by saying this. The MD5 hash itself is relatively secure as hashes go (although SHA hash space could be better). But you are relying on underlying system variables to determine what is put into MD5 hashing in the first place -- and this data is not necessarily the most random-- process ID, time, memory address of the created hash, etc... Are a bit deterministic. rand() might be good if it is on a system that plugs natively into a good entropy generator on that machine. To get a better key, you probably end up spending more time pulling relatively random data sources together so key generation itself would be slow-- a computational tradeoff. Depends on how "secure" you really want to be. For most situations, Apache::Session's key generator will work fine. It also depends how long you intend the sessions to be active. Will they become a "token" that is used in lieu of authentication once the user has entered a username and password or issued a digital client certificate to your web site? Or will it be used after the user registers for a month+ to allow them to get back into your site without remember a password. -- Gunther At 01:34 PM 4/19/00 +0530, Differentiated Software Solutions Pvt. Ltd. wrote: Hi, We are having a site which is programmed with perl/CGI. To enter the site we have a login and password. After which some reports are displayed. I know that using cookies it is possible to secure the site. Can somebody guide me on how to design and implement a cookie based security. Sites and books on same will be greatly appreciated. Would Apache::Session be useful for this ?? Thanks for the help, Murali Differentiated Software Solutions Pvt. Ltd., 176, Gr. Floor, 6th Main 2nd Block RT Nagar Bangalore - 560 032 India Ph: 91 80 3431470 email : diffs+AEA-vsnl.com http://www.diffs-india.com Differentiated Software Solutions Pvt. Ltd., 176, Gr. Floor, 6th Main 2nd Block RT Nagar Bangalore - 560 032 India Ph: 91 80 3431470 email : diffs+AEA-vsnl.com http://www.diffs-india.com __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: mod_perl/apache and db/content server
On Tue, 18 Apr 2000, Angel R. Rivera wrote: hanks a lot that does help. We will not be using apache/mod_perl or DBI on the DS20. It will only be a content server (containing the actual HTML pages) and database server (PostgreSQL and Oracle) everything else will handled by unix and linux boxes running apache/mod_perl/mod- a-bunch-of stuff as the frontend. Can Apache::DBI still control the db reconnection issue? Apache::DBI works only with mod_perl server. At 11:46 AM 4/18/00 -0500, Rafael Caceres wrote: We have an Digital 4100 Alpha box currently running Apache 1.3.3 with mod_perl 1.21 and MS Frontpage extensions. The main use for mod_perl is script that manage a bug tracking application that connects, using DBD:DBI to an Oracle database. The performance advantage is evident, as re-connection to the database is not necessary. I would do it again without any second thoughts. Angel R. Rivera, [EMAIL PROTECTED] -- Website: http://www.wolf.com Lists: http://www.wolf.com/lists/ Our Life: http://www.wolf.com/Ookami.jpg -- "The Quality of a person's life is in direct proportion to their commitment to excellence, regardless of their chosen field of endeavor." Vincent T. Lombardi __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
Re: Implementing security in CGI
Murali, Yes I have a site that uses the exact mechanism that you state. As Jeff said though, you should have an "auto-logout" feature. I implemented this as a cron job that runs every 30 minutes and checks each session for the last time it has been accessed. I'm sure there are other ways to auto-logout - I thought doing it outside of mod_perl is a good idea just to take some load off of it. -Adi Jeff Beard wrote: This is a question for comp.infosystems.www.authoring.cgi. But since I'm here... I would check for the cookie every time a request is made. If you use Apache::Session there will be a separate session data store from the user data. Which is probably what you really want. Apache::Session will allow you to associate whatever data you like with the session id within it's own schema. If the browser is closed, the cookie will remain. You can have a logout feature but there will always be a significant percentage of users that won't bother. So limit the life of the cookie with the time value and periodically cull stale sessions on the server. --Jeff At 05:21 PM 4/19/00, Differentiated Software Solutions Pvt. Ltd. wrote: Hi, My question is much more basic than that. I wanted to validate my design ideas on a programmatic security. I would like somebody to go through the following and tell me that I'm on the right track. The idea I had was, at the time of login, I generate the session id which I write to the cookie. I have also tied to this session_id the user's login profile. Every other screen checks for the cookie's existence and reads back the session_id and gets the user's profile. I hope I'm right till then. When the user signs out then we can delete the tied file. Now any person who has access to the same browser will still have to login to get to the inner pages. If the browser is killed without sign-out from the system, even then there's no problem. Next person who gets access to the browser and tries to access any inner page will not be able to, because the cookie with the session-id does not exist. Am I right ??? Please help. Thanks, Murali
[ANNOUNCE] Apache::XPath::NotXSLT
I've written a little XML temlate processing system that uses XPath to locate nodes. This makes it a bit like XSLT, but not totally. It's pretty quick, using caching to achieve 50rps on my humble PIII550 (apache stock untuned install). http://xml.sergeant.org/notxslt.xml (not on CPAN - and I don't think I intend to upload it there either). -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: [OT] mysql-modules for Win32 platform
Randy, Thanks. I tried doing an install of this remote file but kept getting a SOAP/parser.pm error. I then downloaded this ppd file to my local hard drive and tried to install but it failed again. I set verbose=yes and tried again and got the following error: mismatched tag at line 12, column 2, byte 301 at D:/Perl5/site/lib/XML/Parser.pm line 168 Ideas? Randy Kobes wrote: On Mon, 17 Apr 2000, Erich Markert wrote: I've been trying to get the msql-mysql-modules compiled and installed on my Win98 machine for a couple weeks without much luck. [snip] My questions are: 1. Is there a binary version of *just* DBI,Msql-Mysql-modules for Win32? 2. If not, is there a PPM of the above for Activestate's perl 5.6 for Win32 (I did a search for DBD::mysql but it failed)? Hi, A DBI ppm package for ActiveState's 5.6.0 build is available at http://www.activestate.com/ppmpackages/5.6/. For DBD-mysql, Jochen Wiedmann has a 5.6.0 ppm package which you can install via ppm install ftp://ftp.de.uu.net/pub/CPAN/authors/id/JWIED/DBD-mysql-1.2212.x86.ppd best regards, randy kobes -- __ Mr. Erich L. Markert [EMAIL PROTECTED] Computer Learning Center TEL (914)422-4328 Pace University 1 Martine Ave White Plains, New York 10606-1932 Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer
Re: perl in configs /perl
On Wed, 19 Apr 2000, w trillich wrote: having seen the possibilities from /usr/share/doc/libapache-mod-perl/examples/perl_sections.txt (schwartz's neat virtual host setup) i thought i'd give it a whirl. I don't have this. Can someone point me to a link, or maybe send it via email to either [EMAIL PROTECTED] or [EMAIL PROTECTED]? J. J. Horner
Re: perl in configs /perl
On Wed, 19 Apr 2000, J. J. Horner wrote:
On Wed, 19 Apr 2000, w trillich wrote:
having seen the possibilities from
/usr/share/doc/libapache-mod-perl/examples/perl_sections.txt
(schwartz's neat virtual host setup) i thought i'd give it
a whirl.
I don't have this. Can someone point me to a link, or maybe send it via
email to either [EMAIL PROTECTED] or [EMAIL PROTECTED]?
mod_perl-x.xx/eg/perl_sections.txt
and this was written by Rob Hartill and not Randal, unless we are talking
about different files.
As for the original question from w trillich [EMAIL PROTECTED], here is
a rewritten not yet released section about Perl section that might solve
your problem. The most relevant to the question sections are 'Caveats',
'Verifying' and 'Debugging':
=head1 Apache Configuration in Perl
With CPerl...C/Perl sections, it is possible to configure your
server entirely in Perl.
=head2 Usage
CPerl sections can contain Iany and as much Perl code as you
wish. These sections are compiled into a special package whose symbol
table mod_perl can then walk and grind the names and values of Perl
variables/structures through the Apache core configuration gears.
Most of the configuration directives can be represented as scalars
(C$scalar) or lists (C@list). A C@List inside these sections is
simply converted into a space delimited string for you. Here is an
example:
httpd.conf
Perl
@PerlModule = qw(Mail::Send Devel::Peek);
#run the server as whoever starts it
$User = getpwuid($) || $;
$Group = getgrgid($)) || $);
$ServerAdmin = $User;
/Perl
Block sections such as CLocation..C/Location are represented
in a C%Location hash, e.g.:
Perl
$Location{"/~dougm/"} = {
AuthUserFile = '/tmp/htpasswd',
AuthType = 'Basic',
AuthName = 'test',
DirectoryIndex = [qw(index.html index.htm)],
Limit = {
METHODS = 'GET POST',
require = 'user dougm',
},
};
/Perl
If an Apache directive can take two or three arguments you may push
strings (the lowest number of arguments will be shifted off the
C@List) or use an array reference to handle any number greater than
the minimum for that directive:
push @Redirect, "/foo", "http://www.foo.com/";
push @Redirect, "/imdb", "http://www.imdb.com/";
push @Redirect, [qw(temp "/here" "http://www.there.com")];
Other section counterparts include C%VirtualHost, C%Directory and
C%Files.
To pass all environment variables to the children with a single
configuration directive, rather than listing each one via CPassEnv
or CPerlPassEnv, a CPerl section could read in a file and:
push @PerlPassEnv, [$key = $val];
or
Apache-httpd_conf("PerlPassEnv $key $val");
These are somewhat simple examples, but they should give you the basic
idea. You can mix in any Perl code you desire. See Ieg/httpd.conf.pl
and Ieg/perl_sections.txt in the mod_perl distribution for more
examples.
Assume that you have a cluster of machines with similar configurations
and only small distinctions between them: ideally you would want to
maintain a single configuration file, but because the configurations
aren't Iexactly the same (e.g. the CServerName directive) it's not
quite that simple.
CPerl sections come to rescue. Now you have a single configuration
file and the full power of Perl to tweak the local configuration. For
example to solve the problem of the CServerName directive you might
have this CPerl section:
Perl
$ServerName = `hostname`;
/Perl
For example if you want to allow personal directories on all machines
except the ones whose names start with Isecure:
Perl
$ServerName = `hostname`;
if ( $ServerName !~ /^secure/) {
$UserDir = "public.html";
} else {
$UserDir = "DISABLED";
}
/Perl
Behind the scenes, mod_perl defines a package called
CApache::ReadConfig. Here it keeps all the variables that you
define inside the CPerl sections. Therefore it's not necessarily
to configure the server within the CPerl sections. Actually what
you can do is to write the Perl code to configure the server just like
you'd do in the CPerl sections, but instead place it into a
separate file that should be called during the configuration parsing
with either CPerlModule or CPerlRequire directives, or from within
the startup file. All you have to do is to declare the package
CApache::ReadConfig within this file. Using the last example:
apache_config.pl
package Apache::ReadConfig;
$ServerName = `hostname`;
if ( $ServerName !~ /^secure/) {
$UserDir = "public.html";
} else {
$UserDir = "DISABLED";
}
1;
httpd.conf
--
PerlRequire /home/httpd/perl/lib/apache_config.pl
=head2 Enabling
To enable CPerl sections you should build mod_perl with Sperl
Makefile.PL PERL_SECTIONS=1 [ ... ].
=head2 Caveats
Be careful when you declare package names inside CPerl sections,
for example this code has a problem:
Perl
package My::Trans;
use
mod_perl DSO coexisting with mod_php DSO ?
Has anyone been able to get this arrangement to work ? I have built my setup using apache 1.3.12 mod_perl-1.21 php-3.0.16 under redhat linux 5.2. Everything has been compiled from source, no rpms involved at all. Now when I startup the httpd with both modules (php and perl) Load and Add Module'd in httpd.conf the parent starts but seems to hang; no children are spawned and nothing is logged under error_log either. If I comment out the Load/Add Module for mod-perl it starts up file: [Wed Apr 19 13:48:34 2000] [notice] Apache/1.3.12 (Unix) PHP/3.0.16 configured -- resuming normal operations Should i loose my hair over this or call it a day... any suggestions welcome. J.
[ANNOUNCE] Apache-RequestNotes_0.03
The URL http://morpheus.laserlink.net/~gyoung/modules/Apache-RequestNotes_0.03.tar.g z has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-RequestNotes_0.03.tar.gz size: 3662 bytes md5: abdd6047af7a4bdcb10e042adbdc9714 Changes: 0.03 4.19.2000 - only add COOKIES pnotes if there are cookies to add - changed parsing error log message to error from warn - minor pod changes
[ANNOUNCE] Apache-DebugInfo_0.04
The URL http://morpheus.laserlink.net/~gyoung/modules/Apache-DebugInfo_0.04.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-DebugInfo_0.04.tar.gz size: 6380 bytes md5: d0de31070ef2b954f7632a57b384acf4 Changes: 0.04 4.19.2000 - fixed bug in constructor that didn't set the output file to match DebugFile variable - minor documentation and pod changes and additions
Re: perl in configs /perl
i've seen the manpages for mod_perl -- your rendition has a bit more flesh to it, but my comprehension still suffers the same problem schwartz complained about (also in the same file as the example i quoted, namely /usr/share/doc/libapache-mod-perl/examples/perl_sections_2.txt.gz from debian distribution 2.1/2.2) Well, I've posted the rewrited section and stressed to read the Caveats section for a reason. If you reread it or the file that you've just forwarded you will see that you miss: package Apache::ReadConfig; in your file. And the same text I've forwarded explains how to debug the section when in problem. Hope this helps BTW, please don't refer to a file with a full path on your system just because it was installed there. It confuses people. The second file is at the mod_perl dist at mod_perl-x.xx/eg/perl_sections_2.txt . Enjoy! __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
RE: Modperl/Apache deficiencies... Memory usage.
From: "Jeff Stuart" [EMAIL PROTECTED] To: "Gunther Birznieks" [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Modperl/Apache deficiencies... Memory usage. Date: Tue, 18 Apr 2000 02:07:24 -0400 I understand that. :) And that was something that I had to learn myself. :) It's a BAD thing when suddenly your httpd process takes up 100 MB. :) It's just that it sounded like Shane was saying that his httpds were starting OUT at 4 to 6 MB. That sounded a little unusual to me but then again, I've pared down my httpd config so that I don't have things in that I don't need. I'm just curious as to what he has in there. Why not post here the .conf files and then compare them ? -- Jeff Stuart [EMAIL PROTECTED] -Original Message- From: Gunther Birznieks [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 18, 2000 1:24 AM To: [EMAIL PROTECTED] Subject: RE: Modperl/Apache deficiencies... Memory usage. If you aren't careful with your programming, an apache HTTPD can always grow pretty quickly because Perl never releases the RAM it allocates previously. While it does that reference count garbage collection, that is internal to the RAM that was allocated. Let's say you need to sort a record set returned from a DBI call in an unusual perl-like way. If you do this "in memory", you need an array to hold the entire recordset in memory at once. If you do this, though, you will allocate the RAM for that one request that sorted the array and then the HTTPD will remain that size forever. Keeping the higher RAM allocation is good for performance if you have the RAM of course. So this is one of those design tradeoffs. And Perl was not really written to be a persistent language, so again, the tradeoff of operational speed seems to make sense versus persistent memory usage. Later, Gunther At 12:25 AM 4/18/00 -0400, Jeff Stuart wrote: Shane, question for you. No offense intended here at all but what do you have in your apache servers (other than mod_perl) that use 4 to 6 MB? I've got one server that I'm working on that handles close 1 Mil hits per day than runs WITH mod_perl that uses 4 to 6 MB. ;-) Without mod_perl, it takes up around 500 to 800 KB. Now on another server my mod_perl server uses about 13 Mb per but it's my devel machine so I've got a lot of stuff loaded that I wouldn't have in a production server. -- Jeff Stuart [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 15, 2000 6:46 PM To: Perrin Harkins Cc: [EMAIL PROTECTED] Subject: Re: Modperl/Apache deficiencies... Memory usage. Your apache processes would be the size of a stock apache process, like 4-6M or so, and you would have 1 process that would be 25MB or so that would have all your registry in it. __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/ __ Get Your Private, Free Email at http://www.hotmail.com
JOB: Terrific Perl mod_perl Developer Opportunities
Become part of an exciting new start-up venture called HealthCite. The company is looking for innovative Applications Developers to design, develop, test, deploy, maintain, and document new, innovative Web capabilities. Would work in Baltimore office. Desired qualifications include a work history of applications development, preferably with a variety of software languages, but strengths in Perl and mod_perl in a variety of environments. Applications development involving Web-based database systems is especially applicable. The Applications Developer will work as key members of teams over dedicated periods of time. The developer may work on multiple projects at once. Projects are unique in nature, and Applications Developers will participate in the creation of new Web technologies for the delivery of information. Please contact me for additional information or to apply. Ray Everngam Tel: 443-803-5096 [EMAIL PROTECTED] __ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com
RE: Proxy hijackers?
(Off topic again, but lots of people here are using reverse proxy). For a while I had 'ProxyRequests On' in my httpd.conf mistakenly thinking that it was necessary to make ProxyPass and mod_rewrite proxying work. Then I noticed entries in my logfile where remote sites were sending full http://requests to other remote sites. I've turned off the function, but the requests keep coming in, mostly appearing to request ads from somewhere with referring pages in Russia and China. Is this a common practice and what are they trying to accomplish by bouncing them through my server? Yes it is very common practice, and so is scanning for open proxies on ports 80, 8080 and 1080. Here's a link to a list of open proxies and a faq that explains their use. http://www.cyberarmy.com/lists/proxy/ -- Eric
RE: Proxy hijackers?
On Wed, 19 Apr 2000, Eric Cholet wrote: (Off topic again, but lots of people here are using reverse proxy). For a while I had 'ProxyRequests On' in my httpd.conf mistakenly thinking that it was necessary to make ProxyPass and mod_rewrite proxying work. Then I noticed entries in my logfile where remote sites were sending full http://requests to other remote sites. I've turned off the function, but the requests keep coming in, mostly appearing to request ads from somewhere with referring pages in Russia and China. Is this a common practice and what are they trying to accomplish by bouncing them through my server? Yes it is very common practice, and so is scanning for open proxies on ports 80, 8080 and 1080. Here's a link to a list of open proxies and a faq that explains their use. http://www.cyberarmy.com/lists/proxy/ That leaves out the biggest reason why most of these type (ie. repeated ad requests from the same small set of IPs) of requests are attempted: fraud. There are lots of lusers out there trying to defraud banner exchanges and various types of paid affiliate programs. The reason they use proxies is to make it appear that the hits are coming from a wide variety of different IPs so the company they are defrauding doesn't get as suspicious as easily. The annoying thing is that many of the servers they use are not and never were proxies, but they are just too dumb to tell the difference.
Re: perl in configs /perl KAPUT
In a running httpd you can see how you have configured the CPerl sections through the URI L/perl-status|debug/Apache_Status_Embedded_Inter, by choosing IPerl Section Configuration from the menu. In order to make this item show up in the menu you should set C$Apache::Server::SaveConfig to a true value. When you do that the IApache::ReadConfig namespace (in which the configuration data is stored) will not be flushed, making configuration data available to Perl modules at request time. i must be thick today. not only can i get no effect from perldo "file.pl"/perl but http://localhost/perl-status|debug/Apache_Status_Embedded_Inter gives me 404 not found. /perl-stat by itself works fine; from there i can tell the PerlRequire (actually perldo "file"/perl) has been run. i just want a couple simple virtual hosts on one ip number. the perl code (under "package Apache::ReadConfig;" of course) does run (i can tell by having it display the same string it sends to Apache-httpd_conf()) but doesn't change any apache settings. if this helps, here's the display from http://localhost/perl-status?ApacheReadConfig . . . hashes ApacheReadConfig::Directory, ApacheReadConfig::DirectoryMatch, ApacheReadConfig::Files, ApacheReadConfig::FilesMatch, ApacheReadConfig::Limit, ApacheReadConfig::Location, ApacheReadConfig::LocationMatch, ApacheReadConfig::VirtualHost ios ApacheReadConfig::TTY any clues?
Perl Section...
Anyone know what this error would mean: DBI handle cleared whilst still active at /usr/lib/perl5/site_perl/5.005/i386-linux/DBI.pm line 195. dbih_clearcom (h 0x83b1900, com 0x81b6d50): FLAGS 0x211: COMSET Warn AutoCommit TYPE 1 PARENT undef KIDS 0 (0 active) IMP_DATA undef in 'DBD::mysql::dr' This error comes up in my apache error log. I have a Perl section in my httpd.conf that sets up all my virtual hosts. Apache starts up fine, but the virtual hosts are not set up and I get that error in the error log. I am using Apache 1.3.12 compiled from source. I have the same setup on another machine with Apache 1.3.9 (RPM) and it works fine. DBI is version 1.13. Thanks, Bryan Opfer
RE: Perl Section...
-Original Message- From: Bryan J. Opfer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 19, 2000 3:27 PM To: Modperl List Subject: Perl Section... Anyone know what this error would mean: DBI handle cleared whilst still active at /usr/lib/perl5/site_perl/5.005/i386-linux/DBI.pm line 195. dbih_clearcom (h 0x83b1900, com 0x81b6d50): FLAGS 0x211: COMSET Warn AutoCommit TYPE 1 PARENT undef KIDS 0 (0 active) IMP_DATA undef in 'DBD::mysql::dr' this is a problem with your DBI script - it basically means that you still have a cursor open when you disconnected... try calling $sth-finish before $dbh-disconnect - it should go away. at any rate, it's just a warning... --Geoff This error comes up in my apache error log. I have a Perl section in my httpd.conf that sets up all my virtual hosts. Apache starts up fine, but the virtual hosts are not set up and I get that error in the error log. I am using Apache 1.3.12 compiled from source. I have the same setup on another machine with Apache 1.3.9 (RPM) and it works fine. DBI is version 1.13. Thanks, Bryan Opfer
SUMMARY Re: mod_perl/apache and db/content server
Would like to thank everyone who has answered publicly and privately. Special thanks to Stas Bekman for 'splaining it so I would understand. Apache::DBI uses DBI, it doesn't matter where the db is located as long as you can connect to it thru DBI. If I understand your decription correctly, you shouldn't have any problem. But it has nothing to do with mod_perl, other than my original reply. Angel R. Rivera, [EMAIL PROTECTED] -- Website: http://www.wolf.com Lists: http://www.wolf.com/lists/ Our Life: http://www.wolf.com/Ookami.jpg -- "The Quality of a person's life is in direct proportion to their commitment to excellence, regardless of their chosen field of endeavor." Vincent T. Lombardi
Re: perl in configs /perl
Stas Bekman wrote: I still don't know your name, so I'll just use 'you' :) or trillich (or even 'will' on my birthday). First, please keep the replies posted to the list. We don't want to answer something more than once, when it goes to the list, someone will answer you and it'll be stored in the archive for other people use. So please repost your reply to the list. whoops. 'reply' button is smarter than i am, at times. BTW, please don't refer to a file with a full path on your system just because it was installed there. It confuses people. The second file is at the mod_perl dist at mod_perl-x.xx/eg/perl_sections_2.txt . you've obviously not been sitting over my shoulder lately! i have spent days looking for examples referenced like that. some are under /usr/src which i don't have installed; others are under perl library module directories, others are in /usr/doc. talk about confusion! (in addition, /eg/ seems to be a low-keystroke way to refer to the actual directory, which is actually /examples/. very confusing.) plus, if i sought mod_perl i might not run into apache_mod_perl... so i figure it's easier for someone to decode a full pathname than to imagine and hope and conjure out of thin air which path to append... It's incorrect! The files are located in the *mod_perl distribution*, and they are located just where I've said and not where your binary distribution has happen to include them. You have been looking in all wrong places, you could ask the list first and even better to search the mailing list archives. i try to do some background work before dumping my troubles on other unsuspecting folk. but lemme tellya, looking for the precise configuration file for the precise command is a lot more taxing than just opening a control panel and clicking some checkboxes and menus... so how does one find out what the distribution pathname is when all one has to go by is the installed set of files? (lemme rephrase--the installed fileset is all i know of, to go by.) and still apache ignores my perl 'Apache-httpd_conf($c);'...
Re: perl in configs /perl
It's incorrect! The files are located in the *mod_perl distribution*, and they are located just where I've said and not where your binary distribution has happen to include them. You have been looking in all wrong places, you could ask the list first and even better to search the mailing list archives. i try to do some background work before dumping my troubles on other unsuspecting folk. but lemme tellya, looking for the precise configuration file for the precise command is a lot more taxing than just opening a control panel and clicking some checkboxes and menus... so how does one find out what the distribution pathname is when all one has to go by is the installed set of files? (lemme rephrase--the installed fileset is all i know of, to go by.) It's easy to find, try to look under: http://perl.apache.org/dist or even if this is not obvious (of course you have to go to http://perl.apache.org and click on the link) http://cpan.org is the right place to look for any Perl modules distributions. __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
Re: [RFC] Do Not Run Everything on One mod_perl Server
On Tue, 18 Apr 2000, Stas Bekman wrote: Let's assume that you have two different sets of scripts/code which have a little or nothing in common at all (different modules, no base code sharing), the basic mod_perl process before the code have been loaded of three Mbytes and each code base adds ten Mbytes when loaded. Which makes each process 23Mb in size when all the code gets loaded. Can't you share most of that 23mb between the processes by pre-loading the scripts/modules in your startup.pl? I'd say the main advantage of engineering dissimilar services as if they were on separate servers is scalability rather than memory use. When a site outgrows the hardware it's on, spreading it out to multiple machines requires a lot less ankle grabbing if it was designed that way to begin with. :) - Matt
apache 2.0 port?
Hey everybody, I was just wondering if there is anyone working on porting mod_perl to apache 2.0. I couldn't seem to find any mention of this on the web page or list archives. If noone else is working on this I'm willing to take a crack at it. Brian PGP signature
Re: Perl Section...
I have $sth-finish in there right before the disconnect and it sill
gives me the message. If it is just a warning message then there must
be something else wrong. Is there something else that would cause it
not to work. I gave mod_perl the "PERL_SECTIONS=1" option when I
compiled it.
Here is a small snippit of how my script works to set up the virtuals:
use DBI;
my $db = ;
my $user = ;
my $password = ;
my $baseDir = ;
my $dbh = DBI-connect($db, $user, $password) || die $DBI::errstr;
my $sth = $dbh-prepare("SELECT domain FROM domain") || die
$dbh-errstr;
$sth-execute() || die $sth-errstr;
my($domain);
while($domain = $sth-fetchrow_array)
{
$PerlConfig .= "CONFIG";
VirtualHost $ipAddr
ServerName www.$domain
ServerAdmin webmaster@$domain
ServerAlias $domain
DocumentRoot $baseDir/www.$domain/htdocs/
/VirtualHost
CONFIG
}
$sth-finish;
$dbh-disconnect;
Again, it works fine on another machine with the apache rpm.
Thanks,
Bryan Opfer
Geoffrey Young wrote:
-Original Message-
From: Bryan J. Opfer [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 19, 2000 3:27 PM
To: Modperl List
Subject: Perl Section...
Anyone know what this error would mean:
DBI handle cleared whilst still active at
/usr/lib/perl5/site_perl/5.005/i386-linux/DBI.pm line 195.
dbih_clearcom (h 0x83b1900, com 0x81b6d50):
FLAGS 0x211: COMSET Warn AutoCommit
TYPE 1
PARENT undef
KIDS 0 (0 active)
IMP_DATA undef in 'DBD::mysql::dr'
this is a problem with your DBI script - it basically means that you still
have a cursor open when you disconnected...
try calling $sth-finish before $dbh-disconnect - it should go away.
at any rate, it's just a warning...
--Geoff
This error comes up in my apache error log. I have a Perl
section in my
httpd.conf that sets up all my virtual hosts.
Apache starts up fine, but the virtual hosts are not set up and I get
that error in the error log. I am using Apache 1.3.12 compiled from
source.
I have the same setup on another machine with Apache 1.3.9
(RPM) and it
works fine.
DBI is version 1.13.
Thanks,
Bryan Opfer
Re: [RFC] Do Not Run Everything on One mod_perl Server
On Wed, 19 Apr 2000, Joshua Chamas wrote: Stas Bekman wrote: Geez, I always forget something :( You are right. I forgot to mention that this was a scenario for the 23 Mb of unshared memory. I just wanted to give an example. Still somehow I'm almost sure that there are servers where even with sharing in place, the hypothetical scenario I've presented is quite possible. Anyway, it's just another patent for squeezing some more juice from your hardware without upgrading it. Your scenario would be more believable with 5M unshared, even after doing ones best to share everything. This is pretty typical when connecting to databases, as the database connections cannot be shared, and especially DB's like Oracle take lots of RAM per connection. Good idea. 5MB sounds closer to the real case than 10Mb. I'll make the correction. Thanks!!! I'm not sure that your scenario is worthwhile if someone does a good job preloading / sharing code across the forks, and the difference will really be how much of the code gets dirty while you run things, which can be neatly tuned with MaxRequests. Agree. But not everybody knows to do that well. So the presented idea might still find a good use at some web shops. Interesting novel approach though. I would bet that if people went down this path, they would really end up on different machines per web application, or even different web clusters per application ;) :) __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
Re: [RFC] Do Not Run Everything on One mod_perl Server
On Wed, 19 Apr 2000, Gerd Knops wrote: Stas Bekman wrote: On Wed, 19 Apr 2000, Matt Carothers wrote: On Tue, 18 Apr 2000, Stas Bekman wrote: Let's assume that you have two different sets of scripts/code which have a little or nothing in common at all (different modules, no base code sharing), the basic mod_perl process before the code have been loaded of three Mbytes and each code base adds ten Mbytes when loaded. Which makes each process 23Mb in size when all the code gets loaded. Can't you share most of that 23mb between the processes by pre-loading the scripts/modules in your startup.pl? I'd say the main advantage of engineering dissimilar services as if they were on separate servers is scalability rather than memory use. When a site outgrows the hardware it's on, spreading it out to multiple machines requires a lot less ankle grabbing if it was designed that way to begin with. :) Geez, I always forget something :( You are right. I forgot to mention that this was a scenario for the 23 Mb of unshared memory. I just wanted to give an example. Still somehow I'm almost sure that there are servers where even with sharing in place, the hypothetical scenario I've presented is quite possible. Anyway, it's just another patent for squeezing some more juice from your hardware without upgrading it. But, sure I'll add the correction about the sharing memory which drastically changes the story :) Actually in my experience the sharing of memory doesn't work as well as one would hope. While compiling perl allocates memory for code and data (variables) from the same memory pools, so code and variables are interlaced. Over the lifetime of a apache/mod_perl child a lot of memory pages are promoted from shared to unshared that contain mostly code and one or two variables... If someone with more knowledge of the perl internals were to change that, this would make a huge difference for mod_perl users and everybody else writing daemons in perl that spawn many children. The Perl is a language that uses weak data types, i.e. you don't specify variable size (type) like you do in the strong typed languages like C. Therefore Perl uses heap memory by allocating memory on demand, rather (unmodifiable) text and (modifiable) data memory pages, used by C. The latter get allocated when the program is loaded into memory before it starts to run, the former is allocated at the run-time. On heap there is no separation for data and text pages, when you call malloc it just allocates you a chunk you have asked for, this leads to the case where the code (static in most cases) and the variables (dynamic) land on the same memory pages. I'm not sure this a very good explanation. Perl gurus are very welcome to correct/improve my attempt to explain this. But the main point is that that's how Perl is written, and I don't know whether it can be changed. __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
Apache 2.0 port?
Hey everybody, I was just wondering if there is anyone working on porting mod_perl to apache 2.0. I couldn't seem to find any mention of this on the web page or list archives. If noone else is working on this I'm willing to take a crack at it. Brian PGP signature
Re: apache 2.0 port?
On Wed, 19 Apr 2000, Brian Martin wrote: Hey everybody, I was just wondering if there is anyone working on porting mod_perl to apache 2.0. I couldn't seem to find any mention of this on the web page or list archives. As Eric pointed out -- the work is in a full progress If noone else is working on this I'm willing to take a crack at it. But you are very welcome to jump in and help to make the progress even better, am I right Doug? The first step is to get subscribed to the CVS mailing list, to see those patches as they are added... The second is to start adding patches yourself :) P.S. You know that Apache wasn't called after native American Indians Apache tribe, but after a'patches that were made to the NCSA httpd. __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
Re: crypt() under windows
Hi- We used Martin Vorlaender's Crypt::UnixCrypt module for the same reason you need it - no crypt() on Windows. http://search.cpan.org/search?dist=Crypt-UnixCrypt However we discovered that it is not *exactly* the same as linux crypt(). That is, for some passwords that contained non-alphanumerics in the first 2 character positions, the hash produced by Crypt::UnixCrypt and linux's crypt() differed. If you just need something that works similarly to crypt on windows, this module works well. But don't use it if you need the hashes to be portable. -Tim On Wed, 19 Apr 2000, indrek siitan wrote: Hi, seems like the standard crypt() function is not implemented under Windows. :( does anyone have a perl source, that does the 3DES crypt() encryption? i only need it for a development version, so the speed doesn't matter. the production version will run under Linux and use the standard crypt() call. Rgds, Tfr --== [EMAIL PROTECTED] == http://tfr.cafe.ee/ == +1-504-4467425 ==--
Re: crypt() under windows
On Wed, 19 Apr 2000, indrek siitan wrote: Date: Wed, 19 Apr 2000 13:02:00 -0500 From: indrek siitan [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: crypt() under windows Hi, seems like the standard crypt() function is not implemented under Windows. :( does anyone have a perl source, that does the 3DES crypt() encryption? i only need it for a development version, so the speed doesn't matter. the production version will run under Linux and use the standard crypt() call. Why can't you just snarf it from the libc source? Ain't this free software stuff great? -- "The Funk, the whole Funk, and nothing but the Funk." Billy Donahue mailto:[EMAIL PROTECTED] http://billy.zone.xs2.net
Re: crypt() under windows
On Wed, 19 Apr 2000, Tim Bishop wrote: Hi- We used Martin Vorlaender's Crypt::UnixCrypt module for the same reason you need it - no crypt() on Windows. Nonesense. Read README.win32 before building your perl. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
crypt() under windows
Hi, seems like the standard crypt() function is not implemented under Windows. :( does anyone have a perl source, that does the 3DES crypt() encryption? i only need it for a development version, so the speed doesn't matter. the production version will run under Linux and use the standard crypt() call. Rgds, Tfr --== [EMAIL PROTECTED] == http://tfr.cafe.ee/ == +1-504-4467425 ==--
Re: [RFC] Do Not Run Everything on One mod_perl Server
My apache processes are typically 18MB-20MB in size, with all but 500K to 1MB of that shared. We restart our servers in the middle of the nite as part of planned maintenance, of course, but even before we did that, and even after weeks of uptime, the percentages did not change. We do not use Apache::Registry at all; everything is a pure handler. We cache all data structures (lots of storable things) in the parent process by thawing refs to the datastructures into package variables. We use no globals, only a few package variables (4) that we access by fully qualified package name, and they get reset on each request. We use Apache::DBI and MySQL, and it works perfectly other than a few segfaults that occur once in a while. Having all of the data structures cached (and shared !) allows us to do some neat things without having to rely solely on sql. On Thu, 20 Apr 2000, Stas Bekman wrote: On Wed, 19 Apr 2000, Joshua Chamas wrote: Stas Bekman wrote: Geez, I always forget something :( You are right. I forgot to mention that this was a scenario for the 23 Mb of unshared memory. I just wanted to give an example. Still somehow I'm almost sure that there are servers where even with sharing in place, the hypothetical scenario I've presented is quite possible. Anyway, it's just another patent for squeezing some more juice from your hardware without upgrading it. Your scenario would be more believable with 5M unshared, even after doing ones best to share everything. This is pretty typical when connecting to databases, as the database connections cannot be shared, and especially DB's like Oracle take lots of RAM per connection. Good idea. 5MB sounds closer to the real case than 10Mb. I'll make the correction. Thanks!!! I'm not sure that your scenario is worthwhile if someone does a good job preloading / sharing code across the forks, and the difference will really be how much of the code gets dirty while you run things, which can be neatly tuned with MaxRequests. Agree. But not everybody knows to do that well. So the presented idea might still find a good use at some web shops. Interesting novel approach though. I would bet that if people went down this path, they would really end up on different machines per web application, or even different web clusters per application ;) :) __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
Re: Problem with CGI::Carp under mod_perl
On Wed, 19 Apr 2000, Steve Hay wrote:
Sounds like a difference in the way CGI scripts and mod_perl buffer. I
fyou really want CGI::Carp to work, you need to make sure you don't send
any output before it gets called. Maybe you have PerlSendHeader on?
I did have PerlSendHeader On: turning it off causes a DOS Prompt to pop up
briefly, the die() message still goes to error.log and no output appears in
the browser at all!
I've never used mod_perl on Windows, so I don't know what causes the DOS
prompt. Keep PerlSendHeader On, but suppress your output until the script
has completed (i.e. collect it in a scalar and then print it all at once).
CGI::Carp can't help you if you've already sent a bunch of stuff to the
browser. You don't have this problem with mod_cgi because it buffers
everything until the script finishes.
CGI::Carp can't catch compile errors.
Oh. The CGI::Carp manpage says (regarding the use of "set_message()" to
control the output message): "In order to correctly intercept compile-time
errors, you should call set_message() from within a BEGIN{} block. ", which
suggests it does catch compile errors? I've tried both with "BEGIN
{set_message('...')}" and without a set_message() at all, but to no avail.
My mistake. CGI::Carp doesn't catch compile errors inside an eval block,
which is where you are when compiling under Apache::Registry. You could
work around this by commenting out the first line of the die() subroutine
where it checks to see if it's in an eval, but that's pretty lame and
makes CGI::Carp incompatible with use of eval blocks. I don't use
Apache::Registry or CGI::Carp, so I'm not very motivated to find a better
fix. You could contact the author.
- Perrin
Re: [RFC] Do Not Run Everything on One mod_perl Server
At 01:44 AM 4/20/00 +0300, Stas Bekman wrote: On Wed, 19 Apr 2000, Gerd Knops wrote: Stas Bekman wrote: On Wed, 19 Apr 2000, Matt Carothers wrote: On Tue, 18 Apr 2000, Stas Bekman wrote: Let's assume that you have two different sets of scripts/code which have a little or nothing in common at all (different modules, no base code sharing), the basic mod_perl process before the code have been loaded of three Mbytes and each code base adds ten Mbytes when loaded. Which makes each process 23Mb in size when all the code gets loaded. Can't you share most of that 23mb between the processes by pre-loading the scripts/modules in your startup.pl? I'd say the main advantage of engineering dissimilar services as if they were on separate servers is scalability rather than memory use. When a site outgrows the hardware it's on, spreading it out to multiple machines requires a lot less ankle grabbing if it was designed that way to begin with. :) Geez, I always forget something :( You are right. I forgot to mention that this was a scenario for the 23 Mb of unshared memory. I just wanted to give an example. Still somehow I'm almost sure that there are servers where even with sharing in place, the hypothetical scenario I've presented is quite possible. Anyway, it's just another patent for squeezing some more juice from your hardware without upgrading it. But, sure I'll add the correction about the sharing memory which drastically changes the story :) Actually in my experience the sharing of memory doesn't work as well as one would hope. While compiling perl allocates memory for code and data (variables) from the same memory pools, so code and variables are interlaced. Over the lifetime of a apache/mod_perl child a lot of memory pages are promoted from shared to unshared that contain mostly code and one or two variables... If someone with more knowledge of the perl internals were to change that, this would make a huge difference for mod_perl users and everybody else writing daemons in perl that spawn many children. The Perl is a language that uses weak data types, i.e. you don't specify variable size (type) like you do in the strong typed languages like C. Therefore Perl uses heap memory by allocating memory on demand, rather (unmodifiable) text and (modifiable) data memory pages, used by C. The latter get allocated when the program is loaded into memory before it starts to run, the former is allocated at the run-time. On heap there is no separation for data and text pages, when you call malloc it just allocates you a chunk you have asked for, this leads to the case where the code (static in most cases) and the variables (dynamic) land on the same memory pages. I'm not sure this a very good explanation. Perl gurus are very welcome to correct/improve my attempt to explain this. But the main point is that that's how Perl is written, and I don't know whether it can be changed. That's how I understand it to be. But I could be wrong as well. :) By the way, I think your section here is actually far-thinking. Although Matt and others have pointed out that this scenario may not be the biggest memory booster in the world in some cases, there is another consideration that I think should be mentioned. Reliability and Troubleshooting. Right now, I dare say that most of you probably either are doing custom mod_perl coding or are using an infrastructural tools such as EmbPerl, ASP etc... In these scenarios, it is relatively easy to troubleshoot your code because you either [a] wrote it all or [b] you are running code on top of a well-tested Apache::Mod_perl infrastructural application toolkit. This is, I suspect, because as far as real-world open source applications are concerned, mod_perl is a bit behind. Thousands of open source CGI scripts exist in Perl for plain CGI. Few (if any) are in a repository to work with mod_perl off the bat. However, I see this changing. Efforts such as mine, SmartWorker's etc... will eventually lead to a proliferation of another layer of infrastructural component which is above the Tool level (EmbPerl/Apache::Session/etc). In other words, a component level that is at the application level -- plug and play calendars, bbses, web shopping carts, etc. If people reach this point on mod_perl, you may find that some modules are not written as well as others and so subtle side effects may be introduced when you start throwing everyone's code together in one huge vat of mod_perl. If this happens, I suspect it will be a lot easier to troubleshoot problems that occur if you keep major application suites separate from each other. eg Don't run SmartWorker on the same server as EmbPerl or the same server as Extropia stuff etc... Because although it may work in the short-term... you may end up pulling your hair out if someone ends up changing something
Re: crypt() under windows
At 09:00 PM 4/19/00 +0100, Matt Sergeant wrote: On Wed, 19 Apr 2000, Tim Bishop wrote: Hi- We used Martin Vorlaender's Crypt::UnixCrypt module for the same reason you need it - no crypt() on Windows. Nonesense. Read README.win32 before building your perl. Curiously, the precompiled Win32 ModPerl that perl.apache.org references for people to download does not have crypt() compiled in. Yet ActiveState's binary distribution of build 522 does. Odd. Is there a reason that the source distributions default build would be different from ActiveState's default build? Admittedly I have never bothered compiling Perl on Win32 as I only use it to play with (not serious production for the obvious limitations of mod_perl on Win32). So I have not seen the reference to this readme you are referring to. __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: Perl Sections and Virtual Host
my $realname = 'http://www.main.org';
my %vnames = ( 'sec.ondary.com' = 'second', 'third.dom.com' = 'third' );
^^^
foreach (keys %vnames) {
^^^
$VirtualHost{'192.168.1.2:80'} = {
ServerName = $_,
RedirectPermanent = ( ['/', "$realname/$vname{$_}/index.phtml"] )
^^
Maybe this is just in your example, but you might have cut-and-pasted from
yor config, so I'll mention it: In your RedirectPermanent, you are referencing
%vname, not %vnames. Without strict turned on in your Perl section, Perl
won't tell you.
Yep, I caught this one a few minutes ago (but if I had read my mail earlier,
your message would have saved half of my day. Well, there are times like
that...).
I'm getting somewhat closer, I think it's now just a matter of understanding
more precisely 'what' should be used as the RedirectPermanent value. This
work just fine now :
Perl
my $realname = 'real.domain.com';
my %vnames = ( 'prim.ary.com' = 'first', 'sec.ondary.com' = 'second' );
$VirtualHost{'192.168.1.2:80'} = [ { ServerName = $realname } ];
foreach (keys %vnames) {
my $vhref = {
ServerName = $_,
RedirectPermanent = "/ http://$realname/$vnames{$_}/"
};
push @{$VirtualHost{'192.168.1.2:80'}}, $vhref;
}
/Perl
Whenever I ask for http://prim.ary.com, I get transparently redirected to
http://real.domain.com/first. Cute. Almost there.
But I have other URLs I want to remap. Say, prim.ary.com/europe should be
mapped to real.domain.com/europe. With the above setup, I am redirected to
real.domain.com/first/europe. So I need now to have _several_ RedirectPermanent
(or anything that could save my whole day -- well, night, it's 23 pm here).
I have tried a helluva lot of syntaxes, I'm ashamed to say, to no avail. The
right one just escapes me.
Any hints ?
Tia,
-- Pierre-Yves BONNETAIN
CTO -- http://www.rouge-blanc.com -- Fastest wines in Europe.
Re: [RFC] Do Not Run Everything on One mod_perl Server
On Wed, 19 Apr 2000, Matt Carothers wrote: On Tue, 18 Apr 2000, Stas Bekman wrote: Let's assume that you have two different sets of scripts/code which have a little or nothing in common at all (different modules, no base code sharing), the basic mod_perl process before the code have been loaded of three Mbytes and each code base adds ten Mbytes when loaded. Which makes each process 23Mb in size when all the code gets loaded. Can't you share most of that 23mb between the processes by pre-loading the scripts/modules in your startup.pl? I'd say the main advantage of engineering dissimilar services as if they were on separate servers is scalability rather than memory use. When a site outgrows the hardware it's on, spreading it out to multiple machines requires a lot less ankle grabbing if it was designed that way to begin with. :) Geez, I always forget something :( You are right. I forgot to mention that this was a scenario for the 23 Mb of unshared memory. I just wanted to give an example. Still somehow I'm almost sure that there are servers where even with sharing in place, the hypothetical scenario I've presented is quite possible. Anyway, it's just another patent for squeezing some more juice from your hardware without upgrading it. But, sure I'll add the correction about the sharing memory which drastically changes the story :) Thanks, Matt! __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
