Re: modperl security model question

2001-04-16 Thread Issac Goldstand

Hmm...  There might be another solution, but it's probably a bit dangerous -
and in any case, one of the more experianced mod_perl people would have to
confirm that it works as expected...

But it would seem to me that if you can figure out at an early enough stage
who you want to run the process as, you could set Apache to run as root:root
and then use a ChildInitHandler (or any early stage handler) to do a setuid
and setgid.  Since perl is part of the child process, this should change the
uid  gid of the entire process. This would seem slightly better then the
below alternative as you can set MaxRequestsPerChild to 1 and just have one
parent process spawning children with different uid/gids, instead of having
to start up an entire server for each uid/gid pair...  Of course, there's
the security problem of everything that happens in the child until it gets
to the setuid AND it's very important to make sure that there's a default
uid/gid pair for the process to put on to prevent any sort of bypass.  I
don't know that I'd pick this solution without mulling it over for a few
days, but maybe people on the list can think up some of the pro's and con's
for me :)

  Issac

(PS.  Yes I know it's a dangerous approach, so you don't all have to
personally bash me over the head with it ;-) )

Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
  --Anonymous

Moving the mouse won't get you into trouble...  Clicking it might.
  --Anonymous

PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B

- Original Message -
From: "sterling" [EMAIL PROTECTED]
To: "Thomas K. Burkholder" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, April 15, 2001 6:06 PM
Subject: Re: modperl security model question


 On Sun, 15 Apr 2001, Thomas K. Burkholder wrote:

  Thanks again for the help - I have another one-
 
  My application consists of perl modules with file permissions set only
  to a particular user 'burkhold'.  The database password is kept in
  plaintext in one of those modules.  I use the User: and Group:
  directives in access.conf to cause the uid of the spawned httpd process
  to have permission to execute the code.  It works fine, except that it
  seems I can't embed 'User: burkhold' inside a Location directive, so
  all requests have to be served as 'burkhold'.  It seems like there
  should be some simple way in apache to specify what user the httpd
  should be set to when it's spawned, but except for the global User: I
  haven't found a way.
 

 An httpd process is spawned to handle _all_ locations, that is why the
 Group/User can only be specified per server.  If apache was able to spawn
 separate processes to only handle one location, your suggestion would
 work.

 The only solution i would offer would be to proxy all requests to
 that location to another apache server, running on a different port,
 as user bukhold. The main server could then run with whatever user is
 appropriate, and have a ProxyPass directive to forward requests requiring
 user burkhold.


 sterling




  If I can't make this work, I may have to turf module handlers and go
  with a Registry and setuid solution, which I think would be a shame
  since I think handlers are a lot more elegant.
 
  This is probably well-trodden territory - anyone got a solution?
 
  Thanks again, several of you have been helpful to me, and I do
  appreciate it.
 
  Happy Easter.
 
  file://Thomas
  Thomas K. Burkholder
  [EMAIL PROTECTED]
 






Re: mac_check in eagle book

2001-04-16 Thread Perrin Harkins

 On 16 Apr 2001, Chip Turner wrote:

  The modperl book mentions it double hashes to prevent a
  malicious user from concatenating data onto the values being checked.
  I don't know if they are referring to this weakness, but I suspect
  they are.  Sadly, the book doesn't seem to offer a reference for the
  claim as to the specific md5 vulnderability.  (Hey Doug, wanna shed
  some light on that somewhat cryptic passage? :)

 I'm sure I recall seeing a book on cryptography mentioned in the footnotes
 somewhere...

The crypto section in Mastering Algoritms with Perl is a pretty good
overview.
- Perrin






Re: Apache growing.

2001-04-16 Thread Dave Hodgkinson

Michael Bacarella [EMAIL PROTECTED] writes:

 (I'm not sure this is even a code problem. Maybe perl is just bad at keeping
 a single consistent working set and the copy-on write from the parent Apache
 kicks in and keeps increasing unique per process memory consumption).

There's lots of good stuff in the mod_perl guide on tracking down
leaks. Both perl and mod_perl have both been extensively tested .

It's worthwhile to have done this at least once so you know how to do
it when you really need to do it. In addition, profiling your code is
a Good Thing to do :-)


-- 
Dave Hodgkinson, http://www.hodgkinson.org
Editor-in-chief, The Highway Star   http://www.deep-purple.com
  Interim CTO, web server farms, technical strategy
   



Re: Unwanted \n in output

2001-04-16 Thread G.W. Haywood

Hi there,

On Sat, 14 Apr 2001, willems Luc wrote:

 I have some Apache::ASP scripts that work like a XML::RPC
