Updater kills reconfigured lighttpd
A few days ago now, all my web services were down in the morning. I traced the issue to an overnight update on the Turris Omnia gateway, and from there to lighttpd (which I use as a reverse proxy for various web services delivered by machines on the LAN behind this gateway).
lighttpd was down, and testing that, as I do:
lighttpd -tt -f /etc/lighttpd/lighttpd.conf
revealed the problem. The overnight update had placed a pile of duplicate files in /etc/lighttpd/modules.d
.
How so? Well, the update for example dropped in /etc/lighttpd/modules.d/30-cgi.load
but I have already /etc/lighttpd/modules.d/20-cgi.load
and so of course lighttpd complained about two efforts to assign to cgi.assign
and bailed.
So what's going on here? Well, these configuration files are (as is customary in many similar contexts I think) prefixed with a two digit integer and a dash, to force n alphabetic ordering that reflects the desired order of module loading. That can be important where one depends upon another (requiring it be loaded before).
Anyhow, I tweak these locally with a few goals. One is to get the order I want, and the other is to spread them out so that in the CLI I can use tab completion and one digit expands to one file. It matters not why I do it, but I do, and that is the crux of the matter, and will be predictably the point of contention.
I will content that these are configurable and should be so, and that the updater should be smarter and ignore this sorting prefix when deciding what to copy in. If a module is found and has a different sort key, then the same procedure as with all configurable applies. From memory, what the updater does with other configurables is drop the new file in with the "-opkg" suffix.
Others may contend that these should not be configured locally. We would disagree of course, but either way I need updates not to break my services and do enjoy the freedom to configure my web browsers.
I have a workaround of course, and that is simply not to load these from /etc/lighttpd/lighttpd.conf
and just configure my modules there myself, as that is respected. I see for example /etc/lighttpd/lighttpd.conf-opkg
is there with the Feb 8 date of that update. That's the behaviour I expect for files in modules.d as well, but with smart name matching (ignoring the ordering key).
As a defensive measure I may have to pursue just that for now as I'd rather avoid another system failure after an update. But I wanted to drop a request for consideration here, to smarten this updater a little and this looked like the right repo (defining the lua scripts the updater uses to do what it does).