[gentoo-dev] apache eclass

[gentoo-dev] apache eclass

[Tom Payne]

[Apologies for breaking the thread]

Solar,

Have a look at http://bugs.gentoo.org/show_bug.cgi?id=20642 with regards to
automatically determining DocumentRoot.

Synopsis is that a simple grep breaks configurations that use virtual hosts.

Also consider what happens if a user uses a webserver other than apache
(there's rarely anything about a bunch of HTML, PHP, and CGI scripts that's
apache-specific). There really should be a virtual/httpd to cover this.

Reliably detecting the doc root on all possible installations is very hard
indeed.

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.

Regards,

Tom

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] apache eclass

[Robin H.Johnson]

[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]

On Thu, Jun 12, 2003 at 10:20:03AM +0100, Tom Payne wrote:
> Also consider what happens if a user uses a webserver other than apache
> (there's rarely anything about a bunch of HTML, PHP, and CGI scripts that's
> apache-specific). There really should be a virtual/httpd to cover this.
I did previously mention that this was needed in the last thread.

> Have a look at http://bugs.gentoo.org/show_bug.cgi?id=20642 with regards to
> automatically determining DocumentRoot.
> Synopsis is that a simple grep breaks configurations that use virtual hosts.
> Reliably detecting the doc root on all possible installations is very hard
> indeed.
> 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.
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.

Because of this DocumentRoot must be totally static.
If we ever want DocumentRoot to be variable, somebody has a LOT of work
to do with apache config parsing.

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.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] apache eclass

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 835 bytes --]

On Thursday 12 June 2003 11:37, Robin H.Johnson wrote:
> 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.

I agree with this solution. It also allows running different versions of web 
apps next to eachother. It also allows one to be able to put them in the tree 
where desired. Those locations should also include the package version.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.cs.kun.nl/~pauldv

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] apache eclass

[Robin H.Johnson]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

On Thu, Jun 12, 2003 at 11:53:46AM +0200, Paul de Vrieze wrote:
Content-Description: signed data
> On Thursday 12 June 2003 11:37, Robin H.Johnson wrote:
> > 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.
> I agree with this solution. It also allows running different versions of web 
> apps next to eachother. It also allows one to be able to put them in the tree 
> where desired. Those locations should also include the package version.
Good idea. I didn't think of that.

I've often modified web-application in-place for various reasons, so
that would work well. So install them, with SLOT="${PV}-${PR}" (I don't
know if there is a shortcut for that).

Any suggestions on where the location should be?
/usr/share/www/* is my suggestion.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] apache eclass

[Donny Davies]

>> I agree with this solution. It also allows running different versions of web 
>> apps next to eachother. It also allows one to be able to put them in the tree 
>> where desired. Those locations should also include the package version.
>
>Good idea. I didn't think of that.
>
>I've often modified web-application in-place for various reasons, so
>that would work well. So install them, with SLOT="${PV}-${PR}" (I don't
>know if there is a shortcut for that).

  $PVR will give you that.

>Any suggestions on where the location should be?
>/usr/share/www/* is my suggestion.

  I'm not aware of anything that conflicts with that.

                Donny.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] apache eclass

[Patrick Kursawe]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

On Thu, Jun 12, 2003 at 12:55:56PM -0400, Donny Davies wrote:
> >>I agree with this solution. It also allows running different versions of 
> >>web apps next to eachother. It also allows one to be able to put them in 
> >>the tree where desired. Those locations should also include the package 
> >>version.

> >Any suggestions on where the location should be?
> >/usr/share/www/* is my suggestion.
> 
>  I'm not aware of anything that conflicts with that.

Only if the "web application" is architecture independent and read only. 
See FHS part 4.11.

Bye, Patrick

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] apache eclass

[Ned Ludd]

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.

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

> > Have a look at http://bugs.gentoo.org/show_bug.cgi?id=20642 with regards to
> > automatically determining DocumentRoot.
> > Synopsis is that a simple grep breaks configurations that use virtual hosts.
> > Reliably detecting the doc root on all possible installations is very hard
> > indeed.

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

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

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

> 
> Because of this DocumentRoot must be totally static.
> If we ever want DocumentRoot to be variable, somebody has a LOT of work
> to do with apache config parsing.
> 
> 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.


Another thing which was not addressed by the example eclass is what
permissions should webapps install as. I notice a few ebuilds are making
everything owned by apache.apache and are world readable. I like would
suggest that when you (any dev) dont know what permissions to use try
and make the files root owned apache readable and other non -rwx
readable,executable,writeable
(-rw-r----/0640) root.apache This would keep all users expect the apache
user itself from reading misc the misc php,perl scripts which sometimes
contain things like mysql passwords. Granted crafty local users could
get around those permissions pretty easy to extract passwords but it
would improve the overall security of installed files. 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)

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux (Hardened)


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] apache eclass

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

On 12 Jun 2003 13:25:23 -0400
Ned Ludd <solar@gentoo.org> wrote:


> 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


Just for the record,  Donny Davies (woodchip) has been the apache maintainer for Gentoo for years, so I should think that the final decision will weigh heavily on his input into the matter.
-- 
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux					http://www.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] apache eclass

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]


> Just for the record,  Donny Davies (woodchip) has been the apache maintainer for Gentoo for years, so I should think that the final decision will weigh heavily on his input into the matter.

blah @ my grammar: his input will heavily weigh the final decision.
-- 
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux					http://www.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] apache eclass

[Robin H.Johnson]

[-- Attachment #1: Type: text/plain, Size: 6287 bytes --]

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@orbis-terrarum.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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] apache eclass

[Ned Ludd]

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

Robin thats excellent hopefully we look forward to having one in portage
sometime in the near future.

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux (Hardened)


--
gentoo-dev@gentoo.org mailing list