Re: Regarding the PerlAuthenHandler[2]
You should see this one. Compiled-in modules: -- snip -- mod_perl.c see http://perl.apache.org/guide/install.html for how to build mod_perl against apache Jeff On Fri, May 11, 2001 at 04:50:21PM -, qazi Ahmed wrote: Hi.. When i am giving the command: ./httpd -l in the bin directory of apache i get the following details: rad-sun-2 ./httpd -l Compiled-in modules: http_core.c mod_env.c mod_log_config.c mod_mime.c mod_negotiation.c mod_status.c mod_include.c mod_autoindex.c mod_dir.c mod_cgi.c mod_asis.c mod_imap.c mod_actions.c mod_userdir.c mod_alias.c mod_access.c mod_auth.c mod_setenvif.c suexec: disabled; invalid wrapper /export/home/ats/test-tools/ats/guts/apache/bin/suexec rad-sun-2 What should i get actually to confirm that mod_perl is installed properly. And further if suexec is an error, please reply by sending the solution to overcome it. Thanks and regards Qazi - Original Message -- Owen Boyle [EMAIL PROTECTED] wrote: To:qazi Ahmed [EMAIL PROTECTED] From:Owen Boyle [EMAIL PROTECTED] Date:Fri, 11 May 2001 14:01:11 +0200 Subject: Re: Regarding the PerlAuthenHandler qazi Ahmed wrote: Syntax error on line 547 of /export/home/ats/test-tools/ats/guts/apache/conf/httpd.conf: Invalid command 'PerlRequire', perhaps mis-spelled or defined by a module not included in the server configuration Are you *really* sure you have installed mod_perl? Try ./httpd -l to list the modules and check.. Rgds, Owen Boyle. _ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com Thanks, Jeff -- | Heres milk in your eye.. | | and on your shirt, shorts, couch, and floor. | |- Matthew Scott Sheffield | | (@ six months old)| -- | Jeff Sheffield | | [EMAIL PROTECTED] | | AIM=JeffShef ICQ=4340529 Yahoo=jsheffieus | | NowDocs http://www.nowdocs.com (day gig) | --
Re: ticketsystem
I noticed that the MS Explorer remembers both username and corresponding password, making the cookie based authentication system useless. (closing and reopening all windows does not help) pure evil..!! (IMHO) I don't use exploder very often... is this really true..?? On Wed, Jan 10, 2001 at 11:08:37PM +0100, [EMAIL PROTECTED] wrote: Hi I am using a cookie based authentication scheme. Cookie expires therefore login again. ( like the ticket master example in O'reilly's.) I noticed that the MS Explorer remembers both username and corresponding password, making the cookie based authentication system useless. (closing and reopening all windows does not help) So using the default browser preferences is no good. Does anybody know which browser preference is involved here. Arnold Thanks, Jeff | If you go to the zoo, always take somethin' to feed the animals | | even if the signs say "Do not Feed Animals." It wasn't the | | animals that put them signs up. | | -- Forrest Gump | | -- Winston Groom | ---- | Jeff Sheffield | | [EMAIL PROTECTED] | | AIM=JeffShef |
Re: perl calendar application
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.) I agree with this... however if you have to play in that garden because half of you developers are PHP developers and have are perl developers. then take a look at this module. Apache::ProxyStuff I believe the module was originally written to play will with domonio apps. We used it to have a mason back ended server playing with a php back ended server and then unifying the site. This is really cool when you are "lazy" and you wan to install some app that already written. no more Gosh darn ... that is just what I need guess i will have to port it. Jeff On Sun, Jan 07, 2001 at 11:38:24AM -0500, [EMAIL PROTECTED] wrote: 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. -- /chris Those who cannot remember the past are doomed to buy Microsoft products. Thanks, Jeff --- | "0201: Keyboard Error. Press F1 to continue." | | -- IBM PC-XT Rom, 1982 | --- | Jeff Sheffield | | [EMAIL PROTECTED] | | AIM=JeffShef| ---
Re: the edge of chaos
this is not the solution... but it could be a bandaid until you find one. set the MaxClients # lower. # Limit on total number of servers running, i.e., limit on the number # of clients who can simultaneously connect --- if this limit is ever # reached, clients will be LOCKED OUT, so it should NOT BE SET TOO LOW. # It is intended mainly as a brake to keep a runaway server from taking # the system with it as it spirals down... # MaxClients 150 On Wed, Jan 03, 2001 at 10:25:04PM -0500, Justin wrote: Hi, and happy new year! My modperl/mysql setup does not degrade gracefully when reaching and pushing maximum pages per second :-) if you could plot throughput, it rises to ceiling, then collapses to half or less, then slowly recovers .. rinse and repeat.. during the collapses, nobody but real patient people are getting anything.. most page production is wasted: goes from modperl--modproxy--/dev/null I know exactly why .. it is because of a long virtual "request queue" enabled by the front end .. people "leave the queue" but their requests do not.. pressing STOP on the browser does not seem to signal mod_proxy to cancel its pending request, or modperl, to cancel its work, if it has started.. (in fact if things get real bad, you can even find much of your backend stuck in a "R" state waiting for the Apache timeout variable to tick down to zero..) Any thoughts on solving this? Am I wrong in wishing that STOP would function through all the layers? thanks -Justin Thanks, Jeff --- | "0201: Keyboard Error. Press F1 to continue." | | -- IBM PC-XT Rom, 1982 | ------- | Jeff Sheffield | | [EMAIL PROTECTED] | | AIM=JeffShef| ---
Apache::AuthCookieDBI BEGIN problems...??
Well been racking my brain against this one for awhile now..
so I figured that I would reach-out for some help ;)
First let me say
I am ashamed ... I twitled with the shiny bits.
the following code in the Apache::AuthCookieDBI module
does not work properly (for me).
-- code --
BEGIN {
my @keyfile_vars = grep {
$_ =~ /DBI_SecretKeyFile$/ } keys %{ Apache-server-dir_config() };
foreach my $keyfile_var ( @keyfile_vars ) {
my $keyfile = Apache-server-dir_config( $keyfile_var );
my $auth_name = $keyfile_var;
$auth_name =~ s/DBI_SecretKeyFile$//;
unless ( open( KEY, "$keyfile" ) ) {
Apache::log_error( "Could not open keyfile for $auth_name in
file $keyfile" );
} else {
$SECRET_KEYS{ $auth_name } = KEY;
close KEY;
}
}
### MY DIRTY HACK
my $auth_name = "WhatEver";
$SECRET_KEYS{ $auth_name } = "thisishtesecretkeyforthisserver";
### END MY DIRTY HACK
}
-- end code --
Note that without MY DIRTY LITTLE HACK it does not set those two
variables. I am/was pretty sure that this somehow relates to
"StackedHandlers"
but
I built mod_perl statically with ALL_HOOKS=1 EVERYTHING=1
it is Apache/1.3.14 (Unix) mod_perl/1.24_01 configured
So after I set MY DIRTY LITTLE HACK. Things chug right along
i bind to the database I authenticate against the db.
until I/the module tries to set_cookie in the form
Set-Cookie:
Apache::AuthCookieDBI_WhatEver=jeff:2001-01-02-23-07-10:2001-01-02-23-12-10:2f8e147086c88e6771ac6751b5a1f25d;
path=/; domain=.jeff
So that makes me wonder if Date::Calc is installed correctly.
i.e. he module uses Date::Calc. also note that it installed fine.
I figured that the cookie problem could be a side effect of the
firt problem I mentioned.
ahh yes my config file is here for anyone who is intrested
Any clue's..??
Thanks,
Jeff
-
| Gender Diff's |
| THOUGHT FOR THE DAY: Any married man should forget his mistakes. |
| There's no use in two people remembering the same thing. |
| |
| --Anonymous |
-----
| Jeff Sheffield|
| [EMAIL PROTECTED]|
| AIM=JeffShef |
-
Re: Apache::AuthCookieDBI BEGIN problems...??
ahh yes my config file is here for anyone who is intrested oopse http://www.jspot.org/jeff/temp/custom.after Thanks, Jeff - | Gender Diff's | | THOUGHT FOR THE DAY: Any married man should forget his mistakes. | | There's no use in two people remembering the same thing. | | | | --Anonymous | - | Jeff Sheffield| | [EMAIL PROTECTED]| | AIM=JeffShef | -
Unset PerlAuthenHandler (I wish)
Ok, essentially I want all but one directory on the server to be password protected. I want 1 directory to have the "I forgot my password" functionality. I am using Mason. and setting SetHandler default-handler has undesired results. i.e. mason files do not get parsed. Essentially I want to do this. Unset PerlAuthenHandler here is a portion of my conf file. -- AddType text/html .mhtm FilesMatch ".*\.mhtm$" SetHandler perl-script PerlHandler HTML::Mason /FilesMatch Location /websites/foo.net/htdocs/ AuthName "foo" AuthType Basic PerlAuthenHandler Apache::AuthDBI::authen PerlAuthenHandler Apache::AuthDBI::authz PerlSetVar Auth_DBI_data_source dbi:mysql:database=foo_external_site;host=localhost;port=3306 PerlSetVar Auth_DBI_username jsheffie PerlSetVar Auth_DBI_password fooo # DBI-connect($data_source, $username, $password) PerlSetVar Auth_DBI_pwd_table users PerlSetVar Auth_DBI_uid_field user_id PerlSetVar Auth_DBI_pwd_field password PerlSetVar Auth_DBI_grp_field groups #SELECT pwd_field FROM pwd_table WHERE uid_field=$user require valid-user ErrorDocument 401 /websites/foo.net/htdocs/passwd_forgoten/ /Location Location /websites/foo.net/htdocs/passwd_forgoten/ SetHandler default-handler /Location - Any ideas..?? Thanks, Jeff --- | 7.6.2.1. Configuring /etc/diphosts | | | | (taken from the Linux Networking-HOWTO) | --- | Jeff Sheffield | | [EMAIL PROTECTED] | | AIM=JeffShef| ---
Re: HTMLEmbperl - manually setting %fdat during runtime...
I do the following
a href="http://172.17.30.38/Nactel/common/error.epl?application_id=[+
$fdat{'application_id'} +]
then "error.epl will have the $fdat{'application_id'} = 'some value';
Jeff
On Wed, Nov 24, 1999 at 09:41:08AM -0500, Erich L. Markert wrote:
What I am trying to do is pass the value of the application_id onto the
next form. application_id is not know until the initial screen has been
filled out properly and submitted. After the error checking and
application submission I then attempt to set $fdat{'application_id'} to
the application id value so I can pass it along to the next form screen
Here's the basic jist of what I want to do...
[-
error checking...
$fdat{'application_id'} = 'some value';
-]
HTMLHEADTITLE/TITLE/HEADBODY
[$ if( ( $new_applicant ) || ( $errors ) ) $]
new application form...
[$ else $]
a href="http://172.17.30.38/Nactel/common/error.epl?[+ [%fdat]
+]"Next/a
[$ endif $]
/BODY/HTML
Examining the query string on the href shows all the other form data
that was filled in and passed back to this app except that
application_id manually set has no value.
TIA
--
__
Mr. Erich L. Markert [EMAIL PROTECTED]
Computer Learning Center TEL (914)422-4328
Pace University
1 Martine Ave
White Plains, New York 10606-1932
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer
| Most people don't look dumb till they start talkin'. |
| -- Forrest Gump |
| -- Winston Groom |
--------
| Jeff Sheffield |
| [EMAIL PROTECTED] |
