Problem with sections in httpd.conf, mod_perl 1.26
I have a rather odd problem, one which I can only assume is a bug
somewhere, due to how bizarre it is.
I am attmempting to generate virtual host configs via mod_perl, using
sections in httpd.conf. Not all hosts will be using a /perl
Alias, though, so I'm reading in an external config, which looks like
the following:
### Begin external vhost config ###
$suexec = 0;
$vhost{config} = {
Location => {
"/perl/" => {
SetHandler => "perl-script",
PerlHandler => "Apache::Registry",
Options => "ExecCGI"
}
},
Alias => [ '/perl/' => "$vhostdir/$dir/perl/" ]
};
### End external vhost config #
This config is being read by the following line:
require "$vhostdir/$dir/.config" if (-r "$vhostdir/$dir/.config");
The configuration options are being added to %VirtualHost as follows:
map { $VirtualHost{$host}->{$_} = $vhost{config}->{$_} } keys(%{$vhost{config}});
Now for the oddity:
The above doesn't work. Both Data::Dumper and Apache::PerlSections
show the options as being added to %VirtualHost, but the server never
seems to see the Alias (no idea on the Location directive, since the
Alias fails to work). Examination of the error_log shows that the
server is trying to get htdocs/perl/, as if the Alias didn't exist.
Just to make things a bit stranger: if I add those sections directly
into my vhost code in httpd.conf, they work. Again, Data::Dumper and
Apache::PerlSections shows what I expect (other than the options being
ordered a bit differently in the hash, but that's normal). This is
what makes me suspect a bug, because this is so bizarre.
Included below is the output I grabbed from Apache:PerlSections in both
cases.
Any ideas? This problem is really quite annoying.
### Working config #
%VirtualHost = (
'linuxhelp.mirkwood.net' => {
'Location' => {
'/perl/' => {
'PerlHandler' => 'Apache::Registry',
'Options' => 'ExecCGI',
'SetHandler' => 'perl-script'
}
},
'DocumentRoot' => '/home/vhosts/linuxhelp.mirkwood.net/htdocs',
'ServerAdmin' => 'test@vhost',
'CustomLog' =>
'/home/vhosts/linuxhelp.mirkwood.net/logs/linuxhelp.mirkwood.net.access_log combined',
'Alias' => [
'/perl/',
'/home/vhosts/linuxhelp.mirkwood.net/perl/'
],
'ServerName' => 'linuxhelp.mirkwood.net',
'ErrorLog' =>
'/home/vhosts/linuxhelp.mirkwood.net/logs/linuxhelp.mirkwood.net.error_log',
'ScriptAlias' => [
'/cgi-bin/',
'/home/vhosts/linuxhelp.mirkwood.net/cgi-bin/'
],
'ServerAlias' => 'linuxhelp'
}
);
### Alias is broken here - WHY?
%VirtualHost = (
'linuxhelp.mirkwood.net' => {
'Location' => {
'/perl/' => {
'PerlHandler' => 'Apache::Registry',
'Options' => 'ExecCGI',
'SetHandler' => 'perl-script'
}
},
'ScriptAlias' => [
'/cgi-bin/',
'/home/vhosts/linuxhelp.mirkwood.net/cgi-bin/'
],
'DocumentRoot' => '/home/vhosts/linuxhelp.mirkwood.net/htdocs',
'ServerAdmin' => 'test@vhost',
'Alias' => [
'/perl/',
'/home/vhosts/linuxhelp.mirkwood.net/perl/'
],
'CustomLog' =>
'/home/vhosts/linuxhelp.mirkwood.net/logs/linuxhelp.mirkwood.net.access_log combined',
'ServerAlias' => 'linuxhelp',
'ServerName' => 'linuxhelp.mirkwood.net',
'ErrorLog' =>
'/home/vhosts/linuxhelp.mirkwood.net/logs/linuxhelp.mirkwood.net.error_log'
}
);
--
Mike Edwards
Brainbench certified Master Linux Administrator
http://www.brainbench.com/transcript.jsp?pid=158188
---
Unsolicited advertisments to this address are not welcome.
[ANNOUNCE Apache::AccessCookie-0.32] many new flavors
This is the second public release of the access control module. You can download it from here: http://mod_perl.home.att.net/AccessCookie_0_32.tar Besides few minor corrections from version 0.31, this one adds several ticket issuing mechanisms and the interface to implement new issuer is becoming especially easy to do. In details, here are they: 1) There is a default login page using the simply codes. Webmasters can override the page() method according to the way they like. HTML::Template is not mandatory. 2) The ticket issuer module Apache::AccessCookieMaster, which uses DBI database, is now an interface named as Apache::AccessCookie::Ticket. To actually implement an issuing mechanism, one needs to inherits it and implement his/her own authenticate() method. Arguments to accepts are: $self, this; $r, the request object; $login, the login name; $password, the login password; and $last_access, when the user got a valid ticket last time. It returns an error string or undef if the issuer authentication is successsful. 3) Currently we have implemented the following 7 issuers: DBI: authenticated against a DBI database FTP: against a FTP server (those who can login to the FTP server gets a valid ticket) IMAP: against an IMAP server LDAP: against a LDAP server NIS: again a NIS server NISPlus: against a NIS+ plus server Remote: against a remote URL which is protected by Basic Authentication. 4) Because of the limitation to test all types of servers, PLEASE NOTE that IMAP, LDAP, NIS, NIS+ are actually in the 0.01 version and should be used very carefully. If you use them, please also take a look at the following related CPAN modules: Apache::AuthCookieLDAP Apache::AuthzLDAP Apache::AuthLDAP Apache::AuthenLDAP Apache::AuthNetLDAP Apache::AuthPerLDAP Apache::AuthenIMAP Apache::AuthenN2 Apache::AuthenNIS Apache::AuthzNIS Apache::AuthenNISPlus Authen::Smb Apache::AuthenNTLM Apache::AuthenSmb Apache::AuthenURL. Please help to improve the AccessCookie modules and send me a note! 5) For those who have not checked the last release nor other modules like Apache::AuthCookie, here is a short summary as what they are. Let's take the AccessCookie::Remote as an example. The original idea of authentication against a remote URL is in Apache-AuthenURL-0.8 (by John D Groenveld.): if a visitor can login successfully to a web page that is protected by Basic Authentication, he/she will be allowed to access the current site as well. In AuthenURL, the verification is performed by LWP that has to be made for every request. In the current ticketing system, the authentication is against a valid self-consistent ticket, a MD5 hash. If the visitor has no ticket, he/she is first redirected to the ticket master machine for getting a ticket. The ticket master (issuer) runs the module Apache::AccessCookie::Remote. It checks the credentials against the remote URL. If it passes, the master will issue a self-consistent ticket so the user can use the ticket for the following up requests within a limited time period. There is no need to verify against the remote URL every time. This should boost the speed very much. Peter Bi [EMAIL PROTECTED] Feb. 15, 2002
Re: Enforcing user logged in from only 1 browser?
If you touch SessionDBI for every request, why don't go directly to the
Basic Authentication ? Using AuthCookie would 1) slow down the
authentication process (because an extra MD5 hash calculation) and 2) drop
off 10% of users who have disabled the cookie.
One of the nice features in the AuthCookie, and ticketing authentication
systems in general, is that the ticket is self-consistent. So one can check
if the ticket is valid without calling any DBI (instead, it calculates a
MD5). Repeating SELECTs/UPDATEs to DBI does hurt much the performance of a
high traffic site.
My 2 cents.
Peter Bi
[EMAIL PROTECTED]
..
> If someone comes in with an old active session (assuming it's not
> expired) AuthCookie examines the MD5 hash and says "everything matches
> up, you may proceed". I need to add a step here to say "if newer
> session for user exists, kill this one". But you've just given me a
> great idea! When the old session comes in, there will still be data in
> the session (because the new session is using it - sessions are keyed by
> user id, not session id). So I can't rely on an empty session data to
> be the clue. BUT - I can store the session key that generated this
> session data in with the session data, and try to match those up. I
> like it. This will work, I think. Thank you. =) Why do I use the user
> id instead of the session id for the session key? Because it makes the
> code easier for other developers ("a user will always have a session
> with the key $r->connection->user") and that gets passed around
> automatically rather than me having to expose the developers to the
> AuthCookieDBI cookie directly. I just find it easier to rely on
> $r->connection->user to always be the session key.
>
>>
[JOB] Senior mod_perl developers needed for LRN, Los Angeles
Hey mod_perl & ASP Crew, This is very much the same job posting that I sent out for LRN on April 3rd, except the requirement for Java programming experience has been dropped. :) They are looking to seriously bolster their mod_perl team for their star LCEC product, and need some full time senior engineers on site in Los Angeles. Please send resumes and code samples to me at [EMAIL PROTECTED] and I will forward them on in the next week to the management at LRN. For more information about LRN & LCEC, please see: http://www.lrn.com/ http://www.lrn.com/solutions/lcec/ethicallyaware.html Regards, Josh Chamas Position Title: Web Software Developer Department: Development Brief Overview Of Position: The Web Software Developer will work with a team of other highly skilled developers to rapidly develop, deploy, and maintain Web applications based on LRN knowledge and content delivery platforms. List Essential Job Functions: - Responsible for new feature development, integrations, and extensions to our existing products - Instrumental in developing new features and applications, as well as designing and developing integrations between new and existing product offerings - Highly skilled professional software engineer, able to rapidly develop and deploy professional quality software - Independent learner, thinker, and quality minded individual; the difference between getting it done and doing it right! - Ability to learn new skills and development environments as technology landscape shifts - Conversant in both hardware and software in computer market - Ability to engage in and support position on design and development issues - Ability to lead and teach other both junior and senior developers - Good written and verbal communication skills Technical Skills Required: - 2 years minimum experience with mod_perl/Apache on UNIX platforms - Practical experience with high volume transactional RDBMS based web sites using DBI, preferably with Oracle - An intimate knowledge of Perl Object Oriented programming - Cross platform browser HTML eccentricities - Expertise in a wide variety of computer tools and development environments - Proven capabilities in programming and operating systems Previous Experience Required: - 5 years minimum industry experience - Experience with templates & component based architecture - Practical software engineering experience, including several full life cycles of specification, design, development paradigms, testing, deployment, documentation, and configuration management Education Required (Certifications, Degrees, Majors, etc.): - 4 year degree or equivalent industry experience Experience Preferred: - Oracle RDBMS programming (triggers, stored procedures, etc.) - Linux x86 - Solaris SPARC - Load balanced web clusters - SSL proxy servers - Caching proxy servers - Network engineering List Any Lifting or Physical Requirements of the Position: - None
[ANNOUNCE] Uttu 0.02
Uttu 0.02 has been uploaded to CPAN. It may take a little while before it is available. This version of Uttu should be considered beta (for HTML::Mason users) and alpha (for Template Toolkit users). Uttu is a web-site driver which, together with a suitable framework, provides an environment in which to write/run applications. Uttu is also designed to make application distribution almost trivial - basically not much more difficult than installing a module off CPAN. Uttu is known to work with HTML::Mason (at least prior to version 1.09) and alpha support is included in this version for the Template Toolkit. Current documentation is available at http://uttu.tamu.edu/ . (Netscape 4.7 seems to have problems sometimes with the style sheets -- site was developed to work with Mozilla (and seems to work with Omni, too).) I will be putting out a newer version of the Uttu (site) framework later this week. -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Senior Software Applications Developer, Texas A&M CIS Operating Systems Group, Unix
Re: [OT] [ANNOUNCE] mod_log_sqlite
Matt Sergeant wrote: > Is that any different to how it is with file logging? I would guess it's the same, but I don't know the details of how either system implements locking. I'm mostly interested because if SQLite works for this it might work for fast data sharing between processes as well (maybe as a Cache::Cache backend). - Perrin
[DIGEST] mod_perl digest 2002/04/01
-- mod_perl digest April 1, 2002 - April 14, 2002 -- Recent happenings in the mod_perl world... Features o mod_perl status o module announcements o application announcements o available mod_perlers o seeking mod_perlers o mailing list highlights o links mod_perl status o mod_perl - stable: 1.26 (released July 11, 2001) [1] - development: 1.26_01-dev [2] o Apache - stable: 1.3.24 (released March 21, 2002) [3] - development: 1.3.25-dev [4] o mod_perl 2.0 - beta: 1.99_01 (released April 6, 2002) [5] - development: (cvs only) [6] o Apache 2.0 - stable: 2.0.35 (released April 5, 2002) [7] o Perl - stable: 5.6.1 (released April 9, 2001) [8] - development: 5.7.3 [9] module announcements o Apache::AuthenNTLM 0.15 - use Microsoft's NTLM authentication method [10] o Cache::Cache 1.0 - easy-to-use caching and data sharing [11] module RFCs o Apache::AccessCookie - cookie based access control [12] application announcements o Bricolage 1.3.1 (dev) - full-featured, open-source, enterprise-class content management system [13] available mod_perlers (well... just Java this time) o Expert Java programmer [14] seeking mod_perlers o Senior mod_perl / java developer for LRN, Southern California [15] o Lead programmer(s) for Online Congressional Directory publisher [16] o Developer needed at PrintMe.com [17] mailing list highlights o Apache 1.3.24 proxy problems [18] [19] o Cookies and proxies [19] [20] o mod_perl 1.99_01 release [21] o Content management systems [22] o Request for errata for mod_perl Cookbook [23] links o The Apache/Perl Integration Project [24] o mod_perl documentation [25] o java modules on CJAN [26] o mod_perl homepage [27] o mod_perl news and advocacy [28] o mod_perl list archives - modperl@ [29] [30] - dev@ [31] [32] - docs-dev@ [33] - advocacy@ [34] happy mod_perling... --James [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://perl.apache.org/from-cvs/modperl/ [3] http://www.apache.org/dist/httpd/ [4] http://cvs.apache.org/snapshots/apache-1.3/ [5] http://perl.apache.org/dist/mod_perl-1.99_01.tar.gz [6] http://cvs.apache.org/snapshots/modperl-2.0/ [7] http://www.apache.org/dist/httpd/ [8] http://www.cpan.org/src/stable.tar.gz [9] http://www.cpan.org/src/devel.tar.gz [10] http://mathforum.org/epigone/modperl/twingheryoi [11] http://mathforum.org/epigone/modperl/krehleutrung [12] http://mathforum.org/epigone/modperl/bintrinskoi [13] http://mathforum.org/epigone/modperl/skozahflam [14] http://mathforum.org/epigone/modperl/boxstilsim [15] http://mathforum.org/epigone/modperl/swaxphilwhy [16] http://mathforum.org/epigone/modperl/querskerglerd [17] http://mathforum.org/epigone/modperl/khemgongnimp [18] http://mathforum.org/epigone/modperl/smogixquend [19] http://mathforum.org/epigone/modperl/poyceidwerm [20] http://mathforum.org/epigone/modperl/glilzeezhe [21] http://mathforum.org/epigone/modperl/jycrulzhon [22] http://mathforum.org/epigone/modperl/spemsterspang [23] http://mathforum.org/epigone/modperl/dwanboaphi [24] http://perl.apache.org [25] http://perl.apache.org/#docs [26] http://www.cpan.org/modules/by-module/Apache/ [27] http://www.modperl.com [28] http://www.take23.org [29] http://mathforum.org/epigone/modperl/ [30] http://marc.theaimsgroup.com/?l=apache-modperl&r=1&w=2 [31] http://marc.theaimsgroup.com/?l=apache-modperl-dev&r=1&w=2 [32] http://www.mail-archive.com/dev%40perl.apache.org/ [33] http://perl.apache.org/mail/docs-dev/ [34] http://www.mail-archive.com/advocacy@perl.apache.org/
Re: Found a sprintf() bug inPerl 5.6.1 (and mod_perl)
> I know that roundings are often tricky from language to language (Javascript
> has not the same rules for example and a small solid state calculator has
> different ones also).
.
.
.
> And in Perl I found these rules not very consistent.
The effect that you have discovered has nothing to do with rounding
rules. This has to do with the internal representation of floating
point numbers given a binary numbering system.
There is no guarantee that the following will yield true:
if ( (0.01 - 2 * 0.005) == 0 ) {
# this code probably won't run!
}
This isn't part of Perl or "language rounding rules". This exact
same error would occur in C or FORTRAN or any language.
I did a quick Google search and came up with this page. It seems
to describe this problem fairly well.
http://www.apocalypse.org/pub/u/paul/docs/cport/cport09.htm
I'm sure there are better descriptions out there that could be
found with a bit more looking.
Cheers,
Richard
Re: Found a sprintf() bug inPerl 5.6.1 (and mod_perl)
Thank you for your explanation both of you.
> alester@flr4[~/play]$ perl sprintf.pl
> 056 56.9928946
>
> ...
>
> In general, the chances that you've found a bug in the language or
> implementation that's been around as long and is as widely used as Perl
> 5.6 is preeetty small.
I know that !
That's why I didn't understand this behaviour first. Perl has been around
since 13 years and during past years I've already found a few
workarounds about bad calculations due to roundings.
I imagine that such a discussion occured in 80's.
But this one is different, behaviour is not equally distributed amongst
input values. I'm very puzzling with that.
I know that roundings are often tricky from language to language (Javascript
has not the same rules for example and a small solid state calculator has
different ones also).
But you must know that it's very difficult to write a portable code from
langage to langage when rules are different.
And in Perl I found these rules not very consistent.
Can you tell me what you are thinking of that ?
^
perl -e '$a=0.79; printf sprintf("%03d %30.29f", $a*100, $a*100);'
079 79.0
perl -e '$a=0.69; printf sprintf("%03d %30.29f", $a*100, $a*100);'
069 69.0
perl -e '$a=0.49; printf sprintf("%03d %30.29f", $a*100, $a*100);'
049 49.0
perl -e '$a=0.55; printf sprintf("%03d %30.29f", $a*100, $a*100);'
055 55.00710542735760100
perl -e '$a=0.59; printf sprintf("%03d %30.29f", $a*100, $a*100);'
059 59.0
perl -e '$a=0.56; printf sprintf("%03d %30.29f", $a*100, $a*100);'
056 56.00710542735760100
perl -e '$a=0.61; printf sprintf("%03d %30.29f", $a*100, $a*100);'
061 61.0
perl -e '$a=0.65; printf sprintf("%03d %30.29f", $a*100, $a*100);'
065 65.0
perl -e '$a=0.66; printf sprintf("%03d %30.29f", $a*100, $a*100);'
066 66.0
perl -e '$a=0.68; printf sprintf("%03d %30.29f", $a*100, $a*100);'
068 68.0
perl -e '$a=0.28; printf sprintf("%03d %30.29f", $a*100, $a*100);'
028 28.00355271367880050
perl -e '$a=0.27; printf sprintf("%03d %30.29f", $a*100, $a*100);'
027 27.0
perl -e '$a=0.26; printf sprintf("%03d %30.29f", $a*100, $a*100);'
026 26.0
perl -e '$a=0.24; printf sprintf("%03d %30.29f", $a*100, $a*100);'
024 24.0
perl -e '$a=0.47; printf sprintf("%03d %30.29f", $a*100, $a*100);'
047 47.0
perl -e '$a=0.33; printf sprintf("%03d %30.29f", $a*100, $a*100);'
033 33.0
perl -e '$a=0.17; printf sprintf("%03d %30.29f", $a*100, $a*100);'
017 17.0
And if you try a loop, it works too, since, for perl, 0.01+0.01 > 0.02
and so on.
But if I take my calculator :
0.57*100 = 57 exactly !
Example :
perl -e 'for ($a=0.01;$a<1;$a+=0.01) { print sprintf("%20.19f %03d
%20.19f\n", $a, $a*100, $a*100);} '
0.012 001 1.000
0.024 002 2.000
0.0299989 003 3.000
0.048 004 4.000
0.0500028 005 5.000
0.0600047 006 6.0008882
0.0700067 007 7.0008882
0.0800017 008 8.000
0.0899967 009 9.000
0.017 010 10.000
0.1099867 010 10.9982236
0.1199817 011 11.9982236
0.1299767 012 12.9982236
0.1399856 013 13.9982236
0.1499944 015 15.000
0.1600033 016 16.000
0.1700122 017 17.000
0.1800211 018 18.0035527
0.1900300 019 19.0035527
0.2000389 020 20.0035527
0.2100477 021 21.0035527
0.2200566 022 22.0071054
0.2300655 023 23.0071054
0.2400744 024 24.0071054
0.2500555 025 25.0071054
0.2600644 026 26.0071054
0.2700733 027 27.0071054
0.2800822 028 28.0071054
0.2900910 029 29.0106581
0.3000999 030 30.0106581
0.3101088 031 31.0106581
0.3201177 032 32.0142109
0.3301266 033 33.0142109
0.3401354 034 34.0142109
0.3501443 035 35.0142109
0.3601532 036 36.0142109
0.3701621 037 37.
Re: Found a sprintf() bug inPerl 5.6.1 (and mod_perl)
> correct -269; that's because it's really more like
> -268.94315658 instead. Usually, the
> "sprintf", "printf", or the "POSIX::floor" and
And in this case, that means:
alester@flr4[~/play]$ more sprintf.pl
#!/usr/bin/perl -w
$a=0.57 * 100;
print sprintf("%03d %20.19f\n", $a,$a);
alester@flr4[~/play]$ perl sprintf.pl
056 56.9928946
...
In general, the chances that you've found a bug in the language or
implementation that's been around as long and is as widely used as Perl
5.6 is preeetty small.
#!Andy
--
'Andy Lester[EMAIL PROTECTED]
Programmer/author petdance.com
Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$&)
[unpack'C*',"n2]3%+>\"34.'%&.'^%4+!o.'"])
Re: Found a sprintf() bug inPerl 5.6.1 (and mod_perl)
Dominique Blas wrote:
> Sorry,
>
> I've found the following bug in mod_perl 1.25 and Perl 5.6.1.
> Maybe was it already released but in case not here it is :
>
> perl -e '
> $a=0.57;
> print sprintf("%03d", $a * 100)'
>
> prints "056" instead of "057"
>
> Same behaviour with $a=0,58 that prints "057".
>
> Of course it works for other values and also if you write
>
> $a=0,57*100;
> print sprintf("%03d", $a);
>
>
> Bug in sprintf() ?
No, this is not a bug. %d is the same as int(). Consider:
% perl -le '$a=0.57; print int ($a*100)'
56
Now read the manpage:
int EXPR
int Returns the integer portion of EXPR. If EXPR is
omitted, uses "$_". You should not use this func
tion for rounding: one because it truncates
towards "0", and two because machine representa
tions of floating point numbers can sometimes pro
duce counterintuitive results. For example,
"int(-6.725/0.025)" produces -268 rather than the
correct -269; that's because it's really more like
-268.94315658 instead. Usually, the
"sprintf", "printf", or the "POSIX::floor" and
"POSIX::ceil" functions will serve you better than
will int().
this explains the problem.
__
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
Re: mod_perl 1.99 (for Apache 2.0.35) building on W2K
Pascal, Thanks, I needed some good news. Chuck - Original Message - From: pascal barbedor To: Chuck Goehring Cc: [EMAIL PROTECTED] Sent: Friday, April 12, 2002 11:41 PM Subject: Re: mod_perl 1.99 (for Apache 2.0.35) building on W2K Hi chuck for DBI and DBD::xx it makes no difference if you use them with regular cgi modperl 1 or 2 because they are unrelated to web environment. (at least i suppose so a priori). at least in my test they are used without problem in startup.pl. for cgi.pm used outside modpelr with 2.0.35 no difference as well and for cgi.pm used with modperl I don't know. i guess there is a difference, at least in the Apache::registry setup of the location to use the cgi like script pascal - Original Message - From: Chuck Goehring To: pascal barbedor Sent: Saturday, April 13, 2002 5:11 AM Subject: Re: mod_perl 1.99 (for Apache 2.0.35) building on W2K Pascal and anyone else who can help, I've seen your other posts and I'm wondering how your testing is going with "regular" cgi programs. I don't use any of the exotic mod_perl specifics, so I'm no help there. I'll have to "aquire" more facilities to setup like you have (nt boxes in short supply). I'm mostly concerned about the cgi.pm, dbi.pm dbd::oracle etc. Anybody know the impact that Apache 2.0 has on these modules? Chuck - Original Message - From: pascal barbedor To: Chuck Goehring Sent: Thursday, April 11, 2002 4:40 AM Subject: Re: mod_perl 1.99 (for Apache 2.0.35) building on W2K Hi I am trying to build modperl under win2k saw your message. don't know about your problem but : i use already built asperl build 631 I have built apache succesfully, but when trying to build modperl2 i am asked apxs did you find the apxs program ? thanks pascal barbedor
Re: [OT] [ANNOUNCE] mod_log_sqlite
At Mon, 15 Apr 2002 11:32:55 -0400, Perrin Harkins wrote: > The SQLite FAQ seems to suggest that SQLite isn't very good at parallel > read/write situations: http://www.hwaci.com/sw/sqlite/faq.html#q6 > > Have you seen any problems so far? Yep, that's what I'd expected to happen. Without sqlite's timeout_handler function, there happen many errors due to database locking. But with handler there seems no problem and it just works fine in my personal website which has 10_000 hits a day. I should give it a shot with a site with more accesses, and examine how to rotate the log db file. Thanks! -- Tatsuhiko Miyagawa <[EMAIL PROTECTED]>
Re: [OT] [ANNOUNCE] mod_log_sqlite
At Mon, 15 Apr 2002 17:09:43 +0100 (BST), Matt Sergeant wrote: > PS: Taso: you sent to [EMAIL PROTECTED], which Ask seems to have > setup to redirect to the right address. Yep. I've made a mistake, which Ask kindly had outsmarted ;) -- Tatsuhiko Miyagawa <[EMAIL PROTECTED]>
Re: [OT] [ANNOUNCE] mod_log_sqlite
On Mon, 15 Apr 2002, Perrin Harkins wrote: > Tatsuhiko Miyagawa wrote: > > Announcing new Apache module (written in C): > > > > mod_log_sqlite is an Apache logging module for sqlite database. It > > allows you to log your HTTP stats into sqlite, then you can do queries > > using sqlite's SQL feature (including subselects, views) to HTTP > > statistics. > > The SQLite FAQ seems to suggest that SQLite isn't very good at parallel > read/write situations: http://www.hwaci.com/sw/sqlite/faq.html#q6 > > Have you seen any problems so far? Is that any different to how it is with file logging? PS: Taso: you sent to [EMAIL PROTECTED], which Ask seems to have setup to redirect to the right address. -- <:->Get a smart net
Re: Enforcing user logged in from only 1 browser?
Jeff wrote:
> Forgive a mod_perl newbie for non mod_perl thinking, but this
> is (a simplified overview) of how I would approach this:
>
> request for any protected page
> - if no existing session data [so not authenticated]
> create new session
> remember target page in session
> redirect to login page
>otherwise
> allow access to page
Yes, this is exactly how AuthCookie works.
> login page POST with user id / password.
> - if ( valid user / password )
> add user info to session
AuthCookie sessions don't also carry user info, but that's why I create
an Apache::Session to do it.
> expire previous session [id was saved in db]
Right-o. How to expire an otherwise valid AuthCookie session is the
question.
>[snip]
> If someone now tries to come back with an old session id,
> there is no data in the session, so they will be considered
> un-authenticated, and will get redirected to login page.
If someone comes in with an old active session (assuming it's not
expired) AuthCookie examines the MD5 hash and says "everything matches
up, you may proceed". I need to add a step here to say "if newer
session for user exists, kill this one". But you've just given me a
great idea! When the old session comes in, there will still be data in
the session (because the new session is using it - sessions are keyed by
user id, not session id). So I can't rely on an empty session data to
be the clue. BUT - I can store the session key that generated this
session data in with the session data, and try to match those up. I
like it. This will work, I think. Thank you. =) Why do I use the user
id instead of the session id for the session key? Because it makes the
code easier for other developers ("a user will always have a session
with the key $r->connection->user") and that gets passed around
automatically rather than me having to expose the developers to the
AuthCookieDBI cookie directly. I just find it easier to rely on
$r->connection->user to always be the session key.
> [snip]
> I can see two issues with this approach:
> 1) login ping-pong. Two users using the same id/password will
>be logging each other out as they log in (but this seems
>to be what you want?)
Yes, or at least a page saying "you're logged in elsewhere, do you want
to ax that one and continue, or abort this login". Even a forced logout
of the older one without the user knowing is fine.
> 2) it does not prevent the user from having the same pages
>open multiple times within the same browser instance
>(eg when the user presses Ctrl-N after having logged in)
This is ok, because we're more concerned with an unmanned, logged-in
station. If they want 5 browser windows, they can go nuts.
Thanks for the dialog, Jeff! I think that clue you gave me above is
what I need. The confusion is again because AuthCookie and
Apache::Session both call themselves sessions. AuthCookie does the
authentication, Apache::Session holds the user data. So I need to write
the piece that coordinates the cleanup of old sessions between the two.
-Fran
RE: Enforcing user logged in from only 1 browser?
Forgive a mod_perl newbie for non mod_perl thinking, but this is (a simplified overview) of how I would approach this: request for any protected page - if no existing session data [so not authenticated] create new session remember target page in session redirect to login page otherwise allow access to page login page POST with user id / password. - if ( valid user / password ) add user info to session expire previous session [id was saved in db] save new session id in the database [for next login] redirect to the originally requested page otherwise redirect to login page with error message If someone now tries to come back with an old session id, there is no data in the session, so they will be considered un-authenticated, and will get redirected to login page. In PHP, I would expire the old session during login, by deleting the session storage, if it still existed. mod_perlers can probably best suggest how to empty the contents of a session and / or remove the session storage. As the decisions are made based on information on the server, this should also be safe from users pressing the BACK button, as BACK to a protected page will redirect to login. I'm not sure what happens with using History to select the page that immediately followed login - probably the usual 'Do you want me to post again?' question from Explorer etc. I can see two issues with this approach: 1) login ping-pong. Two users using the same id/password will be logging each other out as they log in (but this seems to be what you want?) 2) it does not prevent the user from having the same pages open multiple times within the same browser instance (eg when the user presses Ctrl-N after having logged in) just my 2 newbie pennies... Regards Jeff -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: 15 April 2002 16:02 To: Fran Fabrizio Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Enforcing user logged in from only 1 browser? Fran Fabrizio wrote: > Unfortunately, there's some terminology muddling...AuthCookie calls it a > session when it establishes that a user is a valid user and sets a > cookie on their browser. Apache::Session considers a session a series > of page hits from the same user. It assumes you've already done > whatever you need to do to assure that the user is valid. I think you may find that neither of these does everything you need without a bit of additional coding. The common way to do this sort of thing is to use Apache::Session to track sessions (as in a series of page hits from the same user), and if the user authenticates, you put his user ID into the session data. You would have to do the auth part yourself, as well as the actual cookie handling, or else hack AuthCookie to cooperate with Apache::Session. - Perrin
Re: [OT] [ANNOUNCE] mod_log_sqlite
Tatsuhiko Miyagawa wrote: > Announcing new Apache module (written in C): > > mod_log_sqlite is an Apache logging module for sqlite database. It > allows you to log your HTTP stats into sqlite, then you can do queries > using sqlite's SQL feature (including subselects, views) to HTTP > statistics. The SQLite FAQ seems to suggest that SQLite isn't very good at parallel read/write situations: http://www.hwaci.com/sw/sqlite/faq.html#q6 Have you seen any problems so far? - Perrin
Found a sprintf() bug inPerl 5.6.1 (and mod_perl)
Sorry,
I've found the following bug in mod_perl 1.25 and Perl 5.6.1.
Maybe was it already released but in case not here it is :
perl -e '
$a=0.57;
print sprintf("%03d", $a * 100)'
prints "056" instead of "057"
Same behaviour with $a=0,58 that prints "057".
Of course it works for other values and also if you write
$a=0,57*100;
print sprintf("%03d", $a);
Bug in sprintf() ?
Sincerely,
db
[OT] [ANNOUNCE] mod_log_sqlite
Announcing new Apache module (written in C):
mod_log_sqlite is an Apache logging module for sqlite database. It
allows you to log your HTTP stats into sqlite, then you can do queries
using sqlite's SQL feature (including subselects, views) to HTTP
statistics.
http://freshmeat.net/projects/mod_log_sqlite/
here's an excerpt from README:
mod_log_sqlite - Apache logging module to sqlite
INSTALL:
You can install this module easily via apxs magic.
% make
# make install
% make clean
CONFIGURATION (summary):
1. install sqlite from http://www.hwaci.com/sw/sqlite/
2. Add following lines to your httpd.conf
LogSQLiteDBFile sqlite-logs/sqlite_log
LogSQLiteAutoChown On
CONFIGURATION (details):
First you should install sqlite module manually. See
http://www.hwaci.com/sw/sqlite/ for details.
Then you should initialize access_log database (from 0.05, this is
optional). Note that the database file and the directory should be
writable by httpd running user ("nobody" by default).
# mkdir /usr/local/apache/sqlite-logs
# chown nobody:nobody /usr/local/apache/sqlite-logs
% sudo -u nobody sqlite /usr/local/apache/sqlite-logs/sqlite_log < create_table.sql
"create_table.sql" is bundled with this module. Note that this module
automatically creates log table if there's not one, from 0.05. You can
let this moule do chown() automatically, by adding directive:
LogSQLiteAutoChown On
Finally, simply add the following line to your httpd.conf:
LogSQLiteDBFile sqlite-logs/sqlite_log
Table name is "access_log" by default. You can change it via
"LogSQLiteTable" directive if you want to.
LogSQLiteTable wwwlog
From 0.05, this module supports separate database files per
VirtualHosts, which means you can even do:
ServerName vh.example.com
LogSQLiteDBFile /home/vh.example.com/logs/sqlite_log
That's all! Enjoy querying your access_log via VIEWs and/or sub-querys.
--
Tatsuhiko Miyagawa <[EMAIL PROTECTED]>
Re: Apache::ServerUtil pb in modperl2
On Sat, 13 Apr 2002, pascal barbedor wrote:
> > Does the following, or some variation, work?
[ .. ]
> > sub handler {
> > my $r = shift;
> > my $key = $r->dir_config->get('TEST');
> > $r->content_type('text/plain');
> > $r->print($key);
> > Apache::OK;
> > }
>
> yes it works perfectly well.
>
> but you are accessing dir_config through a request object and
> in my example I am accessing it through the server object in
> a "use module" in startup.pl
I just wanted to verify that accessing it this way worked ... On
my XP machine (ActivePerl 631, based on perl-5.6.1) and with
httpd-2/modperl-2 from cvs I too find that accessing dir_config
values from a server object doesn't work - it just returns an
empty value. The modperl-2 server object tests run OK, but the
dir_config tests result in a server error when trying to set a
dir_config value from the request object (this occurs after the
tests involving getting a value, but before accessing it from the
server object). I've verified that accessing dir_config thru a
server object gives an APR::Table object, and the table tests
pass; this looks like a more detailed analysis is needed ...
best regards,
randy
Re: Enforcing user logged in from only 1 browser?
> You would have to do the auth part yourself, as well as the actual > cookie handling, or else hack AuthCookie to cooperate with Apache::Session. This is exactly what I've done. I've modified AuthCookieDBI to create an Apache::Session session as soon as it knows it has a valid user. Then if the user is conscientious and logs out or the AuthCookie key is expired, AuthCookie will take care of deleting the Apache::Session session. That part is working. The only thing is AuthCookie needs some foolproof way to check to see if that same user already has a valid session from somewhere else that is still active. It's easy enough to just delete/reset/blow on top of any older Apache::Session objects for this user. It's not so apparent (to me) how to tell AuthCookie to no longer accept the older key for this user. What would otherwise happen is that the user would have two perfectly valid sessions from two different browsers, potentially blowing over his Apache::Session object back and forth. Not to mention someone else could hop onto the old browser and see/do stuff they are not authorized to see/do. Yes, I realize that a certain amount of this depends simply on not having idiots for users. =) But I like to help them out as much as possible. We don't consider the 2 simulataneous logins to be super crucial to avoid, as our expire times are kept fairly short anyhow, but we do think it makes for a more robust interface. A whimsical example of what could happen is that user #1 leaves a browser session open and goes to a different station and logs on. User #2 wants to play joke on user #1. User #2 goes to user #1's old session and changes his style preferences. User #1 is at other workstation, and the entire look of the site changes instantly before his eyes. Of course, more serious things can happen if user #1 happens to be an administrator or user with some advanced privileges to our system and user #2 happens to be an arse looking to get fired. Anyways, just talking through the problem repeatedly here has given me some idea so I am off to try those. =) -Fran
Re: "Kind-of" PerlSections, and location question
Daniel W. Burke wrote: > We have an application we're serving by using the same > set of source code, and setting up different > sections in the virtual host to set different variables > and path aliases based on who the customer is... ... > What I'd like to do (if even possible!), is have something > like this: > > Have a databae table that stores the information for each > setting, then load it dynamically as a request comes in... Off the top of my head, there are two simple ways to do this. The first is to generate your httpd.conf using a template and database. I've done this using Template Toolkit, and it worked great. This also works for servers that don't have mod_perl, like proxy servers. The other way would be to write a PerlTransHandler to look at all incoming requests and then decide how to handle them based on your database info. This is better if you need to be able to update it without restarting apache. - Perrin
Re: Enforcing user logged in from only 1 browser?
Fran Fabrizio wrote: > Unfortunately, there's some terminology muddling...AuthCookie calls it a > session when it establishes that a user is a valid user and sets a > cookie on their browser. Apache::Session considers a session a series > of page hits from the same user. It assumes you've already done > whatever you need to do to assure that the user is valid. I think you may find that neither of these does everything you need without a bit of additional coding. The common way to do this sort of thing is to use Apache::Session to track sessions (as in a series of page hits from the same user), and if the user authenticates, you put his user ID into the session data. You would have to do the auth part yourself, as well as the actual cookie handling, or else hack AuthCookie to cooperate with Apache::Session. - Perrin
Re: [ANNOUNCE] Cache::Cache 1.0
On Sat, Apr 13, 2002 at 04:33:11PM +0200, Eric Cholet wrote: > I'm seeing this problem when using Apache::SOAP, using Cache::Cache > 0.99 or 1.0. Downgrading to Digest::MD5 2.12 indeed solves it. Hi -- I recently released version 1.01 of Cache::Cache to CPAN. This version uses Digest::SHA1 as a substitute for MD5 until the bugs in that library are fixed. If anyone has any issues with 1.0 and MD5, please download 1.01 and let me know if anything goes wrong. Cheers, -DeWitt
Re: Enforcing user logged in from only 1 browser?
> I'm not sure I follow your session id problem. When I check a session, I ask > the client for it's ID, then look the session up by ID. To 'expire' the > session, I simply delete it from the session store (File or Postgres). The confusion is you aren't using sessions in the authentication sense of the word. You say you look up the session by ID...but how do you know the ID? Because they previously authenticated. I'm using sessions at the authentication step, via AuthCookie. Unfortunately, there's some terminology muddling...AuthCookie calls it a session when it establishes that a user is a valid user and sets a cookie on their browser. Apache::Session considers a session a series of page hits from the same user. It assumes you've already done whatever you need to do to assure that the user is valid. So to expire a session in the sense of AuthCookie, you have to explicitly tell AuthCookie that a particular key is no longer valid, because otherwise everything about the AuthCookie cookie looks valid, and you'll have 'gphat' logged in validly from two different browsers. That's completely separate from the Apache::Session session, which has nothing on the client side (other than some method for obtaining the session id, which could be a cookie, a hidden form field, a munged URL, or in my case, the userid obtained from AuthCookie authentication). -Fran
Re: Enforcing user logged in from only 1 browser?
> It's #5 that's troublesome. I wasn't sure how I could expire the older > session (since the session key that matters is sitting client side). I > guess I could keep a table of invalidated session keys, and check > against that every time in along with all the other checks going on in > authen_ses_key(). I was just mainly asking if there was an existing > solution out there. I'm not sure I follow your session id problem. When I check a session, I ask the client for it's ID, then look the session up by ID. To 'expire' the session, I simply delete it from the session store (File or Postgres). Cory 'G' Watson
error compiling modperl2 debug
hi on my way to give a bug report on silver plate...without need to compute pointer arithmetics in head :) there is an error when compiling modperl 2 debug on NT i have perl version 5.6.1 build 629 from activestate i tried perl makefile.pl MP_INST_APACHE2=1 MP_AP_PREFIX=i:/apache2 MP_DEBUG=1 (apache 2.0.35 is compiled in debug version and installed in i:/apache2) I have a lot of messages like these command line warning d00042 : ignoring unknown option -g does this mean I have to rebuild perl itself with -Doptimize='- g' ? (thrilling from the only idea) without the debug flag it compiles and installs ok best regards pascal below bug report -8<--Start Bug Report 8<--- --- 1. Problem Description: perl makefile.pl MP_INST_APACHE2=1 MP_AP_PREFIX=i:/apache2 MP_DEBUG=1 is OK nmake FAILS at the end see section 3 2. Used Components and their Configuration: *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_AP_PREFIX=> i:/apache2 MP_DEBUG=> 1 MP_GENERATE_XS => 1 MP_INST_APACHE2 => 1 MP_LIBNAME => mod_perl MP_TRACE=> 1 MP_USE_DSO => 1 *** i:/apache2/bin/Apache.exe -V Server version: Apache/2.0.35 Server built: Apr 15 2002 15:22:46 Server's Module Magic Number: 20020329:0 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR="server/mpm/winnt" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/apache" -D SUEXEC_BIN="/apache/bin/suexec" -D DEFAULT_ERRORLOG="logs/error.log" -D SERVER_CONFIG_FILE="conf/httpd.conf" *** D:\Perl\bin\perl.exe -V Summary of my perl5 (revision 5 version 6 subversion 1) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi- thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef use5005threads=undef useithreads=define usemultiplicity=define useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cl', ccflags ='-nologo -O1 -MD -DNDEBUG -DWIN32 - D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT - DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS - DPERL_MSVCRT_READFIX', optimize='-O1 -MD -DNDEBUG', cppflags='-DWIN32' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='', ldflags ='-nologo -nodefaultlib -release - libpath:"D:\Perl\lib\CORE" -machine:x86' libpth="D:\Perl\lib\CORE" libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl56.lib Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib - release -libpath:"D:\Perl\lib\CORE" -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS Locally applied patches: ActivePerl Build 629 Built under MSWin32 Compiled at Aug 20 2001 12:27:04 %ENV: PERL_LWP_USE_HTTP_10="1" @INC: D:/Perl/lib D:/Perl/site/lib . 3. This is the core dump trace: (if you get a core dump): nmake Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cd "src/modules/perl" && NMAKE Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. link -out:..\..\..\blib\arch/Apache2 \auto\Apache\Filter\Filter.dll -dll -nologo -nodefaultlib - release -libpath:"D:\Perl\lib\CORE" -machine:x86 Filter.obj D:\Perl\lib\CORE\perl56.lib i:\apache2 \lib\libapr.lib i:\apache2\lib\libaprutil.lib i:\apache2 \lib\libhttpd.lib I:\mod_perl-1.99_01 \src\modules\perl\mod_perl.lib D:\VC98\lib\oldnames.lib D:\VC98 \lib\kernel32.lib D:\VC98\lib\user32.lib D:\VC98\lib\gdi32.lib D:\VC98\lib\winspool.lib D:\VC98\lib\comdlg32.lib D:\VC98 \lib\advapi32.lib D:\VC98\lib\shell32.lib D:\VC98 \lib\ole32.lib D:\VC98\lib\oleaut32.lib D:\VC98 \lib\netapi32.lib D:\VC98\lib\uuid.lib D:\VC98\lib\wsock32.lib D:\VC98\lib\mpr.lib D:\VC98\lib\winmm.lib D:\VC98 \lib\version.lib D:\VC98\lib\odbc32.lib D:\VC98 \lib\odbccp3
Re: Enforcing user logged in from only 1 browser?
[EMAIL PROTECTED] wrote: > How are you handling your sessions? I use Apache::Session::Postgres. I'm using AuthCookie. A customization of AuthCookieDBI to be specific. However, I also use Apache::Session. Basically, I authenticate with AuthCookie, then I pass the authenticated username over to Apache::Session::File (for now, probably soon to become A:S:Postgres) and use the user id as the session key. In that session I store user preferences, etc... > In my scenario, if I needed to do this, I would check the list of valid > sessions I have for one that exists for the user. ie, if 'gphat' tries to > login, I check to see if any of the sessions the db are for user gphat. If so, > eliminate it and create a new one. I can also detect if the user had an existing session already (I store the AuthCookie key in the db for each user). However, the question is just because there's an existing AuthCookie key, it doesn't mean they have another active session. It could just be an expired one. So, it seems the logic would go something like: 1. User logs in 2. Check for another session key for this user 3. If found, check to see if it's expired. 4. If not expired, alert user and ask if user wants to expire older session 5. Expire older session It's #5 that's troublesome. I wasn't sure how I could expire the older session (since the session key that matters is sitting client side). I guess I could keep a table of invalidated session keys, and check against that every time in along with all the other checks going on in authen_ses_key(). I was just mainly asking if there was an existing solution out there. The main requirement that we're trying to solve is that a user cannot be signed on from more than one location at once. Mainly because this probably means that they walked away from a computer with an active session on it, which isn't good. I suppose an inactivity timer might be helpful, too. Thanks, Fran
Re: "Kind-of" PerlSections, and location question
> > what I'm hoping to be able to do should only have to load the > settings once (the first time a request comes in for that location) > for each process, so I'm not too concerned about database access.. > > The main question I need answered first is, is this even possible? IIRC, Jay Lawrence was playing with this exact thing just a few months ago, but I don't know how it turned out. you might want to ping him about it privately if he doesn't catch this thread. HTH --Geoff
Re: "Kind-of" PerlSections, and location question
On Mon, 15 Apr 2002, Steven Lembark wrote:
> > Have a databae table that stores the information for each
> > setting, then load it dynamically as a request comes in...
> > mailer dream code:
> >
> > $ENV{REQUEST_URI} =~ /^\/(.*?)\//;
> > $base_path = $1;
> > if (!exists($Location{$base_path})) {
> > ... do database calls to load necessairy information
> > ... and set as if this was a perl section in an
> > ... httpd.conf file.
> > }
> >
> > ... then execute as if that location section was always there
> >
>
> Timestamping the database entry for the site might also
> help, since you wouldn't have to re-load the entire thing
> every time the site was hit.
>
what I'm hoping to be able to do should only have to load the
settings once (the first time a request comes in for that location)
for each process, so I'm not too concerned about database access..
The main question I need answered first is, is this even possible?
Dan.
[OT] Re: htaccess
Paul Williams wrote:
>
> -
> AuthUserFile /dev/null
> AuthGroupFile /dev/null
> RewriteEngine On
> RewriteCond %{HTTP_REFERER} !^http://www.myserver.com [NC]
> RewriteCond %{HTTP_REFERER} !^http://myserver.com [NC]
> RewriteRule /* http://www.myserver.com/error.mv [R,L]
> -
>
> My question is, instead of a RewriteRule that returns a page, how do i
> write it so it returns either A) nothing or, B) some text like "Not
> Found"?
>
Hi Paul,
maybe you want to tell the user, that it is forbidden to use a page of
your site coming from outside. So use as last rule:
RewriteRule .* - [F]
This will send the standard forbidden status (403) to the user. See:
http://httpd.apache.org/docs/misc/rewriteguide.html
But do NOT rely on the HTTP_REFERER, because some browsers don't send
it:
http://websiteowner.info/articles/pages/hotlinking.asp
Ernest
--
*
* VIRTUALITAS Inc. * *
** *
* European Consultant Office * http://www.virtualitas.net *
* Internationales Handelszentrum * contact:Ernest Lergon *
* Friedrichstraße 95 *mailto:[EMAIL PROTECTED] *
* 10117 Berlin / Germany * ums:+49180528132130266 *
*
PGP-Key http://www.virtualitas.net/Ernest_Lergon.asc
Re: "Kind-of" PerlSections, and location question
> Have a databae table that stores the information for each
> setting, then load it dynamically as a request comes in...
> mailer dream code:
>
> $ENV{REQUEST_URI} =~ /^\/(.*?)\//;
> $base_path = $1;
> if (!exists($Location{$base_path})) {
> ... do database calls to load necessairy information
> ... and set as if this was a perl section in an
> ... httpd.conf file.
> }
>
> ... then execute as if that location section was always there
>
> If there's a better solution then this, I'm also eager to
> hear it :)
Depending on the rate of server additions you might be
better off loading these at startup time or on a user
signal (e.g., $SIG{USR1} = \&reload_stuff_from_db).
Timestamping the database entry for the site might also
help, since you wouldn't have to re-load the entire thing
every time the site was hit.
--
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 800 762 1582
Re: Mod_perl slower than mod_cgi, Please Help!
VML wrote: > On Monday 15 April 2002 04:35 pm, you wrote: > >>VML wrote: >> >>>On Monday 15 April 2002 02:49 pm, you wrote: >>> Oh, boy, this is a wrong test :) You benchmark the code execution and not mod_perl against mod_cgi. You should use ab(8) or similar app for this. To learn how to properly do this and much more see: http://perl.apache.org/guide/performance.html p.s. also remember that doing wallclock benchmarking as in SCRIPT 1 on multitask system can give you very incorrect results, if you load is different during two subsequent benchmarks. >>> >>>Thank you for your answer. >>>Ab is Apachebench right? >>>The result is same, mod_perl slower than mod_cgi. >>> >>>% ./ab -n 100 -c 10 www.example.com/perl/test.pl >>> >>>Are there any testing method or tuning method that can show/prove >>>mod_perl is faster. >>> >>>I am newbie in mod_perl (even perl/cgi) so please as clear as posible. >>>I just got job in linux (previous windows) and my first task is to >>>migrating exiting perl script to better/faster method (now testing >>>mop_perl). Please help me... :) >> >>what's inside your test.pl? >> >>try this script: >> >>use CGI; >>print "Content-type: text/plain\n\n"; >>print "OK"; >> >>the re-load of CGI.pm in mod_cgi should make a big difference between >>mod_perl and mod_cgi. > > > Thanks!!! its show good result. > Forget about my test script :) ;) > But when I test big script I get "Segmentation Fault". > Do you know why is that? No, but read: http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/help.html#How_to_Report_Problems > I beginning to know logic behind mod_perl. > Mod_perl will show big different for script that use many module. > Am I right? Yes, see the performance chapter I've referred to earlier. p.s. please don't respond directly to me but to the list! 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
Re: mod_perl & memory
[EMAIL PROTECTED] wrote: > Hi all. > > Anybody knows, how to view detailed memory usage information > by perl modules. > > Such as > Module1::$var1 - memory size > Module1::$var2 - memory size > > > I can't solve memory leak problem with my site :( > > Thank for help. Apache::Status http://perl.apache.org/guide/performance.html#Measuring_the_Memory_Usage_of_Su -- __ 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
mod_perl & memory
Hi all. Anybody knows, how to view detailed memory usage information by perl modules. Such as Module1::$var1 - memory size Module1::$var2 - memory size I can't solve memory leak problem with my site :( Thank for help.
"Kind-of" PerlSections, and location question
I'm wondering if this is possible at all, and if so, how
to accomplish it...
We have an application we're serving by using the same
set of source code, and setting up different
sections in the virtual host to set different variables
and path aliases based on who the customer is...
But we have clusters of 6 servers in multiple locations,
with more such setups to come, and with the rate of having
to add sites because of new customers and temp sites for
sales demos, it's becoming difficult to manage so many
setups in this fashon, and restarting apache becomes more
and more an unpleasant thing to do with the more end-users
that are hitting it.
What I'd like to do (if even possible!), is have something
like this:
Have a databae table that stores the information for each
setting, then load it dynamically as a request comes in...
mailer dream code:
$ENV{REQUEST_URI} =~ /^\/(.*?)\//;
$base_path = $1;
if (!exists($Location{$base_path})) {
... do database calls to load necessairy information
... and set as if this was a perl section in an
... httpd.conf file.
}
... then execute as if that location section was always there
If there's a better solution then this, I'm also eager to
hear it :)
Dan.
Re: Mod_perl slower than mod_cgi, Please Help!
[ whenever someone replies to your question on the list, please keep the replies CC'ed to the list, unless you were asked to make the thread private. don't be shy to continue solving your problem in public, other benefit from this as well.] VML wrote: > On Monday 15 April 2002 02:49 pm, you wrote: > > >>Oh, boy, this is a wrong test :) You benchmark the code execution and >>not mod_perl against mod_cgi. You should use ab(8) or similar app for this. >>To learn how to properly do this and much more see: >>http://perl.apache.org/guide/performance.html >> >>p.s. also remember that doing wallclock benchmarking as in SCRIPT 1 on >>multitask system can give you very incorrect results, if you load is >>different during two subsequent benchmarks. > > > Thank you for your answer. > Ab is Apachebench right? > The result is same, mod_perl slower than mod_cgi. > > % ./ab -n 100 -c 10 www.example.com/perl/test.pl > > Are there any testing method or tuning method that can show/prove mod_perl is > faster. > > I am newbie in mod_perl (even perl/cgi) so please as clear as posible. > I just got job in linux (previous windows) and my first task is to migrating > exiting perl script to better/faster method (now testing mop_perl). > Please help me... :) what's inside your test.pl? try this script: use CGI; print "Content-type: text/plain\n\n"; print "OK"; the re-load of CGI.pm in mod_cgi should make a big difference between mod_perl and mod_cgi. Also are you sure you are running under mod_perl? http://perl.apache.org/guide/install.html#How_can_I_tell_whether_mod_perl_ Also see this section: http://perl.apache.org/guide/performance.html#Configuration_Tuning_with_Apache __ 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
Re: How to report problems with modperl 2.0
Stas Bekman wrote: > At this time some people will try to run incorrect versions of Apache > and mod_perl and this will cause to most of your problems. So before we > attempt to answer your questions, you have to tell us what versions you > were using. Therefore: > > Whenever you have a problem, first run: > > t/REPORT > report > > which generates all the info that we need. > Now add the description of the problem where it says so, add a coredump > if relevant where it says so and send it here with a nice descriptive > subject. > > Also remember that Apache 2.0 and mod_perl 2.0 weren't released yet and > things change. So if you want to try building things, you must use the > *released* mod_perl 1.99 with *released* Apache 2.0.35 and not mixing up > with cvs versions. This will save you a lot of trouble. > > Also whenever you have problems with interfaces grep for examples in the > t/ directory. There are many tests there, which exercise most of the > mod_perl 2.0. Chances are that if you look there, you will find your > problem solved already. I've put some of this info online http://perl.apache.org/preview/modperl-docs/dst_html/docs/2.0/user/help/help.html#Reporting_Problems -- __ 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
Re: Apache::ServerUtil pb in modperl2
pascal barbedor wrote:
>
>
> apache 2.0.35 / mod_perl 1.99_01 / winnt or win2k
You don't say which perl version you are using. Please remember to run
t/REPORT when sending bug reports. If this is 5.6.0 before we continue,
first update to 5.6.1. 5.6.0 is very buggy. 5.6.1 is very stable.
> I confirm that using a module in startup.pl consisting of
>
>
>>use Data::Dumper ;
>>use XML::LibXML() ;
>>
>>[1] use Apache::ServerUtil ;
>>[2] my $s=Apache->server ;
>>[3] my $base=$s->dir_config('some');
>>[4] my $xml=XML::LibXML->new();
>>[5] print Dumper $xml ;
I cannot reproduce this problem with the same setup and perl 5.6.1 on
linux. i.e. I run the whole test suite without any segfaults.
> here is a backtrace in case useful
>
> PERL56! 28021683()
> PERL56! 28071c17()
> PERL56! 2805c910()
you realize that this bt is not useful :) even if we knew to do the
easily pointer
arithmetics in our head :) You need to recompile your perl and mod_perl
with debugging enabled.
(at least mod_perl to start with). Use MP_DEBUG=1 when building mod_perl
2.0's Makefile.PL.
I'll prepare a proper doc how to build mod_perl for debuggging and
report bugs with 2.0.
For now if you need to recompile perl with debug mode on please use the
info at:
http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/help.html#How_to_Report_Problems
__
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
Re: Mod_perl slower than mod_cgi, Please Help!
VML wrote:
> Hi All,
> Our company planning to move from Perl/CGI to mod_perl.
> But when we test, mod_perl is slower than mod_cgi.
>
> I test with these script:
>
> # TESTING SCRIPT 1
> use Time::HiRes qw(usleep ualarm gettimeofday tv_interval);
> $t0 = [gettimeofday];
> # CODE HERE
> $t1 = [gettimeofday];
> $t0_t1 = tv_interval $t0, $t1;
> $elapsed = tv_interval ($t0, [gettimeofday]);
> $elapsed = tv_interval ($t0);
> print "$elapsed sec\r\n";
> And
> # TESTING SCRIPT 2
> use Benchmark;
> timethis (1000,
> sub {
> # CODE HERE
> }
> );
>
> Both result are same, mod_perl is slower than mod_cgi.
Oh, boy, this is a wrong test :) You benchmark the code execution and
not mod_perl against mod_cgi. You should use ab(8) or similar app for this.
To learn how to properly do this and much more see:
http://perl.apache.org/guide/performance.html
p.s. also remember that doing wallclock benchmarking as in SCRIPT 1 on
multitask system can give you very incorrect results, if you load is
different during two subsequent benchmarks.
__
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
Mod_perl slower than mod_cgi, Please Help!
Hi All,
Our company planning to move from Perl/CGI to mod_perl.
But when we test, mod_perl is slower than mod_cgi.
I test with these script:
# TESTING SCRIPT 1
use Time::HiRes qw(usleep ualarm gettimeofday tv_interval);
$t0 = [gettimeofday];
# CODE HERE
$t1 = [gettimeofday];
$t0_t1 = tv_interval $t0, $t1;
$elapsed = tv_interval ($t0, [gettimeofday]);
$elapsed = tv_interval ($t0);
print "$elapsed sec\r\n";
And
# TESTING SCRIPT 2
use Benchmark;
timethis (1000,
sub {
# CODE HERE
}
);
Both result are same, mod_perl is slower than mod_cgi.
How to make it faster?
I already tried to pre-load the modul when apache start with startup.pl but
no effect.
Here is my httpd.conf
Alias /perl/ /var/www/cgi-bin/
Perlrequire /var/www/cgi-bin/startup.pl
PerlModule Apache::Registry
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
PerlSendHeader On
Here is my startup.pl
#/usr/bin/perl
use strict;
# make sure we are in a sane environment.
# ENV{GATEWAY_INTERFACE} =~ /^CGI-Perl/ or die "GATEWAY_INTERFACE not Perl!";
use Apache::Registry(); # for things in the "/programs" URL
# pull in things we will use in most requests so it is read and compiled
# exactly once
use Apache::RegistryLoader();
Apache::RegistryLoader->new->handler("/perl/timeres.pl","/var/www/cgi-bin/timeres.pl");
use CGI (); CGI->compile(':all');
#use CGI::Carp ();
use DBI ();
use DBD::mysql ();
1;
Any help would be appreciate.
Thank you,
Ricky
Re: bug: calling setlocale(LC_ALL,) more than once crashes httpd with mod_perl
On Mon, 15 Apr 2002, Stas Bekman wrote: > > > > Unfortunately, I don't have time for compiling and installing it.. > > I hope somebody on this list who has already installed version of recent perl > > will test the problem.. > > Confirmed as working with bleadperl (i.e the latest perl-5.7.3) > > Also confirmed as working with the stock 5.6.1 perl on linux. > > So I'd suggest to upgrade to 5.6.1 if possible as the safest step, > before 5.8.0 is released. > > All tested with Apache/1.3.25-dev (Unix) mod_perl/1.26_01-dev but the > non-cvs version should probably work the same way. Thank you very much for this research and suggestions! Thanks! Best regards, -Vlad
