RE: process priorities and performance
Sorry for the late reply - been away for a bit. Everything I've read as an SA (for Solaris at least - though I would expect the other *nices to be similar) was to never set a user space (non O/S) process to less than -15. Other than that, it's another of those YMMV, measure before and after, and if it helps great. Trying to second guess process schedulers is a tricky business though, and you really need to intimately know how your system behaves before trying it. --Jim -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 06, 2002 9:55 PM To: [EMAIL PROTECTED]; Alexey Zvyagin Subject: process priorities and performance Alexey Zvyagin has suggested a use of Unix process priorities to improve the performance of the web services during the peak hours: Alex writes: - The Unix priorities help to improve perfomance : The MySQL server has a -20 Unix priority: /usr/bin/nice -n -20 /usr/local/bin/safe_mysqld --user=mysql The backend apache server has the -10 priority: /usr/bin/nice -n -10 /usr/local/apache_new/bin/apachectl start /dev/null The frontend apache server has the -5 priority /usr/bin/nice -n -5 /usr/local/accel/bin/apachectl start /dev/null The CPU priorities help to handle an increased traffic on the overloaded server. - Has any of you experimented with this technique and found it useful? If you do we could add the tip to the guide's performance chapter. But we need some meat to have a useful section. Thanks. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
New mod_perl site and oddness with IE
Has anyone else had problems with this particular page under IE (6.0.2600 under XP) being extremly slow to update when paging up/down? It works fine under Mozilla, and it's not a memory or cpu issue (checked with task manager already). And when I say slow, I mean a simple down cursor causes the visible portion of the page to get painted in 4 noticble steps/chunks. An older version I tracked down with Google (http://www.apache.jp/perl/guide/performance.html) which is also 300K+ doesn't have the same problem - just to show that it's not purely the raw size of the page that is the problem. Just a little feedback for the new site (which is great, btw). If it's just me with the problem, I'll go find a rock to hide under. :) --Jim A number of the most common sources of memory growth are explained in the guide: http://perl.apache.org/docs/1.0/guide/performance.html#Improving_Perform ance_by_Prevention - Perrin
RE: PerlSetVar WhatEverSecure
It's not the prettiest in the world, but try this (see attached file). If anyone sees room for improvement, please, chime in. It's working fine on the intranet site I run at work - and I haven't tried to make it any better since it's working as is. You use this script instead of the loginscreen method of AuthTicket. It uses the http-equiv refresh when switch schemes since going from https to http causes most browsers to popup a warning about getting redirected to an insecure site. Here are my relevant httpd.conf settings: PerlSetVar realmTicketLoginHandler /LOGIN PerlSetVar realmTicketLogoutURI / PerlSetVar realmLoginScript /login Alias /login /v01/data/web/auth/login Location /login Options ExecCGI SetHandler perl-script PerlHandler Apache::Registry /Location Location /LOGIN IfDefine SSL SSLRequireSSL /IfDefine SetHandler perl-script PerlHandler Apache::AuthTicket-login /Location --Jim -Original Message- From: Brian Reichert [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 1:13 PM To: Michael Schout Cc: Brian Reichert; [EMAIL PROTECTED] Subject: Re: PerlSetVar WhatEverSecure On Thu, Jun 13, 2002 at 10:40:18AM -0500, Michael Schout wrote: Brian Reichert wrote: Location /formscript/login PerlSetVar FormScriptSecure 1 AuthType Apache::AuthTicket ... /Location But, in each case, my login program is server in the clear. What am I missing? THe authnameSecure setting only affects the cookie. If you want to forbid access to the login form from non-ssl, there are verious ways to do that. One way would be to add SSLRequireSSL that block (assuming your using mod_ssl). Apache::AuthTicket says: Finally, by using the Secure mode of Apache::AuthCookie, the ticket is not passed over unencrypted connections. Passed in what direction? It would only go server-client if the client made a SSL request. With the 'FormScriptSecure' as I have it above, I _can_ log in over a non-encrypted channel, so clearly it's not enforcing the 'secure' criteria... (Still reading up on cookies...) I suppose my real question is: How can I intercept a unencrypted request for a protected document, but have the login form be submitted over an encrypted channel? (Thanks for the feedback, by the way...) Regards, Mike -- Brian 'you Bastard' Reichert [EMAIL PROTECTED] 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path login Description: Binary data
[OT] Q:MVC and FuseBox methodology A?
Does anyone know how MVC maps to the fusebox methodology? I haven't used it under PHP, but the adaptation to ASP applies almost directly to Apache::ASP, and at least seems like it's well thought out and practical. Maybe it's really just the Controller aspect of MVC. I'm still trying to wrap my head around this too. Wonderful knowledge transfer going on, BTW! --Jim
RE: Invoke PHP scripts?
How about using php in cgi mode and using `php scriptname` from within perl to capture the output? Not the best performance-wise, but it would do what you want, I think. Jim -- James Helm - Solaris System Administrator [EMAIL PROTECTED] WNS National Operations - Core Services [EMAIL PROTECTED] ATT Wireless Services Inc. (425) 288-4395 (Desk) 3555 Monte Villa Pkwy, Bothell, WA 98021 (206) 618-0438 (Cell) -Original Message- From: Ryan Thompson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 28, 2002 8:48 PM To: [EMAIL PROTECTED] Subject: Invoke PHP scripts? Hi there, Apologies if this has been asked 2^32 times, but I couldn't seem to find anything in the archives or on the web which would solve my problem. I'm developing a large-ish web site in which I would like to use a combination of mod_perl (90%) and PHP (10%). I have run into a roadblock trying to include the output of a PHP script from a mod_perl script. This would do fine: my $r = Apache-request(); return $r-lookup_uri($url)-run; But (and I am familiar with why this happens) run() dumps the results to STDOUT, so the final HTML does not come through in the correct order. I tried to use Apache::SSI in this manner: my $r = Apache-request(); my $ssi = Apache::SSI-new($contents, $r); return $ssi-get_output(); (Where $contents is the raw PHP source), but, possibly because of some Content-type mixup, the output is returned as expected (i.e., not dumped to stdout), but the PHP source is not interpreted. So, in short, I need another way to invoke a PHP script from my mod_perl application... exactly what !--#include virtual=... -- would do. Help..? :-) - Ryan -- Ryan Thompson [EMAIL PROTECTED] SaskNow Technologies - http://www.sasknow.com 901 1st Avenue North - Saskatoon, SK - S7K 1Y4 Tel: 306-664-3600 Fax: 306-664-3630 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
RE: Persistent Net::Telnet Objects
It it possible that KeepAlives are what's making this work? If the user is active enough, in theory, they would always be connected to the same httpd process... Jim -- James Helm - Solaris System Administrator [EMAIL PROTECTED] WNS National Operations - Core Services [EMAIL PROTECTED] ATT Wireless Services Inc. (425) 288-4395 (Desk) 3555 Monte Villa Pkwy, Bothell, WA 98021 (206) 618-0438 (Cell) -Original Message- From: French, Shawn [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 1:50 PM To: 'Perrin Harkins' Cc: [EMAIL PROTECTED] Subject: RE: Persistent Net::Telnet Objects Perrin wrote: I can't see how it could be working now That makes two of us! You're probably opening new telnet connections from each apache process. I know that I am not since they are continuing to log to the same dump file, and my code (as stated in previous message) simply goes to the hash and takes the object. That won't work, since you can't control which process will handle requests from the client. OK, is there a way to make sure that there is just one process? This site is not for milions of users, only 10 - 20. I'm sure that others have had to keep persistent sockets and/or filehandles on their server, and I really don't see how my problem is any different... Please, can anybody help me? Shawn
IE login script woes
(I'm cc'ing the list in hopes that maybe this will help others when deailing with custom error documents that aren't working under IE - there have been a few people having problems with login pages and some of the Apache::Auth* modules, and maybe this will help. If it's old news to everyone, I apologize) Michael, I found something relating to IE (ain't MS grand!) and custom error pages not appearing under the right (wrong?) conditions... Basically, if friendly http error messages is turned on for IE 5.X+, your custom error page has to be over a certain size in order for IE to display the original and not it's own friendly version. The defaults for IE6.0 (don't have an older one to test with) are anywhere from 256 to 512 bytes, depending on the error code returned. I had a user who was having this problem on my site. Took me a while to figure it out too, since I always turn the pesky thing off on my systems. I eventually remembered there was a way to override them, and a quick search on MS Support site turned up the answer. Anyway, that alternate login script I sent to you needs a minor tweak - basically adding 512 spaces (as simple as ' 'x512) to both the refresh page and the actual login page, so as to prevent the intelligent code in IE from hiding the pages. It shouldn't be a problem for most login pages, but the refresh page I'm using to make http-https-http logins work didn't have anywhere near the 512 bytes needed. Hope that's useful to you somehow. Later, Jim
[RFC] Apache::AuthTicketPlus
Title: Message
I've subclassed
Apache::AuthTicket with a 'Require group 'authorization handler, since
neither AuthTicket nor AuthCookie included it (though AuthCookie does have the
hooks for itwhich I took advantage of).
I also added a
'Require not ' hander. I wanted to be able to excludeone or two authenticated
users (like guest) from certain areas while still being able to 'Require
valid-user'. Much easier than having to remember to add every
authenticated use to a group when I only want to exclude one or two users.
If AuthCookie ever changes from requiring all check to pass to just a single
check, this will break. (See Apache::AuthCookie authorize()section for
comments on ALL vs. ANY.)
Example:
Require not group
Require not user
Also, I had to
implement myown 'user'authorization methodsince
Apache::AuthCookie embeds it directlyinto the main authorization
method.Mymethodonly gets called bythe 'not' method
when applicable. I could have just put the code directlyin the not
method, but then anyone subclassing my module would have the same
problem...
Feel free to
do whatever you want with the code... Comment/criticism welcome - especially on
the initmethod. I'll post to CPAN if anyone thinks it's worth
it. I'd gladly accept integrating
this directly into AuthTicket if the maintainer wishes (Michael Schout?).
I'm not crazy about the name, but it has to be called something - suggestions
welcome.
Thanks,
Jim
---snip---
package
Apache::AuthTicketPlus;
use
strict;
use vars qw($VERSION
@ISA %DEFAULTS);
use
Apache::Constants qw(FORBIDDEN OK);use Apache::AuthTicket
qw();
@ISA =
qw(Apache::AuthTicket);
$VERSION =
'0.01';
$DEFAULTS{TicketGroupTable} =
'groups:grpname:usrname';
sub init {
my ($self, $r) = @_;
$self-SUPER::init($r);
map {
$self-{$_} = $self-_get_config_item($r, $_); }
keys %DEFAULTS;
}
sub not {
my ($self, $r, $args) = @_; $self
= $self-new($r) unless ref $self;
my ($requirement, $sub_args) = split(/\s+/, $args,
2);
my $rv = $self-$requirement($r, $sub_args);
return ($rv == OK) ? FORBIDDEN : OK;
}
sub user {
my ($self, $r, $args) = @_; $self
= $self-new($r) unless ref $self;
my $user =
$r-connection-user; my $req_user = (split
/\s+/,$args)[0];
return ($user eq $req_user) ? OK : FORBIDDEN;
}
sub group {
my ($self, $r, $args) = @_; $self
= $self-new($r) unless ref $self;
my $group = (split /\s+/,
$args)[0]; my $user = $r-connection-user;
my $dbh = $self-dbh; my
($_table,$_group,$_user) = split(/:/,
$self-{TicketGroupTable}); my $query =
qq{ SELECT COUNT(*) FROM
$_table WHERE $_group = ? AND
$_user = ? };
my $rows = 0;
eval { my
$sth =
$dbh-prepare($query);
$sth-execute($group,$user);
$sth-bind_columns(\$rows);
$sth-fetch; }; if ($@)
{
$dbh-rollback; die
$@; }
return $rows ? OK : FORBIDDEN ;}
1;
RE: [RFC] Apache::AuthTicketPlus
I don't know, but I'm sure someone here will have the answer... Jim -Original Message- From: Steven Lembark [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 12, 2002 5:50 PM To: Jim Helm Subject: Re: [RFC] Apache::AuthTicketPlus Example: Require not group Require not user Q: do you know how to set multiple require xxx entries in perl sections? I've tried every structure I can think of w/o any success. If I could figure that out the modlue would be a big help. thanx. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
RE: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
Strictly speaking _ is (was?) an illegal character for DNS names. I used to go round-n-round with a fellow sysadmin about that fact, and that we shouldn't use _ in hostnames. Jim -Original Message- From: Rafael Caceres [mailto:[EMAIL PROTECTED]] Sent: Monday, May 06, 2002 10:23 AM To: Peter Bi Cc: [EMAIL PROTECTED] Subject: Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood) Peter: Squid complains about http://mod_perl.home.att.net which it says contains an invalid character (_), so I can't access it. Rafael Caceres At 10:58 PM 5/3/2002 -0700, you wrote: Try my Apache::AccessCookie too. It provides the same ticketing interface for many different authenticating methods such as LDAP, IMAP, ftp, SMB, and (of course) DBI, plus a number of useful features. One can simply implement her own mechanism too. It can be downloaded at http://mod_perl.home.att.net. BTW, I tried to register the module in CPAN, but was kind of lost in the middle. Peter Bi - Original Message - From: Jim Helm [EMAIL PROTECTED] To: 'Fran Fabrizio' [EMAIL PROTECTED]; 'F.Xavier Noria' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, May 03, 2002 10:08 PM Subject: RE: problems setting up Apache::AuthCookieDBI (solved but no fully understood) p.s. FWIW, I ended up using Apache::AuthTicket instead - has a feature I wanted (timeout, not just expiry), which CookieDBI didn't have), and it worked as documented with zero hassle... Jim -Original Message- From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 6:38 AM To: F.Xavier Noria Cc: [EMAIL PROTECTED] Subject: Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood) Does the server load the module that way? It's beyond my expertise at this point but my experience would indicate that it does not work this way since I have PerlModule before the PerlSetVar and it works fine. -Fran
RE: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
I was having the exact same problem 2 days ago... Could it be a difference in static vs. dso? I'm running mod_perl as a dso - how about you two? I did basically the same troubleshooting (added some log_error statements to the BEGIN block) and noticed the same thing - SecretKey file wasn't getting read. For some reason the dir_config hash is empty (completely, not just of *DBI_* entries) when that BEGIN block is executed. I don't know enough about apache internals to understand why moving the PerlModule line to the end of the PerlSetVar *DBI_* directives makes a difference, but it does (for some at least). Jim -Original Message- From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 6:38 AM To: F.Xavier Noria Cc: [EMAIL PROTECTED] Subject: Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood) Does the server load the module that way? It's beyond my expertise at this point but my experience would indicate that it does not work this way since I have PerlModule before the PerlSetVar and it works fine. -Fran
RE: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
p.s. FWIW, I ended up using Apache::AuthTicket instead - has a feature I wanted (timeout, not just expiry), which CookieDBI didn't have), and it worked as documented with zero hassle... Jim -Original Message- From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 6:38 AM To: F.Xavier Noria Cc: [EMAIL PROTECTED] Subject: Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood) Does the server load the module that way? It's beyond my expertise at this point but my experience would indicate that it does not work this way since I have PerlModule before the PerlSetVar and it works fine. -Fran
Lessons learned using PREFIX,LIB and UNINST=1 as root
LESSON: Don't do all 3 of the following for any core modules (unless you know you want the original version removed from the core install): a) remove old versions during install (using UNINST=1) while b) installing modules to an alternate location (using PREFIX=.../LIB=...) as c) root (or same user as the owner of the core installation) Any two alone should be safe, but all 3 can be hazardous to your sanity! STORY: I was having problems a couple of weeks ago getting mod_perl make test to run - both the test programs and apache itself were complaining about CGI.pm not being found. I tried modifying Makefile.PL and httpd.conf-dist and adding local.pl to t/conf to make it work again (which it did but wasn't necessary as it turns out). Well, today I found the source of all my problems...Doh! They were self inflicted. Apologies to all on the list for my getting annoyed (privately) that no-one else had had this problem, or had a clue as to how to fix it. I was using cpan to install modules as root, and had UNINST=1 set, which had the (designed) side effect of uninstalling CGI.pm from the core distribution when I installed the latest version into my alternate location. From now on I'll leave the core install untouched, and install all my add-on modules as a non-root user just to be safe. Once I reinstalled perl (just re-ran last make install from source tree), the mod_perl test suite ran just fine (unmodified version 1.26). I also added PREFIX and LIB to my makepl_args.mod_perl file rather than having to remember to add them to the perl Makefile.PL line for future mod_perl builds. The thing that clued me into my problem was that CGI.pm is a core module (which I was reminded of by skimming thru the Programming Perl/camel book today). CGI.pm should therefore ALWAYS be available (safe assumption I suppose), and it wasn't in this case - so I had done something wrong. It didn't take long (about 5 seconds) to figure out WHY is wasn't in the core any longer. I've never seen anything warning against doing things this way (root, UNINST=1 AND PREFIX/LIB) (that I remember at least) so if this is already well-known and documented, please, make me $humble++, and enlighten me. I understand it - now - I'm just hoping it's an obvious in hindsight only type of thing. Thanks, Jim
RE: Content management systems
Found this site, which has just about every major perl based cms I've run across listed, plus lots more. http://www.clueful.com.au/cgi-bin/cmsdirectory/browse/Products:Free%20sy stems Good luck, and us know what you pick and how it goes. Jim -Original Message- From: claudioprodigy.net.mx@tcp_intranet-daemon [mailto:claudioprodigy.net.mx@tcp_intranet-daemon] On Behalf Of Claudio Garcia Sent: Tuesday, April 09, 2002 1:47 PM To: Maarten Stolte Cc: Drew Taylor; Aaron Ross; mod_perl list Subject: Re: Content management systems Metadot is being used a lot in Schlumberger and Sema intranet websites (Sema is a large European IT company) , among many other clients. It's also being used in a big French ceramics company called St. Gobain. The Open Source version is currently lagging behind our latest (closed-source) release by about three or four months. Our closed-source version is comercially available and comprises, basically, the open-source framework plus a number of useful add-ons. We also do custom additions to the framework (in fact tailoring the software is our main business). Installing Metadot can sometimes get complicated, but is usually a straightforward process. I think Metadot internals are easy to learn and customize, as we have been improving them constantly for the last year. If you know your way around mod_perl and object oriented Perl you should be able to tailor Metadot to your liking in little time. You can also choose to program your own add-ons using the APIs we provide for that. Hope that helps, Claudio Metadot bills itself as a portal product. I've even installed it briefly in the past, and it seemed relatively easy to setup customize. http://www.metadot.com/ The developer site is at http://www.metadot.net/. wow...this looks great, anybody actually use it? Maarten