[snip]
 One of my scrips has a problem that in the response , 7  times a '\n' 
 charecter is put before the actual XML text

Have you got some % # comments % in a template or something like that?
Sometimes you have to fiddle with the exact location of the % and % tags
to get the whitespace just right.

HTH

73,
Ged.




Re: Apache growing.

2001-04-16 Thread Michael Bacarella

On Mon, Apr 16, 2001 at 11:25:47AM +0100, Dave Hodgkinson wrote:
  (I'm not sure this is even a code problem. Maybe perl is just bad at keeping
  a single consistent working set and the copy-on write from the parent Apache
  kicks in and keeps increasing unique per process memory consumption).
 
 There's lots of good stuff in the mod_perl guide on tracking down
 leaks. Both perl and mod_perl have both been extensively tested .
 
 It's worthwhile to have done this at least once so you know how to do
 it when you really need to do it. In addition, profiling your code is
 a Good Thing to do :-)

Since you say so, I'll try it. :)

-- 
Michael Bacarella [EMAIL PROTECTED]
Technical Staff / System Development,
New York Connect.Net, Ltd.



RE: negative LocationMatch syntax?

2001-04-16 Thread Geoffrey Young



 -Original Message-
 From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, April 12, 2001 2:00 PM
 To: [EMAIL PROTECTED]
 Cc: modperl; modssl
 Subject: Re: negative LocationMatch syntax?
 
 

[snip]

  Is there a way I could use LocationMatch to specify a not 
 condition?
  as in 
  LocationMatch !~ "/(thisfile|thatDir|whatever).*"
  SSLVerifyClient require
  /LocationMatch
  
  That would let me list the exceptions, and everything else would be
  restricted by default..
 
 It's really frustrating, but this is *not* possible... 

I _hate_ hearing that...

anyway, after an initial attempt to hack http_request.c (which didn't seem
that hard but proved beyond my meager C) I came up with this:

http://morpheus.laserlink.net/~gyoung/modules/Apache-ReverseLocation-0.01.ta
r.gz

it's just proof-of-concept at this point, but allows for reversed Location
!~ "foo"  and LocationMatch !~ "foo" by just including it as a PerlModule

it's major limitation at this point is that you can only have one reversed
configuration - I didn't build in regex = location mappings yet, just in
case somebody points out that this can never really work.  In my tests,
though, it seemed to work just fine, but I may be missing something.

anyway, if anyone thinks this is a worthy endeavor (over patching httpd
core), and doesn't manage to show how futile the efforts really is, then I
maybe I'll tidy it up, document it, and release it...

have fun...

--Geoff



Re: Unwanted \n in output

2001-04-16 Thread Joshua Chamas

willems Luc wrote:
 
 Hello everybody ,
 
 I have some Apache::ASP scripts that work like a XML::RPC . The idea is to
 send some XML request and the response will be an answer in XML that can be
 used by the client software.
 
 One of my scrips has a problem that in the response , 7  times a '\n'
 charecter is put before the actual XML text (seen by using ethereal ). This
 confuses my clients XML parser (M$ parser ).
 I don't know where these characters come from. The ouput i generated doesn't
 have it. I already tryed Response-Binarywrite and flushing but this doesn't
 do the trick.
 Does anybody know where this comes from ?
 

Like Ged said, check out your % %, but also if you want to kill
leading white space globally, you might post process your output
in your global.asa with Script_OnFlush:

sub Script_OnFlush {
   my $out_ref = $Response-{BinaryRef};
   $$out_ref =~ s/^\s+(\\?xml)/$1/s
}

Then set PerlSetVar BufferingOn 1 so that flush will only be called
once per script.

--Josh

_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks  free web link monitoring   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051



Re: Unwanted \n in output

2001-04-16 Thread Andrew Ho

Hello,

WLOne of my scrips has a problem that in the response , 7 times a '\n'
WLcharecter is put before the actual XML text (seen by using ethereal ).
WLThis confuses my clients XML parser (M$ parser ).

Actually, I think you are misdiagnosing your problem. The "7\n" that you
are seeing in your packet sniff sounds like a chunked Transfer-Encoding
byte size (check RFC 2616, the HTTP 1.1 specification, and read up on
chunked Transfer-Encoding). This would be perfectly normal in the case
that Apache doesn't know the Content-Length to send (which for scripts, it
won't unless you set it yourself).

Humbly,

Andrew

--
Andrew Ho   http://www.tellme.com/   [EMAIL PROTECTED]
Engineer   [EMAIL PROTECTED]  Voice 650-930-9062
Tellme Networks, Inc.   1-800-555-TELLFax 650-930-9101
--




