- May 5, 2003
> Angie,this looks exactly the same as my server.
> Here is how I have my mod_perl server working with ENSIM. Maybe this
> configuration will work for you it seems to be working out alright for
> me currently. If you are an ENSIM user on a sub account then ENSIM does
> only have the single mod_perl/Apache instance running on the box and the
> server configuration lays out as follows.
> Httpd.conf -> /etc/httpd/conf/httpd_app.conf (main configuration file
> which uses the Include directive to pull in the following files)
> /etc/appliance/apacheconf - Defines the default
> virtual host (Basically Rewrite rules for ENSIM)
> /etc/httpd/conf/jserv.conf - Included based on
> whether mod_jserv.c is linked in
> /etc/httpd/conf/roaming.conf - Included based on
> whether mod_roaming.c is linked in
> /etc/httpd/conf/asp.conf - Requires mod_perl as
> well as being uncommented by administrator
> /etc/httpd/conf/virtual - Directory that includes
> the virtual host configurations for all other domains/ips
> The same applies forTHat's what I've got, although just hacking away (gently) to get things working
> mod_perl, with the straightforward filename
> /etc/httpd/conf/site7/cgi/mod_perl which contains the following
> directives on my machine.
> <IfModule mod_perl.c>
> Alias /perl /home/virtual/site7/fst/var/www/perl
> <Directory /home/virtual/site7/fst/var/www/perl>
> Allow from All
> AllowOverride All
> Order allow,deny
> Options +ExecCGI
> SetEnv SITE_PERL /home/virtual/site7/fst/var/www/perl
I changed mine to:
Alias /perl /home/virtual/site8/fst/var/www/perl
SetEnv SITE_PERL /home/virtual/site8/fst/var/www/perl
Just to see if I could get a custom module operational. after making
webclock.pm executable it worked perfectly.... Yipee
> What is important to note here is that no handler is defined so thisYep. I took me a few days to realise that it was all set up for people porting
> will execute as cgi as there are no mod_perl handlers defined. I am not
> sure exactly why this is but you must configure some PerlHandler for
> this directory if you wish to run mod_perl. It would appear as though
> they are really aiming for the use of Apache::Registry but since my
> site(s) make copious use of regular handlers I have done the following.
cgi's rather than people wanting to use actual modules
> In order to impact the other sites and the overall ENSIM configurationThat's quite a problem if you don't have root access I think (I do fortunately),
> minimally I have placed a symbolic link from these original files/names
> to files in the directory of the user under which the mod_perl site
> runs. Something like /etc/httpd/conf/site7 ->
> /home/virtual/site7/fst/etc/httpd/conf/virtual/ssl-site.conf. I have
> also done the same for the files for SSI, mod_perl, cgi etc. This has
> the advantage of allowing you to log in as the sites user and make
> alterations to the configurations as needed. Since all of the users for
> the virtual hosts in this environment are chroot on login they could not
> see/access the configuration files themselves without these
I just wanted to try and get everything set up right in the first place. but I
do need to get on with trying perl as I learn that stuff so this could be a good
stop gap. I'm still finding my way around Linux a bit too.
> I then added some configuration changes to my mod_perl file including acould you give me an example of what you mean by precompile... do you mean call
> startup.pl file that pre-compiles all of my important Perl modules and
> specifies the Perl library that I am using (use lib
them via PerlRequire ro something?
I'm going to re read that startup stuff .I missed something while being buried
in books I'm sure.
> A.) The user for the mod_perl virtual host cannot reboot the siteWe could write a script that does it for them...
> themselves. This is a problem if you are running standard handlers as
> opposed to an Apache::Registry solution with Apache::RegistryLoader.
> This is due to the fact that any updates to code will require a restart
> to take effect which is a serious issue if the site is undergoing a lot
> of changes. You must log in as root in order to reboot the site.
> B.) Apache/mod_perl responds strangely to restarts in this environment.
> When I restart the server its memory footprint grows drastically on
> every restart. This is something I have not seen before and I would love
> to know why it is happening, but I have not had a chance to research it.
> This dictates full stop/start whenever changes are made to the Perl
A proper Stop/Start script.
and protect it with the same username/password set up in ensim for them
> As for some of your specific questions:I think I'll try the later. It helps with backups etc too.
> 1.) Apache::DBI needs to be downloaded and installed. Just install as
> root it should not impact any other sites. (If you are really concerned
> about putting it in the main Perl installation then install it to the
> directory included in the startup.pl file and it should work fine.)
> 2.) Guides recommended: http://perl.apache.org/docs/1.0/guide/index.htmlI'll get that book.
> (This is the one with the real details), mod_perl Developer's Cookbook
> by Geoffrey Young (good quick overview, but you will end up looking to
> the first for specifics), and CPAN documentation/man pages.
I've already got the "Web Development with Apache and Perl" book wich has been
quite a help. Also got "Perl Cookbook" and Programming Perl. Didn't realise
there was a Mod_perl cookbook
>I'll have agood read on that. Not sure how Ensim will react to a second Apache
> If I had more time to get my own server set-up I think that the optimal
> way to not impact the other sites and have your mod_perl Apache server
> running would be to install another instance of mod_perl in the file
> system of the site and proxy the requests from the main Apache server to
> the other instance for mod_perl requests. This would allow complete
> configuration of the new server with zero impact to the existing server
> and if you ever remove the site using ENSIM everything will be nice and
> clean. All that would be necessary is a few mod_proxy directives in the
> siteX.conf/ssl-siteX.conf files and everything else is easy. This
> certainly would be the ideal and would give you quite a few other
> benefits like proxy caching and memory conservation etc. This type of
> installation is described in detail in the mod_perl guide referred to in
> the url above.
having the Vhosts for that site but will have a look anyway.
> Sorry about being so verbose but explaining this to you helps meNo. Thanks very much for being so verbose. This is the biggest hurdle for me.
> understand where I am at if you know what I mean.
the language makes a lot of sense and does the structures of calling modules
etc. I was going mad trying to get other tools to behave this way... then I
realised I had the wrong tool.
- << Previous post in topic Next post in topic >>