On Thu, Feb 12, 2009, Les Mikesell wrote:
>Bill Campbell wrote:
>>
>>>> Of course we don't do things that are likely to take a critical service
>>>> down without proper prior planning (often found out the hard way on our own
>>>> systems :-). If an update is likely to have an impact on operations, it is
>>>> scheduled during a maintenance window.
>>> In other words you'd dedicated sufficient human resources to undo
>>> whatever damage the package management system causes...
>>
>> Isn't that what our customers are paying us to do?
>>
>> That has to be true now matter how one is doing updates.
>
>Yes, but the extent to which it is actually required depends on how
>badly the intended automation fails. I think at least in theory, the
>parts of config files that are likely to need user modifications are
>supposed to be extracted to /etc/sysconfig/... so the files included in
>RPM updates generally won't have local changes and can be replaced
>without regard to the old contents. And programs suitable for inclusion
>in an 'enterprise' distribution should be designed so as not to require
>non-backwards-compatible changes in updates.
With OpenPKG all configuration files are under $prefix/etc/packagename
where $prefix is the base directory of an OpenPKG instance (there may be
more than one on a single system), and packagename is the name of the
package, postfix, amavisd, clamav, mysql, etc. One of the basic principles
of OpenPKG is to have absolutely minimal footprint on the installed system,
only 7 lines in /etc/crontab, and the appropriate /etc/init.d entries
(these actually vary depending on the type of host system).
Some packages have multiple configuration files with only those for site
parameters being declared at %config files in the RPM SPEC file. The
issues occur when one has large, ugly configuration files (can we spell
amavisd.conf :-), and there's a major version update with lots of new
variables or variable name changes.
FWIW, to bring this back to the djbdns topic, the *ONLY* configuration file
in our OpenPKG packaging of djbdns, daemontools, and ucspi-tcp is the
dnsroots.global file used by dnscache. Each server installed is in its own
directory which is not affected by updates.
Bill
--
INTERNET: bill@xxxxxxxxxxxxx Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
Voice: (206) 236-1676 Mercer Island, WA 98040-0820
Fax: (206) 232-9186
The only freedom which deserves the name, is that of pursuing our own good
in our own way, so long as we do not attempt to deprive others of theirs,
or impede their efforts to obtain it. -- John Stuart Mill, 1859
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