[DIGEST] mod_perl digest 04/14/01

2001-04-16 Thread Geoffrey Young

--

  mod_perl digest
 
   April 8, 2001 - April 14, 2001

--

Recent happenings in the mod_perl world...


Features

  o mod_perl status
  o module announcements
  o mailing list highlights
  o news
  o links


mod_perl status

  o mod_perl
- stable: 1.25 (released January 29, 2001) [1]
- development: 1.25_01-dev [2]
  o Apache
- stable: 1.3.19 (released February 28, 2001) [3]
- development: 1.3.20-dev [4]
  o Perl
- stable: 5.6.1 (released April 9, 2001) [5]
- development: 5.7.1 [6]


module announcements

  o Apache::AuthTicket 0.31 - implementation of a cookie based
authentication system similar to the ticket access system
described in the Eagle book [7]


mailing list highlights

  o 58 patches to 2.0 this week! [8] 

  o A little expose on using constant subroutines as debug
constants [9] [10]

  o Here are some hints on getting the elusive PerlSetVar PERL5LIB
configuration to work [11]

  o A quick hack that allows you to pass off scripts to mod_cgi
based on their execution bit [12]

  o Here is an Apache::FakeRequest-like script that also captures
calls to Apache::Request and Apache::Cookie [13]
   
  o A patch for Apache::Session::Lock::File::clean() [14]

  o There was some discussion about a small security risk in MD5 
hashes, stemming from an example in the Eagle book [15]


news

  o Netcraft mod_perl statistics are out for March [16]
  mod_perl: 2,298,821 Domains, 244,201 IP Addresses

  o Apacheweek released a conference report from ApacheCon US [17]


links

  o The Apache/Perl Integration Project [18]
  o mod_perl documentation [19]
  o mod_perl modules on CPAN [20]
  o mod_perl homepage [21]
  o mod_perl news and advocacy [22]
  o mod_perl list archives [23] [24]


happy mod_perling...

--Geoff
[EMAIL PROTECTED]

--
[1] http://perl.apache.org/dist/
[2] http://perl.apache.org/from-cvs/modperl/
[3] http://www.apache.org/dist/
[4] http://dev.apache.org/from-cvs/apache-1.3/
[5] http://www.cpan.org/src/stable.tar.gz
[6] http://www.cpan.org/src/devel.tar.gz 
[7] http://forum.swarthmore.edu/epigone/modperl/twenphalbran
[8] http://marc.theaimsgroup.com/?l=apache-modperl-cvsr=1w=2
[9] http://forum.swarthmore.edu/epigone/modperl/pynultol
[10] http://forum.swarthmore.edu/epigone/modperl/goxskybril
[11] http://forum.swarthmore.edu/epigone/modperl/phanggexshu
[12] http://forum.swarthmore.edu/epigone/modperl/twexboonox
[13] http://forum.swarthmore.edu/epigone/modperl/florweldspix
[14] http://forum.swarthmore.edu/epigone/modperl/vexsixcloi
[15] http://forum.swarthmore.edu/epigone/modperl/spoothixyim
[16] http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=98698878715514w=2
[17] http://www.apacheweek.com/issues/01-04-13
[18] http://perl.apache.org
[19] http://perl.apache.org/#docs
[20] http://www.cpan.org/modules/by-module/Apache/
[21] http://www.modperl.com
[22] http://www.take23.org
[23] http://forum.swarthmore.edu/epigone/modperl/
[24] http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2



Re: mac_check in eagle book

2001-04-16 Thread Larry Leszczynski

Hi Eric -

 I was wondering if someone could explain to me why in the eagle book it
 is necessary to perform 
 an md5 twice before sending a mac_check to a user of a number of
 fields.  I read in the mod_perl book that this is done 'to prevent
 technically savy users from appending data to the @fields'. 
 
 my $mac_check = md5_hex($secret,
 md5_hex(join '', $secret, @fields));  

disclaimer I am not a crypto expert /disclaimer

There is a good explanation starting on page 5 of this:
   ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto1n1.pdf

Basically because the algorithm is iterative and pads the length of input
data to multiples of 512 bits, you can start with a MAC that came from
MD5(secret + data), and use it to create a new MAC that corresponds to
MD5(secret + data + pad + appended_data), without ever knowing what the
original secret was.

As an alternative to MD5(secret + data), the authors recommendations
include:
   MD5(secret + MD5(secret + data) )
or possibly better:
   MD5(secret1 + MD5(secret2 + data) )


