hi matt, On Fri, Oct 14, 2005 at 12:25:46AM +1300, Matt Brown wrote: > I have a question regarding the registration of an application with > webservers (particuarly apache). The webapps policy in chapter 5.1.2 > specifies how and where the configuration snippet should be placed, but > doesn't deal with whether the package should attempt to reload the > webserver configuration. it probably ought to, or at least prompt the maintainer. otherwise a problem could be hidden until the next time the server is restarted. > conf.d directory. Currently the package then runs invoke-rc.d > <webserver> restart (or if invoke-rc.d isn't > present /etc/init.d/<webserver> restart) to attempt to make the new > configuration active. As described below this is problematic: > > - Shouldn't the package call force-reload rather than restart? why not just reload? better yet would be to determine whether the $httpd was running, and if so "$invoke reload || true", otherwise nothing. > - When a package supports multiple webservers and more than one is > installed, should it attempt to configure itself with all of them? don't see why not. better would be to prompt the maintainer and ask, of course, but as a default course of action that could work. keep in mind, however, that multiple web servers (even different apache) may require different configuration options based on flavor/version/site-configuration. as such, symlinking the same file may become problematic. > - When configuring itself with a webserver should a failure to reload > the configuration files cause an error in the postinst/postrm script? OR > Should it only cause a failure only if none of the supported webservers > was successfully reconfigured? i don't htink the error should stop up the installation process, as you could likely end up with packages in a really nasty install state for complex dependencied-packages. again, maybe informing the admin of the problem, and maybe giving them the option what to do would work best. > Neither of these approaches seem perfect when you consider that a > webserver might fail to reload its configuration successfully because it > is removed but not purged (see bug #259098). if it is removed and not purged, you shouldn't be trying to reload it in the first place :). also, wrt that bug, you shouldn't be trying to unconditionally do stuff in your postrm with packages you depend on. either test to see if you should do it, or don't fail if you can't do it (i think the former is a little better). a more graceful aproach would be rm symlink if server installed ( -x /usr/sbin/$httpd could be one test ) reload server fi > - What about if apache and apache2 are installed and configured, but the > adminstrator has disabled apache. Surely the package shouldn't try to > install / configure itself with apache in this scenario. sure, why not? as long as it doesn't turn on a service that was turned off, anyway. > Is there a best practice in these areas? if you're really curious, take a look at the webapps-common package in cvs on alioth. in there, you'll find a file called internal/httpd, which should have a bunch of really useful functions, which could serve as a reference perhaps for something you could do in your own package. on that vein, i am planning on releasing the package a little more publicly than it currently is. if you'd be interested in being a test subject, let me know :) sean --
Attachment:
signature.asc
Description: Digital signature