In order to manage my flock of workstations, in a tightly controlled manner, I
have written the following draft:

(Say, ) there will be a ../dsk-skel/etc folder that will contain all the /etc
files that should be *common* to all workstations ..
That folder should contain *only* those files that could safely copied onto
the workstations. For example the /etc/autofs/auto.home should be common, but
the /etc/sysconfig/network cannot (since it contains the unique hostname).

Care must be taken so that this folder does/does not contain sensitive files,
like /etc/shadow.

This folder could be readable by all machines, but not writtable.

The procedure to follow that folder is that the administrator issues "diff" to
compare that against the actual /etc folder of the workstation machine.
According to the output of that "diff", the administrator may copy files onto
the target machine or manually edit them.

Consider implementing the above procedure as a script.

(Ideally, ) that skeleton should be accompanied by one description file, in
rpm-like syntax (files section). That description file shall contain a
listing of the files, together with their permissions and, if needed,
special flags.

The permissions are better kept in the description file, rather than the
actual flags of the ../skel/ files. That is, the administrator might be free
to edit the skel files under some different user and/or permissions. Then,
the files should be placed onto the target using strictly controlled
permissions (those of the description). Additionally, the description file
will be used so that the permissions can be cross-checked.

Possible flags for the description file could be:
 %noauto    Do not automatically copy the file, but only warn the
     administrator.
 %sensitive  Do not store the contents of the diff (for passwords etc.)
 %optional  This file may be missing on the target
 %optional(package)  This file should exist only if the target has
       'package' installed.
 %reboot    After changing the contents of this file, the system
     should be rebooted
 %relogin  Users shall logout and login again (eg. profile.d/* )
 %restart(service)  The specified service should be restarted by
     calling /etc/init.d/service restart.
 %reload(service)  The service should be reloaded
 %post-exec(command)  The command should be issued after the file is
     changed.

The latter flags could act as a suggestion to the administrator, as to what
actions he should perform after the configuration changes.

The description file could even be skipped when examining the contents of the
/etc files. But then, the comparison would only be limited to the contents of
the files. Copying or moving those files around should be discouraged, once
the description file is not available.

All the files of the ../skel/ folder, along with the description file, could
be stored in a repository. The repository should preferrably be a git one,
since that will be local (less administration cost) and also irrevocably mark
all the stored versions (using a SHA).

Once the skel files are finalized/updated, they could be downloaded to the
target workstations, or checked against them. There could be a periodical
procedure (even a cronjob) that would verify the target's configuration
against the skeleton. However, there shall always be a procedure to manually
issue explicit checkings and/or configuration transfers.

The usage of a git repository also offers the ability to branch the
configuration, in case there should be some offset. For example, if a second
site (subsidiary) is about to be setup, a git branch could describe the
configuration for their machines. As of such, proposed configuration changes
on the master branch could be migrated (merged) onto the subsidiary
branch(es) or (at will) skipped.

The ability of git to produce an archive could be exploited, too. If the
remote site/machine cannot be accessed online from the one that holds the
repository, the archive could be used to bundle the proposed configuration
and let it be transferred onto the target machine.

Git offers certain tools that may bind the configuration changes with the
formal company procedures. All changes, once committed, will mandatorily
carry the author's name. They could, optionally, contain the "Signed off by"
line, which will indicate who has authorized for that specific configuration
change. The SHA, which is in fact a signature, could be reported in procedure
documents, thus proving that the configuration is the one officially signed.

----------
The above specification is still in progress, so expect it to be written more
clearly, enriched with functionality etc.

Please comment.