Hope this helps!
Larry Leszczynski
[EMAIL PROTECTED]




sending a response without a Content-Type header

2001-04-16 Thread Matthew Darwin


I'm buiding an HTTP gateway in mod_perl and trying to send back to the
client exactly what I get from the remote server.  The remote server
doesn't set a Content-Type on the document being returned, so I don't want
to set one either.

However, Mod_perl (or Apache), doesn't like it when I don't send a
Content-type and seems to send a default of text/plain regardless.  I
don't want this.  I don't want any Content-type at all.

What I have now is sending mod_perl a Content-Type of ''.  This sends a
blank Content-Type to the browser.  How can I avoid doing this?

Suggestions?


Here is an abbreviated program:


sub handler {
my $r = Apache-request;
my $ip = '1.2.3.4'; my $port = 80;

my $ua = new LWP::UserAgent;
my $request = new HTTP::Request $r-method, "http://$ip:$port" . $r-uri;
my $response = $ua-request($request);

if (defined $response-header('Content-type')) {
$r-content_type($res-header('Content-type'));
} else {
$r-content_type('');   # don't want to do this
}
$r-status($response-code);
$r-status_line(join " ", $response-code, $response-message);
$response-scan(sub {
$r-header_out(@_);
});

$r-send_http_header;
$r-print($response-content);
}

This is actually what the device returns:


% telnet realdevice 80
Trying 1.2.3.4...
Connected to realdevice.
Escape character is '^]'.
GET /

HTTP/1.0 200 OK

HTML
[chop]
/HTML

-- 
Matthew Darwin
[EMAIL PROTECTED]




Re: modperl security model question

2001-04-16 Thread Thomas K. Burkholder

Actually, what I'm trying to do now is, in access.conf:

Note, /tmp/tmppswd is read-only by the installer of the product, but I should
be root in access.conf (right?) so I should be able to read it anyway.

  perl
use IO::File;
my $input = IO::File-new("/tmp/tmppswd") || die "Couldn't open
/tmp/foo.pl";
my $line = $input-getline();
print STDERR $line;
$input-close();
 #   $line = 'bar';
$Location{'/areaj'} = {
  PerlSetVar = [
[foo = $line]
  ],
  SetHandler = 'perl-script',
  PerlHandler = 'AreaJ::AreaJ'
}
#push @{ $Location{'/areaj'}-{PerlSetVar} }, [foo = $line];
  /perl

