Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
William A. Rowe Jr. wrote: The last I heard, the 'rpm' project is open source, free to be adopted by any platform. Just because rpm is free to be adopted by any platform doesn't mean it has been. Rpm contains features that allow the spec file to tailor itself to its build environment, and I am confident those features would kick in if someone was to try and create an rpm package tailored for an environment other than a Redhat derivative. As for the rest of your comments, if we solve the general problem, I'm all for including it in the httpd tree. If we are solving specific packagers problems, I'm ok with placing this in the httpd.a.o domain, but we should move this nonsense outside of the development tree into a packaging tree. And in turn violate the principle of least surprise. The point behind support for packaging formats is to make the end user's life easier, not harder. Packagers that create weird, non standard, or unexpectedly complex packaging are not doing their users any favours. Regards, Graham --
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
On Fri, Dec 4, 2009 at 12:59 AM, Graham Leggett minf...@sharp.fm wrote: William A. Rowe Jr. wrote: Ok, so they want to roll their own. Sounds like a maintainer issue. What does this say for using our httpd rpm for an Ubuntu or other distribution of linux? Ubuntu is Debian based, and uses the .deb packaging format, and startup scripts derived from the Debian layout. If someone was to donate debian packaging for httpd, I would expect one or two files to appear below build/deb, and that would be all that would be needed. IMHO, if it is fundamentally incompatible with apachectl and non-redhat distributions, let the the packagers tweak and take the zany customizations out from under our problem set. Apachectl is archaic and largely broken for most people - it made sense ten years ago, it makes a lot less sense today. Really? It works perfectly on all boxes I use it on. What precisely has changed about reading a pid from a file, sending signals to a process, or spawning a process with specific arguments that has made apachectl 'archaic and largely broken', I am intrigued. The pattern followed by most modern unix based packaging is for an application to drop a snippet of config contained in a discrete file in a directory ending in .d. So you have /etc/httpd/conf.d/snippet.conf, instead of a manual edit to /etc/httpd/conf/httpd.conf, and your httpd startup goes within an optional script called /etc/sysconfig/httpd instead of in a script file in a bin directory as apachectl wants. I understand Debian has different naming conventions, but otherwise the underlying principles are the same. Did you mean to say 'most Linux' there? The OSes that I regularly use do not display these redhatisms. In our case, we package up config files within standalone RPMs all of their own (suitably tagged and versioned), or we generate the config file using puppet. Editing a file in place is always painful and error prone, it is far less painful to provide a discrete file that can be dropped in and removed cleanly. Apachectl doesn't give us this - you need to edit apachectl directly to modify the command line parameters passed to httpd. As for the packagers tweaking and making zany customisations, that is exactly what they do now. For us it makes the their packaging unsuitable for our needs, simply because we tweak and make zany customisations for needs of our own. It is far less painful to take a vanilla RPM published by the ASF, and then tweak it for our needs, than it is to take a Fedora RPM, untweak all their customisations, and then retweak it with ours. Ah so now the crux of your argument: 1) I use Fedora/RHEL 2) I want customized packages to install 3) Fedora/RHEL package their RPMs in such a way that it makes it difficult for me to modify them. It's much easier when you just say this up front. Cheers Tom
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Tom Evans wrote: Really? It works perfectly on all boxes I use it on. What precisely has changed about reading a pid from a file, sending signals to a process, or spawning a process with specific arguments that has made apachectl 'archaic and largely broken', I am intrigued. And if you have ten boxes? 50 boxes? A Google of boxes? Editing a file in place has long been shown to be a maintenance nightmare, which is why in addition to logrotate.conf you have logrotate.d, in addition to modprobe.conf you have modprobe.d, and so on. This is a pattern long since established in modern unix distributions, to solve the problem of the need to edit files during a software addition, and edit files again during software removal, all without making mistakes. Sure, if you are used to editing config files by hand on one or two boxes, apachectl will meet your needs, but if you do anything that requires a level of scale doing it this way won't. Regards, Graham --
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
On Fri, Dec 4, 2009 at 12:37 PM, Graham Leggett minf...@sharp.fm wrote: Tom Evans wrote: Really? It works perfectly on all boxes I use it on. What precisely has changed about reading a pid from a file, sending signals to a process, or spawning a process with specific arguments that has made apachectl 'archaic and largely broken', I am intrigued. And if you have ten boxes? 50 boxes? A Google of boxes? Editing a file in place has long been shown to be a maintenance nightmare, which is why in addition to logrotate.conf you have logrotate.d, in addition to modprobe.conf you have modprobe.d, and so on. This is a pattern long since established in modern unix distributions, to solve the problem of the need to edit files during a software addition, and edit files again during software removal, all without making mistakes. Sure, if you are used to editing config files by hand on one or two boxes, apachectl will meet your needs, but if you do anything that requires a level of scale doing it this way won't. Regards, Graham -- Sorry, what has apachectl got to do with editing files? What has using apachectl to stop/start a service got to do with scalability? You've completely lost me here. At $JOB we have 200+ servers, all deployed and configured via cfengine. apachectl is still used to stop/start the servers, via cfengine and other CM tools. Cheers Tom
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
On 12/4/09, Tom Evans tevans...@googlemail.com wrote: Sorry, what has apachectl got to do with editing files? What has using apachectl to stop/start a service got to do with scalability? You've completely lost me here. The only practical thing i can think of is OS vendors providing separate worker and prefork binaries. The standard apachectl has the binary name embedded in it, although there are a host of ways to accomodate that. -- Eric Covener cove...@gmail.com
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Graham Leggett wrote: On a Redhat machine (Fedora/RHEL/Centos), search /etc/rc.d/init.d/functions for functions called daemon, status and killproc. These functions provide similar but incompatible functionality to that provided by apachectl, and only exist on Redhat derived machines. Ok, so they want to roll their own. Sounds like a maintainer issue. What does this say for using our httpd rpm for an Ubuntu or other distribution of linux? The startup script is far too trivial to justify jumping through hoops to try and make apachectl work like Redhat's init. It's caused us enough grief already, thus the fix. IMHO, if it is fundamentally incompatible with apachectl and non-redhat distributions, let the the packagers tweak and take the zany customizations out from under our problem set.
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Gregg L. Smith wrote: Original Message --- Finally, I have yet to see any feedback on the pcre mandatory dependency issue. Comments? Personally, I thought your Monopoly metaphor was quite on target. libz, openssl, lua = batteries not included apr, apu, pcre = drive train not included. And what is passing for an excuse for a local PCRE install these days probably doesn't look like 7.8 or later, with various fixes we are vulnerable to. This does not leave me with a warm and fuzzy feeling. As a user, is the pcre 8.0 I've built going to expose me to risks that your maintained 7.8 does not? If yes, then I'd prefer your maintained one. After all, who knows better than you what will interact with your code to produce problems. Regardless of merit, who will ultimately get blamed in the end? Could your reputation be tarnished? Can you completely divorce yourself from something your software requires to run? I'm referring to pre v7 chaos. And mostly not referring to modern linux distros. The 'Jump Ship' factor; To me, and I'm probably wrong, it sounds like Mr. Felt's comment was an ultimatum of sorts as 'indefinitely' is a pretty strong word. With this issue you have created a deal with it or jump ship ultimatum which could very well leave some people scrambling to get off. Each person is going to inevitably weigh the pain factor, the pain of dealing with it over the pain of jumping ship. I consider myself lucky that my second attempt to deal with it was successful, or so it seems so far anyway, but I never know from day to day. Agreed that ease-of-adoption is going to be the usual, first barrier to anyone jumping aboard 2.4 from 2.2, 2.0, or even still from 1.3. I may be wrong but as an outsider looking in, I see you wanting to stop maintaining/including the gear box and are instead spending the time on adding more optional gadgets to choose from (some of the third party modules you've taken over). In the end, I'd prefer having a reverse gear over the rear window defogger. You are also loosing all control of a required piece of equipment, this has got to make some of you at least cringe a little. I'm not 100% sure I understand what you are saying here. Drop the gearbox and let them assemble their own transmission? Or distribute a most modern transmission that the user can ignore or swap out if they want to install their own? Sorry for the outburst, but you opened the door for, and I've said what I've wanted to for some time now, thanks for listening. Corrections and daggers welcomed. No problems, thanks for chiming in.
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
William A. Rowe Jr. wrote: Ok, so they want to roll their own. Sounds like a maintainer issue. What does this say for using our httpd rpm for an Ubuntu or other distribution of linux? Ubuntu is Debian based, and uses the .deb packaging format, and startup scripts derived from the Debian layout. If someone was to donate debian packaging for httpd, I would expect one or two files to appear below build/deb, and that would be all that would be needed. IMHO, if it is fundamentally incompatible with apachectl and non-redhat distributions, let the the packagers tweak and take the zany customizations out from under our problem set. Apachectl is archaic and largely broken for most people - it made sense ten years ago, it makes a lot less sense today. The pattern followed by most modern unix based packaging is for an application to drop a snippet of config contained in a discrete file in a directory ending in .d. So you have /etc/httpd/conf.d/snippet.conf, instead of a manual edit to /etc/httpd/conf/httpd.conf, and your httpd startup goes within an optional script called /etc/sysconfig/httpd instead of in a script file in a bin directory as apachectl wants. I understand Debian has different naming conventions, but otherwise the underlying principles are the same. In our case, we package up config files within standalone RPMs all of their own (suitably tagged and versioned), or we generate the config file using puppet. Editing a file in place is always painful and error prone, it is far less painful to provide a discrete file that can be dropped in and removed cleanly. Apachectl doesn't give us this - you need to edit apachectl directly to modify the command line parameters passed to httpd. As for the packagers tweaking and making zany customisations, that is exactly what they do now. For us it makes the their packaging unsuitable for our needs, simply because we tweak and make zany customisations for needs of our own. It is far less painful to take a vanilla RPM published by the ASF, and then tweak it for our needs, than it is to take a Fedora RPM, untweak all their customisations, and then retweak it with ours. Regards, Graham --
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
William A. Rowe Jr. wrote: I may be wrong but as an outsider looking in, I see you wanting to stop maintaining/including the gear box and are instead spending the time on adding more optional gadgets to choose from (some of the third party modules you've taken over). In the end, I'd prefer having a reverse gear over the rear window defogger. You are also loosing all control of a required piece of equipment, this has got to make some of you at least cringe a little. I'm not 100% sure I understand what you are saying here. Drop the gearbox and let them assemble their own transmission? Or distribute a most modern transmission that the user can ignore or swap out if they want to install their own? Bill, The latter in your statement, distribute the most modern transmission that the user can ignore or if they wish or swap out with something they prefer. Basically it's easy. If it must be there to build the darn thing, pass GO and collect the $$$, then it should be there. If not, then it becomes an option and that is left up to the user/builder ergo openssl zlib and lua. so +1 to including pcre in -deps (or srclib/pcre), basically as it is now in the other branches. In reality I probably shouldn't say anything anymore as I adapted and overcame, begrudgingly. It sure was a sore subject back between 2.3.1 and 2.3.2 and I guess it just held on and I could not resist making noise. Sorry this got into the wrong thread, I blame my webmail :) Gregg
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Graham Leggett wrote: William A. Rowe Jr. wrote: Ok, so they want to roll their own. Sounds like a maintainer issue. What does this say for using our httpd rpm for an Ubuntu or other distribution of linux? Ubuntu is Debian based, and uses the .deb packaging format, and startup scripts derived from the Debian layout. The last I heard, the 'rpm' project is open source, free to be adopted by any platform. As for the rest of your comments, if we solve the general problem, I'm all for including it in the httpd tree. If we are solving specific packagers problems, I'm ok with placing this in the httpd.a.o domain, but we should move this nonsense outside of the development tree into a packaging tree.
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
minf...@apache.org writes: Author: minfrin Date: Mon Nov 30 22:53:43 2009 New Revision: 885606 URL: http://svn.apache.org/viewvc?rev=885606view=rev Log: ... Remove the use of the apachectl script, as a script calling another script makes no sense. I wonder if this is a good idea? apachectl does some things that httpd.init does not. For example, an admin might reasonably expect to be able to control Apache's environment by editing bin/envvars, but this will now silently fail when Apache is installed using RPM. Of course httpd.init could also source bin/envvars, but then we start down the road of having to keep httpd.init in sync with apachectl. I think we should just use the documented, recommended way of controlling apache. The extra cost seems minimal, especially compared to the long-term maintenance costs of not doing so. Dan
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Dan Poirier wrote: minf...@apache.org writes: Author: minfrin Date: Mon Nov 30 22:53:43 2009 New Revision: 885606 URL: http://svn.apache.org/viewvc?rev=885606view=rev Log: ... Remove the use of the apachectl script, as a script calling another script makes no sense. I wonder if this is a good idea? apachectl does some things that httpd.init does not. For example, an admin might reasonably expect to be able to control Apache's environment by editing bin/envvars, but this will now silently fail when Apache is installed using RPM. Of course httpd.init could also source bin/envvars, but then we start down the road of having to keep httpd.init in sync with apachectl. I think we should just use the documented, recommended way of controlling apache. The extra cost seems minimal, especially compared to the long-term maintenance costs of not doing so. Is it reasonable to simply provision apachectl as httpd.init, perhaps even as a symlink?
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Dan Poirier wrote: Remove the use of the apachectl script, as a script calling another script makes no sense. I wonder if this is a good idea? apachectl does some things that httpd.init does not. For example, an admin might reasonably expect to be able to control Apache's environment by editing bin/envvars, but this will now silently fail when Apache is installed using RPM. Of course httpd.init could also source bin/envvars, but then we start down the road of having to keep httpd.init in sync with apachectl. I think we should just use the documented, recommended way of controlling apache. The extra cost seems minimal, especially compared to the long-term maintenance costs of not doing so. Redhat's init scripts don't work anything like the apachectl script, and trying to call one from the other causes the exact problem you mention - loss of environment variables, and all round weirdness. Apachectl is simply a way of starting httpd, it is certainly not the only way, and is definitely not the way you start if if you're on a Redhat derived platform. Regards, Graham --
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
William A. Rowe Jr. wrote: Is it reasonable to simply provision apachectl as httpd.init, perhaps even as a symlink? Unfortunately not, no. Redhat provides a library of functions to be used by startup scripts that daemonise processes, keep track of pids, and do all the cute displaying of OK or Failed, and make the service command work properly. Apachectl, while similar to Redhat's init script, has different semantics when faced with restart, and the standard Redhat setup doesn't work at all. We would either need to change apachectl to work like Redhat (triggering a storm of protest from people who do use apachectl and would ask if it wasn't broken why did you fix it), or change Redhat to work like apachectl (not worth the effort). Regards, Graham --
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Graham Leggett wrote: We would either need to change apachectl to work like Redhat (triggering a storm of protest from people who do use apachectl and would ask if it wasn't broken why did you fix it), or change Redhat to work like apachectl (not worth the effort). Or change apachectl to act silently to assist httpd.init. In fact, a silent mode makes a lot of sense, httpd.init wouldn't be the only consumer. apachectl should be called-not-exec'ed, IMHO (just as apachectl calls envvars).
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Original Message --- Finally, I have yet to see any feedback on the pcre mandatory dependency issue. Comments? Personally, I thought your Monopoly metaphor was quite on target. libz, openssl, lua = batteries not included apr, apu, pcre = drive train not included. And what is passing for an excuse for a local PCRE install these days probably doesn't look like 7.8 or later, with various fixes we are vulnerable to. This does not leave me with a warm and fuzzy feeling. As a user, is the pcre 8.0 I've built going to expose me to risks that your maintained 7.8 does not? If yes, then I'd prefer your maintained one. After all, who knows better than you what will interact with your code to produce problems. Regardless of merit, who will ultimately get blamed in the end? Could your reputation be tarnished? Can you completely divorce yourself from something your software requires to run? The 'Jump Ship' factor; To me, and I'm probably wrong, it sounds like Mr. Felt's comment was an ultimatum of sorts as 'indefinitely' is a pretty strong word. With this issue you have created a deal with it or jump ship ultimatum which could very well leave some people scrambling to get off. Each person is going to inevitably weigh the pain factor, the pain of dealing with it over the pain of jumping ship. I consider myself lucky that my second attempt to deal with it was successful, or so it seems so far anyway, but I never know from day to day. I may be wrong but as an outsider looking in, I see you wanting to stop maintaining/including the gear box and are instead spending the time on adding more optional gadgets to choose from (some of the third party modules you've taken over). In the end, I'd prefer having a reverse gear over the rear window defogger. You are also loosing all control of a required piece of equipment, this has got to make some of you at least cringe a little. Sorry for the outburst, but you opened the door for, and I've said what I've wanted to for some time now, thanks for listening. Corrections and daggers welcomed. Gregg
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
On Tue, Dec 1, 2009 at 9:03 PM, Gregg L. Smith li...@glewis.com wrote: And what is passing for an excuse for a local PCRE install these days probably doesn't look like 7.8 or later, with various fixes we are vulnerable to. Isn't that the responsibility of the distributor? This does not leave me with a warm and fuzzy feeling. As a user, is the pcre 8.0 I've built going to expose me to risks that your maintained 7.8 does not? If yes, then I'd prefer your maintained one. After all, who knows better than you what will interact with your code to produce problems. Regardless of merit, who will ultimately get blamed in the end? Could your reputation be tarnished? Can you completely divorce yourself from something your software requires to run? The opposite might be true too, what about risks that have been patched in the distribution but not in the one shipped by Apache? IMO library duplication should be avoided as much as possible. Olaf
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Graham Leggett minf...@sharp.fm writes: Redhat's init scripts don't work anything like the apachectl script, and trying to call one from the other causes the exact problem you mention - loss of environment variables, and all round weirdness. Maybe I'm just slow getting back up to speed after the holiday, but I'm not seeing how it would cause a problem. Could you please expand on that? -- Dan Poirier poir...@pobox.com
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Dan Poirier wrote: Redhat's init scripts don't work anything like the apachectl script, and trying to call one from the other causes the exact problem you mention - loss of environment variables, and all round weirdness. Maybe I'm just slow getting back up to speed after the holiday, but I'm not seeing how it would cause a problem. Could you please expand on that? On a Redhat machine (Fedora/RHEL/Centos), search /etc/rc.d/init.d/functions for functions called daemon, status and killproc. These functions provide similar but incompatible functionality to that provided by apachectl, and only exist on Redhat derived machines. The startup script is far too trivial to justify jumping through hoops to try and make apachectl work like Redhat's init. It's caused us enough grief already, thus the fix. Regards, Graham --
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Graham Leggett minf...@sharp.fm writes: Dan Poirier wrote: Redhat's init scripts don't work anything like the apachectl script, and trying to call one from the other causes the exact problem you mention - loss of environment variables, and all round weirdness. Maybe I'm just slow getting back up to speed after the holiday, but I'm not seeing how it would cause a problem. Could you please expand on that? On a Redhat machine (Fedora/RHEL/Centos), search /etc/rc.d/init.d/functions for functions called daemon, status and killproc. These functions provide similar but incompatible functionality to that provided by apachectl, and only exist on Redhat derived machines. Well, apachectl doesn't provide any of that functionality. About all it does is source bin/envvars, if it exists, and then call httpd and pass along any command line arguments. httpd does all the start/stop/restart etc. logic internally. So I'm still not seeing the problem with setting httpd=apachectl in httpd.init, which would make bin/envvars apply, and not really change the behavior otherwise. The startup script is far too trivial to justify jumping through hoops to try and make apachectl work like Redhat's init. That's not what I was suggesting, and I don't think it would be necessary. It's caused us enough grief already, thus the fix. What grief is that? I don't actually know what problem we're trying to fix here. Dan
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Dan Poirier wrote: Well, apachectl doesn't provide any of that functionality. About all it does is source bin/envvars, if it exists, and then call httpd and pass along any command line arguments. httpd does all the start/stop/restart etc. logic internally. So I'm still not seeing the problem with setting httpd=apachectl in httpd.init, which would make bin/envvars apply, and not really change the behavior otherwise. You've said it yourself, apachectl doesn't provide that functionality. In the Redhat world, environment vars are set in the file /etc/sysconfig/httpd, not /usr/bin/envvars. Redhat's service httpd restart works differently to apachectl's apachectl restart. It's caused us enough grief already, thus the fix. What grief is that? I don't actually know what problem we're trying to fix here. Look in the original init script before the fix - start, stop and restart were done using Redhat's functions and the settings in /etc/sysconfig/httpd. graceful and status used apachectl and the (non existent) /usr/sbin/envvars file. That meant for us that the server's config behaved differently if the admin did service httpd graceful and service httpd restart, and was very broken. Regards, Graham --
