Re: API Design Question
On Friday, June 29, 2001, at 07:25 , Shawn Devlin wrote: > What advantages do I gain by grouping the functions based on > functionality? As per my response to Mr. Worrall, one of my concerns > with placing each function call into its own module is the amount of > memory used by the various .pm files that will be loaded numerous > times. I can see that grouping functions based on functionality would > reduce the number of .pm files in memory. However, if I go that route, > then would I not be better just to leave the API as one file? A good reason for grouping "related" functions is not so much "functionality" as common dependencies, and ease of change management. If everything is in one huge module, then change management become tricky, especially with multiple developers. Giving every function its own module avoids this, but can make tracking down dependencies tricky (and there may be a small memory overhead for each module, but I've never looked). A happy medium is to group together functions that share a dependencies on underlying database objects. For example, if you have a family of library functions that retrieve, insert, update, or delete user records, it might make sense to group these together in a module. If you need to add a new field to your user records, then you change only that module (as well as any changes required to your scripts).
Re: Is ProxyPass the best you can do?
> Can Squid read Apache configuration files? On a new site I'm making > (www.shoujoai.com), I have directives in httpd.conf like this: Never used it, I'm afraid ... >> Alternatively, you could try using mod_rewrite, to direct requests for >> scripts to a different apache instance (e.g. running on a separate port >> or ip). I've never tried this, but it should work. > > You can use RewriteRule to make it proxy the request to another > Apache? I > thought you can only alias a URL to a file, or make it send an HTTP > redirect. How do you make it proxy? Ah. I was assuming that redirects would be ok (it would be in my environment) ...
Re: Is ProxyPass the best you can do?
Squid is the alternative mentioned in the mod_perl_tuning.pod that comes with mod_perl. Alternatively, you could try using mod_rewrite, to direct requests for scripts to a different apache instance (e.g. running on a separate port or ip). I've never tried this, but it should work. Squid might be more efficient. cheers, Martin On Sunday, June 17, 2001, at 03:43 am, Philip Mak wrote: > I've been thinking about the ProxyPass technique for coping with > mod_perl's high memory usage (setup a non-mod_perl httpd that handles > all > requests, but ProxyPasses the mod_perl calls to a mod_perl enabled > Apache). > > I find that the complexity of this method is more than it should have to > be. For one thing, ProxyPass only works on a directory. But if you have > images and scripts in the same directory, this is a problem (and it's > convenient to be able to have them in the same directory, so that your > scripts can instead of > especially when you have a lot of images in different directories). > > Is there a way to ProxyPass by file extension or something? > > -Philip Mak ([EMAIL PROTECTED]) > >
Re: ssl encryption
One solution is to set a perl variable in a conf file that is only
readable by root. The parent httpd process can read this, and the
children can inherit it, but its not visible in the code.
If your httpd children need to be able to read in the password, then
you'll need less restrictive permissions on the password file.
Of course you need to be able to trust your application developers not
to dump the variable out into the world.
A slightly better method is to abstract away from the connection method,
so that your application developers don't use the password directly, but
call a library routine that hands them a connection object, using the
password variable under the hood.
I've seen this used, and it worked quite well, although having the
password in plain text anywhere is a little disturbing.
A slightly better approach would be to keep a file of blowfish encrypted
keys to be read during startup, and to somehow pass the key to decrypt
the keys in manually during Apache startup, via a prompt. Stronghold
does this at startup, in order to get the passphrase for your
certificate. I'm not sure exactly how to do this from scratch, but I
believe there are modules that allow you to embed perl in conf files,
which might work, or you might be able to do it via startup.pl
On Friday, June 15, 2001, at 12:44 am, Kevin Schroeder wrote:
> This would make an interesting discussion because I've had the same
> question
> come up in my mind. How do you encrypt things on your server without
> giving
> out the passphrase? Is it even possible to keep the key in the same
> location as the program using it and still maintain security?
>
> Kevin
>
> - Original Message -
> From: "Benjamin Trott" <[EMAIL PROTECTED]>
> To: "modperl" <[EMAIL PROTECTED]>
> Sent: Thursday, June 14, 2001 5:00 PM
> Subject: Re: ssl encryption
>
>
>>> When apache is serving a ssl connection, I assume that everything
>>> sent back and forth between the server and the client is encrypted.
>>> I want an mod_perl script to encrypt/decrypt credit card numbers
>>> obtained over the ssl connection for storage in a db on the server.
>>> Is there any access to the same routines that apache is using for the
>>> encryption or do I have to use some other module. If I have to use
>>> another module, what would be a good choice?
>>
>> You could use either an asymmetric cipher or a symmetric cipher.
>>
>> An example of the former is Crypt::RSA (Crypt::DSA is another, but DSA
>> is
>> used only for signing/verification, not for encryption/decryption).
>>
>> A good, fast example of the latter is Crypt::Blowfish. Used together
>> with
>> Crypt::CBC, you get Blowfish in CBC mode:
>>
>> use Crypt::CBC;
>> my $cipher = Crypt::CBC->new('passphrase', 'Blowfish');
>> my $ciphertext = $cipher->encrypt('data');
>> my $plaintext = $cipher->decrypt($ciphertext);
>>
>> In other words, you use the same passphrase to both encrypt and decrypt
> the
>> data (ie. symmetric).
>>
>> Personally, I think I'd use a symmetric cipher, but the thing you have
>> to
> be
>> careful of is leaving your passphrase around in plain text (eg. in a
>> script). Doing this negates many of the benefits of encrypting the
>> data in
>> the first place. :) Sadly I'm not sure of the best answer to this
>> dilemma.
>>
>> bye,
>> Ben
>>
>>
>
>
Re: ssl encryption
Not storing the credit card numbers at all would be the best option :-) If you must, we've usually used crypt for one-way encryption, or Crypt::BlowFish for stuff we need to be able to decrypt (look after your key!). On Thursday, June 14, 2001, at 09:54 pm, Tim Gardner wrote: > When apache is serving a ssl connection, I assume that everything sent > back and forth between the server and the client is encrypted. I want > an mod_perl script to encrypt/decrypt credit card numbers obtained over > the ssl connection for storage in a db on the server. Is there any > access to the same routines that apache is using for the encryption or > do I have to use some other module. If I have to use another module, > what would be a good choice? > > Thanks, > Tim >
Re: IP based instant throttle?
Do you get flooded that frequently that this is an issue? I've seen DOS, and various buffer overflows etc. in the real world, but I've never seen this. Unless its happening very often, I would have thought that some monitoring and a 2am "Deny from ip" in your httpd.conf would be enough ... On Friday, June 8, 2001, at 01:50 am, Justin wrote: > Does anyone see the value in a Throttle module that looked at > the apache parent status block and rejected any request where > another child was already busy servicing *that same IP* ? > (note: the real IP is in the header in a backend setup so it > is not possible to dig it out across children without > creating another bit of shared memory or using the filesystem?). > > I'm still finding existing throttle modules do not pickup and > block parallel or fast request streams fast enough .. ok there are > no massive outages but 10 seconds of delay for everyone because > all demons are busy servicing the same guy before we can conclude > we're being flooded is not really great.. modperl driven forums > (or PHP ones even) can be killed this way since there are so > many links on one page, all active.. > > thanks for any thoughts on this. > > -Justin >
Re: Perm Module VM_Monitor (fwd)
It can be a real nightmare getting it all compiled and working, especially if you're not on Linux, but it is worth it in the end. I strongly recommend building everything yourself from the ground up, wherever possible, especially if you're working in a production environment. Vendor-supplied versions are often subtly different from the public distributions, and when you do need to recompile for some reason (e.g. mod_perl, or Apache modules that don't play nicely with your current build) you don't want to have to wait for your vendor to pull their finger out. The perl sources are obtainable from http://www.cpan.org/src/stable.tar.gz There is additional INSTALL documentation for AIX. It looks like you will need one of a couple of vendor supplied compilers, or gcc and some sweat. The mod_perl source does contain some stuff about patching the perl sources for AIX. This is intended for use by the 'ubiquitous' patch program (also written by Larry Wall). Try 'man patch' or 'which patch' on your system. If you don't have it, there's a Gnu version you can get. If you have trouble getting patch working, just try and patch the sources manually :-) Once you've got your patched version of perl up and running (it may fail a few obscure tests ... on Mac OS X, perl 5.6.1 failed on 4 tests), the rest *should* be fairly straightforward ... Good luck! On Wednesday, June 6, 2001, at 02:54 pm, Stas Bekman wrote: > This is one of those emails where my address is confused with mod_perl > list's addresses. > > Ian, if you have questions about mod_perl you should ask them at > [EMAIL PROTECTED] > > I didn't work with AIX for ages, so neither could be much of help with > its > compiler problems, howerever there are a few folks on the list, who can > probably help you. > > -- Forwarded message -- > Date: Wed, 6 Jun 2001 14:40:58 +0100 > From: Ian Jones <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Perm Module VM_Monitor > > Help please. Do you have any other documentation. I realise some of the > problems we incurred are self inflicted. > > We are using Apache under the guise of IBM's websphere products on AIX > 4.3.3 with RS6000 servers. We thought that the VM-Monitor would be very > useful, > however our knowledge of Perl and C is extremely limited. One of our > Unix > Admin guys had a go with the following results. > > 1) Spend three hours finding out about CPAN modules and picked up one > very > important fact - mod_perl needs to be installed/configured beside the > webserver > before any of this could be used. > > 2) Spend another couple of hours finding the source code for mod_perl > and > getting it onto a test node. Now the fun starts > > 3) Need a C compiler to compiler mod_perl and the test node didn't > have one > or > I had to find/download/installed/compile gcc on to the node > > 4) First failure trying to compile mod_perl was that it needed perl > (pretty > obvious with hindsight). So I moved the C compiler and the mod_perl > build > environment to the unused HUB system (as PSSP comes with perl). > > 5) Oops the packaged version is not at a high enough level. I found an > AIX > perl runtime on the BULL site at the minimum level required and > installed > that. > > 6) Now the instructions on mod_perl are invalid for IHS and building a > DSO > so > it took at bit of time to find a Web Site with the relevant flags > listed. > > 7) Now the apxs system (api extensions) failled as the file appears to > be > misconfigured - there are no instructions anywhere on what it should be > so a > little bit of trial and error was required to get passed this bit. > > 8) Now the C compiler requires a file that doesn't exist and does say > what > should be in it. So time to move C Compilers - I installed the IBM C > Compiler > to see if that gets a further. > > 9) Link errors about symbol tables - will this hell ever end. The > compiler > couldn't find a symbol table in one directory (it was in another one) > so a > symbolic link came about. > > 10) Hurray - I finally get a copy of libperl.so created with no errors. > Time > to test it with IHS. > > 11) Bugger - segmentation fault everytime its called - another search > of > the > internet shows an article saying that for AIX a patch must be applied > to > the > perl distribution before mod_perl is created. It lists all the > relevant C > code > but gives no indication on how to apply it or in which file. Yet more > digging > makes me think the patch would have to be added to the perl source > code and > the > recompiled - as I don't have the source its a dead end. > > ANY help would be gratefully appreciated. > > Regards > > Ian Jones > > > > For more information on Standard Life, visit our website > http://www.standardlife.com/ The Standard Life Assurance Company, > Standard > Life House, 30 Lothian Road, Edinburgh EH1 2DH, is registered in > Scotland > (No SZ4) and regulated by the Pers
Re: advice on Apache::DBI Apache::Session and Apache::AuthCookieDBI intergration
On Sunday, June 3, 2001, at 12:28 pm, Clayton Cottingham aka drfrog
wrote:
>
> heres what im caught on :
> 1.is it best to load Apache::DBI at start up of apache and can i load
> more than
> one connection type?
yes via PerlModule or a PerlRequire for a startup.pl. My understanding
is that forked children will get a copy of the pre-loaded module, rather
than having to load it afresh. This will save you each http child
loading the module when it is first used.
re connection types, these are usually pulled in with a startup.pl line
something like
$dbh = Apache::DBI->connect_on_init("$driver", "$user", "$pwd");
AFAIK, Apache::DBI performs connection caching based on a hash of the
connection parameters,
so next time Apache sees a connect with the same $driver/$user/$pwd
combo, it will hand out a pre-opened connection, if it has one. If you
open a connection for a different user/pwd connection, Apache::DBI will
open a new connection.
To get this other connection pre-opened, just add
$dbh2 = Apache::DBI->connect_on_init("$driver2", "$user2", "$pwd2");
to your startup.pl
I haven't used Apache::Session, so I can't help you with the rest ...
cheers,
Martin
> 2.is it best to login and then set session or set session and then log
> in
> 3. what about 'last session' type storage
> 4. if Apache::DBI is on at startup how can i load a specific connection
> type
> for Sessions?
>
> i think that's all the really big questions i have
>
>
> system info
> mandrake 7.2 with Apache1.3.12, modperl 1.,& postgres 7.1
> 700Mhz 312 mb ram
>
>
>
>
Re: dyld problems with Apache 1.3.19 and mod_perl/mod_php on Mac OS X 10.0.03
On Friday, June 1, 2001, at 08:33 am, Ged Haywood wrote: > > On Fri, 1 Jun 2001, Martin Redington wrote: > >> I'm having some some difficulties with Apache 1.3.19 and >> mod_perl/mod_php. [On Mac OS X] > > Never built on the Mac myself, some people had trouble, looks like > you're > an expert. I was lucky enough to have built everything before, on Linux, and to have the hints and tips from the stepwise and Mac OS Hints crew ... > From what I see on the mod_perl List about mod_perl and PHP on > *other* operating systems they don't always play together too well so > you > perhaps can expect a few teething problems. I'm pretty sure that this is OS X specific. The dyld issue with multiple definitions is a known issue (see the libtool man page). Apache contains a patch which installs error handlers for multiple definitions, which ignores them (although its not clear to me if this code actually get compiled on OS X, there's a change note for Apache that suggests its no longer required). > > Have you been keeping an eye on the mod_perl lists lately at all? > > The reason I ask is that there have been some recent discussions about > mod_perl on MacOS X and if you've not seen them it might be worth your > while browsing. Only in the last few weeks, maybe a couple of months. I've searched the mod_perl (and other) archive(s) pretty extensively. Try google with 'Mac OS X dyld multiple definitions" to see some posts. Lots of people seem to have hit the dyld problem with one thing or another (python is another one), but no-one's posted any good info on fixes for it. > > Sorry if this isn't too much help. Maybe you'll get something more > concrete when people start to disagree with me. :) > I hope so. Right now it seems like no-one is running apache/mod_perl/mod_php with Apache::DBI (if you are, and can get it to work, *please* let me know how you did it) ...
dyld problems with Apache 1.3.19 and mod_perl/mod_php on Mac OS X 10.0.03
I'm having some some difficulties with Apache 1.3.19 and mod_perl/mod_php. Everything builds fine, but I get dyld multiple definition errors in some circumstances. I believe this is connected to the OX X dyld's insistence on freaking out with multiple definitions (so non Mac OS X users might like to stop here) but I'm not sure what the fix is. I've spent quite a long time on this, and am getting quite desperate. Any pointers would be very helpful. I'm used to using persistent database connections under mod_perl and Apache, via the Apache::DBI modules, and Tim Bunce's excellent DBD modules, on Linux. I also like to build everything myself. So, I downloaded and installed Perl 5.6.1, Apache 1.3.19, mod_perl 1.25, mysql 3.23.36, the Msql-Mysql-modules 1.2216, DBI 1.15, Apache::DBI 0.88 and php 4.05. After some fiddling, and with some help from Mac OS X Hints and Stepwise (Thanks especially to the macosx-perl mailing list, Scott Anguish at Stepwise, and Merlin Tishauser <[EMAIL PROTECTED]>), I got everything to build. I also got persistent database connections to a mysql database. When I added mod_php to the build, via apxs, my apache build started dying on startup, with the following error message: dyld: /usr/local/apache1.3.19/bin/httpd multiple definitions of symbol __dig_vec /usr/local/apache1.3.19/libexec/libphp4.so definition of __dig_vec /Library/Perl/site_perl/5.6.1/darwin/auto/DBD/mysql/mysql.bundle definition of __dig_vec /usr/local/apache/bin/apachectl start: httpd could not be started I tracked the error down to a startup script that I run via a PerlRequire directive (see the mod_perl docs), to open an initial database handle, and load various perl Modules. Commenting out the PerlRequire stopped the error, but when I requested my test_database.pl script (which runs a simple select on the database), from a mod_perl directory, the browser hung, and similar dyld errors appeared in the error log. Strangely, a copy of the script that I keep in in a non mod_perl cgi-bin directory runs with no problem. Within the script, the errors originate with the line "use DBD::MySQL", or at an open connection statement, which is effectively the same thing. I think what is happening is that the __dig_vec symbol being loaded from the DBD::MySQL bundle is conflicting with the same symbol in mod_php. I looked in the Apache 1.3.19 source, and can see handlers for multiple definition in os/unix/os.c, but I guess that the DBD::MySQL module is being loaded by code in perl or mod_perl. I guess my question is, is there an easy way to fix this conflict, or do perl and/or mod_perl need to be patched with similar dyld error handlers to the ones in Apache (see os/unix/os.c)? My config info is as follows: Perl: config_args='-ds -Dmksymlinks -Adefine:prefix=/usr/local -Dccflags=-g -pipe -Dfirstmakefile=GNUmakefile -Adefine:privlib=/Library/Perl/5.6.1 -Adefine:sitelib=/Library/Perl/site_perl/5.6.1 -Adefine:vendorlib=/Network/Library/Perl/5.6.1 -Dman1dir=/usr/local/man/man1 -Dman3dir=/usr/local/man/man3 -Uinstallusrbinperl' Apache: ./configure \ "--prefix=/usr/local/apache1.3.19" \ "--with-layout=Apache" \ "--enable-module=all" \ "--enable-shared=max" \ mod_perl: built via apxs, with EVERYTHING=1 PHP (patched as advised by Merlin Tishauser): ./configure \ --with-xml \ --with-zlib \ --with-apxs=/usr/local/apache/bin/apxs \ --with-mysql=/usr/local/mysql \ --disable-pear \ --enable-track-vars \ == ===