Now I get an error:
[Mon Apr 16 15:43:32 2001] [error] Perl: PerlSetVar takes two arguments, Perl
config var and value
... because $line is somehow being evaluated to 0.  If I uncomment the first
commented line, it works, leading me to believe that somehow the values inside
PerlSetVar have to be constants of some sort.  Commenting out the PerlSetVar
part and uncommenting the push line just gives me 404 (doesn't even print out
my STDERR statement earlier in the routine, I really don't get that).

I'm obviously being a bonehead.  Can anyone help?

Thanks,

//Thomas
Issac Goldstand wrote:

 Hmm...  There might be another solution, but it's probably a bit dangerous -
 and in any case, one of the more experianced mod_perl people would have to
 confirm that it works as expected...

 But it would seem to me that if you can figure out at an early enough stage
 who you want to run the process as, you could set Apache to run as root:root
 and then use a ChildInitHandler (or any early stage handler) to do a setuid
 and setgid.  Since perl is part of the child process, this should change the
 uid  gid of the entire process. This would seem slightly better then the
 below alternative as you can set MaxRequestsPerChild to 1 and just have one
 parent process spawning children with different uid/gids, instead of having
 to start up an entire server for each uid/gid pair...  Of course, there's
 the security problem of everything that happens in the child until it gets
 to the setuid AND it's very important to make sure that there's a default
 uid/gid pair for the process to put on to prevent any sort of bypass.  I
 don't know that I'd pick this solution without mulling it over for a few
 days, but maybe people on the list can think up some of the pro's and con's
 for me :)

   Issac

 (PS.  Yes I know it's a dangerous approach, so you don't all have to
 personally bash me over the head with it ;-) )

 Internet is a wonderful mechanism for making a fool of
 yourself in front of a very large audience.
   --Anonymous

 Moving the mouse won't get you into trouble...  Clicking it might.
   --Anonymous

 PGP Key 0xE0FA561B - Fingerprint:
 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B

 - Original Message -
 From: "sterling" [EMAIL PROTECTED]
 To: "Thomas K. Burkholder" [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Sent: Sunday, April 15, 2001 6:06 PM
 Subject: Re: modperl security model question

  On Sun, 15 Apr 2001, Thomas K. Burkholder wrote:
 
   Thanks again for the help - I have another one-
  
   My application consists of perl modules with file permissions set only
   to a particular user 'burkhold'.  The database password is kept in
   plaintext in one of those modules.  I use the User: and Group:
   directives in access.conf to cause the uid of the spawned httpd process
   to have permission to execute the code.  It works fine, except that it
   seems I can't embed 'User: burkhold' inside a Location directive, so
   all requests have to be served as 'burkhold'.  It seems like there
   should be some simple way in apache to specify what user the httpd
   should be set to when it's spawned, but except for the global User: I
   haven't found a way.
  
 
  An httpd process is spawned to handle _all_ locations, that is why the
  Group/User can only be specified per server.  If apache was able to spawn
  separate processes to only handle one location, your suggestion would
  work.
 
  The only solution i would offer would be to proxy all requests to
  that location to another apache server, running on a different port,
  as user bukhold. The main server could then run with whatever user is
  appropriate, and have a ProxyPass directive to forward requests requiring
  user burkhold.
 
 
  sterling
 
 
 
 
   If I can't make this work, I may have to turf module handlers and go
   with a Registry and setuid solution, which I think would be a shame
   since I think handlers are a lot more elegant.
  
   This is probably well-trodden territory - anyone got a solution?
  
   Thanks again, several of you have been helpful to me, and I do
   appreciate it.
  
   Happy Easter.
  
   file://Thomas
   Thomas K. Burkholder
   [EMAIL PROTECTED]
  
 
 




Dynamic httpd.conf file using mod_perl...

2001-04-16 Thread Brian

I work for a small domain hosting company, and we currently host a few
hundred domains.  What I'm trying to do is have apache build the httpd.conf
file dynamically when it starts from a MySQL database.  Easy enough.  Got
most of it working, the only thing I'm running into is mod_rewrite problems.
Does anybody have any idea how to add the following:

RewriteEngine on
RewriteCond %{REMOTE_ADDR} !^90.0.0.1$
RewriteRule .* http://www.whatever.com

to my current perl code (note - this isn't extracting info from the database
yet.  Just a simple text file for testing purposes):

Perl
  open(SC, " /www/conf/virtual-domains.conf") || die "$!";
  while(SC) {
chomp;
next if(/^s*#/);
my($sn,$sa,$ip,$htdir,$errlog,$translog) = split(/:/,$_,-1);
$VirtualHost{$sn} = {
  ServerName   = $sn,
  ServerAlias  = "www.".$sn",
  DocumentRoot = "/www/virtual/".$htdir,
  ErrorLog = "/www/virtual/".$htdir."logs/".$errlog,
  TransferLog  = "/www/virtual/".$htdir."logs/".$translog
};
  }
  close(SC);
__END__
/Perl

I'm thinking I can just add RewriteEngine = "on" to the VirtualHost hash.
But how do I handle the RewriteCond and the RewriteRule?  Can I make a hash
of hashes or something?  Maybe do something like:

RewriteCond = {'\%{REMOTE_ADDR}' = "!^90.0.0.1\$" },
RewriteRule = {'\.*' = "http://www.whatever.com" },

But that doesn't really work.  Just so you know, I've removed all of the
error checking for readability.  I didn't copy and paste this, so there
might be some syntax errors.  Anyway, if anybody can make a suggestion, or
point me at a web site I would appreciate it.  Thanks a ton in advance.

Brian Johnson
Systems Administrator/Programmer
Keweenet, LLC (www.keweenet.com)
Surgeon General announcement:
"Coffee is a direct substitute for sleep."




Re: Dynamic httpd.conf file using mod_perl...

2001-04-16 Thread Perrin Harkins

 What I'm trying to do is have apache build the httpd.conf
 file dynamically when it starts from a MySQL database.

It might be easier and more bulletproof to build the conf file off-line with
a simple perl script and a templating tool.  We did this with Template
Toolkit and it worked well.
- Perrin




RE: Dynamic httpd.conf file using mod_perl...

2001-04-16 Thread Brian

 It might be easier and more bulletproof to build the conf file
 off-line with
 a simple perl script and a templating tool.  We did this with Template
 Toolkit and it worked well.
 - Perrin

That would be fine and dandy, but it's not exactly what I'm going after.
Currently if I want to make a change to all of our clients I have to go
through and edit every config file (I have a .conf file for each domain and
then use an Include in the httpd.conf).  Using the mod_perl way I can change
it once in the httpd.conf file, restart apache, and the change will take
place for all the domains that are affected by the Perl /Perl code.
Know what I mean?

Brian Johnson
Systems Administrator/Programmer
Keweenet, LLC (www.keweenet.com)
Surgeon General announcement:
"Coffee is a direct substitute for sleep."




Re: Dynamic httpd.conf file using mod_perl...

2001-04-16 Thread Jim Winstead

On Mon, Apr 16, 2001 at 07:12:23PM -0400, Brian wrote:
  It might be easier and more bulletproof to build the conf file
  off-line with
  a simple perl script and a templating tool.  We did this with Template
  Toolkit and it worked well.
  - Perrin
 
 That would be fine and dandy, but it's not exactly what I'm going after.

it seems to me you're conflating your goal and your means of achieving
it.

 Currently if I want to make a change to all of our clients I have to go
 through and edit every config file (I have a .conf file for each domain and
 then use an Include in the httpd.conf).  Using the mod_perl way I can change
 it once in the httpd.conf file, restart apache, and the change will take
 place for all the domains that are affected by the Perl /Perl code.
 Know what I mean?

this is certainly possible by generating your configuration files
using a perl script, outside of using mod_perl.

jim



RE: Dynamic httpd.conf file using mod_perl...

2001-04-16 Thread Brian


 it seems to me you're conflating your goal and your means of achieving
 it.

I don't think I'm conflating the goal and the means.  At least I don't see
how I am

 this is certainly possible by generating your configuration files
 using a perl script, outside of using mod_perl.

Aaah, but you see that would create a bunch of configuration files or make
one huge configuration file.  My method would eliminate all but one
configuration file (httpd.conf) and use our billing database to create the
configuration files.  That way when a client is deactivated in the DB it's
automatically deactivated in apache the next time it's HUP'ed.  Yeah, I
could write a separate perl script to go in, find the line that says
"Include /www/conf/viraul/domain.conf" and then pound it out and restart the
server.  I can also write a perl script to create all the config files for
me.  But why not do both in the config file if possible?

It's all written, only problem is the mod_rewrite directives.  Any ideas on
how to do them in a Perl directive?  Thanks in advance.

Brian Johnson
Systems Administrator/Programmer
Keweenet, LLC (www.keweenet.com)
Surgeon General announcement:
"Coffee is a direct substitute for sleep."




Re: Dynamic httpd.conf file using mod_perl...

2001-04-16 Thread Jim Winstead

On Mon, Apr 16, 2001 at 07:37:32PM -0400, Brian wrote:
 
  it seems to me you're conflating your goal and your means of achieving
  it.
 
 I don't think I'm conflating the goal and the means.  At least I don't see
 how I am

well, perhaps that wasn't the best way to put it.

  this is certainly possible by generating your configuration files
  using a perl script, outside of using mod_perl.
 
 Aaah, but you see that would create a bunch of configuration files or make
 one huge configuration file.  My method would eliminate all but one
 configuration file (httpd.conf) and use our billing database to create the
 configuration files.  That way when a client is deactivated in the DB it's
 automatically deactivated in apache the next time it's HUP'ed.  Yeah, I
 could write a separate perl script to go in, find the line that says
 "Include /www/conf/viraul/domain.conf" and then pound it out and restart the
 server.  I can also write a perl script to create all the config files for
 me.  But why not do both in the config file if possible?

and the suggestion perrin made would have basically the same result.
your configuration file would be a template, basically, that was
expanded into the real configuration file that is then read by the
apache process. it is very close to what you are doing, without
introducing the vagaries of getting mod_perl and mod_rewrite
to cooperate.

you would have to do a "run config template expander  HUP" instead
of just doing a HUP of the apache parent process, but that doesn't
seem like a big deal to me.

 It's all written, only problem is the mod_rewrite directives.  Any ideas on
 how to do them in a Perl directive?  Thanks in advance.

nope.

jim



Re: Dynamic httpd.conf file using mod_perl...

2001-04-16 Thread ___cliff rayman___

checkout the following link:
http://www.geocrawler.com/archives/3/182/2000/3/0/3377287/

the search engine at:
http://www.geocrawler.com/lists/3/Web/182/0/

is your friend.

--
___cliff [EMAIL PROTECTED]http://www.genwax.com/

Brian wrote:

 It's all written, only problem is the mod_rewrite directives.  Any ideas on
 how to do them in a Perl directive?  Thanks in advance.







Re: modperl question

2001-04-16 Thread Daniel



John V. Jaskolski wrote:

 I want to write a Web Hosting Control Panel for virtually hosting web sites
 (100 to 1000 per server).  I am debating whether to write it in Perl,
 mod_perl or C.  I want to write it in mod_perl because it would be faster
 than Perl and easier to write than C.  However, In his article on modperl
 and ISP's, Stas says:
 
 
 Note that it's impossible to run suEXEC and cgiwrap extensions under
 
 mod_perl.
 
 Of course as an ISP you can run mod_perl internally, without allowing your
 users to map their scripts so that they will run under mod_perl. If as a
 
 part of
 
 your service you provide scripts such as guest books, counters etc. which
 
 are
 
 not available for user modification, you can still can have these scripts
 
 running
 
 very fast.
 
 
 I have 2 questions:
 
 1.) How do you "run mod-perl internally"?

Just as an example you can create a global mod_perl registry location 
containing scripts that all your clients can use, but not modify. While 
using a different registry enabled directory for your control-panel.
Note: the entire server still has mod_perl loaded regardless of whether 
or not the clients are using mod_perl scripts so you'd better have 
enough ram.

This may contain errors:


#Create a global registry directory in the main server:

Alias /preconfig-scripts/ /home/httpd/user_untouchable
#counters, guestbooks, etc
Location /preconfig-scripts/
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
/Location

#In the virtual hosts:
#your domain:
NameVirtualHost xxx.xxx.xxx.xxx
VirtualHost xxx.xxx.xxx.xxx
ServerName your.isp.net
DocumentRoot /home/httpd/ispname
Directory /control-panel/
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
/Directory
/VirtualHost
#a client:
VirtualHost xxx.xxx.xxx.xxx
ServerName www.someclient.com
DocumentRoot /home/httpd/someclient
Directory /home/httpd/someclient
Options Includes
AllowOverride AuthConfig Indexes Limit

/Directory

ScriptAlias /cgi-bin/ /home/httpd/someclient/cgi-bin/
/VirtualHost

 
 2.) If is there a way to "run mod-perl internally" so that suEXEC and/or
 cgiwrap can be run for security purposes.
 
 The whole reason I hesitate to use mod_perl is because this will be a
 virtual hosting environment where lots of users could "do anything", and I
 want to take all of the security precautions I can.  But if it's at all
 possible to do it securely, then I would love to use mod_perl because it
 would be much easier than C.
 
 Any input anyone has would be greatly appreciated!
 
 Sincerely,
 
 Dr. John V. Jaskolski


