Bugzilla Bug 66397

Hi!

It's very anoying that you cannot change some parameters apache is compiled with, e.g. --with-suexec-docroot=/var/www or --with-suexec-logfile.

Is it possible to read values like the prefered documentRoot from an environment variable (e.g. APACHE_DOCROOT defined in make.conf), and only if they are empty use the default path?

PS: Sorry if this isn't the right place for feature request, i did not found another good place to post this.

Reproducible: Always
Steps to Reproduce:
1. emerge apache
2.
3.

Actual Results:  
After an sync, changes in the apache ebuild are reset.

Expected Results:  
Read those values from a sync-safe place.

this is not *that* simple, unfortunately:

according to those configuration-ability to 
apache-{1,2} we already have an active discussion 
on this without a solution yet.

I personally noticed, too, that suexec root bound to
/var/www is really bad, especially since you also may
have doctoos in /home/$USER/www/htdocs as well.

However, a global configuration variable, like 
APACHE_DOCROOT_BASE="/srv/www"
in /etc/make.conf wouldn't be that good. Imagine whether 
*all* ebuilds would store global configs in there. If so,
the make.conf would blow up in instantly.

So, I'd be interested in a solution all apache devs 
would agree to.

Greetings,
Christian Parpart.

I'm not sure if this fits with with the portage philosophy but...

Would it be possible to have a the ebuild check a user
edited file in net-www/apache, named 'build.conf' or 
something that has the variables stored in it.
like
APACHE_DOC_ROOT=/var/www/htdocs
SUEXEC_DOCROOT=/home/
SUEXEC_USERDIR=public_html
SUEXEC_MINGID=1000
etc...

Optionally the ebuild could create the file with defaults
if it didn't exist.  This would allow the user to install
and update software with emerge maintaining previous 
custom configurations.

I think this would be a very nice idea. It could be extended with "per-ebuild
customized use-flags" (usefull for updates).

Sorry i just saw that the use-flag-feature is already implemented
(/etc/portage/packages.use). Forget the last posting :-)

Created an attachment (id=41403) [details]
allow conf parameters from file

The problem with USE flags is that it is a little difficult to set
suexec-userdir=www in a USE flag.  At least I have never seen this 
done.  If this is possible I will be happy to amend this attachment
to use USE flags.

The attached ebuild gets suexec config parameters from $FILESDIR/build.conf.  
If file does not exist then it is created with default parameters.  Then 
show the parameters to the installer and sleep for 5 seconds so they
can actually read them.

Again, I am not sure if this is the "portage way".  And I am not a an
exceptional bash programmer either.  Just trying to get this moving 
so that I don't have to manually tweak an ebuild every time apache 
is updated.

Unfortunetly, your changes are very hackish and won't work. Every time you
emerge sync all your changes to build.conf will be lost. And you can't really
put build.conf in other places because of sandbox issues.

That leaves us with 2 possible solutions (that I can think of, and I've been
brainstorming this for a while) other then managing your own overlay:

