Feature #2799

allow overriding configuration values

Added by philipp over 1 year ago. Updated over 1 year ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Missing in 1.5.x:


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) 

Associated revisions

Revision 367e62c1 (diff)
Added by philipp over 1 year ago

[core] allow overriding prior config values (fixes #2799)

introduce ":=" config file syntax to replace previously set value

github: closes #78

"allow overriding configuration values"



Updated by gstrauss over 1 year ago

  • Tracker changed from Bug to Feature

Please don't file feature requests as bugs.


Updated by gstrauss over 1 year 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.


Updated by philipp over 1 year ago

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








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


Updated by gstrauss over 1 year 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.


Updated by philipp over 1 year 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."

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


Updated by philipp over 1 year 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?


Updated by philipp over 1 year ago

Can you provide an example of another piece of software which doesn't allow values to be set and (re)set?


Updated by philipp over 1 year ago

Please reopen.

Replacing patch with modified assignment form:

override <var> = <expr>

Updated by gstrauss over 1 year ago

  • Status changed from Wontfix to Reopened
  • Target version set to 1.4.x

Two alternate patches and further discussion can be found at


Updated by philipp over 1 year ago

Updating the PR per IRC convo.


Updated by gstrauss over 1 year ago

  • Status changed from Reopened to Patch Pending
  • Target version changed from 1.4.x to 1.4.46

Updated by philipp over 1 year ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100

Also available in: Atom