-- 
Daniel Bohling




Re: Dynamic httpd.conf file using mod_perl...

2001-04-16 Thread Perrin Harkins

  It might be easier and more bulletproof to build the conf file
  off-line with
  a simple perl script and a templating tool.  We did this with Template
  Toolkit and it worked well.
  - Perrin

 That would be fine and dandy, but it's not exactly what I'm going after.
 Currently if I want to make a change to all of our clients I have to go
 through and edit every config file (I have a .conf file for each domain
and
 then use an Include in the httpd.conf).  Using the mod_perl way I can
change
 it once in the httpd.conf file, restart apache, and the change will take
 place for all the domains that are affected by the Perl /Perl code.
 Know what I mean?

Sure, and it looks like you got your question answered.  The two approaches
are pretty similar in terms of the results, but the off-line approach does
require either using a custom startup script or doing two steps (build conf
and then restart server).  On the other hand, the off-line approach will
allow you to start your server even when the database is down.  You might
want to build your dynamic conf file approach with a cache for the
last-accessed database info, so that it has something to fall back to if the
db goes down.
- Perrin




RE: Dynamic httpd.conf file using mod_perl...

2001-04-16 Thread Brian

Thanks all for the suggestions and idea provoking chatter.  I appreciate.  I
also much apologize as I didn't fully comprehend your first suggestion
Perrin.  Simple mind lapse caused by a lack of sleep and not enough
caffeine.  :o)

