Re: SQL log analyzer for Apache::DBILogger
On Tue, 6 Feb 2001, T.J. Mather wrote: > I have a script that reads the logs from the database and dumps it out > to a flat file in the standard format Apache uses when writing > access_log, then I run a program called webalizer on it. I actually > don't use Apache::DBILogger, but the database table is similar to the > table generated by Apache::DBILogger. I'd thought of doing that or modifying webalizer to work off the SQL tables. It seems to me like there's so much more possible with storing summary information in the database that's periodically refreshed and avoiding HTML generation except when the user requests it. I'm going to look at the code Ask recommended today. -- Those who cannot remember the past are doomed to buy Microsoft products.
Re: SQL log analyzer for Apache::DBILogger
On Mon, 5 Feb 2001, G.W. Haywood wrote: > On Mon, 5 Feb 2001 [EMAIL PROTECTED] wrote: > > > Sometime in the next month I need to embark on a log analyzer for the logs > > we've been accumulating for many moons via Apache::DBILogger. Has anyone > > made any effort to do such a thing already? I've dug around the web for a > > while and come up with zilch. > > There are certainly such things about, and you might like to have a > look at the thread "How to really bang on a script?" about the end of > October 2000. I found the thread ( http://forum.swarthmore.edu/epigone/modperl/binzhimwah ) and there was the mention of a log-related program called Daquiri. This is also mentioned at http://perl.apache.org/guide/download.html#Daquiri_yet_another_webserver . But none of that seems to have anything to do with log analysis. I'm trying to generate the information to keep the marketing types happy - page hits per day and such. -- Those who cannot remember the past are doomed to buy Microsoft products.
SQL log analyzer for Apache::DBILogger
Sometime in the next month I need to embark on a log analyzer for the logs we've been accumulating for many moons via Apache::DBILogger. Has anyone made any effort to do such a thing already? I've dug around the web for a while and come up with zilch. -- Those who cannot remember the past are doomed to buy Microsoft products.
Re: perl calendar application
On Sat, 6 Jan 2001, Blue Lang <[EMAIL PROTECTED]> espoused: > Eh, I'm prepared to take my lynching, but I'd just like to remind > everyone that there's nothing at all wrong with using PHP for things > like this. You'll never be a worse person for learning something new, > and the overheard required to manage a php+perl enabled apache is only > minimally more than managing one or the other. > > IMHO, it's just lame to rewrite something for which there exists > dozens of good apps just because of the language im which it is > written. You might as well be arguing about GPL/BSD/Artistic at that > point. I'm not going to get sucked into a language advocacy debate. But at least in my case, your comments are quite off base. A) I don't need to learn PHP. I learned PHP four or five years ago. The experience wasn't pleasant. My most recent experience with PHP was to port a PHP3 app from PostgreSQL to MySQL. It was very tedious and still unpleasant. (Yes PHP4 supposed finally has a real database interface like DBI, but most of the apps out there aren't written for PHP4.) B) Simplicity is good. The fewer things running inside my web server to meet my needs the better. This is a security issue as well as an ease of maintenance issue. C) We are organizationally committed to perl. Our employees and contractors are not expected to know PHP and most are quite happy that I don't make them write in PHP. A long term strategy of keeping my programmers (including myself) happy seems like a good thing. D) (And I think this is the most important point of all.) There are good reasons for deciding on a language and sticking with it if your hope is to build something large. (Trying to build a garden with three different climates and have it work as one big garden is a huge challenge and certainly not worth pursuing if you're trying to maximize production.) My hope is to take the calendar portion of things and build upon it. Ultimately I'd like to have something that has the functionality of Outlook plus bugzilla. I've gotten several emails privately with offers of source for various "in progress" projects that people say they're willing to make open source. I will keep the list informed. -- Those who cannot remember the past are doomed to buy Microsoft products.
Re: perl calendar application
On Fri, 5 Jan 2001, Jim Serio wrote: > Why not just write one to suite your needs? If you want one > so tightly integrated to your other products, it's almost > always better to custom write it yourself. Or hack up a freeware > version. I'd really like to hack on a freeware version, but it'd be nice to start with one that at least had some decent sheduling features so I could use it in while tearing it apart. I've gotten comments on and off the list and I'm going to do a little more research. I will let the list know what I come up with. -- Those who cannot remember the past are doomed to buy Microsoft products.
perl calendar application
I've looked around the web for perl-based calendar applications for several hours. There are a significant number out there -- I've personally checked out a dozen, but they are generally pretty pathetic. Even most of the ones you can pay for are ugly and have very limited functionality. WebTrend and Calcium are decent, but cost $400 for our situation and any modifications I make would be unsharable. (This presumes that their source code is even legible and in any shape to hack on.) Am I totally missing something? More generally, does anybody have a page of mod_perl business applications? Even more generally, are there any mod_perl applications out there? Neither modperl.org and take23 had much I could find. modperl.org had a page of 'products' that listed some modules, but nothing that I would call an end-user application. I think some of the free web mail programs (?atmail) and forum packages use or can use mod_perl, but how would anybody know that from looking at any of the modperl sites? This is yet another area where the legions of PHP developers are whooping up on us and that's rather depressing. I personally think PHP sucks as a language and I'd rather not have it running on my servers. I certainly don't want to be stuck hacking PHP to add features or fix bugs. But perl folks don't seem to be churning out as many nice SQL-enabled web applications. (And I'd really like to get off Windows for my calendar.) BTW - One notable exception that looks neat that I saw on the mysql mailing list today is maccess: http://www.meopta.com/products/software/maccess/ But it's not aimed at end users. Sigh. -- Those who cannot remember the past are doomed to buy Microsoft products.
Re: Apache 1.3.14 and Mod_Perl
On Wed, 18 Oct 2000, Roger Espel Llima wrote: > It looks to me like perl.apache.org is explicitly blocking wget > requests. If I do the request manually with netcat, sending the same > headers wget sends, it fails: Why is wget considered so evil? -- "The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd edition, June '72
Re: Apache 1.3.14 and Mod_Perl
On 17 Oct 2000 Robin Berjon <[EMAIL PROTECTED]> wrote: > At 23:59 16/10/2000 -0700, Annette wrote: > > How do I install the latest version of Mod_Perl? Every time I try to > > install it I receive a message stating I need Apache 1.3.0 and then > > it aborts. I tried Mod_Perl version 1.19, 1.21, and 1.24 and I > > receive the same error. > > You need 1.24_01 to work with Apache 1.3.14 because of a tiny bug that > prevents mod_perl's setup from parsing Apache's version number > properly. You can grab it from > http://perl.apache.org/dist/mod_perl-1.24_01.tar.gz. Alternatively, > you can play with Makefile.PL to get it to return the version number > you know is true, but it's probably faster this way. Why can't I download it with wget? [root@wakko /root]# wget http://perl.apache.org/dist/mod_perl-1.24_01.tar.gz --15:56:47-- http://perl.apache.org:80/dist/mod_perl-1.24_01.tar.gz => `mod_perl-1.24_01.tar.gz' Connecting to perl.apache.org:80... connected! HTTP request sent, awaiting response... 403 Forbidden 15:56:47 ERROR 403: Forbidden. I was able to download it with lynx, however. Wacky. -- "The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd edition, June '72
Re: open(FH,'|qmail-inject') fails
On 7 Sep 2000 Randal L. Schwartz wrote: > This is neither necessary nor sufficient. Please stop with this > nonsense. An email address can have ANY CHARACTER OF THE PRINTABLE > ASCII SEQUENCE. An email address NEVER NEEDS TO GET NEAR A SHELL, so > ALL CHARACTERS ARE SAFE. Clear? Man, if I see ONE MORE script that > checks for a "legal email", I'm gonna scream. Matter of fact, I > already did. :) I have an immense amount of respect for you Randal, but I think you're generalizing a bit much here. There are a number of cases where checking an email address' validity makes perfectly good sense. The most obvious is just plain human-computer interface design. If I can give the user a message "hay, that's not a valid email address" instead of them wondering why they never received an email, that's makes the interaction more intuitive. Many, many scripts end up calling sendmail to send mail. I'm not for a moment going to applaud that method, but it does mean that shell escapes in an email address will cause problems. -- If you're not part of the solution, you're part of the precipitate. - Steven Wright