Custom environment variables (similiar to how ${USERDIR} works for setting the
--with-suexec-userdir option
Though these would have to be put on the command line for every merge, or added
into make.conf (?) or /etc/portage/bashrc for it to work with emerge -u world

Another solution I was thinking of is creating a suexec-config utility that
would recompile the suexec binary with new defines, so you could configure
suexec how you wanted for your system. I'm not even sure if this is doable, but
it may be - I'm experimenting now.

apache herd: anyone else have any ideas?

*** Bug 55603 has been marked as a duplicate of this bug. ***

@6: No i don't want to put those configuration in use-flags... this was just
another problem i had in the past (per-packages use-flags).

Portage uses rsync for synchronisation, right? Why not change portage to use
--exclude=build.conf* with rsync or something like this? Then other packages
can use this system, too.

hmm.  hackish?  probably.

I did realize that sync would remove files that aren't supposed to be part
of the tree.  That bothers me but there is probably nothing to do about
it now.

ENV variables solve the problem of manually editing files but they aren't
stored anywhere for updates. 

As an alternative to changing portage we could store the "build.conf" to
/etc/portage/builds/apache(2).conf or something like that.

@10: It would require changing portage to be able to read a file such as that.

I am working on a suexec-config script that would rebuild /usr/sbin/suexec(2) with the settings you want.

I will post here when I get it to a working point for everyone to test.

So you are planning on having to recompile suexec after every upgrade?  How
much
different is this from having to tweak ebuilds?

Why does reading /etc/portage/builds/apache(2).conf require changing portage? 
It seems to work during my limited testing.

suexec needs - in its current form - to be recompiled on 
every change. this is, because the path locations are via 
(preprocessing varables) hardcoded.

however, there's technically no need to patch portage for 
your proposal, since the ebuild could source the file himself.

I was mistaken in my understanding of how the portage sandbox works and that
why I thought it wouldn't be able to read a /etc/portage/builds/apache(2).conf
file.

I am working on a proof-of-concept suexec-config utility that would allow easy
changes to /etc/apache(2)/suexec-build.conf as well as rebuild suexec(2) with
those changes. I plan on also modifying the ebuild to use the same settings as
defined in suexec-build.conf.

I should have the proof-of-concept done and committed to the apache-herd SVN
overlay by the end of the day.

Any update on this?

No clue.  vericgar, what's the status on this ?

Resolving LATER, this is something that can be done after the updated stuff goes stable.

This is on my TODO after apache settles down (not sure on that status, been
away
a bit becuase I just moved). I am considering making it an eclectic module, but
I'm still undecided on that.

*** Bug 103695 has been marked as a duplicate of this bug. ***

Reopening this so that I don't forget about it again....

I'd like to remind you of bug 103695, where I attached working patches to do
exactly this, now I don't remember why it was closed, but I think they could be
used w/o problems and aren't too invasive in their approach either.
Best regards, CHTEKK.

Everytime i compile apache, i say in my head "i have to overlay and maintain
manually this ebuild".

We can also make as busybox do :, read in the
/etc/${PN}/${CHOST}/${conf}.config so it would be easy to make an idea as :

echo 'DOCUMENT_ROOT="/home"'>>/etc/apache/i686-pc-linux-gnu/apache.env.conf
emerge -av '=apache-2.0*'

no ?

or just a simply, as another package which i don't remember name, read an env
var to configure apache instead gentoo default (if env var not empty)

That is what suexec-config does, but also allows reconfiguring after the
package is compiled.

And since it seems I forgot to mention in this bug before, apache 2.2.2 has
full suexec-config support and could use some testing. See bug 114232 for more
information on apache 2.2.2.

Does that mean suexec-config won't be added to apache-2.0 ?

(In reply to comment #24)
> Does that mean suexec-config won't be added to apache-2.0 ?
> 

It will be eventually, but it needs a lot of testing under 2.2 first.

> suexec-config needs a lot of testing under 2.2 first.

Ok but this bug exist since 2005, december. a "lot of testing" take some month
too.

I understand that a simple envvar is not a good solution, but is it better than
the overlay solution.

i hope, and i think that many other "admins", that while the tests are
performed on suexec-config, you make the envvar.

with many warning if necessary, but please, add this envvar.


Best regards,

No, we won't now add an envvar just because, and then remove it later... Use
2.2 to get suexec-config if you want this functionality, test it, report bugs,
if it works etc... And if you need it on 1.3, wait... On 2.0 it hasn't much
sense imo as 2.2 works very well and is not unstable or broken, it just lacks
some testing.
Conclusion:
For now, use 2.2 or modify your ebuilds as you did before.
If you need it on 1.3/2.0, wait and help us test suexec-config on 2.2.
Best regards, CHTEKK.

mod_suphp does not work right with 2.2.4.

This bug was started in 2004, plenty of other ebuilds have env vars in them and
there is no reason for the 1.3.x/2.0.x ebuilds to have one too. It's really
annoying to have suexec break because I don't want to use /var/www/.

(er, *not* to have one too)

The current apache-2.2.4-r4 has the new SUEXEC_ environment variables (as
proposed by Luca in #103695) in it. They default to a sane values, but you are
able to overwrite by either configuring them in your /etc/make.conf, or your
current shell.

(In reply to comment #28)
> mod_suphp does not work right with 2.2.4.
> 
> This bug was started in 2004, plenty of other ebuilds have env vars in them and
> there is no reason for the 1.3.x/2.0.x ebuilds to have one too. It's really
> annoying to have suexec break because I don't want to use /var/www/.

I'll see if I can backport most of the chances within the next few weeks, I
won't make any promises.

(In reply to comment #30)
> I'll see if I can backport most of the chances within the next few weeks, I
> won't make any promises.

Looks like I'm not going to backport the stuff.

Thanks so much for suexec environment variables!  It has taken away the fear
that I always had that I'd forget something while upgrading Apache.  ...And I'd
always forget to hack the ebuild to change the suexec parameters.   Now they're
set in my make.conf file.  Now I can emerge -uD world in peace!  :)