Gordon Messmer writes:
It looks like it preserved the old setting (which was no setting) because TLS_TRUSTCERTS:0 was left in some files, while it was changed to TLS_TRUSTCERTS:1 in courierd. Shouldn't that have been modified globally so that all of the daemons could take advantage of the new default setting?
There might've been specific reasons why I chose to bump the version in some cases and not others. Then again, it's possible that I overlooked something. In both cases the error would be in the implementation, not the concept.
"Better" always depends on the use case. Using sysconftool means that there could potentially be problems if the default value changes, the new setting is desirable, but the old value is preserved because the serial number wasn't updated. That's what I perceive with TLS_TRUSTCERTS, though *this* setting doesn't really constitute a problem.
If true, that would be an implementation, usage issue. Not a design issue. I control whether the serial number gets increased, or not. So, if I neglected to increment the serial number of some specific setting, this is not sysconftool's fault.
sysconftool also tends to munge comments in configuration files. Anywhere there's a line of '#' characters used as a separator, for instance, that line and anything in between it and the name of a setting will be moved into the comment section for the previous section on upgrade.
You just can't scribble over a sysconftool-managed file, freehand. The sysconftool files must follow a certain structure. sysconftool's man pages go into some detail. So, yes, if you freely edit the file, the next time sysconftool touches it, it'll eat your changes, if you do not follow the rules.
Finally, if the local configuration files inherited their settings from the .dist version, it would be much easier for me to manage Courier with configuration management tools like bcfg2, puppet, or cfengine. In its current form, the easiest option is also to take the clean configuration files and rebuild my configuration template from scratch each time to avoid missing settings, etc. If they inherited settings and contained only settings which were changed from the default, I could almost always trust that configuration files would work as-is after and upgrade.
I can think of some situations where this won't work. There are certain situations where an upgrade makes existing settings invalid. With sysconftool, the individual setting's serial number gets incremented, and it gets reset back to the default. With your approach, you will keep the previous settings, which will no longer be valid.
sysconftool worked fine for many years. This is the first instance where there was some pain. I see no reason for drastic changes. This was an exceptional situation, where there was not a clear cut upgrade path. In some cases the settings should've been reset, in other cases the settings should've been left alone. I considered incrementing everyone's serial number. Yet, the flip side of the coin is that if someone had a custom OpenSSL configuration, this would've automatically wiped it out with no advance notice. I don't think this situation will occur very often.
pgpdElhC965gy.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
