Installing mod_perl when other things are required, too.

2000-04-23 Thread Forrest Aldrich

I couldn't find a faq on this one.

I need to also install apache with php and mod_ssl.   Those two require a 
simple ./configure --switch to enable them.   I didn't see anything for 
mod_perl in the INSTALL, and it seemed there were a lot of manual things to 
be done, which made me think I wasn't reading it correctly.

What's the magic incantation?


TIA




Re: Installing mod_perl when other things are required, too.

2000-04-23 Thread Matt Sergeant

On Sat, 22 Apr 2000, Forrest Aldrich wrote:

 I couldn't find a faq on this one.
 
 I need to also install apache with php and mod_ssl.   Those two require a 
 simple ./configure --switch to enable them.   I didn't see anything for 
 mod_perl in the INSTALL, and it seemed there were a lot of manual things to 
 be done, which made me think I wasn't reading it correctly.
 
 What's the magic incantation?

Install mod_perl first, making sure you enable mod_so.
Then php should just install fine as a dso. I'm not sure about mod_ssl
though - I think it has to patch the Apache source. I'm almost certain
this is covered in one of the INSTALL.foo documents.

-- 
Matt/

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org




Re: Installing mod_perl when other things are required, too.

2000-04-23 Thread Richard Dice

 I need to also install apache with php and mod_ssl.   Those two require a
 simple ./configure --switch to enable them.   I didn't see anything for
 mod_perl in the INSTALL, and it seemed there were a lot of manual things to
 be done, which made me think I wasn't reading it correctly.
 
 What's the magic incantation?

There isn't a magic incantation, and there is a lot of stuff that has
to be done manually.

Stas' mod_perl Guide is your friend:
  http://perl.apache.org/guide/install.html#Installation_Scenarios_for_mod_p

You won't find something describing your exaction situation here, but
this should give you a leg up.  mod_php should have an option that allows
it to be created as a (guess what) module to be added to the web server
(rather than an integrated build procedure, like what mod_perl does with
DO_HTTPD = 1).  I expect that you could then treat that module similarly
with how you take care of the modules as described with the URL above.

However, you might find that throwing all 3 of those modules into Apache
will create for you a bloated beast of a server.  If conserving memory is
at all important to you, then you should take a look at the recent thread
that went on on this list, "[RFC] Do Not Run Everything on One mod_perl
Server":
  http://forum.swarthmore.edu/epigone/modperl/floivonmel
