The objective here is to allow an administrator (or an automated
backup system) to reliably and securely back up the repository
contents. See the two RFEs referenced in the subject line.
Background
6425993's comment reads:
> I don't think cp will suffice, since svc.configd could be in the
> middle of modifying the repository.
Indeed. The requirement imposed by PSARC/2007/177 that it be possible
to back up the repository in a format which excludes read-protected
properties[0] seems to imply that it's presently possible to back up
the repository, but only (in the face of read-protection) in a manner
which risks accidental exposure. In fact, this is not correct: at
present, there is no reliable way to back up the repository, full
stop.
We do have the XML format generated by svccfg archive; however, svccfg
import does not import these files. It could be made to do so fairly
easily, by treating them as a series of manifests; however,
reimporting triggers the 3-way merge and affects the last-import
snapshot (and possible others). This is not too bad in the case in
which a system is installed, customizations made, an archive
generated, and then the archive is reimported on top of an otherwise
identical new installation of the same version. In the face of
upgraded systems, reimportation after other customizations or
upgrades, and other changes, it will almost certainly yield incorrect
or surprising results.
6546699 also notes that a correct implementation must consider
interaction with Enhanced Profiles[1]. While this is true, it seems
to me that the correct solution in the face of Enhanced Profiles is
simply to back up the contents of the local profile and all
admin-class profiles. Indeed, by extracting administor intent away
from parameters of the operating system and hardware configuration,
Enhanced Profiles should greatly simplify the solution to this
problem. This means that project will need to accomodate restoration
of pre-Enhanced Profile archives, however, and presumably utilise
profile-aware interfaces to generate a new archive format.
Ideas
The simplest way to address this need is the most obvious: simply
treat restoration as a series of manifest imports. The drawbacks of
this appropach also apply generally to any manifest import and are
described well in [1]. This is a "better than nothing" approach but
will likely require additional work on the administrator's part to
completely restore the repository, especially if other aspects of the
system have changed in the meantime or it has since been reinstalled
or upgraded to a newer version of the operating system.
Another possibility is to create a new archive format containing only
the differences between the current state of the repository and the
last-import snapshots. This, in effect, creates a very poor man's
Enhanced Profile. Restoration, however, would require all of the
manifests to have been imported previously, and if the imported
manifests on the restore target are different from those from which
the archive was made, the administrator is still left to resolve
conflicts by hand. Again, these problems are well-described in [1].
Yet a third way, which suffers from none of the above problems but is
highly dangerous in other ways, is to simply override all existing
repository content with that found in the archive. While this
provides a consistent repository with no administrator intervention,
there is no guarantee that the repository makes sense in the broader
context: for example, a daemon may have been upgraded to a version
which expects that a property has been renamed, an operation which
would have taken place during the upgrade but would not occur upon
restoration.
In short, it appears that the problems described in [1] concerning
import and upgrade are effectively insurmountable in the absence of
Enhanced Profiles. No archive/restore implementation is likely to
offer substantially more value than a hand-merge of known
customizations from a combination of local policy documents and the
XML archive.
However, I'm interested in hearing other thoughts on this - both
alternatives from the SMF team and thoughts on the utility of any of
these imperfect solutions from administrators.
[0]
http://www.opensolaris.org/os/community/arc/caselog/2007/177/opinion-txt/,
see 2 and 4.4.2.
[1] http://www.opensolaris.org/os/project/smf-profiles/
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
