install solution for new mod_perl based application needed

["Thomas K. Burkholder" <bu...@dogrobber.com>]

Hi,

I've just spent about 2 months and 5000 lines of code writing a great
little mysql/mod_perl/ImageMagick based web application for managing and
tweaking digital photographs.  It's really been a whole lot of fun.

There are three kinds of code involved - .pm modules that are strictly
handlers for apache requests, scripts intended to be run by the user
administering the site, and .pm modules that are generally used by both
the handler modules and the scripts.

Now I want to package it in such a way that it'll be easy for folks to
use if they want it.  My first attempt was to use MakeMaker the way it
seems to be intended in all the CPAN modules.  That works fine if the
installer is root... but it winds up making all the installed perl code
root-owned and it seems like the wrong thing in that all sorts of perl
modules that I've written just to provide handlers wind up in the
general @INC path, and there doesn't seem to be any obvious way to make
it possible for both scripts and mod_perl modules to be able to access
the reuseable modules if I tell MakeMaker to install the modules
elsewhere.  Plus, MakeMaker apparently doesn't provide a hook for a
script (in this case, a database-configuration script) to be run after
the 'make install' is done.

So, I'm figuring this must have been encountered before - does anyone on
this list know of a good example of an install mechanism for a
mod_perl-based web application?  Ideally something that doesn't require
that the user be root except maybe to modify their httpd.conf.

Thanks in advance-

//Thomas
Thomas K. Burkholder
burkhold@dogrobber.com

Re: install solution for new mod_perl based application needed

["Thomas K. Burkholder" <bu...@dogrobber.com>]

Thanks for the info - I was able to get a lot further with it, rootless
install now works, sorta.  I had the following comments/questions.  I'm
afraid only one of them is directly related to mod_perl, but I imagine the
topic should still be of interest to anyone like me trying to write a
simply-installable product with mod_perl:

1.  doing a perl Makefile.PL PREFIX=~/perl did much of what I needed - made
it possible to do a make install without being root.  I had to put
~/perl/local/share/perl/5.6.0 on PERLLIB in order to make the scripts access
the libraries.

2.  (Somewhat unrelated) PERM_RW and PERM_RWX don't seem to be preserved
after things are copied to the INSTALL location.  This results for me in a
security hole (folks being able to read perl code they shouldn't, and folks
being able to execute perl executables they shouldn't).  The permissions seem
to take effect in blib/script and blib/lib, but wind up being 444 and 555
respectively, regardless of the value of PERM_RW.  I'm working around this by
having my post-install script chmod them properly, but if anyone knows how to
do this from Makefile.PL as seems more natural, please let me know.  I
actually doubt there's a way since the generated Makefile seems to
arbitrarily set the umask before copying the files without even using a
defined make symbol (it just does @umask 022) - leading me to believe that
without some kind of tricky tweaking to MM_Unix, there's no way to make this
happen.

3.  Because the source is (deliberately, it contains a randomly-generated
database password) read-only, owner-only, to the installing owner, I had to
use "User burkhold" and "Group burkhold" in httpd.conf.  This won't work for
vending the pages of other users of course - can this be done within the
Location directive?  Hmmm... empirically, no.  Does anyone know how to do
this such that it's scalable to more than one user with Apache?

4.  The ability to override MakeMaker methods as reccomended in the perldoc
page only allows you to override or add to whole sections of the Makefile.
Short of parsing the superclass output, there doesn't seem to be any way to
modify an existing target, which is what's necessary in order to have
configuration behaviour occur after a make install (for instance).  Having
this ability would of course make non-interactive installs like that provided
by the CPAN module either not possible or necessitate operational changes to
those tools.  There might be a way to do this, but if it's there it's very
non-obvious.  I'm going to stick to a manually-initiated interactive install
script after the make install, life's too short.

Thanks again,

//Thomas

Randy Kobes wrote:

> On Wed, 11 Apr 2001, Thomas K. Burkholder wrote:
>
> > Hi,
> >
> > I've just spent about 2 months and 5000 lines of code writing a great
> > little mysql/mod_perl/ImageMagick based web application for managing and
> > tweaking digital photographs.  It's really been a whole lot of fun.
> >
> > There are three kinds of code involved - .pm modules that are strictly
> > handlers for apache requests, scripts intended to be run by the user
> > administering the site, and .pm modules that are generally used by both
> > the handler modules and the scripts.
> >
> > Now I want to package it in such a way that it'll be easy for folks to
> > use if they want it.  My first attempt was to use MakeMaker the way it
> > seems to be intended in all the CPAN modules.  That works fine if the
> > installer is root... but it winds up making all the installed perl code
> > root-owned and it seems like the wrong thing in that all sorts of perl
> > modules that I've written just to provide handlers wind up in the
> > general @INC path, and there doesn't seem to be any obvious way to make
> > it possible for both scripts and mod_perl modules to be able to access
> > the reuseable modules if I tell MakeMaker to install the modules
> > elsewhere.
>
> Why not let the user decide where to install things? She/he then
> has the control and presumably knows how to deal with it. The FAQ
> entries in perlfaq8 on keeping one's own module directory, and
> subsequently how to use it, explains how to do this.
>
> >            Plus, MakeMaker apparently doesn't provide a hook for a
> > script (in this case, a database-configuration script) to be run after
> > the 'make install' is done.
>
> See the mod_perl Makefile.PL, for example, for an illustration on how
> to modify Makefile targets - it basically involves overriding a
> Makefile section by defining, in Makefile.PL, a sub like MY::top_targets
> or MY::install. See 'perldoc ExtUtils::MakeMaker', near the end,
> for details.
>
> best regards,
> randy kobes

Re: install solution for new mod_perl based application needed

[Randy Kobes <ra...@theoryx5.uwinnipeg.ca>]

On Wed, 11 Apr 2001, Thomas K. Burkholder wrote:

> Hi,
> 
> I've just spent about 2 months and 5000 lines of code writing a great
> little mysql/mod_perl/ImageMagick based web application for managing and
> tweaking digital photographs.  It's really been a whole lot of fun.
> 
> There are three kinds of code involved - .pm modules that are strictly
> handlers for apache requests, scripts intended to be run by the user
> administering the site, and .pm modules that are generally used by both
> the handler modules and the scripts.
> 
> Now I want to package it in such a way that it'll be easy for folks to
> use if they want it.  My first attempt was to use MakeMaker the way it
> seems to be intended in all the CPAN modules.  That works fine if the
> installer is root... but it winds up making all the installed perl code
> root-owned and it seems like the wrong thing in that all sorts of perl
> modules that I've written just to provide handlers wind up in the
> general @INC path, and there doesn't seem to be any obvious way to make
> it possible for both scripts and mod_perl modules to be able to access
> the reuseable modules if I tell MakeMaker to install the modules
> elsewhere.  

Why not let the user decide where to install things? She/he then
has the control and presumably knows how to deal with it. The FAQ
entries in perlfaq8 on keeping one's own module directory, and
subsequently how to use it, explains how to do this.

>            Plus, MakeMaker apparently doesn't provide a hook for a
> script (in this case, a database-configuration script) to be run after
> the 'make install' is done.

See the mod_perl Makefile.PL, for example, for an illustration on how 
to modify Makefile targets - it basically involves overriding a 
Makefile section by defining, in Makefile.PL, a sub like MY::top_targets
or MY::install. See 'perldoc ExtUtils::MakeMaker', near the end,
for details.

best regards,
randy kobes