The concepts discussed here could help you manage your memory more effectively
(though you'll have to come up with the implementation yourself).

Cheers,
Richard
 

 Richard Dice * Personal 514 816 9568 * Fax 514 816 9569
 ShadNet Creator * http://shadnet.shad.ca/ * [EMAIL PROTECTED]
 Occasional Writer, HotWired * http://www.hotwired.com/webmonkey/
 "squeeze the world 'til it's small enough to join us heel to toe"
 - jesus jones



RE: mod_perl-1.99_01-dev [ - possibly OT ]

2000-04-23 Thread Gerald Richter


 I though the new apache model was a hybrid were there were preforked
 children that then used threads - have I missed the plot here ?


Yes, you can configure any combination. See Erics mails on the "RE: mod_perl
2.x/perl 5.6.x ?" for a list of possible combinations.

Gerald





RE: mod_perl 2.x/perl 5.6.x ?

2000-04-23 Thread Gerald Richter


 So, does that still leave mod_perl serializing access until
 everything is rewritten to be thread-safe?


No, mod_perl 2.0 assign a "full" Perl interpreter to every Apache thread. So
the Perl modules itself need not to be thread safe. Perl 5.6 has some nice
features to clone a Perl interpreter in a efficent way (syntax tree of
modules (loaded before clone) is used by all cloned Perl interpreters, while
the data is separate for all cloned Perl interpreters). mod_perl 2.0 get
manages a pool of cloned Perl interpreters which is assigns as neccessary to
the Apache threads.

Gerald


-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:   Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151
WWW:http://www.ecos.de  Fax:  +49 6133 925152
-




Re: Installing mod_perl when other things are required, too.

2000-04-23 Thread JoshNarins

If you get the CVS version of mod_perl it has a 
INSTALL.simple.ssl file. If you pick up mod_ssl from
Engelschall's site it comes with the same INSTALL.ssl
file. Both files (which are identical) have build 
instructions for what you need near the bottom.

However, just as a note, they aren't as clear if you
want to do it DSO. It seems though, that all one need
do is add USE_DSO=1 to the mod_perl stage and drop the
APACI and APXS references. Then, when you get to making
Apache, in addition to defining SSL_BASE and the vars
for EAPI_MM and RSA_BASE, add the configure option for
--enable-shared=all.





Re: Installing mod_perl when other things are required, too.

2000-04-23 Thread shane

On Sun, Apr 23, 2000 at 11:03:01AM +0100, Matt Sergeant wrote:
 On Sat, 22 Apr 2000, Forrest Aldrich wrote:
 
  I couldn't find a faq on this one.
  
  I need to also install apache with php and mod_ssl.   Those two require a 
  simple ./configure --switch to enable them.   I didn't see anything for 
  mod_perl in the INSTALL, and it seemed there were a lot of manual things to 
  be done, which made me think I wasn't reading it correctly.
  
  What's the magic incantation?
 
 Install mod_perl first, making sure you enable mod_so.
 Then php should just install fine as a dso. I'm not sure about mod_ssl
 though - I think it has to patch the Apache source. I'm almost certain
 this is covered in one of the INSTALL.foo documents.

Just install the SSL patch first, and then do what Matt said and
everything should work fine.  I have a similar config over here.

Thanks,
Shane.



RE: mod_perl 2.x/perl 5.6.x ?

2000-04-23 Thread Gunther Birznieks

At 02:51 PM 4/23/00 +0200, Gerald Richter wrote:
 
  So, does that still leave mod_perl serializing access until
  everything is rewritten to be thread-safe?
 

No, mod_perl 2.0 assign a "full" Perl interpreter to every Apache thread. So
the Perl modules itself need not to be thread safe. Perl 5.6 has some nice
features to clone a Perl interpreter in a efficent way (syntax tree of
modules (loaded before clone) is used by all cloned Perl interpreters, while
the data is separate for all cloned Perl interpreters). mod_perl 2.0 get
manages a pool of cloned Perl interpreters which is assigns as neccessary to
the Apache threads.

In the end, there may still be some threading issues that should be watched 
out for I suspect. If mod_perl 2.0 follows a similar design to 
ActiveState's PerlEx, PerlEx also has some problems when the Perl modules 
themselves link to stuff that is not threadsafe as a shared library.

eg, every 2 weeks or so, the PerlEx mailing list has someone post "I get 
mysterious crashes with Win32::ODBC"... and the perennial  reply of "Don't 
use that module with PerlEx as it's not threadsafe"...

I don't know if there is anything else that might cause a similar problem.

Later,
Gunther





Re: mod_perl-1.99_01-dev [ - possibly OT ]

2000-04-23 Thread Greg Cope


- Original Message -
From: "Gerald Richter" [EMAIL PROTECTED]
To: "Greg Cope" [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: 23 April 2000 13:46
Subject: RE: mod_perl-1.99_01-dev [ - possibly OT ]


 
  I though the new apache model was a hybrid were there were preforked
  children that then used threads - have I missed the plot here ?
 

 Yes, you can configure any combination. See Erics mails on the "RE:
mod_perl
 2.x/perl 5.6.x ?" for a list of possible combinations.

Thanks

Greg


 Gerald







RE: mod_perl 2.x/perl 5.6.x ?

2000-04-23 Thread Jeffrey W. Baker

On Sun, 23 Apr 2000, Gerald Richter wrote:

 
  So, does that still leave mod_perl serializing access until
  everything is rewritten to be thread-safe?
 
 
 No, mod_perl 2.0 assign a "full" Perl interpreter to every Apache thread. So
 the Perl modules itself need not to be thread safe. Perl 5.6 has some nice
 features to clone a Perl interpreter in a efficent way (syntax tree of
 modules (loaded before clone) is used by all cloned Perl interpreters, while
 the data is separate for all cloned Perl interpreters). mod_perl 2.0 get
 manages a pool of cloned Perl interpreters which is assigns as neccessary to
 the Apache threads.

I suspect that two things are going to happen here.  The CPAN community is
going to have to turn the crank one more time to update popular modules to
work under this environment.  DBI and its drivers are going to be
particularly important.  Secondly, this Perl environment is going to
reveal things that people never considered doing before, and some new and
useful modules will be added to our arsenal.

But first, Apache 2.0 will need to get out the door.

-jwb




[OT] Lotus Domino as Web server ?

2000-04-23 Thread Jean-Denis Girard

Hi dear modperlers,

We have a client here willing to use Domino to serve
his Web site.

The site should not be very busy (we expect about 15000
hits per day), but is relatively complex, with database
integration, visitors tracking, customers logins, SSL...

As anyone on the list already used this strange beast ?

What could I say to this client to make him change his
mind, apart from obvious reasons (price, closed and
proprietary solution, nobody uses it, less than 1% on
the Internet).

Thanks for any response.

Jean-Denis Girard
Essential Software




Re: [OT] Lotus Domino as Web server ?

2000-04-23 Thread gnielson

I am just curious why they are fixated on Domino to start with?
What are their concerns?

On Sun, 23 Apr 2000, Jean-Denis Girard wrote:

 Date: Sun, 23 Apr 2000 08:36:45 -1000
 From: Jean-Denis Girard [EMAIL PROTECTED]
 To: mod-perl Mailing List [EMAIL PROTECTED]
 Subject: [OT] Lotus Domino as Web server ?
 
 Hi dear modperlers,
 
 We have a client here willing to use Domino to serve
 his Web site.
 
 The site should not be very busy (we expect about 15000
 hits per day), but is relatively complex, with database
 integration, visitors tracking, customers logins, SSL...
 
 As anyone on the list already used this strange beast ?
 
 What could I say to this client to make him change his
 mind, apart from obvious reasons (price, closed and
 proprietary solution, nobody uses it, less than 1% on
 the Internet).
 
 Thanks for any response.
 
 Jean-Denis Girard
 Essential Software
 




Re: [OT] Lotus Domino as Web server ?

2000-04-23 Thread jb

The usual reasons: I bet they use lotus notes internally for
everything, and domino is the only choice for those
companies that have chained themselves^h^h^h^h made a strategic
decision to go notes.
-Justin

On Sun, Apr 23, 2000 at 02:24:20PM -0400, gnielson wrote:
 I am just curious why they are fixated on Domino to start with?
 What are their concerns?
 
 On Sun, 23 Apr 2000, Jean-Denis Girard wrote:
 
  Date: Sun, 23 Apr 2000 08:36:45 -1000
  From: Jean-Denis Girard [EMAIL PROTECTED]
  To: mod-perl Mailing List [EMAIL PROTECTED]
  Subject: [OT] Lotus Domino as Web server ?
  
  Hi dear modperlers,
  
  We have a client here willing to use Domino to serve
  his Web site.
  
  The site should not be very busy (we expect about 15000
  hits per day), but is relatively complex, with database
  integration, visitors tracking, customers logins, SSL...
  
  As anyone on the list already used this strange beast ?
  
  What could I say to this client to make him change his
  mind, apart from obvious reasons (price, closed and
  proprietary solution, nobody uses it, less than 1% on
  the Internet).
  
  Thanks for any response.
  
  Jean-Denis Girard
  Essential Software
  

-- 
Justin Beech --- http://www.dslreports.com
Phone:212 269 7052 x252 : 212 706 9129 (home)
mailto:[EMAIL PROTECTED] --- http://dslreports.com/contacts



Re: [OT] Lotus Domino as Web server ?

2000-04-23 Thread Gunther Birznieks

Why do you need to settle on one or the other?

Anyway, the only reason you need Domino IMHO is because you have linked in 
with other Lotus notes applications. However, if this is a public site not 
an intranet, I would strongly urge them not to use this short cut for 
putting apps out there. Lotus Notes apps are badly slapped together front 
ends on top of apps written on another computing paradigm (client 
server)... which don't mix well.

However, if that argument is not being listened to, you can use the 
engineering tact. Sneak apache in there with mod_proxy and mod_rewrite and 
follow Stas' guide on having backend versus front end servers.

Use apache on the front end (and an optional backend for mod_perl) and 
Lotus notes as a backend server. This has the advantage of allowing the 
domino server to scale better since it will only be hit for domino app-like 
things rather than images which can be cached by the front-end server. This 
includes security advantages in that Lotus Notes server, being so bloated 
with app code) is not something you might want directly exposed to the 
Internet.

Anyway, I've been at two largish organizations in the last 4 years that 
wanted to switch away from Notes to the Web.

One was early enough. The other was too late as their infrastructure was 
already dedicated to it and it was very hard to convert all the apps 
because the requirements that went into building the apps were organic and 
never written down-- so a web rewrite would have involved a lot of 
analysis. In the end, that company did switch off of Notes in a major way 
though but it was done in pockets and done very gradually over the course 
of a year -- and they still are not completely off of it.

If Notes is used in an Intranet, I see no reason to rewrite everything for 
the web from scratch with today's shortage of IT personnel. And it will 
give the Notes developers the capability to start learning how a web server 
works so that they can slowly train themselves up on other technologies...

One thing to understand, is a lot of the time notes admins are really 
secretaries, ex-mail administrators, etc... that also double as form 
builders and data entry clerks. So it isn't so easy or instant to convert 
these pseudo-IT people into web people with a point and click and 
installing an apache server.

You don't want to piss these people off either. They are [a] close to the 
data and [b] usually close to the business that creates the data (and a 
business person can usually override an IT person in any organization). A 
lot of training and hand holding is required to get buy-in from these 
pseudo-IT people -- on the surface they are not powerful, but they do form 
a strong current.

Later,
Gunther

At 08:36 AM 4/23/00 -1000, you wrote:
Hi dear modperlers,

We have a client here willing to use Domino to serve
his Web site.

The site should not be very busy (we expect about 15000
hits per day), but is relatively complex, with database
integration, visitors tracking, customers logins, SSL...

As anyone on the list already used this strange beast ?

What could I say to this client to make him change his
mind, apart from obvious reasons (price, closed and
proprietary solution, nobody uses it, less than 1% on
the Internet).

Thanks for any response.

Jean-Denis Girard
Essential Software




RE: mod_perl 2.x/perl 5.6.x ?

2000-04-23 Thread Gunther Birznieks

At 09:59 AM 4/23/00 -0700, Jeffrey W. Baker wrote:
On Sun, 23 Apr 2000, Gerald Richter wrote:

  
   So, does that still leave mod_perl serializing access until
   everything is rewritten to be thread-safe?
  
 
  No, mod_perl 2.0 assign a "full" Perl interpreter to every Apache 
 thread. So
  the Perl modules itself need not to be thread safe. Perl 5.6 has some nice
  features to clone a Perl interpreter in a efficent way (syntax tree of
  modules (loaded before clone) is used by all cloned Perl interpreters, 
 while
  the data is separate for all cloned Perl interpreters). mod_perl 2.0 get
  manages a pool of cloned Perl interpreters which is assigns as 
 neccessary to
  the Apache threads.

I suspect that two things are going to happen here.  The CPAN community is
going to have to turn the crank one more time to update popular modules to
work under this environment.  DBI and its drivers are going to be
particularly important.  Secondly, this Perl environment is going to
reveal things that people never considered doing before, and some new and
useful modules will be added to our arsenal.

I agree... but to some degree I hope this has been done for many of the 
major modules and the major DBI modules (eg DBD sybase)... as they ended up 
having to work on ActiveState's PerlEx which uses a similar model. In a 
way, PerlEx's model has been a test for mod_perl 2.0.

Caveat to my statement: I am not a Perl internals guru. So what I say is 
conjecture and hope rather than what will definately happen when mod_perl 
2.0 comes out.

Later,
Gunther




Re: vanilla install failure 1.3.12/1.22/5.6.0

2000-04-23 Thread jb

Hope this helps...

GNU gdb 19991004
(gdb) httpd

Program received signal SIGSEGV, Segmentation fault.
0x806412e in perl_handler (r=0x8727d9c) at mod_perl.c:844
844 dPPREQ;

(gdb) bt

#0  0x806412e in perl_handler (r=0x8727d9c) at mod_perl.c:844
#1  0x8097e23 in ap_invoke_handler (r=0x8727d9c) at http_config.c:508
#2  0x80ab309 in process_request_internal (r=0x8727d9c) at http_request.c:1215
#3  0x80ab772 in ap_internal_redirect_handler (
new_uri=0x8727d7c "/perl/action.pl/LoadClass.pm", r=0x872704c)
at http_request.c:1351
#4  0x80909b1 in action_handler (r=0x872704c) at mod_actions.c:255
#5  0x8097e96 in ap_invoke_handler (r=0x872704c) at http_config.c:520
#6  0x80ab309 in process_request_internal (r=0x872704c) at http_request.c:1215
#7  0x80ab36c in ap_process_request (r=0x872704c) at http_request.c:1231
#8  0x80a2c4e in child_main (child_num_arg=0) at http_main.c:4177
#9  0x80a2ddc in make_child (s=0x818b404, slot=0, now=956521954)
at http_main.c:4281
#10 0x80a2f39 in startup_children (number_to_start=5) at http_main.c:4363
#11 0x80a3566 in standalone_main (argc=4, argv=0xbb94) at http_main.c:4651
#12 0x80a3cf3 in main (argc=4, argv=0xbb94) at http_main.c:4978

