[gobolinux-users] Placement of httpd modules

Jonas Karlsson jonka750 at student.liu.se
Tue Sep 12 20:54:00 UTC 2006


2006/9/12, Hisham Muhammad <hisham.hm at gmail.com>:
> On 9/12/06, Jonas Karlsson <jonka750 at student.liu.se> wrote:
> > On Tue, 12 Sep 2006 16:11:43 +0200, MJ Ray <mjr at phonecoop.coop> wrote:
> >
> > > "Jonas Karlsson" <jonka750 at student.liu.se> wrote: [...]
> > >> One of the former solutions, either one, is better, but which one
> > >> should be used?
> > >
> > > I'd prefer putting them under /System/Links/Libraries (share seems
> > > wrong, as they are binaries) and the default apache being configured to
> > > look there in its modules path.
> >
> > Yes, I'd prefer that as well, when I think about it. I didn't like the
> > share solution, but that was the only way I could think of for the modules
> > to be reachable for httpd, without too long pathname (as
> > /Programs/Foo/X.Y/share is a symlink to /System/Links/Shared).
> >
> > Unfortunately I can't find a way to relocate where httpd looks for
> > loadable modules. So I guess there has to be a long path in httpd.conf
> > instead (anyone knows if one could use variables instead in httpd.conf?).
>
> Is it very problematic to use the full pathname in httpd.conf? (I
> figure the Current symlink would alleviate the upgrade scenario). I
> never set up an Apache server, so I know zero about its configuration.
>
It's not that it's very problemmatic, just that it has to be decided
what to do. And that all documentation on the net has modules/foo.so
as path, which makes our approach hard to understand for newcomers.
Besides, all apps that interact with httpd through modules somehow
expect that the modules should be in the 'modules' directory in the
httpd path.

Compare 'LoadModule mod_php5 modules/libphp5.so'
with 'LoadModule mod_php5 /System/Links/Libaries/httpd/modules/libphp5.sp'

> > > Alternatively, debian systems has a program called something like
> > > a2enmod to symlink an apache module into the correct folder and all
> > > modules from that folder are loaded.  There's a similar program and
> > > folder for config sections.
> > >
> > The modules are always to be placed in /Programs/HTTPD/Current/odules, by
> > default, and one could use unmanaged to symlink/copy the module there,
> > even though unmanaged shouldn't be used to place files inside the
> > /Programs structure (why?).
>
> To keep valid the invariant that every /Programs entry contains files
> only from a single program. Spreading files from different apps around
> the /Programs tree would be the beginning of the Unix mess again
> (symlinks diminish the problem, of course), but most importantly would
> make stuff like CreatePackage less clean. So, essentially, I think it
> goes against the overall design of the tree.
>
Yes, but here's where our views part. I can't see anyone make a
package from a app when he/she has had it running for a while. I
always make my packages directly after having had them compiled and
make them public a few days later, only if nothing has been broken by
then. I don't think a running apps should be packed, because one never
know what might have tainted it, no matter how try you've tried not
to. And if one does, a failed file sig check should raise enough
alarms for anyone to try anyway.

> > The problem is that, with that approach, one
> > has to symlink mod_php and similar everytime one recompiles httpd.
>
> True. Spreading inter-programs links around /Programs makes management
> more complicated. We used to do it very early on, with the "mirror"
> (later called MirrorTree script).
>
Yes, I agree that it's ugly.

Just as I typed that sentence above I think I cracked the problem. Why
don't we make /Programs/HTTPD/Current/modules to be a symlink,
pointing at /System/Links/Libraries/httpd/modules and have all mod_foo
to install to /Programs/Foo/X.Y/lib/httpd/modules? That way everyone
will be happy!
We can have everything contained in their own application directories,
but still have the "normal" modules/mod_foo path in httpd.conf.
PRoblem solved

-- 
/Jonas


More information about the gobolinux-users mailing list