Turris Build issueshttps://gitlab.nic.cz/turris/os/build/-/issues2024-01-23T09:46:40+01:00https://gitlab.nic.cz/turris/os/build/-/issues/328Updater kills reconfigured lighttpd2024-01-23T09:46:40+01:00Bernd WechnerUpdater kills reconfigured lighttpdA 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 mac...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).