Loading ...
Sorry, an error occurred while loading the content.

51623RE: Ensim

Expand Messages
  • Angie Ahl
    May 5, 2003
    • 0 Attachment
      > Angie,
      >
      > 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
      >

      this looks exactly the same as my server.

      <SNIP>

      > The same applies for
      > 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
      > </Directory>
      > SetEnv SITE_PERL /home/virtual/site7/fst/var/www/perl
      > </IfModule>
      >

      THat's what I've got, although just hacking away (gently) to get things working
      I changed mine to:

      file: /etc/httpd/conf/site8/cgi/mod_perl

      <IfModule mod_perl.c>
      PerlModule Apache::Registry
      PerlRequire /home/virtual/site8/fst/var/www/perl/Examples/WebClock.pm
      Alias /perl /home/virtual/site8/fst/var/www/perl
      <Directory /home/virtual/site8/fst/var/www/perl>
      SetHandler perl-script
      PerlHandler Apache::Registry
      Options ExecCGI
      </Directory>
      <Location /time>
      SetHandler perl-script
      PerlHandler Examples::WebClock
      </Location>
      SetEnv SITE_PERL /home/virtual/site8/fst/var/www/perl
      </IfModule>

      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 this
      > 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.
      >

      Yep. I took me a few days to realise that it was all set up for people porting
      cgi's rather than people wanting to use actual modules

      > In order to impact the other sites and the overall ENSIM configuration
      > 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
      > modifications.
      >

      That's quite a problem if you don't have root access I think (I do fortunately),
      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 a
      > startup.pl file that pre-compiles all of my important Perl modules and
      > specifies the Perl library that I am using (use lib
      > "/home/virtual/site7/fst/var/www/mod_perl";).

      could you give me an example of what you mean by precompile... do you mean call
      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 site
      > 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
      > modules.

      We could write a script that does it for them...

      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:
      >
      > 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.)

      I think I'll try the later. It helps with backups etc too.

      > 2.) Guides recommended: http://perl.apache.org/docs/1.0/guide/index.html
      > (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'll get that book.

      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

      >
      > 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.
      >

      I'll have agood read on that. Not sure how Ensim will react to a second Apache
      having the Vhosts for that site but will have a look anyway.

      > Sorry about being so verbose but explaining this to you helps me
      > understand where I am at if you know what I mean.
      >

      No. Thanks very much for being so verbose. This is the biggest hurdle for me.
      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.
    • Show all 30 messages in this topic