... or possibly "before apache2", or some more general construct. Chillispot is a captive portal system, generally for use in wireless hotspot type setups. It may make sense to tell the init scripts to have chillispot start up before Apache does - Chillispot expects the network interface to be unbound when it starts up, and allocates its IP address to a VPN tunnel once Chillispot's up and running. I'm guessing that it's a fairly common setup where the Apache server running the login screens only binds to the interface which Chillispot brings up, which won't be available until after that service has been started. That's the case on the system that I've just been working with anyway. I think that Chillispot does allow for Apache servers running on other hosts, so it probably shouldn't bring up Apache automatically, but in the case where both are supposed to be started, I think it makes sense to have Chillispot come up first.
Eh, it doesn't depend on apache at all, plus we have no "provide httpd" or similar stuff anywhere in webservers' init scripts. I don't think that this makes sense until Bug 11007 is solved.
Ah, yeah, I hadn't considered non-Apache setups. I'd also agree re: Bug 11007. Obviously this isn't a big deal, though, so no hurry or anything. Anyone who needs it can just go in and edit the init script by hand (like I did).
there is no need for this bug. And 11007 is not fitting for chilli either.
(In reply to comment #3) > there is no need for this bug. And 11007 is not fitting for chilli either. Why do you say that? I'd think that Apache-only-listening-on-the-captive-network is the most common case for a hotspot. In such a case, Apache will not start until Chillispot has been started as well, because the captive interface does not exist before Chillispot's been started. I agree that it wouldn't make sense to modify the Apache (or other httpd) init scripts, but it seems both harmless and useful to do so with the Chillispot init scripts. (Though I do think that it makes the most sense to wait for some kind of virtual/httpd before implementing this.) Not that it's very difficult for someone to just go and make the necessary modification to the init script by hand, like I've done, but IMO it's better to make sure that a user won't have to edit an init script.
Cuz the web server does not have to run on the localhost. infact to me it would not even make sense for it to run on the localhost.. chillispot is pretty much targeted for embedded devices.
I didn't want Chillispot to have a hard dependency on Apache (or any other httpd), or even bring an httpd up automatically before starting. I just think it makes sense that *if* you've got both running on the same box, it's likely that Chillispot has to start first. AFAIK, the "before" directive would accomplish just that - if both chillispot and apache are in the "default" runlevel, then chillispot would start first. Perhaps Chillispot *is* targetted more at embedded devices than not (though I can find no mention of such on its homepage, and their FAQ includes a section on running it on the same host as Apache), but I've got it running in a production environment which requires me to do the simple init script change, or else Apache won't start. If you're not convinced, of course, then I'll obviously just cope with the manual init script change and say no more about it, but I fail to see how the added directive would harm systems without Apache on the same box, and I think it would provide a valuable enhancement to systems which do.
