[pkg-lighttpd] Bug#642604: Bug#642604: Bug#642604: lighttpd always binds to IPv6 on TCP port 80

[Olaf van der Spek]

On Fri, Sep 30, 2011 at 12:35 PM, Adam Nielsen <a.nielsen at shikadi.net> wrote:
>>> It is a limitation I think of any/every configuration control system.
>>
>> Why can't it show the diff / update like dpkg does?
>
> It could, but because it's designed to control large numbers of machines it
> would need some careful planning to avoid showing the same/similar diff
> dozens of times.  It's also distribution neutral, so it would have to be
> able to parse output from many versions of dpkg (not just the latest), as
> well as 'emerge' on Gentoo and countless others.  Since Puppet runs as a
> daemon (syncing changes every 15 minutes or so) there would need to be some
> way of notifying a user, e.g. via e-mail and having them respond.  It would
> certainly be doable, but it's a huge job, so I don't think it's a surprise
> nobody has done it yet.

So how does it handle updated conf files?

>>> Not quite.  Since enabling IPv6 support works the same on any distro, it
>>> shouldn't go in the platform-specific section.  I would say, as a rough
>>
>> Does it? The IPv6 code is Debian specific (AFAIK).
>
> The code is Debian specific but the resulting lighttpd options aren't.  If
> you're using Puppet to configure lighttpd you are unlikely to want to
> autoconfigure IPv6,

Why? Are IPv6 and Puppets no friends?

> so you would hard-code the IPv6 stuff in the config file
> if you wanted it on, and not use the Debian script.  If you did want to
> autoconfigure it you'd include your own script (or copy the Debian one...)
> so it worked on any distro.

> The benefit is simply that you don't have to maintain those options in your
> configuration repository, keeping it as distribution-neutral as possible.

Right

>> Security (and stable) updates are unlikely to contain updated conf files.
>>
>> BTW, I've requested upstream to enable IPv6 by default or to provide a
>> better/easier way to enable it. Unfortunately they didn't want to do
>> this for 1.4.
>
> I think the way you have done it is fine for anyone editing the
> configuration by hand, it just unfortunately doesn't make it as clean when
> using an automated tool.  I think this was the original reason behind the
> general move to conf.d style directories - so automated tools could add and
> remove configuration options without having to modify individual files.

Split configs also avoid conflicts when automated tools aren't used.

Olaf