Greetings,
I've recently been pondering how we might allow administrators to
deliver customisations to configuration files using packages instead of
suggesting use of a service, configuration tools like puppet, etc.
Examples might include files such as: /etc/mysql/5.1/my.cnf,
/etc/apache2/2.2/envvars, /etc/motd, /etc/wgetrc,
/etc/apache2/2.2/magic, /etc/apache2/2.2/mime.types, /etc/zshrc.
The above are all examples of files that an administrator might want to
deploy identical copies of across multiple systems, for which scripting
is not required, and for which the customisation being delivered is
final (that is, the files aren't intended to be edited if customised
through packaging in this way).
If we punt and say "deliver customisations to application configuration
through third-party tools or scripts" the administrator has to rely on
that to:
* enforce a specific version of configuration
* verify configuration correctness
* determine which version of configuration is in use on a system
* maintain configuration history and metadata
By allowing administrators to package customised versions of editable
files such as the ones listed above, there are several benefits:
* mass deployment of configuration using AI
* verifiable configuration using pkg verify
* restorable configuration (due to incorrect alteration or corruption)
using pkg revert
* ability to deliver configuration based on installed package version
* ability to determine configuration based on installed packages
* ability to find which files are customised via packaging using pkg
search
To accomplish this, the following changes are proposed:
1) File Actions
===============
Add additional values for the preserve attribute on file actions:
custom-true
custom-renameold
custom-renamenew
The 'custom' prefix on the above values simply indicates that the
editable file allows another package to deliver a custom version.
Otherwise, the behaviour is identical to what rename uses today.
custom
Indicates that this file should:
* overwrite any editable file already installed on the system
(or that will be installed as part of the operation)
* be installed if no other package delivers the editable file
* be installed if the content changes, even if the version on-disk
doesn't match what was originally delivered
* be part of verify checking (meaning users can't alter this file
without causing verify to fail)
Suggestions on attribute values or alternative mechanisms welcomed.
2) Conflict checking
====================
Only one action with a value of preserve=custom will be allowed at a
time. If multiple packages claim the same editable file within a single
operation, the operation should fail with a conflict error message.
3) Upgrade logic
================
Example packages:
pkg:/[email protected]
file path=etc/motd ... preserve=custom-true
pkg:/[email protected]
file path=etc/motd ... preserve=custom
Given the example packages above:
If SUNWcs was upgraded to a newer version, the existing /etc/motd would
be preserved, just as it is today.
If mycfg was upgraded or downgraded, the new version of /etc/motd would
be installed regardless of whether /etc/motd had been modified.
If SUNWcs was removed and mycfg was not, /etc/motd would be left in place.
If mycfg was uninstalled, and SUNWcs was not, /etc/motd would be left as-is.
If both SUNWcs and mycfg were removed, then /etc/motd would be removed.
This proposal is not intended for configuration files such as
/etc/passwd, /etc/ftpd/ftpusers, any configuration file generated or
modified by a service, or that already has an equivalent action for
modification (e.g. driver actions).
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
