Re: TIPool / multiple database connections
Hi,
I am a little late for the thread, nevertheless I like to give experiences I
gathered trying to get DBI threadafe. As Stas already said before in this
thread I have made a patch to DBI which makes DBI threadsafe. The result is
released in DBI 1.30. This doesn't mean that the DBD driver can handles
this, but mostly it's not hard to add.
Threadsafe means not that you can share any sort of DBI handles. It's means
that it's safe to use DBI with threads and that it is made sure that every
intances of the Perl interpreter (i.e. every thread) gets it own instance of
DBI.
My inital goal was to share DBI handles between threads, but this would need
very much work inside DBI. Additionaly Perl does not yet support sharing of
objects (BTW share does not deep share data structures). So Tim suggested to
first make DBI work correctly with threads at all. That's what we have done.
Gerald
P.S. I have some experimental code to share database handles inside of
DBD::Oracle, since this was much easier to implement, but this is not quite
ready yet.
-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131
WWW:http://www.ecos.de Fax: +49 6133 925152
-
- Original Message -
From: Elizabeth Mattijsen [EMAIL PROTECTED]
To: Stas Bekman [EMAIL PROTECTED]; Perrin Harkins [EMAIL PROTECTED]
Cc: Tim Keefer [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, July 16, 2002 11:17 AM
Subject: Re: TIPool / multiple database connections
At 02:57 PM 7/16/02 +, Stas Bekman wrote:
Perrin Harkins wrote:
Hmmm... That could really throw a wrench in things. If you have an
object based on a hash, and you share that hash, and you re-bless the
object in each thread, does that work? What if the hash contains
references to other variables. Do they need to be explicity shared as
well?
That's what I meant. Probably non need for Thread::Pool, at all. use a
shared datastructure, maintain a list of free and busy items and simply
hand pointers inside this datastructure to the threads asking for an
item.
e.g.:
package DBI::Pool;
use threads::shared;
my @pool : shared;
sub init {} # pre-populate pool with N connections
sub get {} # return a ref to $dbh, grow the pool if needed
sub put {} # move the pointer from the busy list to the free list
Hmmm... as long as you do this _before_ the (Apache) threads get started,
this might work. I still haven't got my mind entirely around what one is
allowed to do, what you can do and is allowed, what you can't do but is
allowed and crashes, and what in principle is possible but you're barred
from because of e.g. prototyping getting in the way.
won't this work? I guess Perrin is right in respect that the whole item
needs to be shared (deep-shared). can we have such an attribute/function
that will automatically traverse the datastructure and share it all? or
is
this the case already with 'shared'?
Good question. I don't think it is deep shared and that's why it probably
doesn't work. The way Thread::Queue::Any (which is the transport medium
for Thread::Pool) handles this, is by serializing any data structure with
Storable, pass that around and deserialize that on the other end.
Now since we want to have various connections, it can be:
my %pools : shared;
where each key is a unique identifier, compiled from the dbi connect's
DSN string and a value is the actual pool.
That's an approach. If you could actually share the $sth objects. About
which I have my doubts.
BTW, there is no more need for Apache prefix in Apache::DBI, this can be
a
generic Pool class. I guess Apache::DBI can subclass DBI::Pool and add
things like connect_on_init(), but just to build the initial pool when
the
process starts.
DBI::Pool would be ok. But unless I'm wrong about the sharing issues,
you're going to be stuck, at least with this version of Perl, with
serializing between threads.
Liz
Local file security (in 1.27)
I'm developing an online survey system under mod_perl (with a homemade perlhandler, not under Apache::Registry). Since I've had as a goal to avoid as many dependencies as possible, I store results in local plaintext files. By nature, these files has (?) to be writable by the uid apache runs as. In the mod_perl documentation it is written: When a handler needs write permissions, make sure that only the user, the server is running under, has write permissions to the files. Sometimes you need group write permissions, but be very careful, because a buggy or malicious code run in the server may destroy files writable by the server My files fit this description (the files are chmodded 600). However, as the system is intended for academic use, and it is not entirely uncommon to have one student web server for everything, I cannot force admins not to install (as an example) PHP with default options and allowing the students to write PHP scripts. In PHP, to completely remove all my stored data with one line of code: ? passthru(rm -rf /usr/local/mod_survey/data/*) ? Now, this is obviously a flaw with (in descending order) PHP for not having an installation with a secure default configuration, and with the admins for giving untrusted users access to an inherently insecure scripting language. However, the problem ends up being mine as I have to handle it somehow. So, question is: How do I protect my data files from being accessed by anything else than my own perlhandler? Can I set another uid for all that has to do with my specific perlhandler? Hints are most welcome. // Joel
[Newbie Q] Running into strange 420-character POST limit.
Apologies in advance for a question that may or may not make any sense. Fact is, there seems to be no other place to go but here to find a healthy collection of Apache + mod_perl + experience. Mailing list archive searches of mine must be targetting the wrong keywords because nothing has helped. Setup: Apache/1.3.26 (Win32) and mod_perl/1.26_01-dev. Internet Explorer 6.0.26 and Mozilla 1.0 (2002053012) on the browser end. Let my newbie roots show. :) Problem: I am writing a very basic discussion form under the above platform. When a form reply is POSTed with a CONTENT_LENGTH greater than 420 characters, all data from the form seems to get wiped out. Example: A) CONTENT_LENGTH: 153 CONTENT_TYPE: application/x-www-form-urlencoded Message body Apache/mod_perl actually see: A simple test. I don't ask that goddamn much from you, mod_perl. WHY MUST YOU DO THIS? Message body Apache/mod_perl actually see: A simple test. I don't ask that goddamn much from you, mod_perl. WHY MUST YOU DO THIS? B) CONTENT_LENGTH: 859 CONTENT_TYPE: application/x-www-form-urlencoded Message body Apache/mod_perl actually see: Blank. Message body: With ATIs unique positioning in the value space with RADEON 9000 PRO, what does it compete with? Officially, the answer is NVIDIAs GeForce4 MX series. The MSRP of the RADEON 9000 PRO matches up very closely with GeForce4 MX 440, while the RADEON 9000s equivalent would be the GeForce4 MX 420. But in the real world, things are much more complicated than that. NVIDIA has two GeForce4 Ti 4200 variants with street prices that are very competitive with RADEON 9000 PRO. And if that wasnt enough, making things even more complicated are RADEON 8500 and RADEON 8500LE cards manufactured by ATI and its partners that are also selling within a handful of dollars of the RADEON 9000 PRO. But before we get into those aspects in more detail, lets discuss the roots of the RADEON 9000/RADEON 9000 PRO. Answer: You tell me! :) A problem with Apache? A problem with mod_perl? A problem with IE/Mozilla? Do I need to be posting large forms such as this using multipart/form-data with mod_perl? Please. Help. Ever humble, S. Syed -- A computer lets you make more mistakes faster than any invention in human history - with the possible exceptions of handguns and tequila. -- Mitch Ratliffe
RE: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails
Hmm.. I have only this week compiled the exact same versions of Apache and mod_perl on Solaris 2.6, without any problems. I'd suggest to get the latest gcc from: ftp://ftp.sunfreeware.com/pub/freeware/sparc/2.6/gcc-3.1-sol26-sparc-local.g z And it won't hurt to renew zlib,ncurses and gdbm either while you're at it: ftp://ftp.sunfreeware.com/pub/freeware/sparc/2.6/zlib-1.1.4-sol26-sparc-loca l.gz ftp://ftp.sunfreeware.com/pub/freeware/sparc/2.6/ncurses-5.2-sol26-sparc-loc al.gz ftp://ftp.sunfreeware.com/pub/freeware/sparc/2.6/gdbm-1.8.0-sol26-sparc-loca l.gz Hope it helps. Cheers, Michiel -Original Message- From: John E. Mendenhall [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 31, 2002 23:26 To: [EMAIL PROTECTED] Subject: re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails I have compiled mod_perl 1.27 with apache 1.3.26 under perl 5.6.1, solaris 2.6. When I run the make test, it fails with the following in the error_log: [notice] Destruction-DESTROY called for $global_object Prototype mismatch: sub Socket::INADDR_ANY vs () at /usr/local/lib/perl5/5.6.1/sun4-solaris/Socket.pm line 329. Prototype mismatch: sub Socket::INADDR_BROADCAST vs () at /usr/local/lib/perl5/5.6.1/sun4-solaris/Socket.pm line 330. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/local/lib/perl5/5.6.1/sun4-solaris/Socket.pm line 331. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/local/lib/perl5/5.6.1/sun4-solaris/Socket.pm line 332. [Wed Jul 31 14:12:36 2002] [warn] [notice] child_init for process 10483, report any problems to [no address given] This might all be fine and good, but when the test tries to retrieve the test.html document, the server immediately stops, with no other messages anywhere. If I start the httpd daemon separately from running the tests (make start_httpd), it starts just fine. If I attach a truss to the single process (running under -X), then run the tests (make run_tests), I get these errors: --- truss log --- # truss -p 10483 accept(16, 0xE8F0, 0xE8EC) (sleeping...) accept(16, 0xE8F0, 0xE8EC) = 3 fcntl(17, F_SETLKW64, 0x001994C8) = 0 sigaction(SIGUSR1, 0xE730, 0xE830) = 0 getsockname(3, 0xE900, 0xE8EC) = 0 setsockopt(3, 6, 1, 0xE86C, 4) = 0 brk(0x006E9000) = 0 brk(0x006EB000) = 0 brk(0x006EB000) = 0 brk(0x006ED000) = 0 alarm(300) = 0 read(3, G E T / t e s t . h t.., 4096) = 98 sigaction(SIGUSR1, 0xEFFFD640, 0xEFFFD740) = 0 time() = 1028149998 alarm(300) = 300 alarm(0)= 300 stat64(/usr/local/src/mod_perl/mod_perl-1.27/t/docs/test.html, 0x006E91E8) = 0 open64(/usr/local/src/mod_perl/mod_perl-1.27/t/.htaccess, O_RDONLY) Err#2 ENOENT open64(/usr/local/src/mod_perl/mod_perl-1.27/t/docs/.htaccess, O_RDONLY) = 5 fstat64(5, 0xE5C0) = 0 fstat64(5, 0xEFFFD420) = 0 brk(0x006ED000) = 0 brk(0x006EF000) = 0 ioctl(5, TCGETA, 0xEFFFD3AC)Err#25 ENOTTY read(5, , 8192) = 1 read(5, 0x006EB104, 8192) = 0 read(5, 0x006EB104, 8192) = 0 llseek(5, 0, SEEK_CUR) = 1 close(5)= 0 Incurred fault #6, FLTBOUNDS %pc = 0x0002D6F0 siginfo: SIGSEGV SEGV_MAPERR addr=0x0018 Received signal #11, SIGSEGV [caught] siginfo: SIGSEGV SEGV_MAPERR addr=0x0018 sigprocmask(SIG_SETMASK, 0xEF567D90, 0x) = 0 sigaction(SIGSEGV, 0xE140, 0x) = 0 sigprocmask(SIG_SETMASK, 0xEF570A90, 0x) = 0 setcontext(0xE300) Incurred fault #6, FLTBOUNDS %pc = 0x0002D6F0 siginfo: SIGSEGV SEGV_MAPERR addr=0x0018 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x0018 *** process killed *** # --- truss log end --- I have used mod_perl up through versions 1.15, using perl 5.004_04, earlier versions of Apache. I am trying to upgrade to the latest stable releases of everything and it just does not seem to be working. I have checked the list archives as well as google and anywhere else I could think of and could not find why it is dying. Any help is appreciated. Thank you very much. JohnM ## John Mendenhall ## [EMAIL PROTECTED] ## Senior Network/Systems Administrator
Re: Local file security (in 1.27)
[...] So, question is: How do I protect my data files from being accessed by anything else than my own perlhandler? Can I set another uid for all that has to do with my specific perlhandler? Hints are most welcome. You can't. The only solution is run a dedicated server for each user. Currently the pure Apache solution is to use suexec, which you cannot run under mod_perl. This is all covered at: http://perl.apache.org/docs/general/multiuser/multiuser.html this issue will be addressed in 2.0 with perchild Apache mpm which allows you to run different groups of servers/threads under different uids/gids. If I remember correctly this mpm is highly experimental at this point. __ 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: Fwd: Re: Apache::DBI as a prerequisite
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On July 30, 2002 10:02 pm, Stas Bekman wrote: 2) See http://perl.apache.org/docs/2.0/devel/testing/testing.html Though you can really rely on it once Apache::Test is released, which will happen when mod_perl 2.0 is released. 1) That's an interesting problem. It seems that nobody has asked this question before. Here is my take on it. If you like this solution I'll add it to the docs. Thanks a lot. Your solution for Apache::DBI works and is very Perlish! - -- Simon Perreault [EMAIL PROTECTED] Web: http://www.linuxquebec.com/~nomis80 PGP: $Web/nomis80.gpg -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9R94IqaCdwBMK2KkRAn9IAKCJ7UlIztV6MlThz8Y79b7+FbEGAQCZAdE+ 3yP5wB/0udz2Rkgkvh+2S4U= =ETSh -END PGP SIGNATURE-
Re: Local file security (in 1.27)
So, question is: How do I protect my data files from being accessed by
anything else than my own perlhandler? Can I set another uid for all that
has to do with my specific perlhandler? Hints are most welcome.
// Joel
Maybe you are facing the same problem, that I asked earlier in this
list? Question: http://groups.yahoo.com/group/modperl/message/43025
The only solution I came with was to patch mod_perl.c and mod_perl.h
with settings that disable handlers except from httpd.conf. At least I
think these attached patches should do the trick... ;-)
Best wishes, Kari
--- mod_perl.h Thu Jul 18 07:58:54 2002
+++ mod_perl.h.new Thu Jul 18 08:00:48 2002
-768,7 +768,7
#define PERL_DISPATCH_CMD_ENTRY \
PerlDispatchHandler, (crft) perl_cmd_dispatch_handlers, \
NULL, \
-OR_ALL, TAKE1, the Perl Dispatch handler routine name
+RSRC_CONF | ACCESS_CONF, TAKE1, the Perl Dispatch handler routine name
#define PERL_DISPATCH_CREATE(s) s-PerlDispatchHandler = NULL
#else
-875,7 +875,7
#define PERL_AUTHEN_CMD_ENTRY \
PerlAuthenHandler, (crft) perl_cmd_authen_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Authentication handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Authentication handler routine name
#define PERL_AUTHEN_CREATE(s) s-PerlAuthenHandler = PERL_CMD_INIT
#else
-892,7 +892,7
#define PERL_AUTHZ_CMD_ENTRY \
PerlAuthzHandler, (crft) perl_cmd_authz_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Authorization handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Authorization handler routine name
#define PERL_AUTHZ_CREATE(s) s-PerlAuthzHandler = PERL_CMD_INIT
#else
#define PERL_AUTHZ_HOOK NULL
-908,7 +908,7
#define PERL_ACCESS_CMD_ENTRY \
PerlAccessHandler, (crft) perl_cmd_access_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Access handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Access handler routine name
#define PERL_ACCESS_CREATE(s) s-PerlAccessHandler = PERL_CMD_INIT
#else
-927,7 +927,7
#define PERL_TYPE_CMD_ENTRY \
PerlTypeHandler, (crft) perl_cmd_type_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Type check handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Type check handler routine name
#define PERL_TYPE_CREATE(s) s-PerlTypeHandler = PERL_CMD_INIT
#else
-944,7 +944,7
#define PERL_FIXUP_CMD_ENTRY \
PerlFixupHandler, (crft) perl_cmd_fixup_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Fixup handler routine name
+RSRC_CONF, PERL_TAKE, the Perl Fixup handler routine name
#define PERL_FIXUP_CREATE(s) s-PerlFixupHandler = PERL_CMD_INIT
#else
-961,7 +961,7
#define PERL_LOG_CMD_ENTRY \
PerlLogHandler, (crft) perl_cmd_log_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Log handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Log handler routine name
#define PERL_LOG_CREATE(s) s-PerlLogHandler = PERL_CMD_INIT
#else
-978,7 +978,7
#define PERL_CLEANUP_CMD_ENTRY \
PerlCleanupHandler, (crft) perl_cmd_cleanup_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Cleanup handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Cleanup handler routine name
#define PERL_CLEANUP_CREATE(s) s-PerlCleanupHandler = PERL_CMD_INIT
#else
-995,7 +995,7
#define PERL_INIT_CMD_ENTRY \
PerlInitHandler, (crft) perl_cmd_init_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Init handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Init handler routine name
#define PERL_INIT_CREATE(s) s-PerlInitHandler = PERL_CMD_INIT
#else
-1012,7 +1012,7
#define PERL_HEADER_PARSER_CMD_ENTRY \
PerlHeaderParserHandler, (crft) perl_cmd_header_parser_handlers, \
NULL, \
-OR_ALL, PERL_TAKE, the Perl Header Parser handler routine name
+RSRC_CONF | ACCESS_CONF, PERL_TAKE, the Perl Header Parser handler routine name
#define PERL_HEADER_PARSER_CREATE(s) s-PerlHeaderParserHandler = PERL_CMD_INIT
#else
--- mod_perl.c Thu Jul 18 07:58:53 2002
+++ mod_perl.c.new Thu Jul 18 08:00:29 2002
-107,13 +107,13
RSRC_CONF, FLAG, Turn on -w switch },
{ PerlScript, (crft) perl_cmd_require,
NULL,
- OR_ALL, ITERATE, this directive is deprecated, use `PerlRequire' },
+ RSRC_CONF | ACCESS_CONF, ITERATE, this directive is deprecated, use
+`PerlRequire' },
{ PerlRequire, (crft) perl_cmd_require,
NULL,
- OR_ALL, ITERATE, A Perl script name, pulled in via require },
+ RSRC_CONF | ACCESS_CONF, ITERATE, A Perl script name, pulled in via require },
{ PerlModule, (crft) perl_cmd_module,
NULL,
- OR_ALL, ITERATE, List of Perl modules },
+ RSRC_CONF | ACCESS_CONF, ITERATE, List of Perl modules },
{ PerlSetVar, (crft) perl_cmd_var,
NULL,
OR_ALL, TAKE2, Perl config var and value },
-122,19 +122,19
OR_ALL, ITERATE2, Perl config var and value
Re: [Newbie Q] Running into strange 420-character POST limit.
On Thu, Aug 01, 2002 at 03:51:09AM -0400, sully wrote: Answer: You tell me! :) A problem with Apache? A problem with mod_perl? A problem with IE/Mozilla? Do I need to be posting large forms such as this using multipart/form-data with mod_perl? Please. Help. Have you tried just regular get? It might give you some clue as to what's happening to the data. I've never had to provide a content type when submitting form, except on those forms where I upload files. Also, check that you're not reading the post content more than once. Sometimes on small requests you can read the post content twice, but on larger requests, it'll fail. I remember having this problem 5 years ago, under IIS, so it may not apply. You can also try running tcpdump or other packet sniffing software to see what's really being transmitted between client and server. Good luck, Rob
Re: Mandrake default mod_perl dose not seem to be working.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Some how the mod_perl was missing some files. A --force reinstall of the RPM file fixed it. mod_perl is working now and I understand it much better. Though my goal is to get Mason working and it still does not. Thanks everyone for the help. - -- Roy Souther [EMAIL PROTECTED] http://www.SiliconTao.com Linux, resisting tyranny. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj1JRHIACgkQCbnxcmEBt41p7ACg2Xm6wHdxBjK7kWqzPLobGWAy gd0AoMLMHFQr1Jm6/e9i1bXdC9GYInv3 =x0w1 -END PGP SIGNATURE-
Re: $r-dir_config-(un)set issue...
The following pices of code do not work:
-
code sample 1
--
1. sub handler {
2.my $r = instance Apache::Request(shift);
3.
4.$r-dir_config(MyVar = undef);
5.
6.$r-dir_config-unset(MyVar);
7.
8.$r-dir_config-set(MyVar = undef);
9.
10. }
None of lines 4, 6 or 8 actually unset the variable.
did you try $r-server-dir_config-unset(MyVar) as well?
the dir_config table is a bit strange, since it merges per-server and
per-directory configurations at runtime - from what I remember when
playing with this last time, if you remove it from the per-dir config
but you set it on a per-server config (which sounds like what you are
doing) it will be perpetually re-populated on access to the per-dir
config. so, you may need to wipe both dir_config tables clean in
order to really unset the variable from your handler.
HTH
--Geoff
Re: [ANNOUNCE] StateMachine::Gestinanna 0.01
On Wed, Jul 31, 2002 at 09:08:54PM -0500, James G Smith wrote: My apologies. np :). It's fun to prattle on about my babies ;). The StateML:: stuff does sound neat though :) I'm wanting to eventually put together a gui for creating web-based wizard-like applications -- draw the circles and the lines, hang a few requirements off the edges, and you almost have an app. And with the OO stuff, the apps can be sub-classed. I came *this* close to doing this sort of thing for the last webapp I did, a survey tool, but the design put all the pages in a linear sequence and I just couldn't bring myself to add StateML in to the mix :). I have so many things I want to do with this: getting a dia-based editor or an SVG based editor is a prime goal (I'm not wed to dia or SVG, but the former I know a little bit about the source code of and the latter is sexy and can be run-in-browser w/ a plugin). Using it for Workflow apps, etc. is also a possibility, but need clients needing these things, I'm afraid. - Barrie
[Newbie Q] Cleanest way to implement one logon per user?
Title: [Newbie Q] Cleanest way to implement one logon per user? Hello. I am hoping someone can point me in the right direction. What I want to do is limit client logons to one logon per username ie while a client has a session open, he/she cannot logon to the website from another terminal. Platform: Apache 1.3.x with mod_perl DBI I have looked high and low, gone through Apache book after book with no measurable success (mod_usertrack mod_session are the only modules briefly mentioned). If someone could just point me in the right direction, I will gladly do all the required research. TIA, Ballay :)
Re: [Newbie Q] Cleanest way to implement one logon per user?
Baljit Sethi wrote: What I want to do is limit client logons to one logon per username ie while a client has a session open, he/she cannot logon to the website from another terminal. The simplest thing to do is create a new session for the user each time he logs in and invalidate any old sessions this user may have. This assumes you are talking about actual logins, not just sessions for anonymous browsers. - Perrin
Re: [Newbie Q] Cleanest way to implement one logon per user?
This isn't strictly a mod_perl thing but this is probably the safest way to make this happen. This happens to be how I've created a secure (by my definition. correct me if I get something wrong) web application. Pipe everything through an SSL tunnel The initial logon is username + password. A session id # is incremented and stored on the web client in a cookie. A md5 hash of that session id and a stored secret on the server is also passed to the web client and stored in a cookie. From here on out the web client must present an accurate session id # + md5 hash. While the session # is predictable it is guaranteed to be unique. The hash prevents users from modifying the session# since an attacker would not be able to create the correct hash for other session #s. So from there a user session table only holds one stored session # / hash per username. This would allow one authenticated user to have many open windows but would not allow multiple sessions per user. You can extend this concept to force a user to use only a single browser window though that is pretty draconian. Josh Baljit Sethi [EMAIL PROTECTED] 08/01/2002 02:08 PM To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] cc: Subject:[Newbie Q] Cleanest way to implement one logon per user? Hello. I am hoping someone can point me in the right direction. What I want to do is limit client logons to one logon per username ie while a client has a session open, he/she cannot logon to the website from another terminal. Platform: Apache 1.3.x with mod_perl DBI I have looked high and low, gone through Apache book after book with no measurable success (mod_usertrack mod_session are the only modules briefly mentioned). If someone could just point me in the right direction, I will gladly do all the required research. TIA, Ballay :)
Re: [Newbie Q] Cleanest way to implement one logon per user?
On Thu, Aug 01, 2002 at 03:08:40PM -0400, Baljit Sethi wrote: Hello. I am hoping someone can point me in the right direction. What I want to do is limit client logons to one logon per username ie while a client has a session open, he/she cannot logon to the website from another terminal. The problem isn't determining when they've logged in, but determining when they've logged out. While it may be possible to write a record to the db that contains username, password, and IP address, it does not gaurentee that the user's ip address will not change mid session. (cable modem disconnect and reconnects with new ip, transparent to the user.) The short answer is, you can't. The long answer is that you can, but it takes way more work than it's worth. The only way I've seen is to set a cookie (encrypted) on the client's machine and flag the user as logged in. If the user tries to log in again (from anywhere), it rejects it. Only if the original client connects and clicks logout (and the cookie still exists) does it actually remove the flag (and the cookie). The drawback here is that if any user ever deletes their cookies before logging out, they're screwed, and will call asking you to fix it. Good luck, Rob
Re: [Newbie Q] Cleanest way to implement one logon per user?
The drawback could probably be at least partially mitigated with an inactivity timeout. When they attempt to login, you check both the flag and the last time you heard from them. If they had timed out, then you log them out and let them go ahead and try to log in. It does cost an extra database write on each request though, to keep the last activity time up to date. Wes Robert Landrum [EMAIL PROTECTED] on 08/01/2002 03:28:05 PM To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Re: [Newbie Q] Cleanest way to implement one logon per user? On Thu, Aug 01, 2002 at 03:08:40PM -0400, Baljit Sethi wrote: Hello. I am hoping someone can point me in the right direction. What I want to do is limit client logons to one logon per username ie while a client has a session open, he/she cannot logon to the website from another terminal. The problem isn't determining when they've logged in, but determining when they've logged out. While it may be possible to write a record to the db that contains username, password, and IP address, it does not gaurentee that the user's ip address will not change mid session. (cable modem disconnect and reconnects with new ip, transparent to the user.) The short answer is, you can't. The long answer is that you can, but it takes way more work than it's worth. The only way I've seen is to set a cookie (encrypted) on the client's machine and flag the user as logged in. If the user tries to log in again (from anywhere), it rejects it. Only if the original client connects and clicks logout (and the cookie still exists) does it actually remove the flag (and the cookie). The drawback here is that if any user ever deletes their cookies before logging out, they're screwed, and will call asking you to fix it. Good luck, Rob
Re: [Newbie Q] Cleanest way to implement one logon per user?
Oh yes, changing IPs. I hear that WebTV terminals may have different IP addresses per each HTTP request. I suppose the specific behaviour you want on the event 'user A at station A is authenticated. user A at station B attempts to authenticate'. I handle that by expiring the original session and keeping the new one. You could take Robert's advice and force the user A at station A to logout first but that's a management headache. I use my SQL database to enforce timeouts. If you examine this PostgreSQL SQL code you'll notice that while the session records are stored in UserSession that checks for *valid* sessions are done agains the ValidSession view. That view ensures that stale sessions are not considered. The full database including schema may be downloaded from my home page at http://www.greentechnologist.org/downloads/jbj-0731.tgz. That's a reference to *one* possible implementation anyway. CREATE TABLE UserSession ( SessionID INTEGER PRIMARY KEY, SessionDigest TEXT CHECK (length(SessionDigest) IN (40, 30)) NOT NULL, UserId INTEGER NOT NULL UNIQUE REFERENCES Users (ObjectId) ON DELETE CASCADE ON UPDATE CASCADE, Created TIMESTAMP NOT NULL DEFAULT current_timestamp, Modified TIMESTAMP NOT NULL DEFAULT current_timestamp ); -- Uninitialized and stale sessions don't appear CREATE VIEW ValidSession AS SELECT s.*, u.Username AS activeuser FROMUserSession AS s, ValidUsers AS u WHERE s.UserId = u.ObjectId AND s.Modified = current_timestamp - '15 minutes'::interval AND s.SessionDigest != ''::text; Robert Landrum [EMAIL PROTECTED] 08/01/2002 02:28 PM To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] cc: Subject:Re: [Newbie Q] Cleanest way to implement one logon per user? On Thu, Aug 01, 2002 at 03:08:40PM -0400, Baljit Sethi wrote: Hello. I am hoping someone can point me in the right direction. What I want to do is limit client logons to one logon per username ie while a client has a session open, he/she cannot logon to the website from another terminal. The problem isn't determining when they've logged in, but determining when they've logged out. While it may be possible to write a record to the db that contains username, password, and IP address, it does not gaurentee that the user's ip address will not change mid session. (cable modem disconnect and reconnects with new ip, transparent to the user.) The short answer is, you can't. The long answer is that you can, but it takes way more work than it's worth. The only way I've seen is to set a cookie (encrypted) on the client's machine and flag the user as logged in. If the user tries to log in again (from anywhere), it rejects it. Only if the original client connects and clicks logout (and the cookie still exists) does it actually remove the flag (and the cookie). The drawback here is that if any user ever deletes their cookies before logging out, they're screwed, and will call asking you to fix it. Good luck, Rob
Re: [Newbie Q] Cleanest way to implement one logon per user?
... It does cost an extra database write on each request though, to keep the last activity time up to date. Unless you maintain a timestamp in the cookie and hash it with the session id (or whatever sensitive info you're hashing). Regards, Tim Tompkins -- Programmer http://www.arttoday.com/ http://www.rebelartist.com/ --
Building with VC++ neads awk???
To all, Trying to hurriedly build mod_perl 1.27 and Apache 1.3.26. Getting error bulding mod_perl like at the bottom of this message. I think this is because awk is needed to convert the .xs files to .c(). Can't remember how to put this in in VC++. It was somewhere in one of he instructions from the previous releases. I may not even be on the right track, can't remember. Anyone have the answer handy. Trying to get this out fast because the security folks are on us. Thanks Chuck Build : warning : failed to (or don't know how to) build 'E:\src\mod_perl-1.27\src\modules\perl\Util.c' Compiling... Apache.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\Apache.c': No such file or directory Connection.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\Connection.c': No such file or directory Constants.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\Constants.c': No such file or directory File.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\File.c': No such file or directory Log.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\Log.c': No such file or directory mod_perl.c E:\src\mod_perl-1.27\src\modules\perl\mod_perl.h(90) : fatal error C1083: Cannot open include file: 'mod_perl_version.h': No such file or directory mod_perl_opmask.c E:\src\mod_perl-1.27\src\modules\perl\mod_perl.h(90) : fatal error C1083: Cannot open include file: 'mod_perl_version.h': No such file or directory ModuleConfig.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\ModuleConfig.c': No such file or directory perl_config.c E:\src\mod_perl-1.27\src\modules\perl\mod_perl.h(90) : fatal error C1083: Cannot open include file: 'mod_perl_version.h': No such file or directory perl_util.c E:\src\mod_perl-1.27\src\modules\perl\mod_perl.h(90) : fatal error C1083: Cannot open include file: 'mod_perl_version.h': No such file or directory perlio.c E:\src\mod_perl-1.27\src\modules\perl\mod_perl.h(90) : fatal error C1083: Cannot open include file: 'mod_perl_version.h': No such file or directory perlxsi.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\perlxsi.c': No such file or directory Server.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\Server.c': No such file or directory Table.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\Table.c': No such file or directory URI.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\URI.c': No such file or directory Util.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\Util.c': No such file or directory Error executing cl.exe. mod_perl.so - 16 error(s), 1 warning(s)
aphid 0.17a
Version 0.17a of aphid, the web-based Perl/Apache/SSL installer is now available at sourceforge: http://www.sourceforge.net/projects/aphid 0.17a 08/01/2002 Changed software_list.text to download Perl 5.8.0, URI 1.20, HTML::Parser 3.26, libnet 1.12, Digest::MD5 2.20, libwww 5.65, Apache 1.3.26, OpenSSL 0.9.6e, mod_ssl 2.8.10, and Devel::Symdump 2.03 Regards, -pete
RE: Building with VC++ neads awk???
Got past that one. Now it can't fine ModuleConfig.c. Seams to be the same problem but all the rest worked after doing perl makefile.pl and nmake install (why isn't this nmake prep?) Please help -Original Message- From: Goehring, Chuck Mr., RCI - San Diego Sent: Thursday, August 01, 2002 2:47 PM To: mod perl list (E-mail) Subject: Building with VC++ neads awk??? To all, Trying to hurriedly build mod_perl 1.27 and Apache 1.3.26. Getting error bulding mod_perl like at the bottom of this message. I think this is because awk is needed to convert the .xs files to .c(). Can't remember how to put this in in VC++. It was somewhere in one of he instructions from the previous releases. I may not even be on the right track, can't remember. Anyone have the answer handy. Trying to get this out fast because the security folks are on us. Thanks Chuck Build : warning : failed to (or don't know how to) build 'E:\src\mod_perl-1.27\src\modules\perl\Util.c' Compiling... Apache.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\Apache.c': No such file or directory Connection.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\Connection.c': No such file or directory Constants.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\Constants.c': No such file or directory File.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\File.c': No such file or directory Log.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\Log.c': No such file or directory mod_perl.c E:\src\mod_perl-1.27\src\modules\perl\mod_perl.h(90) : fatal error C1083: Cannot open include file: 'mod_perl_version.h': No such file or directory mod_perl_opmask.c E:\src\mod_perl-1.27\src\modules\perl\mod_perl.h(90) : fatal error C1083: Cannot open include file: 'mod_perl_version.h': No such file or directory ModuleConfig.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\ModuleConfig.c': No such file or directory perl_config.c E:\src\mod_perl-1.27\src\modules\perl\mod_perl.h(90) : fatal error C1083: Cannot open include file: 'mod_perl_version.h': No such file or directory perl_util.c E:\src\mod_perl-1.27\src\modules\perl\mod_perl.h(90) : fatal error C1083: Cannot open include file: 'mod_perl_version.h': No such file or directory perlio.c E:\src\mod_perl-1.27\src\modules\perl\mod_perl.h(90) : fatal error C1083: Cannot open include file: 'mod_perl_version.h': No such file or directory perlxsi.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\perlxsi.c': No such file or directory Server.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\Server.c': No such file or directory Table.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\Table.c': No such file or directory URI.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\URI.c': No such file or directory Util.c fatal error C1083: Cannot open source file: 'E:\src\mod_perl-1.27\src\modules\perl\Util.c': No such file or directory Error executing cl.exe. mod_perl.so - 16 error(s), 1 warning(s)
can't fine ModuleConfig.c.
Please disregard other messages. This is the one I'm stuck on. Everything builds except the ModuleConfig.c.
No error log, no database
Hi. Yesterday it happened that our error log reached 2Gb. Since ours is a linux box writing to it stopped. At the same time all database driven functionality stopped working (Plain DBI on Mysql, no Apache::DBI). The database was still usable through the PHP admin interface. The filesystem was not full. When the log was rotated, everything returned to normal. This was on a virtual Apache 1.3.26, mod_perl 1.25. Does anybody have an idea what happened? Thanx, Joachim -- ... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden koennen.- Bertolt Brecht - Leben des Galilei
Re: No error log, no database
Joachim Zobel wrote: Hi. Yesterday it happened that our error log reached 2Gb. Since ours is a linux box writing to it stopped. At the same time all database driven functionality stopped working (Plain DBI on Mysql, no Apache::DBI). The database was still usable through the PHP admin interface. The filesystem was not full. When the log was rotated, everything returned to normal. This was on a virtual Apache 1.3.26, mod_perl 1.25. Does anybody have an idea what happened? You've hit the 2GB limit. First make sure that your OS/fs has a large file support. http://www.suse.de/~aj/linux_lfs.html Then re-build Apache (it should automatically add -D_LARGEFILE_SOURCE flag) and Perl with -Duselargefiles and finally rebuild mod_perl. -- __ 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
Thanks for the help
Thanks for the help I've got from this list over the past few years, esp. Randy Kobes. I won't be involved with mod_perl in the foreseeable future but it was fun being here. regards, Rod
Re: mod_perl2 DBD::Oracle problem
Hi Stas,
Do you suggest that %ENV is getting lost along the way? Or can it be
some other problem? I don't have Oracle to test with. Or can you think
of some other way to reproduce the problem without depending on Oracle
being installed?
I think this reason is my configuration or DBI/DBD module problem.
I checked some DBI/DBD module program(DBI.pm/Oracle.pm).
In these program, %ENV and other variable was correct.
But I didn't check more deep C program, I'll ask them to other place.
1.
instead of using ModPerl::Registry, use Apache::Registry. Of course
configure Location to use Apache::Registry.
use Apache::compat;
use Apache::Registry; # hopefull you have mod_perl 1.0 installed
any change when you use the Apache::Registry from 1.0? Currently the
only difference (mainly) is that ModPerl::Registry doesn't chdir() into
the script's dir. (which eventually will change)
I tried to use Apache::Registry, but it still showed same error in error_log
as following.
[error_log]
DBI-connect(ynt0) failed: (UNKNOWN OCI STATUS 1804) OCIInitialize. Check
ORACLE_HOME and NLS settings etc. at
/yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 30
[Wed Jul 31 19:00:24 2002] [error] Cannot connect: (UNKNOWN OCI STATUS 1804)
OCI Initialize. Check ORACLE_HOME and NLS settings etc. at
/yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 30.
My machine is as following.
- perl5.6.1(/yopt/perl5.6.1normal)
- DBI-1.30
- DBD-Oracle-1.12
- mod_perl1.99_04(DSO build)
- apache2.0.39(/yopt/httpd-2.0.39_prefork_perl5.6.1normal)
- perl5.005_3(/yopt/perl5.0)
- mod_perl1.26(static build, for installing Apache::Registry)
- apache1.3.26(/yopt/apache_1.3.26)
[httpd.conf]
LoadModule perl_module modules/mod_perl.so
...
IfModule mod_perl.c
PerlRequire /yopt/httpd-2.0.39_prefork_perl5.6.1normal/conf/startup.pl
PerlModule ModPerl::Registry
Location /cgi-bin
SetHandler perl-script
PerlResponseHandler Apache::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
/Location
/IfModule
[startup.pl]
#!/yopt/perl5.6.1normal/bin/perl
use Apache2 ();
use Apache::compat ();
use lib qw(/yopt/perl5.0/lib/site_perl/5.005/i686-linux);
use Apache::Registry ();
1;
Thank you very much,
Atsushi.
- Original Message -
From: Stas Bekman [EMAIL PROTECTED]
To: Atsushi Fujita [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, July 31, 2002 11:18 AM
Subject: Re: mod_perl2 DBD::Oracle problem
Atsushi Fujita wrote:
Hi all,
I am trying to use DBD::Oracle1.12 on mod_perl2.
But it doesn't work fine.
It shows error as following in error_log at $dbh = DBI-connect.
[error_log]
DBI-connect(ynt0) failed: (UNKNOWN OCI STATUS 1804) OCIInitialize. Check
ORACLE_HOME and NLS settings etc. at
/yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 42
[Mon Jul 29 20:15:37 2002] [error] 25703: ModPerl::Registry: `Cannot
connect:
(UNKNOWN OCI STATUS 1804) OCIInitialize. Check ORACLE_HOME and
NLS settings etc.at
/yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 42.
[test1.cgi]
use DBI;
my $dsn = 'dbi:Oracle:';
my $user = 'username/password';
my $password = '';
$ENV{'ORACLE_HOME'} = '/u01/app/oracle/product/9.0.1';
$ENV{'ORACLE_SID'} = 'ynt0';
$ENV{'NLS_LANG'}= 'japanese_japan.ja16euc';
print ORACLE_HOME=$ENV{'ORACLE_HOME'}br\n;
print ORACLE_SID=$ENV{'ORACLE_SID'}br\n;
print NLS_LANG=$ENV{'NLS_LANG'}br\n;
print DSN=$dsn$ENV{'ORACLE_SID'}br\n;
$dbh = DBI-connect($dsn$ENV{'ORACLE_SID'}, $user, $password)
or die Cannot connect: .$DBI::errstr;
...
At first, I suspect that the reason is %ENV in this script.
But I set surely, and this output as following.
[Broser output HTML]
ORACLE_HOME=/u01/app/oracle/product/9.0.1
ORACLE_SID=ynt0
NLS_LANG=japanese_japan.ja16euc
DSN=dbi:Oracle:ynt0
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to
complete your request.
And if I turned off the mod_perl, it works fine on normal CGI-script.
This error occurred only mod_perl.
(I tested mod_perl1.26 apache 1.3.26, it worked fine...)
My machine is as following.
- perl5.6.1(non thread)
- DBI-1.30
- DBD-Oracle-1.12
- mod_perl1.99_04(DSO build)
- apache2.0.39(prefork)
[httpd.conf](is this wrong??)
LoadModule perl_module modules/mod_perl.so
...
IfModule mod_perl.c
PerlModule ModPerl::Registry
Location /cgi-bin
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
/Location
/IfModule
Do you suggest that %ENV is getting lost along the way? Or can it be
some other problem? I don't have Oracle to test with. Or can you think
of some
Re: ANNOUNCE: Mason 1.12
On 1 Aug 2002, Vivek Khera wrote: Cool... I just updated one system from 1.05 to 1.1201 and cpan says that HTML::Mason::ApacheHandler is now older than the version in 1.05: Package namespace installedlatest in CPAN file HTML::Mason::ApacheHandler 1.242 1.68 J/JS/JSWARTZ/HTML-Mason-1.05.tar.gz ... Can the version number for ApacheHandler get fixed up so CPAN doesn't think it is old? It can, but I'm not sure what to update it to. Frankly, I think CPAN is more at fault here given that _many_ people use CVS for this sort of stuff and this quite normal when using CVS. But we'll come up with something. -dave /*== www.urth.org we await the New Sun ==*/
Re: ANNOUNCE: Mason 1.12
On Thursday, August 1, 2002, at 01:43 PM, Dave Rolsky wrote: It can, but I'm not sure what to update it to. Frankly, I think CPAN is more at fault here given that _many_ people use CVS for this sort of stuff and this quite normal when using CVS. No, CVS is kind-of brain-dead about this. I suggest you use sprintf to properly format the version number with appropriate number of 0s. Although, with those version numbers, it might be a little late. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: ANNOUNCE: Mason 1.12
On Thu, 1 Aug 2002, David Wheeler wrote: No, CVS is kind-of brain-dead about this. I suggest you use sprintf to properly format the version number with appropriate number of 0s. Although, with those version numbers, it might be a little late. See, that's the problem. We're up in the hundreds. Maybe we should've started formatting these with '%04d' way back when but that certainly wouldn't help now. We _could_ just jack up the first number, but that'd be a bit odd given that Mason itself is only at 1.1201. Or we could just use the CVS revision as an integer, not a float. That is weirder in some ways, but will just work right forever. -dave /*== www.urth.org we await the New Sun ==*/
[OT] Re: ANNOUNCE: Mason 1.12
On Thursday, August 1, 2002, at 02:11 PM, Dave Rolsky wrote: See, that's the problem. We're up in the hundreds. Maybe we should've started formatting these with '%04d' way back when but that certainly wouldn't help now. I've given up on letting CVS set $VERSION, for just this reason. It's a major PITA. I set $VERSION manually. Or we could just use the CVS revision as an integer, not a float. That is weirder in some ways, but will just work right forever. Hm, not sure I understand how this would work. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: ANNOUNCE: Mason 1.12
DR == Dave Rolsky [EMAIL PROTECTED] writes: DR See, that's the problem. We're up in the hundreds. Maybe we should've DR started formatting these with '%04d' way back when but that certainly DR wouldn't help now. How 'bout removing Mason 1.05 from CPAN? Or are there too many apps that require that specific version? I know RT had to be updated to work with the latest releases, so for a while it required 1.05. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: ANNOUNCE: Mason 1.12
Dave Rolsky wrote: It can, but I'm not sure what to update it to. Frankly, I think CPAN is more at fault here given that _many_ people use CVS for this sort of stuff and this quite normal when using CVS. This is a common complaint about CPAN.pm, but it's kept this way so far because of performance issues with doing fancier version parsing. I would suggest following David Wheeler's advice and setting version manually, so that you can just make 1.69 or something. Incidentally, all hell is going to break loose when Perl 5.10 gets released. Maybe that will force a change in CPAN.pm. - Perrin
