Re: AW: Apache::DBI and password security
On Fri, Nov 15, 2002 at 12:52:13PM +, Rafiq Ismail (ADMIN) wrote: > $Apache::PARANOID::dbiPassword > = $bfish->decrypt($encryptedPassword); > then whenever you want your password you access > $Apache::PARANOID::dbiPassword. > Hmm. I think that the guy who wrote Blowfish_PP would cut my danglies off > for that one. Which is why you copied him in the first place? :-) In general, though, there isn't a good way to get any security from any system that has to be able to access sensitive data in an automatic way. MBM -- Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/
Re: Using mod_ssl and client certificates
On Sat, Nov 09, 2002 at 02:52:54PM +0100, Florian Weimer wrote: > We are moving to client certificates for authentication on our > internal web sites. So far, we use a rather crude scheme > (all-or-nothing), but we would like to differentiate between clients > in the future. > > Is there are straightforward way to integrate certificate-based > authentication and mod_perl, i.e. access information on the client > certificate from mod_perl? A moderate performance hit is acceptable > because it's for our internal sites only. Presumably in the worst case, you can do a FakeBasicAuth type trick (I know that this is available in Apache-SSL, I think it's available in mod_ssl too), and access the certificate DN as if it were a userid. MBM -- Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/
Re: XML::RPC
On Sun, Apr 21, 2002 at 01:06:28PM +0200, F. Xavier Noria wrote: > On Sun, 21 Apr 2002 10:50:53 +0100 > Matthew Byng-Maddick <[EMAIL PROTECTED]> wrote: > : On Sun, Apr 21, 2002 at 03:16:53AM -0400, Sam Tregar wrote: > : > SOAP::Lite module to be of excelent quality and the SOAP::Lite community > : > to be very helpful. > : Apart from the obvious security bug, you mean? The one where it doesn't > : actually restrict what remote code can be run at all? > SOAP::Lite 0.55 was released some days ago, it addresses that issue > according to > http://www.soaplite.com/ I'm aware of this, but I can't stress the importance of reviewing such security-critical code. And the "excellent quality" of the code that was mentioned by Sam Tregar in his post. RPC often is a nightmare security-wise, the SOAP::Lite bug illustrates the problems perfectly. MBM -- Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/
Re: XML::RPC
On Sun, Apr 21, 2002 at 03:16:53AM -0400, Sam Tregar wrote: > SOAP::Lite module to be of excelent quality and the SOAP::Lite community > to be very helpful. Apart from the obvious security bug, you mean? The one where it doesn't actually restrict what remote code can be run at all? If you are going to use SOAP, be *very* *very* aware of the security issues with any RPC-like mechanism, review any code you're going to use, thoroughly. And only then, decide whether it is actually the best solution. MBM -- Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/
Re: [OT] log analyzing programs
On Sun, Dec 02, 2001 at 12:52:11PM +, Dave Hodgkinson wrote: > Bill Moseley <[EMAIL PROTECTED]> writes: > > Any suggestions for favorite ones? wusage seems to require a lot of > > resources -- maybe that's not unusual? It runs once a week. Here's a > > about six days worth of requests. Doesn't see like that many. > analog - but _do_ read the words that go with it, know what you're > analysing. i have a stats redux note on my site too. We like analog, Stephen Turner is a Cam.pm member, and makes regular appearances at our social meets. I've looked at webalizer too, but webalizer is appallingly written, keeps everything in globals (though I believe analog also currently does this and Stephen said he'd like to change it), and uses scary amounts of memory. It also doesn't have particularly good integrity checking for its database dumps. MBM -- Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/
Re: Advanced daemon allocation
On Mon, Jun 18, 2001 at 10:41:50AM -0500, Keith G. Murphy wrote: >Trevor Phillips wrote: >> >>Is there any way to control which daemon handles a certain request with apache >>1.x? >> >>eg; Out of a pool of 50 daemons, restricting accesses to a certain mod_perl >>application to 10 specific daemons would improve the efficiency of data cached >>in those processes. >Making sure the browser supports HTTP 1.1 (persistent connections) will >get you a lot better performance in many cases, since a particular user >will tend to keep hitting the same daemon, so that helps if they're >hitting the same or a related script over and over. This only works within the keepalive timeout. (default configuration 15s) >In one case, I was seeing really bad performance from an app, but it >seemed acceptable to the users, who were all running IE, where I was >running Netscape, which still doesn't support 1.1 in version 4 >browsers. :-( Dunno about 6, Mozilla, etc. This is only true if you're serving images off the mod_perl server which is crazy unless you're generating them. Anyway: the point of this post was: http://perl.apache.org/guide/performance.html#KeepAlive Sorry. Although: Stas: "Since keepalive connections will not incur the additional three-way TCP handshake, turning it off will be kinder to the network." erm Surely if you turn it *on* you'll be kinder to the network, because you're not reinitiating the handshake? MBM -- Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/
Re: Advanced daemon allocation
On Mon, Jun 18, 2001 at 02:29:18PM +0800, Trevor Phillips wrote: >Gunther Birznieks wrote: [>>Trevor wrote:] >>Yeah, just use the mod_proxy model and then proxy to different mod_perl >>backend servers based on the URL itself. >Isn't this pretty much what I said is *a* solution? Yes, and the only one. >>>I suppose I could do this now by having a front-end proxy, and mini-Apache >>>configs for each "group" I want, but that seems to be going too far (at this >>>stage), especially if the functionality already exists to do this within the >>>one server. > To me, this isn't very ideal. Even sharing most of an apache configuration > file, what is the overhead of running a separate server? And can multiple > Apache servers share writing to the same log files? No. The way the multiple process model that apache uses works because of the way that sockets work: Parent process runs as root, calls: socket() (create the socket) bind() (bind to our local sockaddr_in structure - ip/port) listen() (set the socket to listen mode) now, normally, it would then call accept() to sit there and block for while it waits for a connection to be made. Instead what it does is rather more cunning. It fork()s (several times) to create the children, and immediately setuid()s to drop its root privs. However, the bit that needs the root privs is the bind() call above, and because of the way that fork() works, we inherit the socket from the parent. These *children* then call accept(). And they all block. When a connection comes in on that socket, whichever is currently in the schedule queue will return from the accept() system call, and handle the request. It is, however, up to the kernel, which one calls accept(). accept() returns a *new* file descriptor, which is the one for the *stream* (as opposed to the socket). Obviously, if your modperl is URL dependent, then you can't determine what URL they are going to ask for at the time you have to call accept. The only alternative way of doing what you're asking for is to use file descriptor passing, which is still about *the* topmost unportable bit of UNIX. :-( It is also quite complicated to get right. >It also doesn't help if I have dozens of possible groupings - running dozens of >slightly different Apache's doesn't seem a clean solution. Hence me asking if >it was possible within the one Apache server to prioritise the allocation to >specific daemons, based on some criteria, which would be a more efficient and >dynamic solution, if it's possible. It isn't, because otherwise there'd be even more context-switching, (which is slow). The clean solution, in this case, would be to have the one apache that actually accepts, does a bit of work on the URL, and then delegates to children (probably by passing the fd), but then you still have to do rather too much work on the URL before you can do anything about it. It isn't as unclean as you might think, though. Hope this helps MBM -- Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/
Re: can not redirect on POST w/ CGI.pm
On Wed, Jun 13, 2001 at 11:58:24AM -0400, David Young wrote:
> I've found that if I post to this PerlAccessHandler, I get no response:
> #
> package Apache::Redirect;
>
> use strict;
> use Apache::Constants qw(REDIRECT);
> use CGI ();
>
> sub handler {
> my($r) = @_;
>
> my $q = new CGI();
>
> $r->header_out(Location => "http://www.modperl.com/";);
> return REDIRECT;
> }
>
> 1;
> #
> If I comment out "my $q = new CGI();" then it works fine. Any ideas on what
> is causing this?
Actually, it's apache not letting it redirect on a POST form. I don't know
why commenting out CGI makes any difference, but the HTTP RFC does say that
the behaviour is undefined, for 301/2 on anything other than GET, if you
think about it, this makes sense:
>>>POST url
:
<<<302 Location Moved
<<
Re: Getting MAC address
On Wed, 21 Mar 2001, John Whitnack wrote: > Is there a way to get a person MAC address using apache, mod_perl or > javascript. I have yet to find a way to do this? I need a way to > uniquely identify the computer a person is using (i.e. not ip address). Bear in mind that a MAC address is something specific to an *Ethernet* network. ATM networks have their own addressing scheme and other networks will have theirs. This would only work if the person is on the same *link layer network* as you, ie, non-routed (because then you'll just get the mac of the router). The answer is to parse the output of arp -a, or equivalent... MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8980 5714 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) Genius may have its limitations, but stupidity is not thus handicapped. -- Elbert Hubbard
Re: [OT] ApacheCon BOF
On 21 Mar 2001, Piers Cawley wrote: > You mean apart from the trademark infringement? I know, what about > "mod_perl is my bNO CARRIER All your base are belong to mod_perl ?? MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8980 5714 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) perl -e 'print reverse split//,"\n.rekcah lreP rehtona tsuJ"' perl -e '$_="\n.rekcah lreP rehtona tsuJ";m!$!;print$&while($`=~m,.$,s)'
[CV] [JOB WANTED]
After not following up a lot of potential leads when I tried this last time, I'm once again posting my CV here. The CV in question is at http://colondot.net/mbm/cv.shtml I am up for doing sysadmin on any UNIX (although I'd prefer one of FreeBSD/Solaris/Linux), mod_perl development (which I've spent the last year and a half or so doing), apache development in C. Internet daemon development of any sort (perl or C). Other kinds of Perl and C are also good, but I've not done it so much. Email me rather than the list to follow-up, please. MBM -- VMS, n.: The world's foremost multi-user adventure game.
Re: Using rewrite...
On Fri, 19 Jan 2001, Matthew Byng-Maddick wrote:
> On Fri, 19 Jan 2001, Tomas Edwardsson wrote:
> > The problem is that I can't find a way to send the request
> > to a relevant port if the request calls for a URL which ends
> > with a slash ("/"). Any hints ?
> RewriteCond and %{REQUEST_FILENAME} ?
> This happens after the default URI Translation handler.
Oops. This appears that I'm lying. It doesn't work in my setup either.
MBM (needs to go read some source :)
--
Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile)
Under any conditions, anywhere, whatever you are doing, there is some
ordinance under which you can be booked. -- Robert D. Sprecht, Rand Corp.
Re: Using rewrite...
On Fri, 19 Jan 2001, Tomas Edwardsson wrote:
> RewriteCond %{REQUEST_FILENAME} .*\.php$
> RewriteRule ^(.*)$ http://%{HTTP_HOST}:83$1
> I Tested it like this and this doesn't seem to work, either
> I'm misunderstanding RewriteCond or this method doesn't work.
What happens if you turn RewriteLog On and set RewriteLogLevel 9?
MBM
--
Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile)
Under any conditions, anywhere, whatever you are doing, there is some
ordinance under which you can be booked. -- Robert D. Sprecht, Rand Corp.
Re: Using rewrite...
On Fri, 19 Jan 2001, Tomas Edwardsson wrote:
> The problem is that I can't find a way to send the request
> to a relevant port if the request calls for a URL which ends
> with a slash ("/"). Any hints ?
RewriteCond and %{REQUEST_FILENAME} ?
This happens after the default URI Translation handler.
MBM
--
Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile)
Under any conditions, anywhere, whatever you are doing, there is some
ordinance under which you can be booked. -- Robert D. Sprecht, Rand Corp.
Re: how to secure backend server ?
On Tue, 2 Jan 2001, darren chamberlain wrote: > Oleg Bartunov ([EMAIL PROTECTED]) said something to this effect on 01/02/2001: > > > You can explicitly bind an apache server to localhost. > > This works only if frontend and backend are on the same physical server. > > But it will not works even in this situation if you have several > > proxies running while you want backend accepts requests only from > > one specific proxy. > > Bind an address on the 192.168.0 net as an alias on a real interface: RFC 1918 says that you should choose a random network on one of the private subnets: 10/8 172.16/12 192.168/16 But yes, using a private network is a good solution. [explanation of ifconfig] > And then bind another address on the same private subnet to an interface > on another machine, and they can talk to each other via this network > (set the route correctly as well, naturally). > This interface will be invisible from the 'net. Unless you are unlucky and it is found to be routable. You ought to drop these three at your firewall anyway. but modperl!=NANOG :) However, it is unlikely to route to your machine... MBM -- Tell me, O Octopus, I begs, / Is those things arms, or is they legs? / I marvel at thee, Octopus; / If I were thou, I'd call me us. -- Ogden Nash
[JOB] [CV] Job wanted
I'd like to leave my current job. Is anyone here offering mod_perl or apache programming jobs in and around London? I'd be interested in any job involving: + apache (mod_perl and C module programming) + Perl + XS + C My current CV is available at http://colondot.net/mbm/cv.shtml, and details what experience I have. I would be on a 1 month notice period in terms of availability. I would be happy to answer any questions you may have about things I've done in email. Please reply by private email (the email address here) rather than to the list. Thank you Matthew Byng-Maddick -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) What passes for woman's intuition is often nothing more than man's transparency. -- George Nathan
Re: mod_perl in chroot environment
On Tue, 12 Dec 2000, Gunther Birznieks wrote:
> At 09:58 AM 12/11/00 +0000, Matthew Byng-Maddick wrote:
> >On Sun, 10 Dec 2000, Gunther Birznieks wrote:
> > > For example, perhaps the mod_perl server and the HTML/images server should
> > > be separately chrooted from each other? That way, someone who breaks the
> > > dynamic script won't be able to mess with the frontpage of the website to
> > > deface it assuming the hacker could get around permissions issues within
> > > the chroot jail.
> >Why do you need the proxy server to be chrooted at all? what does that
> >gain you. After all if apache is insecure, you can break out of the
> >chroot()ed jail anyway.
> If Apache is insecure it's not necessarily possible to break out of the
> chrooted jail. It depends on if the part of Apache that grabs the socket is
> insecure which is a tiny part of Apache.
Ah. I see what you're getting at. By insecure I really meant that you
could achieve root. I see that if you were trying to read files on the
system, yes, a chroot would help.
> Apache itself is large and complex and if you are talking about a front-end
> server, you are talking about having at minimum mod_proxy, mod_rewrite and
> maybe even mod_backhand. These modules are not trivial code but breaking
> them wouldn't allow someone to break out of the chroot jail with root
> privileges.
yes, you can only break out of the jail once you have achieved root.
> > > BTW, OT Question on the subject -- does anyone know if /chroot/etc/shadow
> > > necessary once the chroot jail is in effect? The author creates a shadow
If you can't break up to root in the jail, then you don't need to worry
about a shadow file.
> >Well, you've lost if you break root inside a traditional chroot() (as
> >opposed to FreeBSD4's jail() -
> >1) attacker can mknod() (and can therefore attack kmem.
> >2) attacker can call chroot()
> >- int j; mkdir("./bin"); chroot("./bin");
> > for(j=0;j Doesn't this require the root ID in order to issue .. chroots? I may be
> misunderstanding this portion of your statement.
Yes, but I'm showing that in a traditional chroot, if the attacker can get
root (in order to read the /chroot-path/etc/shadow file), then you've lost
anyway, because he can break out of the jail by the trick above.
> >In which case the shadow file can be there. What isn't there is a way to
> >get root (any suid programs or similar). You hope. :)
> I agree that it's an important point to make is that any binary copied
> to the chroot jail should not be suid root as that would allow a point
> of attack.
That's why chroot() is useful. :)
MBM
--
Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile)
Think Honk if you're a telepath.
Re: mod_perl in chroot environment
On Sun, 10 Dec 2000, Gunther Birznieks wrote:
> At 03:33 PM 12/10/00 +0100, Stas Bekman wrote:
> >Do you think I should include the scenario of making Apache run in chroot
> >enviroment in the guide?
> I think chroot Apache is important especially for dynamic services.
Definitely.
> For example, perhaps the mod_perl server and the HTML/images server should
> be separately chrooted from each other? That way, someone who breaks the
> dynamic script won't be able to mess with the frontpage of the website to
> deface it assuming the hacker could get around permissions issues within
> the chroot jail.
Why do you need the proxy server to be chrooted at all? what does that
gain you. After all if apache is insecure, you can break out of the
chroot()ed jail anyway.
> BTW, OT Question on the subject -- does anyone know if /chroot/etc/shadow
> necessary once the chroot jail is in effect? The author creates a shadow
Well, you've lost if you break root inside a traditional chroot() (as
opposed to FreeBSD4's jail() -
1) attacker can mknod() (and can therefore attack kmem.
2) attacker can call chroot()
- int j; mkdir("./bin"); chroot("./bin");
for(j=0;j file but it seemed odd to me. He also advocates copying it over and then
> creating a new one from scratch which seems redundant and potentially
> dangerous if the second step is forgotten.
Very much so, agreed.
MBM
--
Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile)
philosophy, n.: Unintelligible answers to insoluble problems.
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
not that it's bad (it's > actually great... kudos to the DBI crew) but kind of the opposite; it's so > easy to use that most people don't think beyond it. How many of you have > ever thought about implementing an Object-Relational middleware layer using > mod_perl? We could create a set of generic OR classes as part of our > foundation framework. DBI is actually quite a hassle to use sensibly, and I've got my own library functions that call the DBI ones, and return errors in a way that is consistent. I also have the run object open DB connections. (YATS) http://codix.net/ASPerl/. MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) Genius may have its limitations, but stupidity is not thus handicapped. -- Elbert Hubbard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, brian moseley wrote: [coldfusion/php] > how is mason not like this? It has no point-n-drool authoring tools. This is actually the killer app. Once this is done, Mason / other templating system of choice gets catapulted to the forefront MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) Genius may have its limitations, but stupidity is not thus handicapped. -- Elbert Hubbard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question
On Wed, 22 Nov 2000, Jonathan Tweed wrote: > I would be grateful if someone could answer this question: > Even if you tell Apache only to execute files in a certain directory under > mod_perl do all processes still include the mod_perl code? If I understand your question correctly, yes. MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) Diplomacy is the art of saying "nice doggie" until you can find a rock. -- Wynn Catlin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl for NT when using another Web server other than Apache.
On Tue, 21 Nov 2000, Gurumustuk Singh Khalsa wrote: > Hi there... I was just wondering if any of you know of a way to use > mod_perl on NT using another webserver other than Apache. I am running > the Lotus Domino web server and currently have the latest ActivePerl > installed. No. Mod_perl is heavily tied into the Apache API. I don't know whether Domino supports ISAPI, but someone I know was looking into the prospect of writing a mod_perl for ISAPI. Perhaps you should be looking more in that direction? > Any help would be greatly appreciated! Not much that anyone can do, unfortunately. MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) Trifles make perfection, and perfection is no trifle. -- Michelangelo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::VirtualHostRegistry
On Fri, 17 Nov 2000, Gunther Birznieks wrote: > At 11:15 AM 11/17/00 +0000, Matthew Byng-Maddick wrote: > >man jail() on FreeBSD 4. > But then you lose the benefits of having shared apache processes among many > shared users many of whom may have very non-busy web sites. No? Yes, but this is the only way to reliably have security with mod_perl in such a way as they can't interfere with anyone else's code. MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) In California they don't throw their garbage away -- they make it into television shows. -- Woody Allen, "Annie Hall" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::VirtualHostRegistry
On Fri, 17 Nov 2000, Nigel Hamilton wrote: > Going along ths lines of sharing mod_perl between users for ISPs > is there a median position that tempers security concerns/support > costs/hassles etc that a CPAN module could fill? I wouldn't do it like that. > I'm thinking of a module like APache::Registry but it segments the > namespace/memory netween virtual servers --- a sandbox that each virtual > host is kept in? man jail() on FreeBSD 4. MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) In California they don't throw their garbage away -- they make it into television shows. -- Woody Allen, "Annie Hall" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Microperl
On Thu, 16 Nov 2000, Robin Berjon wrote: > At 00:12 16/11/2000 -0600, Les Mikesell wrote: > >> Nothing against mod_rewrite -- I was just wondering if a small perl could > >> be embedded with out bloating the server too much. > >I don't think 'small' and 'perl' belong in the same sentence... > I know what you mean but this is MicroPerl, not Perl. I don't know how much > difference it makes, but it's certainly smaller. I'm afraid I can't help > with embedding it though. I like the idea, not just for rewrites (I'm quite > happy with mod_rewrite most of the time) but for all the conf stuff. It > doesn't have dynaloader, but you could still do things like read conf from > a flat file db or that sort of thing. It doesn't have anything that isn't *entirely* portable and *entirely* guaranteeable, which means a large number of syscalls, and anything which isn't in K&R2. MBM -- Science is built up of facts, as a house with stones. But a collection of facts is no more a science than a heap of stones is a house. -- Poincare
Re: Fast DB access
On Fri, 10 Nov 2000, Les Mikesell wrote: [ReiserFS] > production just to avoid the possibility of a slow fsck after a crash, > but it is enormously faster at creating and deleting files too because > everything is indexed so it would be an ideal stash for fast changing > session data. If you don't trust it for the whole system you can just > use it on one partition for the session database. Several Linux > distributions include it now. As I recall, it has a problem if you manage to have a hash collision in your naming, IIRC it was something to do with the way in which it extends the hash it uses for dents. This is, of course, FUD. :) I've also heard bad things about his attitude... FreeBSD 4's softupdates make ufs rather wonderful too. These basically make UFS's write() calls asynchronous, and hence much faster. They also keep dependencies, and can be very good for spools MBM -- It is wrong always, everywhere and for everyone to believe anything upon insufficient evidence-- W. K. Clifford
Re: mod_perl on specific scripts (fwd)
n 6 Nov 2000, David Hodgkinson wrote: > Matthew Byng-Maddick <[EMAIL PROTECTED]> writes: > > On 1 Nov 2000, David Hodgkinson wrote: > > > Matthew Byng-Maddick <[EMAIL PROTECTED]> writes: > > > > You do, of course, know about all the latest patches for this, due to > > > > potential security problems > > > ...moving to Apache 1.3.14, right? > > Some are fixed in 1.3.14 but there are an extra set of patches for 1.3.14 > > to fix the things that weren't fixed. > And where do these hide? I can't see them on apache.org in either > patches directory... Tony Finch wrote: | I have also made the patch available from | http://httpd.apache.org/dist/apache_1.3.14-fix.diff | because there are a few other problems we want to fix before releasing | 1.3.15 and getting the patch out of the bug database is unnecessarily | painful. >From when I spoke to Tony, he said that these were mod_rewrite isssues too. MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) The Universe shipped by weight, not by volume. Some expansion of the contents may have occurred during shipment.
Re: mod_perl on specific scripts
On 1 Nov 2000, David Hodgkinson wrote: > Matthew Byng-Maddick <[EMAIL PROTECTED]> writes: > > On 31 Oct 2000, David Hodgkinson wrote: > > > Did I just condemn you to learning mod_rewrite? Ooops :-) > > You do, of course, know about all the latest patches for this, due to > > potential security problems > ...moving to Apache 1.3.14, right? Some are fixed in 1.3.14 but there are an extra set of patches for 1.3.14 to fix the things that weren't fixed. MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) To err is human, to forgive is against company policy.
Re: mod_perl on specific scripts
On 31 Oct 2000, David Hodgkinson wrote: > Did I just condemn you to learning mod_rewrite? Ooops :-) You do, of course, know about all the latest patches for this, due to potential security problems MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) To err is human, to forgive is against company policy.
Re: how to really bang on a script?
On Mon, 30 Oct 2000, Perrin Harkins wrote:
> On Sat, 28 Oct 2000, Matthew Byng-Maddick wrote:
> > Theo, during the mod_backhand talk, or at lunch just before, I can't
> > remember.
> It was during the talk. The tool is called Daquiri, and he said it was
> available in the mod_backhand CVS tree.
Ah yes, I remember someone joking about what flavour it was next to me. :)
MBM
--
Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile)
perl -e '$_="Oyvv bsswjfw Thtm mefmfw2\n";while(m([^\n])){$_=$'"'"';$a=$&;
$a=($a=~m(^\s)?$a:pack "c",unpack("c",$a)-5+($i++%5));print $a}print"\n";'
Re: Apache Modules in General
On Mon, 30 Oct 2000, Jimi Thompson wrote: > It is me or has anyone noticed a definite LACK of information on how to > modify the httpd.conf for the various modules in order to get them > working??? Why is it that no one has ever posted an actual working copy > of an httpd.conf file for mod_perl in its various incarnations? Could it > be because one doesn't exist? erm are you sure this is where you wanted to write this? can I suggest usenet's alt.flame instead? I have mod_perl working in several incarnations. On several machines. If you like, I can send you a working config, but I don't know if it would be useful to you, because it is heavily dependent on how the apache is configured at build time. The reason that the httpd.conf exists is that apache is an extremely flexible web server. One person's httpd.conf might well be entirely different from someone else's. > I have also noticed a large amount of MISSING information regarding > dependencies among the various modules. mod_so is needed for dynamic loading. Other than that, modules don't tend to depend on each other. Various configuration directives depend on modules being loaded (all the logging, for example). > I think it's all a hoax and no one else can get the stupid thing to work > either ;) You know, Santa Claus, Easter Bunny, Tooth Fairy, Working > Mod_perl | [mbm@hard]:~$ telnet www.londontransport.co.uk 80 | Trying 195.92.250.96... | Connected to www.londontransport.co.uk. | Escape character is '^]'. | HEAD / HTTP/1.0 | | HTTP/1.1 200 OK | Date: Tue, 31 Oct 2000 00:07:56 GMT | Server: Apache/1.3.12 (Unix) mod_perl/1.24 ^ | Connection: close | Content-Type: text/html | | Connection closed by foreign host. I'd say that was working > Totally frustrated, from my own notes on how to do this... | cd into your apache build directory | $ ./configure --with-shared=max | $ cd ../mod_perl-x.xx | $ perl Makefile.PL DO_HTTPD=1 EVERYTHING=1 APACHE_HEADER_INSTALL=1 \ | USE_APACI=1 USE_DSO=0 APACI_ARGS='--enable-shared=rewrite,\ | --disable-rule=WANTHSREGEX, --enable-module=all, \ | --enable-module=define, --enable-shared=max, \ | --disable-shared=perl, \ and if you want suexec for your cgis. | --enable-suexec=max, --suexec-caller=nobody, \ | --suexec-uidmin=500, --suexec-gidmin=500' Then you do | $ make | $ make test | # make install | # cd ../apache_x.xx | # make install But that's how I do it. and being perl, TIMTOWTDI. MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) Trifles make perfection, and perfection is no trifle. -- Michelangelo
Re: Problem with Apache::ASP
On Mon, 30 Oct 2000, Fabio Albertin wrote: > There's one thing I forgot to mention: I'm running a statically compiled > version of Papche, as recommended in the Apache::ASP README, so I don't > think my httpd.conf needs to load any modules, or does it? > I checked my log file for the status message and it didn't mention > mod_perl... Do I have to re-install it or how do I get it to work with my > statically compiled Apache? You'll still need an AddModule mod_perl.c declaration in your httpd.conf MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) Trifles make perfection, and perfection is no trifle. -- Michelangelo
Re: maximum (practical) size of $r->notes
On Mon, 30 Oct 2000, Matt Sergeant wrote: > On Mon, 30 Oct 2000, Todd Finney wrote: > > I'm concerned about putting large amounts of data into > > $r->notes. Some of our script output can be pretty > > heavy. If $r->notes can only take simple strings, how > > large of a simple string is it safe to put in it? Is there > > a better way to do this? > AxKit uses the notes table to store interim strings for template > processing. I've not yet heard a bug related to it, but then I'm not > delivering massive files. I'd imagine it would probably be limited by > available memory. This is basically correct. The notes table is tied to Apache::Table, which in itself is an ap_table, (with C accessors of ap_table_get() and ap_table_set()). Like everything else in Apache, it is based on the pools system of memory management, which will quite happily allocate up to the amount of memory you have, and will then throw it away at the end of the request. However, apache itself calls malloc() but never calls free(), because once it has allocated the memory, it manages it itself. Given that the notes table is allocated from the request pool (such that it is thrown away at the end of a request). It will always happen in the child and can never be shared - so if you have large numbers of apache processes, then this might (if you're using a lot of memory) be able to take the machine down. But the memory management system in apache is only limited by the amount of memory that the system will let it allocate - which means that you should be OK. MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) "It's today!" said Piglet. "My favourite day," said Pooh.
Re: ApacheCon report
On Sat, 28 Oct 2000, Greg Cope wrote:
> Matt Sergeant wrote:
> > http://modperl.sergeant.org/ApacheConRep.txt
> > Enjoy.
> Thanks for that Matt, I did enjoy it - IBM's party coninciding with Suns
> I eventually could not make the conferance due to a nasty deadline
You missed a lot.
> Did Doug mention when mod_perl 2.0 would / maybe / migh possibly be
> ready (I know, I know that it will be ready when its ready, only
> asking!)
I don't remember him mentioning anything, but it will certainly have to
wait until all the bugs in apache 2.0 are fixed. :) (hopes that rbb
doesn't read this...)
According to various asf people, apache2 is at least a month away from
being finished, and probably more...
MBM
--
Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile)
perl -e '$_="Oyvv bsswjfw Thtm mefmfw2\n";while(m([^\n])){$_=$'"'"';$a=$&;
$a=($a=~m(^\s)?$a:pack "c",unpack("c",$a)-5+($i++%5));print $a}print"\n";'
Re: how to really bang on a script?
On Sat, 28 Oct 2000, Matt Sergeant wrote:
> exactly the same thing (changing server logs into a benchmark tool) at
> ApacheCon, only I can't for the life of me remember who it was.
Theo, during the mod_backhand talk, or at lunch just before, I can't
remember.
MBM
--
Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile)
perl -e '$_="Oyvv bsswjfw Thtm mefmfw2\n";while(m([^\n])){$_=$'"'"';$a=$&;
$a=($a=~m(^\s)?$a:pack "c",unpack("c",$a)-5+($i++%5));print $a}print"\n";'
Re: ApacheCon Sunday Pub Meet
On Thu, 26 Oct 2000, Stas Bekman wrote: > On Fri, 20 Oct 2000, Doug MacEachern wrote: > > On Thu, 19 Oct 2000, Matt Sergeant wrote: > > > How about Harvey Floorbangers, from 7 till late. (erm, I think late might > > > still be 11pm for england *sigh*)... Except.. > Sorry folks I've missed this meeting, but I've got my doze of cranberry > juice at the rest of our pub hangouts :) Just a few pub hangouts - I didn't get to bed last night until about 4. I'm back in work this morning - damn. > For those who have missed the conference -- it was very cool, both in a > number of attendees to the mod_perl classes and the hours spent with cool > people outside the classes, when there were no mod_perl classes :) :) Sorry I didn't come to your talk this time stas. > Just in case you are wandering what one could do at the conference if > looking at the schedule program doesn't give you an insentive to go to the > confence -- you miss an important point. Conferences are not about > learning new things (well sometimes :) but about meeting people face to > face and having fun that you couldn't have otherwise over email. That's > it. Seconded. > BTW, Doug's mod_perl 2.0 talk was so cool!!! Just imagine that the demos > and slides were running on 'mod_perl/1.99-dev apache/2.0-dev perl/5.7.0' > you get the idea... This is when it didn't segfault. :) But that's what you get for being on the bleeding edge, I guess? Doug, could you post a URL for your slides at some point, please? > And last but not least, you have missed the talk by Douglas Adams and his > books signing... And noticing various covalent people with BSD horns on. Including Sander's green hair and flashing horns. > [...490 more mod_perl emails to read...] I've managed to catch up, already - wow. MBM -- Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home) http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile) The secret of creativity is knowing how to hide your sources. -- Albert Einstein
Re: Remembering Authentication
On Tue, 17 Oct 2000, John Saylor wrote:
> From: "Ian Frawley" <[EMAIL PROTECTED]>
> > Is it not just possible through a perl module as I am not very clued
> > up on digital certificates.
> Well, you have to have some credentials- and if it's not a cookie [bad
> idea anyway], and if it's not a username/password- what would it be?
Form based authentication. Rather than the HTTP Basic box that the browser
provides.
> You could have IP address based authentication, but this is probably
> more prone to misconfiguration and forgery than digital certificates.
Yes. You forgot proxying and cacheing.
What you also appear to have forgotten is that mod_perl provides you with
a fantastic handle - PerlTransHandler - where you can really have some fun
with the Translation.
| # some test code
| sub handler
| {
| my $r=shift;
| my $uri=$r->uri();
| if(extract_crypto(\$uri))
| {
| # push the credentials into the notes table, or the
| # %ENV or similar at this point.
| $r->uri($uri);
| }
| return DECLINED;
This can still be cryptographically secure - requires the transmission of
username/password pair once - which can be done over https if required.
Thereafter you can do what you like to identify a session
> How important is access control to your application? In other words,
> where is the line on how much effort you [and your users] are going to
> put into security at the expense of convenience?
I think that the usage of digicerts is not wide enough yet that the use of
them is probably an inconvenience. Plus it doesn't work if someone
physically steals the computer. :)
MBM
--
Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile)
standards n.: The principles upon which we reject other people's code.
Re: bytes_sent -> bytes_received?
On Sat, 7 Oct 2000, Drew Degentesh wrote:
> In addition to the number of bytes sent to the client, Id like to log how
> many bytes are sent *by* the client (the size of the request + posts , etc.)
Fair enough
> I was guessing/hoping that length( scalar( $r->content ) ) would do it, but
> earlier in my application (before the log phase) I use Apache::Request to
> (potentially) process a file upload, and Im guessing that clears out
> $r->content.
I'm not sure if it does or not. Anyhow, $r->content won't get you the full
request, plus all the headers. The best way to do this would be to put
your measuring code in as a URI Translation handler (with whatever method
works erm...) and then put the value in a notes field which you can
then recover later on in the processing.
> Any ideas?
Not very helpful, I'm afraid.
MBM
--
perl -e '$_=unpack"b196",pack"H50","cafa9c0e0abbdf7474590e8296e56c103a3c".
"5e97e52e104821";while(m(^.{7})){$a.=$&."0";$_=$'"'"'}print pack"b224",$a'
Re: auth headers & logging
On Mon, 2 Oct 2000, steven wrote: > I'm rewriting authentication headers on the fly and those rewritten > headers are being logged, but I would like to log the details supplied by > the client as opposed to what I've rewritten them as. I thought of writing > a logging module and passing it a note, but it seems a bit long-winded and > I'm worried about the performance overhead. Is there a more efficient way > of doing this? Given that filling the notes table is the standard method for things to be logged, then is there much of a performance overhead. You might even be able to pass data using notes to the standard apache logging mechanism, although I'm not the right person to know quite how to do this. MBM -- The power to destroy a planet is insignificant when compared to the power of the Force. -- Darth Vader
Re: Determine which subroutine to call at runtime
On Sat, 30 Sep 2000 [EMAIL PROTECTED] wrote: > I'm going to write a perl cgi which needs to determine which > subroutine to call at runtime. And the number of choice is huge (more > than 300 and it is growing). I know I could do a bunch of if-then-else > but it makes the code looks very unreadable. Yes. And unmaintainable. > I've basically figured out how to do so. I'd like to seek advice > from you gurus of whether the way I'm doing it is good. As I'm going > to run it under mod_perl, anything I need consider (memory > consumption, performance, etc)? It depends on the spec of your server, mod_perl servers can take up a lot of memory. All of your code will be loaded all of the time, so you want the loading of the hash to occur at compile time, so it will be shared as much as possible across all the apache children. > The basic idea is, in the package, I export a hash which stores > subroutine name and the corresponding anonymous sub reference. The > caller could determine which subroutine to call by getting the sub ref > from the hash with the subroutine name. This is a good way of doing things. > Below is the prototype I've written. Any suggestion/comment are highly > appreciated. Thanks a lot. You might want to think about the security of your system. For example, is there any verification that something the user has just typed in is a sensible thing to run code with? Is there any kind of verification that this function exists first? can they get stuff into the hash by some spurious quoting? MBM -- The Universe shipped by weight, not by volume. Some expansion of the contents may have occurred during shipment.
Re: OT: use problem (need interpolation)
On Thu, 28 Sep 2000, Jerrad Pierce wrote:
> Is there anyway to fool perl into letting you do a:
> use Foo ($bar, 'baz', 'quux');
> ??
> Foo is only getting 'baz' and 'quux', the value of $bar is lost in the
> ether.
> I have tried many ways of trying to sneak it past but none seems to work...
use is syntactically equiavalent to
BEGIN
{
require Foo;
Foo->import(@argarray);
}
so $baz will need to be defined at compile time, ie. within its own BEGIN
block.
MBM
--
Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile)
Genius may have its limitations, but stupidity is not thus handicapped.
-- Elbert Hubbard
Re: tracking down why a module was loaded?;
On Wed, 27 Sep 2000, Matt Sergeant wrote: > On Wed, 27 Sep 2000, Matthew Byng-Maddick wrote: > Actually I think the people we need to get involved are the web site > builders - the larger companies offering dynamic web content creation. We > also need some more mainstream tools, the oft-requested "Zope-a-like" in > Perl. And it needs to be trivial to install (I'm not sure how likely that > is to be yet). This is roughly the kind of company I work for, so agreed. > > > PHP comes with a lot of ISP accounts for free with no extra cost. Java does > > > not yet, but I've started seeing ISPs starting to support Java in the low > > > end shared server accounts... > > Wow. I'm surprised, for the security reasons I've outlined above. But then > > I don't know much about PHP, really. > PHP can runs as a normal CGI, using suExec. So it's like advertising Perl > support. Right. > What would help mod_perl is a working sandboxing system, based on Safe and > SafeHole. I've advocated that idea before, but still don't have the time > to go and build it. With that sort of system, and ISP could easily trap or > prevent whatever they need to, and we could work with them to build up > secure proffessional installations. Schwern and I were discussing a new mechanism for a sandbox in Perl6, but unfortunately, I'm not sure how trivial it would be for Perl5, and also, you have to wonder whether any improvement will take away any performance advantage that mod_perl gives you. > However, I'm honestly not sure if the whole of mod_perl is "right" for the > majority of small fee ISP's. What the ISP's need is perhaps one of the > mod_perl modules, like Mason, Embperl or AxKit, or something like > that. Rather than letting users write PerlInitHandlers! Unfortunately I > have no idea how you might secure one of these modules, even though one is > my own. With difficulty. :) that wasn't helpful - but we really need a perl sandboxing mechanism. (perhaps if you can use safe to restrict open(), socket(), creat() etc, then you're doing the right thing) MBM -- UNIX is hot. It's more than hot. It's steaming. It's quicksilver lightning with a laserbeam kicker. -- Michael Jay Tucker
Re: tracking down why a module was loaded?;
On Wed, 27 Sep 2000, Gunther Birznieks wrote: > At 10:28 PM 9/26/2000 +0200, Alexander Farber (EED) wrote: > >Doug MacEachern wrote: > > > > modperl is the best kept secret on the net. Shame! > > > seems to generate plenty of list traffic for a "secret" ;) > >Don't you all think, that mod_perl isn't promoted enough and > >this will kill it someday, despite its technical goodness? Perl in general too, although I disagree with Stas on this one. (we discussed it in the pub on the first night of the conference). > >- There are no articles in the "mainstream" computer press > > (like cnet.com, www.ix.de, etc) about mod_perl. True, but then you need to explain the apache phenomenon first, and too many corporates want to deal only with corporates, making them feel a need to use IIS (with no mod_perl :/ ) > >- There are no benchmarks, comparing to Java/Coldfusion/whatever. None of these give you anything like the hooks that mod_perl gives you, though, so in general they are uncomparable. CF is pig-slow, and java - well. :) > >- I work at a big telco, and no one cares/knows here about > > mod_perl (except our intranet-webmaster, who still prefers > > PHP, since it makes him less trouble). Again, not comparable. I have written a quick hack auth system that hooks into uri translation, try doing that under any other system. > >- People, who have heard about mod_perl, are looking for servlet/ > > JSP-programmers, because mod_perl-coders are hard to find. perhaps. Mod_perl jobs are hard to find too... :/ > I unfortunately have to agree. perhaps. > Depending on where you go Perl programmers may be easier to find that Java > programmers, but finding an existing mod_perl programmer is not easy. It's > doable, but not easy. And in the end, the salaries for mod_perl programmers > are pretty high right now because of it -- so will a system really cost > less to develop in mod_perl than in Java if Java programmers are becoming > less expensive than mod_perl programmers? I have yet to see companies in this country really advertising for mod_perl jobs. The company where I currently work mentions it, but we're not really looking for it very hard, and if they've done any perl, we mostly teach them about the templating system we use (yes, yet another one, and going on CPAN soon :) > We all have to do our part to evangelize mod_perl more. I think ISPs are > really key here as I think I may have mentioned before. If you get the ISPs Well, I can tell you for a fact that mod_perl is running on http://www.bluepet.co.uk/ http://www.freedomjewellery.com/ http://www.londontransport.co.uk/ http://www.swisslife.com/ http://www.sciencephoto.com/ (the current version uses PerlRun, but the new version will be all mod_perl) > supporting and evangelizing mod_perl (and pre-installed mod_perl > applications) then you will get users using it and liking it. How many ISPs Yes, but the way it runs does raise problems for security > advertise support for mod_perl? How many without charging like US$100 more > a month on top of the normal account fees? This is difficult, due to the security issues. If you have client cgi, you can always use something like suEXEC or even something as complex as userv to run your cgi scripts. With mod_perl, the plugged in scripts can do anything that the webserver can, and you can (by writing a module that doesn't compile) break the entire webserver. > PHP comes with a lot of ISP accounts for free with no extra cost. Java does > not yet, but I've started seeing ISPs starting to support Java in the low > end shared server accounts... Wow. I'm surprised, for the security reasons I've outlined above. But then I don't know much about PHP, really. MBM -- UNIX is hot. It's more than hot. It's steaming. It's quicksilver lightning with a laserbeam kicker. -- Michael Jay Tucker
Re: open(FH,'|qmail-inject') fails
On Mon, 25 Sep 2000, Matt Sergeant wrote: > On Mon, 25 Sep 2000, Stas Bekman wrote: > > On Mon, 25 Sep 2000, Doug MacEachern wrote: > > > On Mon, 25 Sep 2000, Stas Bekman wrote: > > > > All you care about is to measure the time between email sending start and > > > > end (when the process continues on its execution flow). Why should one > > > > care about the details of internal implementation. > > > i only skimmed the first part of this thread, but assumed if you're > > > talking about performance, you'd want to compare the overall impact on > > > your system(s) of Net::SMTP vs. |qmail-inject. you cannot measure the > > > overall impact just using Benchmark.pm is all i'm trying to clarify. > > Yup, you are right. The overall impact is important as well. > > * Benchmark to see the responce times. > > * Send lots of emails and watch to compare the overall impact. > And unfortunately you'll also miss certain issues with that too, unless > its a live system, for example DNS lookup issues with sending to different > hosts. The joys of benchmarking code when the network is involved! Plus the minor fact that email systems seem highly non-deterministic in general :) We have some code for London Transport, which seems to be very random about when it actually sends the email. MBM -- Tell me, O Octopus, I begs, / Is those things arms, or is they legs? / I marvel at thee, Octopus; / If I were thou, I'd call me us. -- Ogden Nash
Re: Apache::Request server error??
On Mon, 25 Sep 2000, Sophokles Zafeiris wrote: > I' m trying to run the file_upload.pl. script, that can be found in the eg > directory of the Apache::Request source file. I've installed the > Apache::Request but I get the following server error : > Can't locate object method "new" via package "Apache::Request" at > /export/home0/www/cgi-bin/file_upload.pl.cgi line 8. > Can anyone help me?? The most obvious mistake is that you haven't 'use'd or 'PerlModule'd Apache::Request. This will often result in the above kind of error. MBM -- Tell me, O Octopus, I begs, / Is those things arms, or is they legs? / I marvel at thee, Octopus; / If I were thou, I'd call me us. -- Ogden Nash
Re: flock under win32
On Sun, 24 Sep 2000, Jim Winstead wrote: > On Sep 24, Gunther Birznieks wrote: > > The PerlCookbook seemed to indicate that mkdir is an atomic operation (both > > checks if the directory exists and creates it if it does not), so a locking > > mechanism based on mkdir would take care of this issue > > presumably. Removing the lock is a matter of removing the directory. > be careful, mkdir isn't really atomic under nfs. But NFS is Not a File System, so this doesn't matter :) The other possible atomic operation that things use for locking (emacs/netsacpe etc) is symlink() but you don't get that on win32, so not a great suggestion here, but you don't get NFS on win32 either. MBM (wittering before disappearing off to YAPC) -- I'm not even going to *bother* comparing C to BASIC or FORTRAN. -- L. Zolman, creator of BDS C
Adding directives using mod_perl
I'm following the description in Chap 8. of the Eagle Book for creating a module which adds configuration directives to Apache, however on my server version etc (see below), the first time through, the directive passes, but the directive gets rejected as an invalid command in the reload phase. Does the method in the Eagle book for defining directives no longer work, if this is the case, what can I do to have per-server variables such that I can use them at another modules initialisation time. MBM ---8<--- The server reports itself as Apache/1.3.11 (Unix) mod_perl/1.21 PHP/3.0.7 mod_ssl/2.5.0 OpenSSL/0.9.4 and [mbm@rigel]:~$ /usr/sbin/httpd -l Compiled-in modules: http_core.c mod_so.c mod_perl.c suexec: enabled; valid wrapper /usr/sbin/suexec [mbm@rigel]:~$ /usr/sbin/httpd -V Server version: Apache/1.3.11 (Unix) Server built: Feb 1 2000 21:17:00 Server's Module Magic Number: 19990320:6 Server compiled with -D EAPI -D EAPI_MM -D EAPI_MM_CORE_PATH="/var/run/httpd.mm" -D HAVE_MMAP -D HAVE_SHMGET -D USE_SHMGET_SCOREBOARD -D USE_MMAP_FILES -D USE_FCNTL_SERIALIZED_ACCEPT -D HTTPD_ROOT="/usr" -D SUEXEC_BIN="/usr/sbin/suexec" -D DEFAULT_PIDLOG="/var/run/httpd.pid" -D DEFAULT_SCOREBOARD="/var/run/httpd.scoreboard" -D DEFAULT_LOCKFILE="/var/run/httpd.lock" -D DEFAULT_XFERLOG="/var/log/httpd/access_log" -D DEFAULT_ERRORLOG="/var/log/httpd/error_log" -D TYPES_CONFIG_FILE="/etc/httpd/conf/mime.types" -D SERVER_CONFIG_FILE="/etc/httpd/conf/httpd.conf" -D ACCESS_CONFIG_FILE="/etc/httpd/conf/access.conf" -D RESOURCE_CONFIG_FILE="/etc/httpd/conf/srm.conf"