(gdb) print *r

$1 = {pool = 0x8727024, connection = 0x8726014, server = 0x818b404, 
  next = 0x0, prev = 0x872704c, main = 0x0, 
  the_request = 0x872773c "GET /LoadClass.pm HTTP/1.0", assbackwards = 0, 
  proxyreq = NOT_PROXY, header_only = 0, protocol = 0x8727794 "HTTP/1.0", 
  proto_num = 1000, hostname = 0x8727984 "localhost", 
  request_time = 956521956, status_line = 0x0, status = 200, 
  method = 0x872775c "GET", method_number = 0, allowed = 0, sent_bodyct = 0, 
  bytes_sent = 0, mtime = 0, chunked = 0, byterange = 0, boundary = 0x0, 
  range = 0x0, clength = 0, remaining = 0, read_length = 0, read_body = 0, 
  read_chunked = 0, expecting_100 = 0, headers_in = 0x87271a4, 
  headers_out = 0x8728084, err_headers_out = 0x872756c, 
  subprocess_env = 0x87280fc, notes = 0x87282a4, content_type = 0x0, 
  handler = 0x8508644 "perl-script", content_encoding = 0x0, 
  content_language = 0x0, content_languages = 0x0, vlist_validator = 0x0, 
  no_cache = 0, no_local_copy = 0, 
  unparsed_uri = 0x8727ef4 "/perl/action.pl/LoadClass.pm", 
  uri = 0x8727f14 "/perl/action.pl/LoadClass.pm", 
  filename = 0x87285e4 "/work/mod_perl-1.22/t/net/perl/action.pl", 
  path_info = 0x872861c "/LoadClass.pm", args = 0x0, finfo = {st_dev = 2053, 
__pad1 = 0, st_ino = 3957, st_mode = 33261, st_nlink = 1, st_uid = 1000, 
st_gid = 100, st_rdev = 0, __pad2 = 0, st_size = 17592186044530, 
st_blksize = 8, st_blocks = 956521953, st_atime = 946518392, 
__unused1 = 0, st_mtime = 956245011, __unused2 = 0, st_ctime = 0, 
__unused3 = 0, __unused4 = 0, __unused5 = 0}, parsed_uri = {scheme = 0x0, 
hostinfo = 0x0, user = 0x0, password = 0x0, 
hostname = 0x8727f14 "/perl/action.pl/LoadClass.pm", port_str = 0x0, 
path = 0x0, query = 0x0, 
fragment = 0x1 Address 0x1 out of bounds, hostent = 0x8728a84, 
port = 32564, is_initialized = 0, dns_looked_up = 1, dns_resolved = 0}, 
  per_dir_config = 0x872891c, request_config = 0x7265702f, 
  htaccess = 0x63612f6c}

