-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04.10.2011 13:56, Adam Nielsen wrote:
> If you're really that much against the idea then I won't try to persuade
> you otherwise. All I can say is that it would make life much easier for
> anyone who uses tools to manage the config files, and I wou
On Tue, Oct 4, 2011 at 2:07 PM, Adam Nielsen wrote:
> Interesting idea about extracting the config options. I'd be a little
> worried though about extracting the options, appending my own, then writing
> it back to lighttpd.conf. If anything ever went wrong it would be very easy
> to severely br
On Tue, Oct 4, 2011 at 1:52 PM, Stefan Bühler wrote:
> On 10/04/2011 01:34 PM, Olaf van der Spek wrote:
>>
>> On Tue, Oct 4, 2011 at 1:08 PM, Adam Nielsen
>> wrote:
>>>
>>> but at least in this case the files will
>>> both be small enough that it shouldn't really be a problem in practice.
>>
>> S
Otoh it is true that probably not all platforms would provide a similar
config, so i'm not sure how useful this is for puppet users.
perhaps it would be better to extract those settings from the current config
(lighttpd -p -f /etc/lighttpd/lighttpd.conf | grep "..." >
new-puppet-plaform.conf) in a
On 10/04/2011 01:34 PM, Olaf van der Spek wrote:
On Tue, Oct 4, 2011 at 1:08 PM, Adam Nielsen wrote:
but at least in this case the files will
both be small enough that it shouldn't really be a problem in practice.
Shouldn't? Really? Those qualifications indicate potential problems.
Splitting
but at least in this case the files will
both be small enough that it shouldn't really be a problem in practice.
Shouldn't? Really? Those qualifications indicate potential problems.
Not really, it just means that there will be some small number of users who
will need to do things differently,
On Tue, Oct 4, 2011 at 1:08 PM, Adam Nielsen wrote:
> but at least in this case the files will
> both be small enough that it shouldn't really be a problem in practice.
Shouldn't? Really? Those qualifications indicate potential problems.
Splitting lighttpd.conf makes things harder for the majori
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 specific
-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 tim
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
Thanks both for your replies, I have responded to both below.
From: Olaf van der Spek
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
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
On Fri, Sep 30, 2011 at 12:35 PM, Adam Nielsen 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 planni
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On 30.09.2011 09:23, Adam Nielsen wrote:
> 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
You always need to check major upgrades for changes and
in
On Fri, Sep 30, 2011 at 11:55 AM, Adam Nielsen 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
On Fri, Sep 30, 2011 at 9:23 AM, Adam Nielsen 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 use
I get your point, but I consider every setting in /etc specific to
Debian, but yet allowed and suggested to be changed by the user.
Note, we don't distinguish between settings supposed to be changed by
users and those considered a distribution specific detail. Of course it
does not make too much
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Adam,
On 29.09.2011 07:25, Adam Nielsen wrote:
> That's a fair point, and to explain my reasoning in a bit more detail,
> my problem is that I want to leave the Debian-specific parts of the
> configuration alone. At the moment there is one conf
I discussed your bug report with Olaf and we came to the conclusion that
having core settings like server and socket setup in
conf-available/-enabled is the wrong approach. This setup is merely for
module setup and configuration for our own and other package
maintainer's modules.
We just can't mo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Adam,
On 25.09.2011 02:23, Adam Nielsen wrote:
> Thanks for the quick reply! That would be fine - removing a symlink is
> no problem, as it doesn't require touching anything else.
I discussed your bug report with Olaf and we came to the conclu
Could I please request that this line be moved into its own script in
/etc/lighttpd/conf-available/ instead, so that enabling or disabling IPv6
support can be toggled on and off with a symlink, like the other options?
This way the default config file would not have to be altered to change IPv6
opt
On Sat, Sep 24, 2011 at 1:29 PM, Adam Nielsen wrote:
> 1) You are forced to have IPv6 on, even when "server.use-ipv6" is set to
> disabled
server.use-ipv6 is deprecated (and might be broken)
> 2) You are forced to listen on port 80 on the IPv6 interface, whether you
> want to or not (for the r
Package: lighttpd
Version: 1.4.28-2
lighttpd ships with a line in the default config which calls
"/usr/share/lighttpd/use-ipv6.pl", the idea being to bind to port 80 on any
IPv6 interface, if present.
Unfortunately this has two drawbacks:
1) You are forced to have IPv6 on, even when "server
23 matches
Mail list logo
