Feature #2799: allow overriding configuration values - Lighttpd - lighty labs

Actions

Copy link

Feature #2799

closed

allow overriding configuration values

Added by philipp over 7 years ago. Updated over 7 years ago.

Status:

Fixed

Priority:

Normal

Category:

core

Target version:

1.4.46

ASK QUESTIONS IN Forums:

Description

Your top-level configuration file /etc/lighttpd/lighttpd.conf might come as part of your distro and probably sets quite a lot of configuration.

Rather than tweaking that file directly, you might want to put your changes as in a file which gets read after everything else, e.g. /etc/lighttpd/conf.d/90-site.conf.

Unfortunately, this likely won't work as you'll be attempting to set a value which has already been set, and you'll see an error much like:

Duplicate config variable in conditional 0 global: server.modules
2017-03-15 03:12:44: (configfile.c.1154) source: cat /etc/lighttpd/conf.d/*.conf line: 177 pos: 23 parser failed somehow near here: (EOL) 
2017-03-15 03:12:44: (configfile.c.1154) source: /etc/lighttpd/lighttpd.conf line: 33 pos: 1 parser failed somehow near here: (EOL)

Actions

Copy link

Updated by gstrauss over 7 years ago

Tracker changed from Bug to Feature

Please don't file feature requests as bugs.

Actions

Copy link

Updated by gstrauss over 7 years ago

Status changed from New to Wontfix
Target version deleted (~~1.4.x~~)

and probably sets quite a lot of configuration.

Example, please. I run a fork of openwrt and the /etc/lighttpd/lighttpd.conf is not large and does not change frequently. When it does, it is easy to review and merge the new /etc/lighttpd/lighttpd.conf-opkg.

If you do not want to use the lighttpd.conf that is shipped with your distro, then simply update your startup scripts to use a different lighttpd.conf. For example, instead of the startup script running
/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
it could run
/usr/sbin/lighttpd -f /path/to/custom/lighttpd/lighttpd.conf
You can even create your own service and startup scripts if you do not want touch the ones shipped by your distro. Just remember to disable the service shipped with your distro if you create a replacement service.

Actions

Copy link

Updated by philipp over 7 years ago

I also run a fork of LEDE and OpenWRT both, and I want to override various values:

server.errorlog

server.errorlog-use-syslog

mimetype.assign

static-file.exclude-extensions

server.upload-dirs

cgi.assign

server.document-root

most of which are set... others might be set in the future, and I don't want that breaking my configuration.

Actions

Copy link

Updated by gstrauss over 7 years ago

As I mentioned, if you upgrade the package and there is a changed lighttpd.conf, the new file will be installed as /etc/lighttpd/lighttpd.conf-opkg, and will not break your current configuration. This is off-topic. Please look at opkg --help, specifically opkg list-changed-conffiles. You want to back those up (because it is a good idea to have backups). After running an opkg update, check for new *-opkg files under /etc.

Actions

Copy link

Updated by philipp over 7 years ago

But, equally to the point... so what if someone wants to change a value that they've previously set to something else?

Why is that fatal, much less noteworthy?

Worst case, I would generate a warning in verbose mode (if lighttpd had a verbose mode).

As Jon Postel beat into me, "Be liberal in what you accept, and conservative in what you send." https://tools.ietf.org/html/rfc1122#page-12

He also said, "Never confuse protocol with policy", i.e. don't express policy decisions through protocol restrictions. The two are orthogonal.

Actions

Copy link

Updated by philipp over 7 years ago

I know how it works.

I'm also a Fedora and Centos contributor, and rpm does the same thing, leaving a .rpmnew version of the file, rather than overwrite your changes.

This is not a revelation.

It's still useful to be able to say, "regardless of whatever the upstream packager in his wisdom (or lack thereof) has provided," these values are the ones I ultimately want.

The new incoming config file might well have improvements, bug fixes, etc. which I'd certainly want to merge in...

But it's not a dichotomy: you shouldn't have to choose between accepting new functionality and fixes upstream via upgrades versus fine grained control over the few knobs that really, really matter to you.

I don't understand why you're presenting this as an either/or choice. It's not.

If this is such an obvious way to want to do things, why can't I think of a single other piece of software with truly complex configuration files which also doesn't allow you to override previously set values?

Actions

Copy link