Re: [gentoo-dev] apache eclass

[Robin H.Johnson]

On Thu, Jun 12, 2003 at 01:25:23PM -0400, Ned Ludd wrote:
> Aside from all DocumentRoot stuff I feel that one of the most important
> things that needs to be addressed by any apache.eclass is what version
> of apache are we using 1,2 when ~arch flags are set. I was reently very
> unhappy to find out that apache2 got installed on one of my production
> servers after doing an upgrade world when -apache2 was explicitly set
> and the box previously had apache1 installed.
>
> A FORCE_APACHE=1|2 option was mentioned the other day here on the ml, I
> support that idea fully.
Apache IS slotted. The ONLY data that is overwritten between the two
installs is the default pages in /home/httpd/htdocs.
As such, you can have both installed quite easily. While this does add
some undesirable overhead, it is not an impediment to using Apache1.

> What I would like/hope to see is for carpaski to make the final decision
> if any sort of dynamic method should be used to gain the apache
> docroot,user,group, and other runtime settings. Then hopefully one of
> you (Brad Laue comes to mind as it looks like he was willing to step up
> to the plate) will parent the needed {apache,http}.eclass
I had already suggested and offered it write it, long before any of the
current work was done.

> Thus why the example code only extracted the very first case of
> DocumentRoot out of the conf and ensured there would be no extra
> whitespace/tabs something that a simple "grep | cut " can not address
> correctly. I also feel the logic I used is for the example code to get
> the docroot is sane (other than UPPER vs lower case, but that could be
> addressed by using grep -i). I suppose one could do more and add the
> extra step to ensure that the document root really does exists.
> [ ! -d "${DOCUMENT_ROOT}" ] && die "some clever error msg here"



> Note: I'm not 100% sure that we can die correctly from within an eclass
We can actually. I use it in the php.eclass with the /usr/bin/sendmail check.

> > > After discussion with others, my recommendation is that the document root
> > > should always be /home/httpd/htdocs. You could allow this to be overridden
> > > with DOCUMENT_ROOT= in /etc/make.conf if you're feeling generous.
> This is what I would really like to see in the end result.
This is easily done with the installing the web packages in a common
directory and building symlinks.
Possibly we need a framework/installer config system for the web
applications to abstract all of the common database setup and symlink
creation stuff after detecting the correct documentroot setting.

> > Actually, in a further discussion today in #gentoo-dev, we noted that
> > detected the DocumentRoot or allowing to be variable in any fashion
> > causes more serious problems with tbz2 binary tarballs.
> > For example:
> > DocumentRoot is /var/www
> > User builds a web application, which installs to /var/www. The tbz2
> > contains files with that pathname component in them.
> > Now DocumentRoot gets change to /home/httpd/htdocs (any number of ways,
> > including emerging the binary package on a different system).
> > User tries to install the package, telling emerge to use the
> > pre-existing binary.
> > Package is extracted to /var/www, which is never looked at by the
> > webserver.
> I feel one of the really great things about gentoo is its flexiablity,
> users can build there systems exactly how they want when they want.
> Having such variables in an eclass that can be overridden by the enduser
> at compile time to me seems by far the best option for our users. I have
> faith that "most" of gentoo's users that would edit such an option would
> know what there doing in reguards to there own DocumentRoot.
This ignores the issue of the tarball problem. The best solution is to
move it away from compile time, to config/postinst instead.

> > In cases where users want a different DocumentRoot, I would suggest that
> > the packages are all installed in a fixed location (not nessicarily even
> > in the DocumentRoot directory), and then the user can symlink them into
> > their own DocumentRoot.
> > A possible solution:
> > All webapps install to something NOT inside DocumentRoot.
> > 'ebuild /usr/portage/.../foo.ebuild config' sets up the application
> > (needed in most cases already) AND puts in a symlink to the
> > DocumentRoot.
> > This also makes it easier to support virtualhost configurations that all
> > have access to a common tool, and makes temporarily disabling an
> > application for security reasons much easier to do.
> For security reasons I see that as having both pros and cons.
> You addressed the pros, I will address the only con I can think of off
> the top of my head. This type of setup would require that FollowSymLinks
> must always be set which could potentionaly introduce new security holes
> depending on the app thats being installed.
Symlinks to outside the DocumentRoot structure as should already be
taken care of due to the "<Directory />" settings which deny everybody.

To minimize any further impact however, is there any way we can set an
option and NOT have it inherit?  eg I want "Options +FollowSymlinks" in
/home/httpd/htdocs but not in any of it's subdirectories?

Failing that, we just need to take more care with symlinks. Not too
difficult based on the "<Directory />" settings.

> Another thing which was not addressed by the example eclass is what
> permissions should webapps install as. I notice a few ebuilds are making
[snip]
> would improve the overall security of installed files.
I'd agree that root.apache(u=rw,g=r) as the permissions would be a good
move for security, without adversely affecting things.

> And when a webapp says its needs to be mode 666 (laugh to yourself and
> try to make the file apache owned with 0600 or 0660)
I have seen a few that need this. Most notably the horde config system,
and anything that wants to write back to it's own config files.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@××××××××××××××.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85