(gdb) print perl_module

$2 = {version = 19990320, minor_version = 7, module_index = 18, 
  name = 0x814fccf "mod_perl.c", dynamic_load_handle = 0x0, next = 0x8179960, 
  magic = 1095774515, init = 0x80632e4 perl_module_init, 
  create_dir_config = 0x8065da8 perl_create_dir_config, 
  merge_dir_config = 0x8065b8c perl_merge_dir_config, 
  create_server_config = 0x8065f44 perl_create_server_config, 
  merge_server_config = 0x8065e34 perl_merge_server_config, 
  cmds = 0x8178d64, handlers = 0x8178f2c, translate_handler = 0, 
  ap_check_user_id = 0, auth_checker = 0, access_checker = 0, 
  type_checker = 0, fixer_upper = 0, logger = 0, header_parser = 0, 
  child_init = 0x806441c perl_child_init, child_exit = 0, 
  post_read_request = 0}
(gdb) quit
The program is running.  Exit anyway? (y or n) 

On Thu, Apr 20, 2000 at 10:58:56PM -0700, Doug MacEachern wrote:
 On Thu, 20 Apr 2000 [EMAIL PROTECTED] wrote:
 
  Hi, After much fast progress buiding a new machine, I'm stuck.
  This is a vanilla RH6.2 box with almost nothing on it.. no
  residue from RPM perl or httpd (deselected at machine blast time).
  
  I've built perl 5.6.0 (all tested out ok), also built apache 1.3.12
  both with and without Ben-SSL (all tested out ok).
  
  The most basic Modperl 1.22 install attempt fails though: just with
  a simple perl Makefile.PL and let it build vanilla httpd next door.
  
  It builds a binary, and make test starts it, chucks a few requests
  and it core dumps. The trace is below, followed at the end by
  the perl -V output.
  
  The segfault comes in the third test .. "GET LoadClass.pm", just
  after it looks around for some .htaccess files
 
 if you could build mod_perl with PERL_DEBUG=1, then in mod_perl-1.22 run:
 
 % gdb ../apache-x.x.x/src/httpd
 (gdb) httpd