But, you are right about the DB being down.  A cache is a must in such a
case.  Thank you for pointing that out.  :o)

Brian Johnson
Systems Administrator/Programmer
Source1hosting.tv (www.source1hosting.tv)
Surgeon General announcement:
"Coffee is a direct substitute for sleep."

 Sure, and it looks like you got your question answered.  The two
 approaches
 are pretty similar in terms of the results, but the off-line approach does
 require either using a custom startup script or doing two steps
 (build conf
 and then restart server).  On the other hand, the off-line approach will
 allow you to start your server even when the database is down.  You might
 want to build your dynamic conf file approach with a cache for the
 last-accessed database info, so that it has something to fall
 back to if the
 db goes down.
 - Perrin





Re: modperl security model question

2001-04-16 Thread darren chamberlain

Be sure to check that $line is defined:

Thomas K. Burkholder ([EMAIL PROTECTED]) said something to this effect on 
04/16/2001:
 Note, /tmp/tmppswd is read-only by the installer of the product, but I should
 be root in access.conf (right?) so I should be able to read it anyway.
 
   perl
 use IO::File;
 my $input = IO::File-new("/tmp/tmppswd") || die "Couldn't open /tmp/foo.pl";
 my $line = $input-getline();

  die "\$line is not defined" unless (defined $line);

 print STDERR $line;
 $input-close();
  #   $line = 'bar';
 $Location{'/areaj'} = {
   PerlSetVar = [
 [foo = $line]
   ],
   SetHandler = 'perl-script',
   PerlHandler = 'AreaJ::AreaJ'
 }
 #push @{ $Location{'/areaj'}-{PerlSetVar} }, [foo = $line];
   /perl

