Bug#642604: [pkg-lighttpd] Bug#642604: Bug#642604: lighttpd always binds to IPv6 on TCP port 80
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, what should we do here? I conclude that neither Olaf nor I are particularly thrilled from your idea. On the other hand I can also see how you have some valid points - despite of a very specific use case you have. Hence I guess its decision time. Any proposals? - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOitXYAAoJEMcrUe6dgPNtjhQP/RIUrqa3lNHapfXbB8sycpv+ t+28EuF+SUMlz5HrA3UWQWLSdDmor86C0btBDa/fp3GWjqMLADVBErqc1IPRympE Xoiwkr7vFHs5a2q91I5OJKgUo6anjDHxW++VqJTK4bSdFFlm5mzBR+gKJtORbbzN Lf2LL2eWVAVaMU9HcYcLWtGqWVmFTgI6SlLAY07ZWG4VvSGCA82g8hF1liCr5WtK ZTpsixop1na9mLIMqthGgQnKLPFYYFnz8RHAk/9JwVmfRVudYxKdFdR9SxtFgIsg 26hVysv7CaqM2bBZv9dwRZXrwCUkFq3V8LyBwFMaAQW4VODrAE7a86+fYyg/fy1o YxT4yhajTyus84qEVe/+Qpg7jAq+nRB0UCmq6oUThXs+i3hMSC3CKPuBWTBlP6wY 0MevRdET1YuljPY3W3Qc+/893okwKDH1yaYLQbiC2alehLr8szl2yf2TGAHde3TO occKyAxg3fYyDuMKgkQOwY+h0AVlYVFpOrLorT84ZKmN4nf3cH/9U6EfHX9Gb1ML E2h+RrS9xr4hj7xKcNj59kLeLblTKzR/MVLudUOu8WGIqUWPhHvhRPDAuHWTZBeP hQHWVouG3utrcmKh7/2Y+TxStvxnYBTZZSeSdCHAf0Ul9/haf8L5NYcpEzn/QJLe qqeBEf+YlyLakRvvS1+T =xf4Y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642604: [pkg-lighttpd] Bug#642604: Bug#642604: lighttpd always binds to IPv6 on TCP port 80
what should we do here? I conclude that neither Olaf nor I are particularly thrilled from your idea. On the other hand I can also see how you have some valid points - despite of a very specific use case you have. Hence I guess its decision time. Any proposals? Hmm, do you have anything specifically against breaking out those handful of directives into debian.conf/platform.conf, that would outweigh the benefits of making automated configuration management easier to handle? Yes, it might make it more difficult to find specific directives if they're spread across two files instead, but at least in this case the files will both be small enough that it shouldn't really be a problem in practice. Thanks, Adam. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642604: [pkg-lighttpd] Bug#642604: Bug#642604: lighttpd always binds to IPv6 on TCP port 80
On Fri, Sep 30, 2011 at 9:23 AM, Adam Nielsen a.niel...@shikadi.net wrote: I have no problem with supporting it, but likewise I think segregating it would be useful too without introducing any limitations. For example, while unlikely, if Debian decides that all pidfiles should now go into /tmp instead, all users will have to examine lighttpd.conf and merge in the change. Those people using a configuration management system like Puppet won't get to see dpkg's nice output, and will have to merge the changes by hand in their repos and push them out to all their machines. Isn't that a limitation of Puppet? That's true, but my argument is that you shouldn't impede progress just in case someone might come along with a better idea one day :-) I realise you don't want to keep changing things, but to be honest, if each change is backwards compatible then you are incrementally improving things, which is always good. The point is that it's not a perfect improvement. Having conf bits in more files means it's harder for a normal user to find/read/update all bits. We do agree that (in principle) it would be nice to support stuff like Puppet better. So let's say we've got lighttpd.conf and platform.conf. Where would the ipv6 include go? I'd say platform.conf. Since you wanted to disable the ipv6 include, you'd have to modify platform.conf and you'd have the same problem as you do now, right? -- Olaf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642604: [pkg-lighttpd] Bug#642604: Bug#642604: lighttpd always binds to IPv6 on TCP port 80
On Fri, Sep 30, 2011 at 11:55 AM, Adam Nielsen a.niel...@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? The point is that it's not a perfect improvement. Having conf bits in more files means it's harder for a normal user to find/read/update all bits. That's true, but then in this case the user already has to find/read/update the bits in the conf-available directory so one more split shouldn't come as a surprise. By default no confs are enabled there. We do agree that (in principle) it would be nice to support stuff like Puppet better. So let's say we've got lighttpd.conf and platform.conf. Where would the ipv6 include go? I'd say platform.conf. Since you wanted to disable the ipv6 include, you'd have to modify platform.conf and you'd have the same problem as you do now, right? 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). guide, anything you *must* change from the upstream lighttpd.conf to make it fit into Debian (user/group, pidfile, etc.) would go into platform.conf, and anything you change just to make it nicer (like IPv6 or the default module list) can go into some other file. For example, I would only expect these options to be in platform.conf: server.upload-dirs = ( /var/cache/lighttpd/uploads ) server.errorlog = /var/log/lighttpd/error.log server.pid-file = /var/run/lighttpd.pid server.username = www-data server.groupname = www-data compress.cache-dir = /var/cache/lighttpd/compress/ Those are quite unlikely to change, so what benefit do you get from moving them to another file? Note that the main lighttpd.conf has already been minimized. With a new daemon version yes, but with a security update or similar where the version is unchanged it may not be necessary. Say for example you had accidentally set the lighttpd user to root and the default document-root to /. The web server would still work and when the mistake is realised the platform.conf could be easily updated to correct the mistake, without requiring any config merging. 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. Olaf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642604: [pkg-lighttpd] Bug#642604: Bug#642604: lighttpd always binds to IPv6 on TCP port 80
On Fri, Sep 30, 2011 at 12:35 PM, Adam Nielsen a.niel...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642604: [pkg-lighttpd] Bug#642604: Bug#642604: lighttpd always binds to IPv6 on TCP port 80
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. 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, 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. Those are quite unlikely to change, so what benefit do you get from moving them to another file? Note that the main lighttpd.conf has already been minimized. The benefit is simply that you don't have to maintain those options in your configuration repository, keeping it as distribution-neutral as possible. 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. Cheers, Adam. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642604: [pkg-lighttpd] Bug#642604: Bug#642604: lighttpd always binds to IPv6 on TCP port 80
Thanks both for your replies, I have responded to both below. From: Olaf van der Spek olafvds...@gmail.com Those people using a configuration management system like Puppet won't get to see dpkg's nice output, and will have to merge the changes by hand in their repos and push them out to all their machines. Isn't that a limitation of Puppet? It is a limitation I think of any/every configuration control system. The point is that it's not a perfect improvement. Having conf bits in more files means it's harder for a normal user to find/read/update all bits. That's true, but then in this case the user already has to find/read/update the bits in the conf-available directory so one more split shouldn't come as a surprise. We do agree that (in principle) it would be nice to support stuff like Puppet better. So let's say we've got lighttpd.conf and platform.conf. Where would the ipv6 include go? I'd say platform.conf. Since you wanted to disable the ipv6 include, you'd have to modify platform.conf and you'd have the same problem as you do now, right? 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 guide, anything you *must* change from the upstream lighttpd.conf to make it fit into Debian (user/group, pidfile, etc.) would go into platform.conf, and anything you change just to make it nicer (like IPv6 or the default module list) can go into some other file. For example, I would only expect these options to be in platform.conf: server.upload-dirs = ( /var/cache/lighttpd/uploads ) server.errorlog = /var/log/lighttpd/error.log server.pid-file = /var/run/lighttpd.pid server.username = www-data server.groupname= www-data compress.cache-dir = /var/cache/lighttpd/compress/ From: Arno Töll deb...@toell.net You always need to check major upgrades for changes and incompatibilities anyway. In particular there is no guarantee your old configuration file will work with the new daemon version. With a new daemon version yes, but with a security update or similar where the version is unchanged it may not be necessary. Say for example you had accidentally set the lighttpd user to root and the default document-root to /. The web server would still work and when the mistake is realised the platform.conf could be easily updated to correct the mistake, without requiring any config merging. I just hate splitted configuration files personally because I prefer one single file where I can see all things I need to know at one sight. Sometimes it makes sense to split files, e.g. for actual configuration vs site/vhost configuration but most of the time settings spread randomly throughout different files are hard to read, to understand and to configure in my opinion. That is a valid point, and unfortunately not one I can counter argue. If you are editing by hand then yes, a single file is nice, but if you are editing by machine then separate files are easier to handle. Perhaps, if you have a large enough file, it will also be difficult to find the section you want. But with nicely-named separate files, it can be made easy to locate the section you are interested in. I'm afraid, but we have no influence at all what other distributions choose as configuration layout and/or which files they ship. Eventually Suse (or whatever) still continues to ship a lighttpd.conf happily specifying their own pidfile stuff there. One more reason not to use Suse then, if they make it difficult :-) Also you say you have no influence over other distros, but I don't think you give yourself enough credit. There are many distributions that are based on Debian! If you want to introduce such a change among all Linux distributions, you better get upstream to split their configuration files out of the box to make sure distributions will follow more likely. This is an interesting idea, but upon closer investigation, probably not practical. The upstream config file has defaults like storing the log files next to the document-root, which the Debian package has overridden and changed to /var/log. So in upstream, there would be no need to split that option out, but in Debian there is because of the change. So I would argue that since you are changing the option anyway, you may as well change it in a separate file :-) Thanks again for being so willing to discuss this, you have given me plenty to think about! Cheers, Adam. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642604: [pkg-lighttpd] Bug#642604: Bug#642604: lighttpd always binds to IPv6 on TCP port 80
Why can't it show the diff / update like dpkg does? nobody has done it yet. So how does it handle updated conf files? I'm not entirely sure. It runs dpkg in non-interactive mode, which means it would either overwrite configs without asking (and then overwrite them again with what's in the Puppet repo) or flag it as an upgrade failure and require manual intervention. Personally I have configured Puppet not to upgrade anything automatically so I can do distro upgrades by hand, as I only have a small number of servers to maintain. People with large numbers of servers may automatically upgrade one or two, test them, fix any problems by updating the config repo, then upgrade the rest with the fixed config. 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? Sorry, let me rephrase - if you are using Puppet to configure lighttpd, you almost certainly don't want IPv6 support left as 'autodetect'. You will either enable it or disable it. The Debian script only enables IPv6 if it is available, which is great for having it 'just work' on a newly installed machine which may or may not have IPv6 available. However people going to the effort of using Puppet to manage their configuration generally want to know exactly how each machine is configured, and setting things to autodetect introduces some unpredictability into the mix. For example if you want to deploy an IPv6 capable web server and for some reason the machine doesn't have IPv6 support, the Debian script would happily start lighttpd in IPv4-only mode, and you would not realise the mistake until someone reported that they could not connect to the server over IPv6. But if you forced IPv6 on in the lighttpd config, it should fail to start without IPv6. Your other monitoring tools would then pick up that lighttpd wasn't running and alert an admin for an immediate fix. Cheers, Adam. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
