Re: New mod_perl Logo
I really don't think a catchy name would have helped in your case. Your management, like many others, prefer to manage by magazine. And we all know who is in all the magazines. If your management did not like Perl, why not try java, c or php? If your management did not like MySQL, why not Postgres, Sybase, Oracle, Informix? My point is it would not matter. The issue was not Perl, the real issue was that it was not a Microsoft product. - Original Message - From: Chris Thompson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 29, 2002 5:29 PM Subject: Re: New mod_perl Logo On Tue, 29 Jan 2002, Jonathan M. Hollin wrote: Ideas for logos, banners, powered by-type buttons are all welcome. Well, I'd like to just throw one idea into the mix. It's something that's bugged me for a long time, no better time than the present. mod_perl is a lousy name. There, I've said it. For any number of reasons, perl does now and will always face an uphill struggle in any Enterprise application. For example, at my place of employment, we just went through a rather arduous task that I fought against and lost. We had a production site that handled a decent amount of traffic. Apache, mod_perl, Linux and MySQL. It ran and ran with almost no intervention. The management team of the company that bought us a year ago had been trying to force a change in the product by throwing up various arguments, which were always false. (MySQL doesnt support Transaction, Yes it does. But they arent atomic., Yes they are. Well, you can't roll them back., Yes you can.) In the end, I lost. From October to mid January they set about taking our fully functional product and replatforming it to Win2k/IIS/ASP+VB/MSSQL. The final reason? Responsible enterprises do not use perl. mod_perl needs a name. Something marketable, something catchy. The java folks learned that a long time ago. Their systems are called Tomcat/Jakarta and Cocoon and Resin. THAT, in my opinion, is what should happen for mod_perl 2.0. It should be Adirondack or Orwell or any other generic, innocuous name. Even MonkeyButter v1.0 is probably a better deal than mod_perl. As for logos, Avoiding Camels or Eagles is a requirement. I don't blame ORA for requiring the trademark notices, the twisted concepts of US trademark law REQUIRE them to do that. The first time they didnt, they could lose their trademark. But we should have a mascot that makes sense and is OURS. Linux has the penguin, OpenBSD has the blowfish, the other BSD's have the devil. Those images are clearly associated with those products, and can be used WITHOUT corporate approval. -- ___ Chris Thompson
PerlAccessHandler and LimitExcept question.
When I put a PerlAccessHandler inside a LimitExcept, it does not seem to work within the LimitExcept. It behaves as if there was no LimitExcept. For instance, I wrote a simple access handler for webdav that only allows users into their own directories. So user joe can only get to /home/joe/public_html with webdav and all users are in the same password file. I also don't need to setup every users' directory like this: Directory /home/joe/public_html ... require user joe /Directory Instead I was able to do this: Directory /home/*/public_html DAV On AllowOverride None Options None LimitExcept GET HEAD POST OPTIONS Order allow,deny Allow from all AuthName WebDav AuthType basic PerlAccessHandler Apache::AuthByDir require valid-user AuthUserFile /home/httpd/users/passwd /LimitExcept /Directory My AuthByDir simply parses the user from the file name requested and DECLINEDs when the user name enterred is the same as the user directory in the filename. That way basic authentication will get called, otherwise it returns FORBIDDEN. The LimitExcept is so that visitors do not need to authenticate, but web dav users do. Without my PerlAccessHandler, normal visitors don't get prompted for user and password. But when I put my access handler in as above, every visitor gets prompted for username and password. Is this just the way is it or might I have some other bug? I guess I could check for the GET, HEAD, etc., in my access handler but that would mean my handler would get called for the majority of the requests. -- Joe Pearson Database Management Services, Inc. 208-384-1311 ext. 11 http://www.webdms.com
Re: [OT?] Cross domain cookie/ticket access
I thought you could set a cookie for a different domain - you just can't read a different domain's cookie. So you could simply set 3 cookies when the user authenticates. Now I'm curious, I'll need to try that. -- Joe Pearson Database Management Services, Inc. 208-384-1311 ext. 11 http://www.webdms.com -Original Message- From: Aaron Johnson [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thursday, September 07, 2000 10:08 AM Subject: [OT?] Cross domain cookie/ticket access I am trying to implement a method of allowing access to three separate servers on three separate domains. The goal is to only have to login once and having free movement across the three protected access domains. A cookie can't work due to the limit of a single domain. Has anyone out there had to handle this situation? I have thought about several different alternatives, but they just get uglier and uglier. One thought was that they could go to a central server and login. At the time of login they would be redirected to a special page on each of the other two servers with any required login information. These pages would in turn return them to the login machine. At the end of the login process they would be redirected to the web site they original wanted. This is a rough summary of what might happen - domain1.net - user requests a page in a protected directory. They don't have a cookie. They are redirected to the cookie server. This server asks for the user name and pass and authenticates the user. Once authenticated the cookie server redirects the client to each of the other (the ones not matching the originally requested domain) domains. This redirect is a page that hands the client a cookie and sets up the session information. domain2.net gets the request and redirects the user to a page that will return them to the cookie machine which will add the domain2.net to the list of domains in the cookie. And then the process will repeat for each domain that needs to be processed. Am I crazy? Did I miss something in the documentation for the current Session/Auth/Cookie modules? I did some hacking of the Ticket(Access|Tool|Master) Example in the Eagle book, but the cookie limit is keeping it from working correctly. ( BTW: I already use it for a single server login and it works great. ) Any information would be appreciated. Aaron Johnson
Re: Hi ppl need some help
I've noticed that my httpd's will start thrashing whenever I get an syntax
error in a mod_perl program.I'm very careful to do a perl -c program
before I try running it from the web or else I will need to stop/start the
web server.
Joe Pearson
Database Management Services, Inc.
208-384-1311 ext. 11
http://www.webdms.com
-Original Message-
From: FEITO Nazareno [EMAIL PROTECTED]
To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
Date: Wednesday, May 03, 2000 8:46 AM
Subject: Hi ppl need some help
Hi ppl, my home webserver still eating all the memory, it swap very much,
the disk light is On all the time and the system almost freeze until I stop
the webserver... here are some parameters of my configuration
Timeout 150
keepalive on
MaxKeepAliveRequest 70
keepAliveTimeout 15
minspareservers 3
maxspareservers 6
StartServers 2
MaxClients 20
MaxRequestPerChild 30
and mod_perl
Alias /perl/ /home/www/perl/
Location /perl
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlSendHeader on (sometime this is set to oFF)
/Location
And I have another problem too... i´m using a handler in my perl scripts is
like this:
handler($s,0)
sub handler ($$)
{
if ($s = 0)
{
print AskForAName();
}
elsif
{
$name=$q-param (´name´);
bla bla bla
}
}
well when I run this script from the webserver like this:
http://192.168.0.20/perl/script.pl?s=0
the error_log of apache say me something like...:
PROTOTYPE MISSMATCH: root:Apache::Registry::handler vs ($$) error...
something like that... i don´t know what i´m doing wrong, please help!!
any help will be very very precied! thanks buddies.
Nazareno.
Perl Programmer www.obsequie.com
[EMAIL PROTECTED]
Re: Another IE5 complaint
Sorry everyone...I thought this was dead also. I sent this to list the couple of months ago, it got sent again by mistake. I did not realize it was also sitting in my out box on my home computer. I recently made a change in sendmail to allow that computer to relay through our office server, then the mail went out. Joe Pearson -Original Message- From: Tim Tompkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Tuesday, November 23, 1999 10:10 PM Subject: Re: Another IE5 complaint Is this horse dead yet?!? I don't know, but let's kick it an' see if it squeels! Thanks, Tim Tompkins -- Programmer / IS Technician http://www.arttoday.com/ - Original Message - From: Stephen Anderson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 23, 1999 4:10 AM Subject: RE: Another IE5 complaint -Original Message- From: Rod Butcher [mailto:[EMAIL PROTECTED]] Sent: 23 November 1999 10:20 Cc: [EMAIL PROTECTED] Subject: Re: Another IE5 complaint Am I the only battling service vendor who actually feels good when somebody bookmarks my website ? I can absorb the overhead of accesses to a favorites icon. This may be a security hazard for the client, but I detect a holier-than-thou attitude here against M$. Will somebody tell me why this M$ initiative is bad, other than for pre-determined prejudices ? Rgds Rod Butcher Speaking as someone who works for an ISP, anything that obscures (by volume) genuine errors is a Bad Thing. The error log is a useful diagnostic tool only if you can see the errors. Yes, you could filter out the requests before examining the file, but the point is MS is making more work for people by being thoughtless. Further reasons it's a bad idea * It's not standard * It's a specific solution to a general problem, and therefore fragile (i.e. it breaks too easily) * It's a quick hack rather than a genuine initiative (which would take effort) Stephen. -- disclaimer type="std" The views expressed are personal and do not necessarily reflect those of Planet Online Limited. /disclaimer