(darren)

-- 
The three most dangerous things are a programmer with a soldering iron,
a manager who codes, and a user who gets ideas.



Mea Culpa [Was: Re: modperl security model question]

2001-04-16 Thread Thomas K. Burkholder

It's defined all right, it gets printed to STDERR.

The problem was that the file I was actually using was a perl file '/tmp/foo.pl', just
because it didn't matter what was in the file while I tried to make it work.  But, 
wait, it
does matter, because the first thing in the file was "use Data::Dump;".  Apparently, 
some
translation that goes on in there turns that string into an execution of it (or 
something).
It's probably a bug if anyone cares - just use the same example I gave but make sure 
the
first two lines are "use Data::Dump;" and it should reproduce.

Or am I missing something?  Is there a perfectly logical reason why having the $line 
variable
contain "use Data::Dump;" should result in $line being evaluated to undef a few lines 
later?

Thanks to those who helped.

//T

darren chamberlain wrote:

 Be sure to check that $line is defined:

 Thomas K. Burkholder ([EMAIL PROTECTED]) said something to this effect on 
04/16/2001:
  Note, /tmp/tmppswd is read-only by the installer of the product, but I should
  be root in access.conf (right?) so I should be able to read it anyway.
 
perl
  use IO::File;
  my $input = IO::File-new("/tmp/tmppswd") || die "Couldn't open /tmp/foo.pl";
  my $line = $input-getline();

   die "\$line is not defined" unless (defined $line);

  print STDERR $line;
  $input-close();
   #   $line = 'bar';
  $Location{'/areaj'} = {
PerlSetVar = [
  [foo = $line]
],
SetHandler = 'perl-script',
PerlHandler = 'AreaJ::AreaJ'
  }
  #push @{ $Location{'/areaj'}-{PerlSetVar} }, [foo = $line];
/perl

 (darren)

 --
 The three most dangerous things are a programmer with a soldering iron,
 a manager who codes, and a user who gets ideas.




fatal Relocation error (revisted)

2001-04-16 Thread Carlos Ramirez


I recently upgraded to Apache/1.3.19 (Unix) mod_perl/1.25 mod_ssl/2.8.2
OpenSSL/0.9.6a on Solaris 2.5.1 running perl 5.004_04. Everyhting works
dandy except for .so stuff (??). specifically when trying to run Apache:;AuthenSmb.
I hit a brick wall trying to figure out a solution for the "...fatal: relocation
error:". I read through the archives but after several hours of trying
to figure things out, i'm thoroughly confused now.
Is this a mod_perl problem?. I've read several potential fixes, such
a re-building perl with -Xlinker --export-dynamic . I tried going back
to older versions of mod_perl without any luck ;(
Here's the error I get. The module, Authen::Smb runs fine through a
regular perl script from the command line. but stops working through mod_perl.
Can't load '/usr/local/lib/perl5/site_perl/sun4-solaris/auto/Authen/Smb/Smb.so'
for module Authen::Smb: ld.so.1: /usr/local/etc/apache_1.3.19/bin/httpd:
fatal: relocation error: file /usr/local/lib/perl5/site_perl/sun4-solaris/auto/Authen/Smb/Smb.so:
symbol main: referenced symbol not found at /usr/local/lib/perl5/sun4-solaris/5.00404/DynaLoader.pm
line 166.

at /usr/local/lib/perl5/site_perl/Apache/AuthenSmb.pm line 5
BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/Apache/AuthenSmb.pm
line 5.
Can someone point me in the right direction?
Thanks,
Carlos



--
---
Carlos Ramirez + Boeing + Reusable Space Systems + 714.372.4181
---