When SSL is configured for a vserver and the certificate goes away, cherokee fails to start

[kinnison]

When the webserver has virtual servers configured with SSL certificates, and the certificate (or key) moves fr.ex. the webserver cannot start.

This is a problem and means that the webserver ceases to operate when a graceful restart unrelated to the missing certificate is requested.

We ought to make these errors disable the requisite virtual server, and also get them reported in the front of the admin interface and/or on the commandline when the init script is invoked to start the server.

[skinkie]

In the admin this should cause an error upon save right? The main problem when 'just disabeling' the server and not giving an error at all suggests everything is working without a problem. Which is also bad.

[kinnison]

So long as the error message gets back to the admin I don't mind. It was a big pain because a user of mine had 'rearranged' their SSL certificate directory without telling me :-(

[skinkie]

I don't like the non graceful behavior, neither do I like what you propose. What should we do if the default certificate is not present? We can't just generate a random one can we? Should we drop SSL then? What if SSL is the only port listening?

[kinnison]

I'd be happy if we had some way to "test" the config so that the restart operation only occurs if the config passes basic checks (externally referenced files and paths exist, etc)

Then when you press 'graceful restart' we'd check that everything was okay before sending the signal to restart the cherokee worker.

[skinkie]

So refuse to restart is killall -s HUP is send?

[kinnison]

I'm not sure if the worker should refuse to restart on signal, just that the admin interface would run checks before sending the signal.

[skinkie]

Could you verify that it currently doesn't check that the file exists? Maybe it only does prior to save.

[kinnison]

I can confirm that I was editing a different virtual server, hit save and graceful restart and no error was reported to me, but the webserver worker wasn't running afterwards.

[skinkie]

https://github.com/cherokee/webserver/blob/master/admin/PageVServer.py#L129

So we basically should enforce every check done while editing also while saving the file... and that is only from the perspective that we are dealing with an admin situation. The alternative is that we would initiate a graceful restart, but we able to back off when the config can't be parsed. This is really a best effort scenario, because if for one reason the webserver does die, it won't start anymore.

[kinnison]

I think forcing all the checks in the admin interface is enough for now. I'd spot that pretty fast, and then fixing the init script to report the error (It is likely just losing it right now) will help for boot-time issues.

Longer-term we might have to work out a way to disable vservers which can't start and then have a tool to report vservers which are enabled but not startable.

[skinkie]

I guess it should be user configurable what the webserver should do when something is not ok... and document this behavior carefully.

[kinnison]

Yeah, it's a tough one to get right, and you're correct that strong documentation will be key to not confusing people. Still, I wanted an issue to record that this happens so that we can worry about it when we have time. Thanks for discussing the issue with me.