Re: security suggestion
I think these are good points. However, to some degree, if this is an attempt to allow an ISP protection, it's not because most ISPs offer CGI access to their customers. In addition, the moment you give mod_perl access to a developer they have the rights to do a LOT of stuff that goes beyond putting PerlHandlers in an htaccess file. It's possible to go through the Apache::Registry package and walk the subroutine tree of precompiled scripts and conceivably figure out stuff about other people's scripts. Actually probably easier to just figure out what packages exist in memory and walk the memory and variables directly. If some of those variables are config vars, then oh well. In fact, I should think it is conceivable that one mod_perl script could theoretically replace another mod_perl script within the Apache::Registry by manipulating the global variables within Apache::Registry. So in other words, if you can't have a semblance of trust your developers against each other, then mod_perl simply cannot be configured in a way that developers can truely share the same web server. However, I don't think many people advocate sharing mod_perl web servers in teh real world with apache 1.3. When Apache and mod_perl 2.0 come out, I suspect the new architecture will allow very cool things like Perl Interpreter segmentation among virtual hosts. But until that happens, there's really not much you can do. It seems to me that mod_perl wasn't really designed for safety against your own developers doing something malicious. And most if not all people pretty much run their servers that way. Most people who run mod_perl run it as their own dedicated server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] ApacheCon USA 2001: Call For Papers
At 08:43 PM 11/15/00 +0300, Ilya Martynov wrote: On 15 Nov 2000, David Hodgkinson wrote: DH Stas Bekman [EMAIL PROTECTED] writes: DH DH Ralf is always talking about SSL stuff, so if you want to do it, why don't DH you just contact him and sync with him. It's not mod_perl but many of us DH are using it. So it'd probably be questionable for TPC , but perfect for DH ApacheCon. DH DH Is there a way of doing mod_rewrite maps in perl? RewriteMap config option allows you specify external program as source of map information. It can be in perl. Apache documentation for mod_rewrite has an example of such program. I am not sure (it might be nice if someone could clarify) but I think that mod_rewrite has to launch it as an external program each time it does this. It strikes me that this would be expensive? But I am not sure. Maybe mod_rewrite can cache the program output? Later, Gunther - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New Module Idea: MLDBM::Sync
Hey,
I'm working on a new module to be used for mod_perl style
caching. I'm calling it MLDBM::Sync because its a subclass
of MLDBM that makes sure concurrent access is serialized with
flock() and i/o flushing between reads and writes. Below is
the code for the module. I believe it could be used too as a
safe backing store for Memoize in a multi-process environment.
It could be used like:
tie %mldbm, 'MLDBM::Sync', '/tmp/mldbm_dbm', O_CREAT|O_RDWR, 0666;
$mldbm{rand()} = [ rand() ];
%mldbm = ();
The history is that I hunted around for on disk caching in
which I can stuff db query results temporarily, and the best I
liked was File::Cache, which is really cool BTW. I would use it,
but MLDBM::Sync using default SDBM_File seems to be 2 to 3 times
faster, getting about 1000 writes / sec on my dual PIII 400.
MLDBM::Sync using MLDBM in DB_File mode is considerably slower
than File::Cache, by 5-10 times, so it really depends on the
data you want to store, for which you might use. The 1024 byte
limit on SDBM_File makes it often not the right choice.
I also thought about calling it MLDBM::Lock, MLDBM::Serialize,
MLDBM::Multi ... I like MLDBM::Sync though. For modperl
caching usage, I imagine tieing to it in each child, and clearing
when necessary, perhaps even at parent httpd initialization...
no auto-expiration here, use File::Cache, IPC::Cache for that!
Any thoughts?
--Joshua
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
package MLDBM::Sync;
use MLDBM;
use Fcntl qw(:flock);
use strict;
no strict qw(refs);
use vars qw($AUTOLOAD);
sub TIEHASH {
my($class, $file, @args) = @_;
my $fh = "$file.lock";
open($fh, "$fh") || die("can't open file $fh: $!");
bless {
'args' = [ $file, @args ],
'lock' = $fh,
'keys' = [],
};
}
sub DESTROY {
my $self = shift;
if (($self-{lock})) {
close($self-{lock})
}
}
sub AUTOLOAD {
my $self = shift;
$AUTOLOAD =~ /::([^:]+)$/;
my $func = $1;
$self-exlock;
my $rv = $self-{dbm}-$func(@_);
$self-unlock;
$rv;
}
sub STORE {
my $self = shift;
$self-exlock;
my $rv = $self-{dbm}-STORE(@_);
$self-unlock;
$rv;
};
sub FETCH {
my $self = shift;
$self-shlock;
my $rv = $self-{dbm}-FETCH(@_);
$self-unlock;
$rv;
};
sub FIRSTKEY {
my $self = shift;
$self-shlock;
$self-{keys} = [ keys %{$self-{dbm_hash}} ];
$self-unlock;
$self-NEXTKEY;
}
sub NEXTKEY {
shift(@{shift-{keys}});
}
sub mldbm_tie {
my $self = shift;
my $args = $self-{args};
my %dbm_hash;
my $dbm = tie(%dbm_hash, 'MLDBM', @$args) || die("can't tie to MLDBM with args:
".join(',', @$args)."; error: $!");
$self-{dbm_hash} = \%dbm_hash;
$self-{dbm} = $dbm;
}
sub exlock {
my $self = shift;
flock($self-{lock}, LOCK_EX) || die("can't write lock $self-{lock}: $!");
$self-mldbm_tie;
}
sub shlock {
my $self = shift;
flock($self-{lock}, LOCK_SH) || die("can't share lock $self-{lock}: $!");
$self-mldbm_tie;
}
sub unlock {
my $self = shift;
undef $self-{dbm};
untie %{$self-{dbm_hash}};
flock($self-{lock}, LOCK_UN) || die("can't unlock $self-{lock}: $!");
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Apache::VirtualHostRegistry
Hi, Going along ths lines of sharing mod_perl between users for ISPs is there a median position that tempers security concerns/support costs/hassles etc that a CPAN module could fill? I'm thinking of a module like APache::Registry but it segments the namespace/memory netween virtual servers --- a sandbox that each virtual host is kept in? NIge Nigel Hamilton __ http://e1mail.come1mail - Encrypted 1st Class Maile1mail: 1001 On Fri, 17 Nov 2000, Gunther Birznieks wrote: I think these are good points. However, to some degree, if this is an attempt to allow an ISP protection, it's not because most ISPs offer CGI access to their customers. In addition, the moment you give mod_perl access to a developer they have the rights to do a LOT of stuff that goes beyond putting PerlHandlers in an htaccess file. It's possible to go through the Apache::Registry package and walk the subroutine tree of precompiled scripts and conceivably figure out stuff about other people's scripts. Actually probably easier to just figure out what packages exist in memory and walk the memory and variables directly. If some of those variables are config vars, then oh well. In fact, I should think it is conceivable that one mod_perl script could theoretically replace another mod_perl script within the Apache::Registry by manipulating the global variables within Apache::Registry. So in other words, if you can't have a semblance of trust your developers against each other, then mod_perl simply cannot be configured in a way that developers can truely share the same web server. However, I don't think many people advocate sharing mod_perl web servers in teh real world with apache 1.3. When Apache and mod_perl 2.0 come out, I suspect the new architecture will allow very cool things like Perl Interpreter segmentation among virtual hosts. But until that happens, there's really not much you can do. It seems to me that mod_perl wasn't really designed for safety against your own developers doing something malicious. And most if not all people pretty much run their servers that way. Most people who run mod_perl run it as their own dedicated server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::VirtualHostRegistry
On Fri, 17 Nov 2000, Nigel Hamilton wrote: Going along ths lines of sharing mod_perl between users for ISPs is there a median position that tempers security concerns/support costs/hassles etc that a CPAN module could fill? I wouldn't do it like that. I'm thinking of a module like APache::Registry but it segments the namespace/memory netween virtual servers --- a sandbox that each virtual host is kept in? man jail() on FreeBSD 4. MBM -- Matthew Byng-Maddick Home: [EMAIL PROTECTED] +44 20 8981 8633 (Home) http://colondot.net/ Work: [EMAIL PROTECTED] +44 7956 613942 (Mobile) In California they don't throw their garbage away -- they make it into television shows. -- Woody Allen, "Annie Hall" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::VirtualHostRegistry
At 11:15 AM 11/17/00 +, Matthew Byng-Maddick wrote: On Fri, 17 Nov 2000, Nigel Hamilton wrote: Going along ths lines of sharing mod_perl between users for ISPs is there a median position that tempers security concerns/support costs/hassles etc that a CPAN module could fill? I wouldn't do it like that. Regardless of wanting to do it like that, I dont think you can do it like that. Perl code can't truly segment other arbitrarily written Perl code yet. The way to do it is as I said in my last post. You need Apache 2.0/mod_perl 2.0 so that you can explicitly designate perl interpeter pools to be assigned to certain virtual hosts. I'm thinking of a module like APache::Registry but it segments the namespace/memory netween virtual servers --- a sandbox that each virtual host is kept in? man jail() on FreeBSD 4. But then you lose the benefits of having shared apache processes among many shared users many of whom may have very non-busy web sites. No? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::VirtualHostRegistry
On Fri, 17 Nov 2000, Gunther Birznieks wrote: At 11:15 AM 11/17/00 +, Matthew Byng-Maddick wrote: man jail() on FreeBSD 4. But then you lose the benefits of having shared apache processes among many shared users many of whom may have very non-busy web sites. No? Yes, but this is the only way to reliably have security with mod_perl in such a way as they can't interfere with anyone else's code. MBM -- Matthew Byng-Maddick Home: [EMAIL PROTECTED] +44 20 8981 8633 (Home) http://colondot.net/ Work: [EMAIL PROTECTED] +44 7956 613942 (Mobile) In California they don't throw their garbage away -- they make it into television shows. -- Woody Allen, "Annie Hall" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dynamic configuration.
Hello everyone,
I`m writing a module to process templates on which our web server is
built. This module is invoked during PerlInitHandler. We have a
global configuration for our site which is a plain text file
containing a hash like this:
{
bgcolor = '',
text = '',
}
etc...
This configuration can be changed using a simple web page or by
uploading it directly using FTP. Since my module processes each
request it does $cfg = do '/path/to/config'. Doing this on each
request can be time consuming -- i want to load the configuration
again after the modification time of the configuration has changed.
After reading the guide i have found a snippet of code which i have
inserting in the handler function of my module. So the module looks
like this now:
[...]
use vars qw ($VERSION %MODIFIED);
[...]
*My::Apache::Module::handler = \ApacheRequestInit;
sub ApacheRequestInit {
[...]
my $file = '/path/to/config';
$^M = (stat $file)[9]; # even if not set -- does not work
# correctyly
if (!$MODIFIED{$file} and $MODIFIED{$file} != -M $file) {
unless ($auth_config = do $file) {
if ( $@ ) {
$r-log_error( "Unable to load configuration." );
return SERVER_ERROR;
}
}
$r-log_error( "Configuration reloaded..." );
$MODIFIED{$file} = -M $file;
$r-log_error("Modification time: " . $MODIFIED{$file});
}
[...]
}
I have restarted the server on which i test all the code and began
to watch ErrorLog to see if it works. On each request my module
reloads the configuration again, but the modification was not
changed. Going to /perl-status i check the MODIFIED hash and see the
path to the configuration with the modification value and even so i
think it is because i set my module to handle all request comming to
the root location /. What shall i do properly handle the
modification time of a file in my module?
Any help will be great. Thanks in advance.
Best regards,
Alexei V. Alexandrov ([EMAIL PROTECTED])
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Install problems
I assume your using apache_1.3.14 and mod_perl-1.24. You need mod_perl-1.24_01. It will work. I had the same problem. Kevin Riggins Dice.com email: [EMAIL PROTECTED] email: [EMAIL PROTECTED] phone: (515) 313-2127 -Original Message- From: James Hall [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 16, 2000 3:13 PM To: [EMAIL PROTECTED] Subject: Install problems Hello, I am trying to install apache and mod_perl according to the instructions found at http://perl.apache.org/guide/install.html#A_Summary_of_a_Basic_mod_perl_In : % cd /usr/src % lwp-download http://www.apache.org/dist/apache_x.x.x.tar.gz % lwp-download http://perl.apache.org/dist/mod_perl-x.xx.tar.gz % tar xzvf apache_x.x.x.tar.gz % tar xzvf mod_perl-x.xx.tar.gz % cd mod_perl-x.xx % perl Makefile.PL APACHE_SRC=../apache_x.x.x/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 % make make test make install % cd ../apache_x.x.x % make install when I run the makefil.pl for mod_perl, it gets about 1/2 way done and reports the following: Using config file: /usr/local/mod_perl-1.24/src/Configuration Creating Makefile + configured for Linux platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules + checking sizeof various data types + doing sanity check on compiler and options Creating Makefile in support Creating Makefile in regex Creating Makefile in os/unix Creating Makefile in ap Creating Makefile in main Creating Makefile in lib/expat-lite Creating Makefile in modules/standard EXTRA_CFLAGS: -DLINUX=2 -DUSE_HSREGEX -DUSE_EXPAT -I$(SRCDIR)/lib/expat-lite -DNO_DL_NEEDED * WARNING * Apache Version 1.3.0 required, aborting... * WARNING * So I installed apache completely, tried the makefile again (and again and again), but no matter what I do, it always kills at that point, with that warning. I've been searching the FAQ's/mail list archives for similar probs, but haven't found anything yet. I am trying to install on a Redhat 7 OS, the apache version is 1.3.16, and have perl 5.6.0 installed. I was just wondering if anyone had thoughts/experience with this that could point me in a better direction? Thanks in advance! -Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: compiling modperl on alpha
The -Wl flag is used to cause the rpath part to be passed on the ld stage of compiling if it is called with cc. The man pages for cc explain it in better detail. The problem is that the Makefile for mod_perl in $APACHE_SRC/src/modules/perl calls ld directly and the -Wl flag is not supported by ld. In order to get it to compile I edited $APACHE_SRC/src/modules/perl/Makefile after running configure and added the -rpath stuff without the comma to the LDFLAGS variables and removed all the -Wls. Example: LDFLAGS = SOMETHING = -Wl,rpath,... to LDFLAGS = -rpath path . SOMETHING = -rpath path This let it compile, but I never could get it to actually work. Kept getting undefined errors on things like PL_perl_destruct_level and such. Pleaes let me know if you actually get it to work. Kevin Riggins Dice.com -Original Message- From: Didier Godefroy [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 16, 2000 8:31 PM To: Jeremy A. Mates Cc: [EMAIL PROTECTED] Subject: Re: compiling modperl on alpha on 11/16/00 8:50 PM, Jeremy A. Mates at [EMAIL PROTECTED] uttered the following: Make sure the ld that is being called is the exact same one that was used to build perl itself, e.g. by altering your PATH environment variable to point to either the vendor default first (under /usr/bin) or perhaps to the GNU ld that might have gotten installed somewhere under /freeware/bin or /usr/local/bin. GNU ld isn't on either system and the error is the exact same on both, they seem to all this in common: -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE' Configure script; you can run `perl -V` to show what the flags are on the perl binary earliest in your PATH. Changing the ld binary used or ld here it is: perl -V Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=dec_osf, osvers=4.0, archname=alpha-dec_osf uname='osf1 ulysium.ulysium.net v4.0 564 alpha ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=define use64bitall=define uselongdouble=define usesocks=undef Compiler: cc='cc', optimize='-O4', gccversion= cppflags='-std -ieee -D_INTRINSICS -I/usr/local/include -DLANGUAGE_C' ccflags ='-std -fprm d -ieee -D_INTRINSICS -I/usr/local/include -DLANGUAGE_C' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=8, ptrsize=8, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=8, nvtype='long double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='ld', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /usr/shlib /usr/ccs/lib /usr/lib/cmplrs/cc /usr/lib /var/shlib libs=-lbind -ldbm -ldb -lm -liconv libc=/usr/shlib/libc.so, so=so, useshrplib=true, libperl=libperl.so Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE' cccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -O4 -msym -std -s -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES Built under dec_osf At first when I tried building mod_perl, it complained about the large file support no being in apache, so I recompiled apache for that. Also note that mod_perl as a DSO isn't recommended by the mod_perl documentation... What is the problem with doing that? I tried compiling it statically first, but I get other types of errors when running the tests, it always fails. The httpd is running but the tests won't, and the log doesn't say anything that helps to find out why. What other choices are there then? -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling modperl on alpha
on 11/17/00 8:10 AM, [EMAIL PROTECTED] at [EMAIL PROTECTED] uttered the following: supported by ld. In order to get it to compile I edited $APACHE_SRC/src/modules/perl/Makefile after running configure and added the -rpath stuff without the comma to the LDFLAGS variables and removed all This is assuming a static compile, but I'm trying to do a dso now... Anyway, when I tried to do a static, I didn't get such ld errors, it compiled all the way and the problem was with the tests, which wouldn't even run because it found the httpd not working, although httpd was actually up and when it tries to do the tests, it starts it, waits for it to warm up and finds it running because it says "done" after a moment, so httpd does start, but once the tests try to check on httpd for the second time before actually running the tests, it gives an error because it can't get a reply from httpd. The log file doesn't give anything useful to track this down and the httpd that was started stays in there running... I would prefer having mod_perl static anyway, if I could get it to pass the tests, it would be a good thing... -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
Gunther Birznieks wrote:
It seems to me that mod_perl wasn't really designed for safety against your
own developers
I accept this point. But it's really beside _my_ point, which was that
mod_perl modules can offer critical added functionality to run-of-the-mill
web publishers (whether it be a counter, a new authentication method, a
special content handler, or just some thingie I wrote for them). I think
it would be great to be able to offer web publishers the ability to _use_
those modules without giving them direct access to Perl.
Not all shops consist of a small group of twenty-something developers who
all eat pizza and beer together on Fridays. Many of us operate in hetero-
geneous environments with hundreds, if not thousands, of web "developers"
who are part of our community, and who may really need some custom modules
written for them, but who I can't be bothered monitoring on a day-to-day
basis - and who I don't want to grant blanket access to my server inter-
nals to.
Let me return to my C module analogy. When I compile in mod_auth_dbi, I
am giving users added functionality. But I'm not giving them the ability
to execute arbitrary C code. I think everyone would agree that this is a
useful (no, critical) feature of Apache.
I simply want to be able to do the same thing in Perl with mod_perl. I
want to be able to give developers ("users" - whatever you want to call
them) added functionality, without giving them the ability to execute
arbitrary Perl code.
I'd have no problem if mod_perl was set up to turn off PerlSetEnv, lit-
eral 'sub { ... }' handlers, Perl sections, and the use of Perl modules
in non-system paths (except where ExecCGI is turned on). I don't know
what else would need to be done, but it all strikes me as critical to
the use of mod_perl in shops that don't fit the "pizza and beer" model
that something along these lines be done.
--
Richard Goerwitz[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling modperl on alpha
on 11/17/00 8:35 AM, [EMAIL PROTECTED] at [EMAIL PROTECTED] uttered the following: When building static, I use the following: Configuring and compile mod_perl: $ perl Makefile.PL \ APACHE_SRC=../apache_x.x.x/src \ USE_APACI=1 \ DO_HTTPD=1 \ EVERYTHING=1 \ PREP_HTTPD=1 $ make That's exactly what I was doing, but the make test fails, and since I don't even know why and the tests didn't run, I didn't dare going to the next step.. I'll try it again, and if the test don't run, I'll still try to go ahead, but how can it be tested after install to make sure it works? -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Richard" == Richard L Goerwitz [EMAIL PROTECTED] writes:
Richard I simply want to be able to do the same thing in Perl with mod_perl. I
Richard want to be able to give developers ("users" - whatever you want to call
Richard them) added functionality, without giving them the ability to execute
Richard arbitrary Perl code.
Use Template Toolkit, and disable the "EVAL_PERL" option for their space.
Set up Plugins and Filters that call your Cool Perl Code.
Then they write arbitary text files to be delivered, but when they
want your added functionality, all they can do is call your interfaces
using the mini-Toolkit language embedded in their files.
And they get a slick templating system for free!
Best of both worlds.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Randal L. Schwartz" wrote: Use Template Toolkit, and disable the "EVAL_PERL" option for their space. Set up Plugins and Filters that call your Cool Perl Code. Then they write arbitary text files to be delivered... Suppose it were possible to set Perl-based modules to work the same way C modules currently do (in the sense that they let you offer developers, users, etc. access to the module without letting them execute arbitrary code on the server). Would you agree that this would be a good thing? Your solution above is great. But it's another one of those "I have a workaround" suggestions. I wonder if there is a way to skip the workarounds. If there is, would you agree that it would be a good (no, wonderful) thing? And would you agree that, if it's possible to do it, mod_perl would be more useful if it were set up in such a way that merely enabling it didn't essentially give everyone with access to the webserver's docroot the ability to execute arbitrary Perl? I'm interested in knowing what's possible here. My knowledge of mod_ perl right now is pretty good, from a module developer's standpoint. I'm just not familiar enough (yet) with its internals to be able to think and speak creatively about the security possibilities. -- Richard Goerwitz[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tempfile and send_fd()
barries [EMAIL PROTECTED] wrote:
On Fri, Nov 17, 2000 at 03:51:35PM +1100, Steve Smith wrote:
seek $f, 0, 0;
Had a look in Apache::File (below), and it sysopens, so you might want
to sysseek(...) instead.
Just to clear up one thing: sysopen() doesn't actually belong to the
sys* family of functions (syswrite, sysread, sysseek). File handles
under perl are buffered by default, whether you open them with perl's
open() or with sysopen(). Internally sysopen() does a plain libc
open(), but then it follows with a fdopen() call to get a stdio handle
anyway.
Example (Linux 2.2):
$ strace -e trace=open,write,close,nanosleep perl -MFcntl -e 'sysopen(FH, "/tmp/bla",
O_WRONLY|O_CREAT); print FH "hey"; sleep 1; print FH "hoy\n"; close FH;'
[ ... ]
open("/tmp/bla", O_WRONLY|O_CREAT|O_LARGEFILE, 0666) = 3
nanosleep({1, 0}, {1, 0}) = 0
write(3, "heyhoy\n", 7) = 7
close(3)= 0
So the rule of thumb is: use either sysread/syswrite/sysseek, or
read//print/seek, but don't mix the two sets on the same filehandle.
But you can open your filehandles with open(), sysopen() or any of the
OO file packages, as you see fit; both sets of IO functions will work on
a filehandle no matter how it was opened.
Personally, I don't like the magic parsing in open(), so I tend to use
sysopen() always, in combination with the usual read//print/seek.
--
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tempfile and send_fd()
On Fri, Nov 17, 2000 at 03:51:03PM +0100, Roger Espel Llima wrote: Internally sysopen() does a plain libc open(), but then it follows with a fdopen() call to get a stdio handle anyway. That explains the results I saw, thanks. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DBI related
Hey Friends,
I have two ORACLE_HOME directories in my client
machine (7.2.2 and 8.0.5). When I set ENV to 8.0.5 or
7.2.2, this seems there no effect. Also when I use the
connection like this :
$dbh = DBI-connect("DBI:Oracle:$sid", "$username",
"$password",
{ RaiseError = 1, AutoCommit = 0 } );
I get ORA-12545 error.
But when I use this:
$dbh = DBI-connect('dbi:Oracle:',
"$username/$password@(DESCRIPTION =
(ADDRESS=(PROTOCOL=TCP)(HOST=$server)(PORT=$port))
(CONNECT_DATA=(SID=$sid)))", "");
I get connected.
How to force the connection to use 8.0.5?
Thank you for your help in advance.
Ben
__
Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!
http://calendar.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
trying to isolate VirtualHosts running identical .pm's
I'm trying to configure a single box to host completely separate instances of development and test versions of the same code base (currently 49 modules). Right now I have 2 virtual hosts configured on the same IP and servername, but use different ports, i.e., 80 and 82. I attempted to use PerlSetEnv PERL5LIB /usr/local/lib/perl5/site_perl/5.005/sun4-solaris:/path/to/mydevel or, PerlSetEnv PERL5LIB /usr/local/lib/perl5/site_perl/5.005/sun4-solaris:/path/to/test in each respective's VirtualHost section, but this did not work. /perl-status?inc always shows: @INC = /usr/local/lib/perl5/5.00503/sun4-solaris /usr/local/lib/perl5/5.00503 /usr/local/lib/perl5/site_perl/5.005/sun4-solaris /usr/local/lib/perl5/site_perl/5.005 . /usr/local/apache/ /usr/local/apache/lib/perl I then tried PerlVINC (version 0.03) by adding to my devel virtualhost section: PerlModule Apache::PerlVINC PerlINC /path/to/mydevel/ PerlFixupHandler Apache::PerlVINC PerlCleanupHandler Apache::PerlVINC # PerlVersion Apache::TicketMaster but then get an error if I uncomment out the above line, saying that it can't locate TicketMaster in @INC ... Assuming I could get the above to work for a single module (by reloading it with PerlVersion), is there any way to globally force the server to execute the proper module, depending on which virtualhost it's serving, without having to explicitly do a reload of each individual module (potentially 50)? Thanks in advance, Scott
Re: trying to isolate VirtualHosts running identical .pm's
I'm trying to configure a single box to host completely separate instances of development and test versions of the same code base (currently 49 modules). Right now I have 2 virtual hosts configured on the same IP and servername, but use different ports, i.e., 80 and 82. The only way I know to achieve what you want is to run two httpds with different configs. This has the added advantage that your developers can stop/start their server without impacting your testers. HTH, Simon. __ This email contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or reply on this email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Use of .htaccess files
Hello all, I'm a newbie to mod_perl, and I have a question. We have mod_perl on our server, but it is a standard out of the box install (Only PerlHandler is enabled.) Now, I'd like to use .htaccess files to test some stuff out (no dev server either) and I don't want to be constantly restarting the server. Am I correct in thinking that since .htaccess files are read by the server every request, I do not need to use techniques like Apache::StatINC to ensure that the libs get read every request. What Perl directives can I not put in .htaccess? I plan on testing this stuff in a directory, and if it works, moving it into the main server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: security suggestion
I'd have no problem if mod_perl was set up to turn off
PerlSetEnv, lit-
eral 'sub { ... }' handlers, Perl sections, and the use of
Perl modules
in non-system paths (except where ExecCGI is turned on).
Maybe another approach would be to explicitly list the handlers that
are allowed to be used in any given context. Kind of
like 'Options', but for perl handlers. Something like 'PerlOptions',
perhaps?
Location /users
PerlOptions "My::AuthHandler My::ContentHandler My::TransHandler"
/Location
Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: trying to isolate VirtualHosts running identical .pm's
This is what we do. Except we use the SAME config file, but we just have some conditionals that depend on which port number is being started up. -c At 3:47 PM + 11/17/00, [EMAIL PROTECTED] wrote: I'm trying to configure a single box to host completely separate instances of development and test versions of the same code base (currently 49 modules). Right now I have 2 virtual hosts configured on the same IP and servername, but use different ports, i.e., 80 and 82. The only way I know to achieve what you want is to run two httpds with different configs. This has the added advantage that your developers can stop/start their server without impacting your testers. HTH, Simon. __ This email contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or reply on this email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Chris Thorman (413) 473-0853 e-fax - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Document Contains no data
I have a program which runs fine 90% of the time under mod_perl. About 10% of the time Netscape reports "Document contains no data". Looking at the socket traffic, the client receives an orderly release indication (T_ORDEL_IND = 132) on the socket and reponds with a orderly release request, which closes the socket. I've added some printing calls to determine how far it's getting in the script, even one on the first line. When it fails there are no warnings, none of the STDERR output shows up in the error log, and the html is still generated and output to the error_log. It seems like once the socket it closed, the script continues, but output to STDERR dissapears and STDOUT goes to the error log. Any ideas why the server is sending the orderly release indication or any ways to trace it? I've run the server in single process mode, but it still doesn't give any errors or warnings. I've tried on two different machines, both DECs, one running Perl 5.00404, Apache/1.3.12, mod_perl/1.24, the other running perl 5.00404, Apache/1.3.6, mod_perl/1.20. Steve Cochran - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: trying to isolate VirtualHosts running identical .pm's
Scott Dayberry ([EMAIL PROTECTED]) said something to this effect: I'm trying to configure a single box to host completely separate instances of development and test versions of the same code base (currently 49 modules). Right now I have 2 virtual hosts configured on the same IP and servername, but use different ports, i.e., 80 and 82. Hey Scott, Try something like this: 1. Bind some addresses in the 192.168.0.x range to your main NIC, like hme0:1 bound to 192.168.0.1, hme0:2 bound to 192.168.0.2, etc. 2. Have each developer run their httpd process on one of the virtual addresses, bound to a high port (so they can restart the server without having root access). 3. Run a lightweight proxying front end (pretend the real address is 1.2.3.4): # # This is its httpd.conf # NameVirtualHost1.2.3.4:80 Location 1.2.3.4:80 ServerName dev-1.example.tld ProxyPass/ http://192.168.0.1:8000/ ProxyPassReverse / http://192.168.0.1:8000/ /Location Location 1.2.3.4:80 ServerName dev-2.example.tld ProxyPass/ http://192.168.0.2:8000/ ProxyPassReverse / http://192.168.0.2:8000/ /Location #...etc... All the development servers would point to the proxy's address in DNS, by the way, and its (the proxy's) virtual host configuration would take care of pushing the requests to the correct host. Make sure the front end has mod_proxy, of course. 4. Provided the front end server doesn't die or do something strange, it will faithfully proxy other servers back and forth. Hope this helps! (darren) -- Freedom is nothing else but the chance to do better. -- Camus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Document Contains no data
On 17 Nov 2000, Stephen A. Cochran wrote: I have a program which runs fine 90% of the time under mod_perl. About 10% of the time Netscape reports "Document contains no data". Looking at the socket traffic, the client receives an orderly release indication (T_ORDEL_IND = 132) on the socket and reponds with a orderly release request, which closes the socket. I've added some printing calls to determine how far it's getting in the script, even one on the first line. When it fails there are no warnings, none of the STDERR output shows up in the error log, and the html is still generated and output to the error_log. It seems like once the socket it closed, the script continues, but output to STDERR dissapears and STDOUT goes to the error log. Any ideas why the server is sending the orderly release indication or any ways to trace it? I've run the server in single process mode, but it still doesn't give any errors or warnings. run it in single mode and attach to the process with strace(1) or truss(1) (depending on what you have). See the debug chapter in the mod_perl guide. I've tried on two different machines, both DECs, one running Perl 5.00404, Apache/1.3.12, mod_perl/1.24, the other running perl 5.00404, Apache/1.3.6, mod_perl/1.20. Steve Cochran - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
two identical directives in Perl configuration
Say I have a $Directory{} configuration in a Perl section like so:
$Directory{"/home/httpd/html-ssl/demo"} = {
SetHandler = "perl-script",
PerlAuthenHandler = "Authen",
PerlAuthzHandler = "Authz",
require = "group payer_manager",
require = "payer_group demo",
};
Obviously this won't work because the second "require = " directive will
clobber the first. So what's the workaround? I couldn't think of what the
logical perl translation to having two require directives would be...
-Adi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: two identical directives in Perl configuration
I think require = ["group payer_manager", "payer_group demo"] should do it.
On Fri, Nov 17, 2000 at 01:11:09PM -0500, Adi Fairbank wrote:
Say I have a $Directory{} configuration in a Perl section like so:
$Directory{"/home/httpd/html-ssl/demo"} = {
SetHandler = "perl-script",
PerlAuthenHandler = "Authen",
PerlAuthzHandler = "Authz",
require = "group payer_manager",
require = "payer_group demo",
};
Obviously this won't work because the second "require = " directive will
clobber the first. So what's the workaround? I couldn't think of what the
logical perl translation to having two require directives would be...
-Adi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Tom Lancaster Red Hat, Inc.
Web Engineer(415) 777-9810 x 228
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling modperl on alpha
I suspect that this has something to do with using Perl 5.6.0. I and several others have had problems getting mod_perl to work with this version of Perl under various flavors of Unix (Solaris, AIX, HP-UX). We have all also found that if you roll Perl back to 5.005 that this appears to solve the problem. "Jeremy A. Mates" wrote: On Thu, 16 Nov 2000, Didier Godefroy wrote: GNU ld isn't on either system and the error is the exact same on both, they seem to all this in common: -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE' [snip] dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE' cccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -O4 -msym -std -s -L/usr/local/lib' Hmmm... the Digitals I have share similar ccdlflags statements. Did you install perl 5.6.0 from scratch or via a package of some kind? (If via package, the people who built the package may have used a different ld or had different environment settings from yours.) You might be able to pass the flag ld appeared to be complaining about with the following trick: $ LDFLAGS="-_SYSTYPE_SVR4" command_that_fails Which should work for Bourne-related shells. The ld man page didn't appear contain anything useful, so I'm guessing moreso than usual at this point. :) You could also try asking on the tru64-unix-managers list: http://www.ornl.gov/cts/archives/mailing-lists/ mailto:[EMAIL PROTECTED]?body=subscribe What is the problem with doing that? I tried compiling it statically first, but I get other types of errors when running the tests, it always fails. The httpd is running but the tests won't, and the log doesn't say anything that helps to find out why. What other choices are there then? If static fails, then you can probably get away with DSO if you keep the httpd process memory usage down with various directives. There's more on this just recently in this list's archives, as I recall... -- Jeremy Mates http://www.sial.org/ -- Jimi Thompson Web Master L3 communications "It's the same thing we do every night, Pinky." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
mgraham wrote:
Maybe another approach would be to explicitly list the handlers that
are allowed to be used in any given context. Kind of
like 'Options', but for perl handlers. Something like 'PerlOptions',
perhaps?
Location /users
PerlOptions "My::AuthHandler My::ContentHandler My::TransHandler"
/Location
That's a neat idea.
The only quibble I can think of is that this doesn't go far enough.
This lower level of privilege we're talking about is one in which -
1) Only specific Perl modules are available (or ones in specific
paths; no literal 'sub { ... }' handlers)
2) PerlSetEnv (and PerlPassEnv?) aren't usable
3) PERL5LIB isn't changeable
4) Perl sections are unavailable
--
Richard Goerwitz[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling modperl on alpha
on 11/17/00 1:20 PM, Jimi Thompson at [EMAIL PROTECTED] uttered the following: I suspect that this has something to do with using Perl 5.6.0. I and several others have had problems getting mod_perl to work with this version of Perl under various flavors of Unix (Solaris, AIX, HP-UX). We have all also found that if you roll Perl back to 5.005 that this appears to solve the problem. Actually, I just compiled mod_perl with apache (static) and bypassed the tests, I only did the make and install of mod_perl then did apache, doing no tests anywhere, and it worked!!! But I have to do some testing of the perl module, everything seems to work fine but I don't know if mod_perl will work right... The install I just did was on the older DU4.0b system, now I'll try the same thing on the new Tru64 5.1 and we'll see what happens. What would be a good enough test to make sure mod_perl works right? -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Richard" == Richard L Goerwitz [EMAIL PROTECTED] writes:
Richard That's a neat idea.
Richard The only quibble I can think of is that this doesn't go far enough.
Richard This lower level of privilege we're talking about is one in which -
Richard 1) Only specific Perl modules are available (or ones in specific
Richard paths; no literal 'sub { ... }' handlers)
Richard 2) PerlSetEnv (and PerlPassEnv?) aren't usable
Richard 3) PERL5LIB isn't changeable
Richard 4) Perl sections are unavailable
I think y'all are missing it. As soon as I have any Perl code access
via Apache::Registry or anything like that, I can do this:
*Apache::Registry::handler = \my_trojan_horse;
Unless you use "Safe", any access to any Perl invocation means you are
insecure.
So mod_perl is inherently unsafe. Either you have access to Perl, or
you don't. And when you don't, you might as well invent a meta-API,
like the one I suggested with Template Toolkit. You can't use the
generic tools... they're too powerful.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: trying to isolate VirtualHosts running identical .pm's
Hi,
just use magic...:
1. move your test modules to /path/TEST/YourPrefix/name.pm
2. add /path to @INC (NOT /path/TEST !)
3. add PerlSetVar test TRUE for your test virtual host and change the
PerlHandlers to read TEST::YourPrefix::name
4. write a Filter that does something like
if ($r-dir_config('test') {
s/YourPrefix::/TEST::YourPrefix::/g;
}
5. USE your new Filter in all Modules BEFORE the "package"-line
Now Perl will see your test modules as TEST::YourPrefix::name and the normal
modules als YourPrefix::name. No changes are necessary when migrating tested
modules to production.
Abracadabra and done.
cu/2
Michael Jacob
PS: Or just run 2 Apache instances with different @INCs. That's easier...
Datum: 17.11.2000 17:15
An:[EMAIL PROTECTED]
Betreff: trying to isolate VirtualHosts running identical .pm's
Nachrichtentext:
I'm trying to configure a single box to host completely separate instances
of development and test versions of the same code base (currently 49
modules).
Right now I have 2 virtual hosts configured on the same IP and servername,
but use different ports, i.e., 80 and 82.
I attempted to use
PerlSetEnv PERL5LIB
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris:/path/to/mydevel
or,
PerlSetEnv PERL5LIB
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris:/path/to/test
in each respective's VirtualHost section, but this did not work.
/perl-status?inc always shows:
@INC =
/usr/local/lib/perl5/5.00503/sun4-solaris
/usr/local/lib/perl5/5.00503
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris
/usr/local/lib/perl5/site_perl/5.005
.
/usr/local/apache/
/usr/local/apache/lib/perl
I then tried PerlVINC (version 0.03) by adding to my devel virtualhost
section:
PerlModule Apache::PerlVINC
PerlINC /path/to/mydevel/
PerlFixupHandler Apache::PerlVINC
PerlCleanupHandler Apache::PerlVINC
# PerlVersion Apache::TicketMaster
but then get an error if I uncomment out the above line, saying that it
can't locate TicketMaster in @INC ...
Assuming I could get the above to work for a single module (by reloading it
with PerlVersion), is there any way to globally force the server to execute
the proper module, depending on which virtualhost it's serving, without
having to explicitly do a reload of each individual module (potentially
50)?
Thanks in advance,
Scott
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
porting mod_perl content handler to CGI
Howdy,
I have an application that's pure mod_perl -- its modules use the request
object to do a few bits of work like reading parameters, query string,
specialized logging, dealing with NOT_MODIFIED, and so on. Normal stuff
provided by the methods of Apache, Apache::Util, Apache::URI and
Apache::Connection.
Now, I'd like to use a few of my modules under CGI -- for an administration
part of the application that's bigger and not used enough to use up space
in the mod_perl server. But it would be nice to have a common code base.
So, I'm writing a replacement module of those classes and supporting just
the few methods I need. I'm using CGI.pm, URI, HTTP::Date and so on to
handle those few mod_perl methods I'm using in my modules.
For example, I have a function that does specialized logging that I want to
use both under mod_perl and CGI. So, this would work under CGI
my $r = Apache-request;
my $remote = $r-connection-remote_ip;
where in the replacement package Apache::Connection:
sub remote_ip { $ENV{REMOTE_ADDR} }
Before I spend much time, has this already been done?
Might be kind of cool if one could get new CGI programmers to write all
their CGI applications like mod_perl handlers -- could run as CGI on other
servers, but when they want speed they are ready to use mod_perl.
Anyway, does a mod_perl emulator for CGI exist?
Bill Moseley
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
compiling modperl on alpha
More troubles in this saga to install mod_perl with apache: After building mod_perl static with apache on DU4.0b and getting no errors (so far), I tried the same thing on Tru64 5.1 and I'm still getting this: ld -shared -expect_unresolved "*" -O4 -msym -std -s -L/usr/local/lib -o libperl.so mod_perl.lo perlxsi.lo perl_config.lo perl_util.l o perlio.lo mod_perl_opmask.lo Apache.lo Constants.lo ModuleConfig.lo Log.lo URI.lo Util.lo Connection.lo Server.lo File.lo Table.l o -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE -L/usr/local/lib /usr/local/lib/perl5/5.6.0/alpha-dec_osf/auto/DynaLoade r/DynaLoader.a -L/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE -lperl -lbind -lgdbm -ldbm -ldb -lm -liconv ld: Invalid flag usage: Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE, -Wx,-option must appear after -_SYSTYPE_SVR4 ld: Usage: ld [options] file [...] I'm trying again to do it static, I thought that stuff wasn't used in the static build! What could be the difference between DU4.0b and Tru64 5.1 that could cause this? Both systems have Perl 5.6.0 installed (from source), I'm using cc and there is no GNU ld in either. Apache is 1.3.14 and mod_perl 1.24_01 -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling modperl on alpha
Try getting rid of Perl 5.6 and using 5.005. This has worked for me and for several other folks running other flavors of Unix. Didier Godefroy wrote: More troubles in this saga to install mod_perl with apache: After building mod_perl static with apache on DU4.0b and getting no errors (so far), I tried the same thing on Tru64 5.1 and I'm still getting this: ld -shared -expect_unresolved "*" -O4 -msym -std -s -L/usr/local/lib -o libperl.so mod_perl.lo perlxsi.lo perl_config.lo perl_util.l o perlio.lo mod_perl_opmask.lo Apache.lo Constants.lo ModuleConfig.lo Log.lo URI.lo Util.lo Connection.lo Server.lo File.lo Table.l o -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE -L/usr/local/lib /usr/local/lib/perl5/5.6.0/alpha-dec_osf/auto/DynaLoade r/DynaLoader.a -L/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE -lperl -lbind -lgdbm -ldbm -ldb -lm -liconv ld: Invalid flag usage: Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE, -Wx,-option must appear after -_SYSTYPE_SVR4 ld: Usage: ld [options] file [...] I'm trying again to do it static, I thought that stuff wasn't used in the static build! What could be the difference between DU4.0b and Tru64 5.1 that could cause this? Both systems have Perl 5.6.0 installed (from source), I'm using cc and there is no GNU ld in either. Apache is 1.3.14 and mod_perl 1.24_01 -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jimi Thompson Web Master L3 communications "It's the same thing we do every night, Pinky." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: porting mod_perl content handler to CGI
On Fri, Nov 17, 2000 at 11:53:05AM -0800, Bill Moseley wrote: Now, I'd like to use a few of my modules under CGI -- for an administration part of the application that's bigger and not used enough to use up space in the mod_perl server. But it would be nice to have a common code base. One possibility is to require My::Memory::Hog ; once you know it needs to be used, then to suicide your process when done with the request. That's not always a good idea, if your childinit takes a long time, for instance, but it may simplify your life to not have to worry about the two different environments. Before I spend much time, has this already been done? I do exactly this for a largish chunk of code, I have a Safari::Request object that I fill in from a comand-line or CGI script. You might also look at Apache::FakeRequest. I can send you mine (I posted it to this list or another list recently). There is definitely a recurring interest in runnng mod_perl scripts from command line and via CGI. That's not feasible for all scripts, but for the more "plain vanilla" ones, it should be. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: compiling modperl on alpha
ld -shared -expect_unresolved "*" -O4 -msym -std -s -L/usr/local/lib -o For whatever reason, it's trying to build a dso. I'd double check my settings. Kevin Riggins - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling modperl on alpha
on 11/17/00 3:48 PM, [EMAIL PROTECTED] at [EMAIL PROTECTED] uttered the following: ld -shared -expect_unresolved "*" -O4 -msym -std -s -L/usr/local/lib -o For whatever reason, it's trying to build a dso. I'd double check my settings. You were right, it must be because I had --enable-shared=max in there, maybe it applied that to the extra mod_perl, so I added a --disable-shared=perl and that error is gone, and the make goes all the way now... -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Randal L. Schwartz" wrote: I think y'all are missing it. As soon as I have any Perl code access via Apache::Registry or anything like that, I can do this: *Apache::Registry::handler = \my_trojan_horse; Can you explain in what server-configuration context the above directive would be executed? (I'm not disputing anything you say; just trying to follow.) -- Richard Goerwitz[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with %Location in Perl Config
I'm working on an apache configuration script, and I'm having trouble with
the enabling of perl-status, server-info, etc.
I modified the examples in the eg directory, so I have:
my %handlers = (
"/perl-status" = "Apache::Status",
);
for (keys %handlers) {
$Location{$_} = {
PerlHandler = $handlers{$_},
SetHandler = "perl-script",
Options = "ExecCGI",
};
}
for (qw(status info)) {
$Location{"/server-$_"} = {
SetHandler = "server-$_",
};
}
print STDERR Apache::PerlSections-dump();
---
the dump gives me:
...
#hashes:
%Location = (
'/perl-status' = {
'PerlHandler' = 'Apache::Status',
'SetHandler' = 'perl-script',
'Options' = 'ExecCGI'
},
'/server-status' = {
'SetHandler' = 'server-status'
},
'/server-info' = {
'SetHandler' = 'server-info'
}
);
-
I still get 404 errors. Any suggestions?
--
Barry Hoggard
Chief Technology Officer
http://www.investorama.com
v: 212.905.1639 x194
e: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: two identical directives in Perl configuration
"Adi Fairbank" [EMAIL PROTECTED] wrote:
No I tried that (sorry I should have said so). I think:
Perl
$Location{"blah"} = {
require = ["group payer_manager", "payer_group demo"]
};
/Perl
is equivalent to:
Location "blah"
require group payer_manager payer_group demo
/Location
but I'm not sure.
i belive it is. in fact, i didn't realize specifing two require coditions (one group
and one user) worked on *separate* lines :)
something like:
$Location{"blah"} = {
require = "group payer_manager, payer_group demo"
};
should do the trick.
-dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Apache::Scoreboard
Hi all again, I was trying to add the Apache::Scoreboard module to perl using cpan and it's giving out errors: cc: Error: /usr/local/lib/perl5/site_perl/5.6.0/alpha-dec_osf/auto/Apache/include/inclu de/http_protocol.h, line 153: Invalid declara tion. __attribute__((format(printf,2,3))); ^ cc: Error: /usr/local/lib/perl5/site_perl/5.6.0/alpha-dec_osf/auto/Apache/include/inclu de/http_log.h, line 119: Invalid declaration. __attribute__((format(printf,5,6))); ^ cc: Error: /usr/local/lib/perl5/site_perl/5.6.0/alpha-dec_osf/auto/Apache/include/inclu de/http_log.h, line 122: Invalid declaration. __attribute__((format(printf,5,6))); ^ cc: Error: /usr/local/lib/perl5/site_perl/5.6.0/alpha-dec_osf/auto/Apache/include/inclu de/http_log.h, line 133: Invalid declaration. __attribute__((format(printf,2,3))); ^ is there a bug in that module? Or is there a way to get this to install anyway? (system is Alpha DU4.0b ) -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: two identical directives in Perl configuration (doc patch included)
Dave Kaufman wrote:
i belive it is. in fact, i didn't realize specifing two require coditions (one
group and one user) worked on *separate* lines :)
something like:
$Location{"blah"} = {
require = "group payer_manager, payer_group demo"
};
should do the trick.
-dave
Thanks, that fixed it.
One thing I noticed through all this, is I think the mod_perl documentation is
wrong.. I don't think the following is supported...
DirectoryIndex = [qw(index.html index.htm)],
... unless DirectoryIndex is a special case.
From perl_config.c:
1148 #define SECiter_list(t) \
1149 { \
1150 I32 i; \
1151 for(i=0; i=AvFILL(entries); i++) { \
1152 SV *rv = *av_fetch(entries, i, FALSE); \
1153 HV *nhv; \
1154 if(!SvROK(rv) || (SvTYPE(SvRV(rv)) != SVt_PVHV)) \
1155 croak("not a HASH reference!"); \
1156 nhv = newHV(); \
1157 hv_store(nhv, (char*)key, klen, SvREFCNT_inc(rv), FALSE); \
1158 tab = nhv; \
1159 t; \
1160 SvREFCNT_dec(nhv); \
1161 } \
1162 entries = Nullav; \
1163 continue; \
1164 }
lines 1154-1155 will cause it to croak if any array value in entries is not a
hashref, so an arrayref of scalars (e.g. DirectoryIndex = [qw(index.html
index.htm)]) won't work.
Am I wrong here? I did some simple tests which confirmed my suspicions, but I
may still be missing something.
Below is a documentation patch that I think will prevent other people's
confusion in the future:
Index: mod_perl.pod
===
RCS file: /home/cvspublic/modperl/mod_perl.pod,v
retrieving revision 1.20
diff -u -r1.20 mod_perl.pod
--- mod_perl.pod2000/03/05 23:46:30 1.20
+++ mod_perl.pod2000/11/17 23:18:54
@@ -618,7 +618,7 @@
AuthUserFile = '/tmp/htpasswd',
AuthType = 'Basic',
AuthName = 'test',
- DirectoryIndex = [qw(index.html index.htm)],
+ DirectoryIndex = 'index.html index.htm',
Limit = {
METHODS = 'GET POST',
require = 'user dougm',
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with %Location in Perl Config
To reply to my own messages...
These work fine in the httpd.conf with a Perl section, but I was trying to
do it in a separate startup script. I'm just going to move my code back to
the main conf file for now.
--
Barry Hoggard
Chief Technology Officer
http://www.investorama.com
v: 212.905.1639 x194
e: [EMAIL PROTECTED]
- Original Message -
From: "Barry Hoggard" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, November 17, 2000 5:35 PM
Subject: Problem with %Location in Perl Config
| I'm working on an apache configuration script, and I'm having trouble with
| the enabling of perl-status, server-info, etc.
|
| I modified the examples in the eg directory, so I have:
|
| my %handlers = (
|"/perl-status" = "Apache::Status",
| );
|
| for (keys %handlers) {
| $Location{$_} = {
| PerlHandler = $handlers{$_},
| SetHandler = "perl-script",
| Options = "ExecCGI",
| };
| }
|
|
| for (qw(status info)) {
| $Location{"/server-$_"} = {
| SetHandler = "server-$_",
| };
| }
|
| print STDERR Apache::PerlSections-dump();
|
| ---
| the dump gives me:
|
| ...
|
| #hashes:
|
| %Location = (
| '/perl-status' = {
| 'PerlHandler' = 'Apache::Status',
| 'SetHandler' = 'perl-script',
| 'Options' = 'ExecCGI'
| },
| '/server-status' = {
| 'SetHandler' = 'server-status'
| },
| '/server-info' = {
| 'SetHandler' = 'server-info'
| }
| );
|
|
| -
|
| I still get 404 errors. Any suggestions?
|
|
|
| --
| Barry Hoggard
| Chief Technology Officer
| http://www.investorama.com
| v: 212.905.1639 x194
| e: [EMAIL PROTECTED]
|
|
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: two identical directives in Perl configuration (doc patch included)
Dave Kaufman wrote:
i belive it is. in fact, i didn't realize specifing two require coditions (one
group and one user) worked on *separate* lines :)
something like:
$Location{"blah"} = {
require = "group payer_manager, payer_group demo"
};
should do the trick.
-dave
I wrote:
Thanks, that fixed it.
Actually, no that didn't fix it!
$r-requires
returns
[{ 'group' = "payer_manager, payer_group demo"}]
for the above $Location{} directive. It does no comma separation. I guess the
only workaround is to split on comma after calling $r-requires (in the Auth
handler).
This is definitely not ideal.. I think we should fix this in perl_config.c.
Basically I think there should be some straightforward way to have two (or more)
require statements in $Location{} directives. The most logical seems to be what
Tom suggested:
require = ["group payer_manager", "payer_group demo"]
I'd be happy to submit patches if I got a go ahead from Doug that this would be
useful.
-Adi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: two identical directives in Perl configuration (doc patch included)
"Adi Fairbank" [EMAIL PROTECTED] wrote:
Dave Kaufman wrote:
$Location{"blah"} = {
require = "group payer_manager, payer_group demo"
};
should do the trick.
I wrote:
Thanks, that fixed it.
Actually, no that didn't fix it!
$r-requires
returns
[{ 'group' = "payer_manager, payer_group demo"}]
d'oh! we have the syntax wrong to begin with.
http://www.apache.org/docs/mod/core.html#require says:
Require directive
The allowed syntaxes are:
Require user userid userid ...
Only the named users can access the directory.
Require group group-name group-name ...
^
Only users in the named groups can access the directory.
Require valid-user
All valid users can access the directory.
implying that you *must* specify either
'user' username username ...
or 'group' groupname groupname ...
or 'valid-user'
but the concept of specifying access based on a combination of
username-or-group-memership seems to be undefined.
i thought maybe the satisfy directive might help, ala:
satisfy any
require group simpson
require user bart
but the satisy docs say its only for mixing allow deny type access restrictions with
auth-based restrictions...
i could have sworn i had successfully done this in the past though, allowing a whole
group plus one named user... (but maybe i just added him to the group in question)
perhaps someone else can enlighten us...
-dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling modperl on alpha
On Fri, 17 Nov 2000, Jimi Thompson wrote: Try getting rid of Perl 5.6 and using 5.005. This has worked for me and for several other folks running other flavors of Unix. Weird, but compiled 5.6 perl with default options does not mesh well with mod_perl, however I run Mandrake Linux, and 5.6 precompiled for this platform, seem to integrate into mod_perl somewhat seamlessly. I suppose if you want 5.6 with mod_perl you gotta ask Mandrake folks for compile time options. just 2c Pavel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compiling modperl on alpha
Here is an other one: I finally got mod_perl statically compiled and installed with apache. I didn't run the tests on mod_perl as they fail every time, maybe it has something to do with what's going on now, I'm not sure. When I try to run one of those test scripts that come with apache in the cgi-bin, only the one with the shell works, not the perl one. I tried disabling suexec then mod_perl, but it doesn't change anything with both disabled. CGI works but not with perl, and I even tried it with tcl and the result is the same with tcl and with perl. Using bash or sh work fine. The perl script printenv runs manually on the system but not as a cgi. I checked and double checked the permissions and ownerships, especially since I was trying to get suexec enabled, I think I got all that right (I never used suexec before), but it makes no difference anyway, because I disabled it and it's the same thing. I looked of course in the error logs, including cgierrors, nothing useful there, it only reports a 500 error (premature end of script headers) and nothing more, even with loglevel at debug and the -w perl warnings on. What could I be missing??? -- Didier Godefroy mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: porting mod_perl content handler to CGI
Bill Moseley wrote: Howdy, I have an application that's pure mod_perl -- its modules use the request object to do a few bits of work like reading parameters, query string, specialized logging, dealing with NOT_MODIFIED, and so on. Normal stuff provided by the methods of Apache, Apache::Util, Apache::URI and Apache::Connection. Now, I'd like to use a few of my modules under CGI -- for an administration part of the application that's bigger and not used enough to use up space in the mod_perl server. But it would be nice to have a common code base. I have the stub of one I developed for Apache::ASP called Apache::ASP::CGI. I got it to the point that I could run ASP scripts from the command line, but not much farther. I was able to get scripts to run under CGI, but as I recall, I never implemented POST reading very well. If you would like to roll this into a CGI::Apache or Apache::CGI, that would be great. You can find this package in the body of the ASP.pm module. --Joshua - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
