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 attachment 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! :)
