Date: Thu, 05 Sep 2013 09:23:56 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: olli hauer <ohauer@gmx.de> Cc: apache@FreeBSD.org Subject: Re: www/apache22/files/patch-support__apachectl.in change in r322368 Message-ID: <5228237C.4090807@FreeBSD.org> In-Reply-To: <52277B92.40508@gmx.de> References: <522757BF.60300@FreeBSD.org> <52277B92.40508@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
on 04/09/2013 21:27 olli hauer said the following: > On 2013-09-04 17:54, Andriy Gapon wrote: >> >> http://svnweb.freebsd.org/ports?view=revision&revision=322368 >> Commit message says: >> - add fix for CVE-2013-1862 >> - adjust vuxml >> >> At the same time there is the following change to patch-support__apachectl.in: >> +-case $ARGV in >> +-start|stop|restart|graceful|graceful-stop) >> +- $HTTPD -k $ARGV >> ++case $ACMD in >> ++start|stop|restart|rcvar|reload|graceful|gracefulstop|graceful-stop) >> ++# $HTTPD -k $ARGV >> ++ $SERVICE $( echo $ACMD | tr -d '-' ) >> + ERROR=$? >> + ;; >> >> Of particular interest to me is this change from direct start of httpd to >> starting via service(8) command. >> There is no rationale for this change in commit message... >> >> Now I will describe a problem that this changes causes for us. >> Among other things we use piped loggers with apache. Our filter commands need >> custom PATH to be specified for them. Basically they start with: >> #!/usr/bin/env blah-blah >> And finding blah depends on the proper PATH. >> We are careful to set PATH before running apachectl. Everything used to work >> without any glitch. >> >> Now, service(8) does the following: >> exec env -i HOME=/ PATH=/sbin:/bin:/usr/sbin:/usr/bin $dir/$script $* >> This obviously nullifies any effects of our PATH customization. >> Our configuration became broken. >> >> Do you have any suggestions on how we can work around the problem? >> >> Another minor consequence of this change is that now apache22_enable="YES" must >> be set to start httpd even via apachectl. Previously it didn't have to be >> specified. >> And unlike rc.d/apache22 which accepts onestart/forcestart as all rc scripts do, >> apachectl rejects these commands. >> >> So, I think that the change: >> - was not appropriately committed but rather sneaked into another change >> - is a POLA violation >> - is a PITA >> >> So, perhaps you could consider reverting it? >> >> Thank you very much for all the hard work on apache ports. >> Hope that you will be able to help to resolve the reported issues. >> > > Hm, starting apache with a clean environment was one of the intention behind this > change. In any case you don't want apache to sucks in the environment from the user > starting the server via apachectl. > > The clean way will be to place the custom vars in apache22/24/envars.d this way > > cat apache22/envvars.d/foo.env > export FOO=BAR > export ILOVE=FreeBSD > ... > > The name of the file doesn't matter as long as it ends with '.env', then > it will be processed by the $LOCALBASE/sbin/envvars script. > > Hope this helps. Thank you very much for the suggestion! Indeed, it does fix the problem and it looks much nicer than what we used before. How about the other problem? For various reasons we don't want to put apache22_enable="YES" into rc.conf, but we still need apachectl to work without asking any questions. And yet another problem. For various reasons our apache stores its pid in a custom location. But rc.d/apache22 seems to know only about /var/run/httpd.pid and I couldn't find a way to override that location. So, for example, apachectl stop doesn't work for us, because it now operates via the rc script and it doesn't know about our pid file. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5228237C.4090807>