Quoth Keith M Wesolowski on Fri, Aug 03, 2007 at 02:37:30PM -0700:
> 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.
There's no reliable, public way for the *administrator* to create
a backup -- the system creates repository backups named
/etc/svc/repository-* . Probably not suitable for our purposes here,
though their creation does include a solution to the cp problem.
...
> 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.
I don't think this is appropriate because manifest importation attempts
to preserve administrative customizations, whereas the point of backup
restoration is to return configuration / software behavior to some
previous state.
I don't think accommodating upgraded software should be a requirement,
since we don't have the infrastructure to solve this generally. As long
as service-specific configuration upgrade logic is relegated to class
action scripts and postinstall scripts (which generally can't access SCF
anyway), and we can't tell which software is consuming which
configuration, we just have to make the administrator understand that
backups are only valid within systems with the same software. Besides,
this is no worse than using plain configuration files as backups.
I presume this will be addressed after Enhanced Profiles, with SCF
versioning and the upgrade method, and possibly the packaging 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].
What's the problem with requiring restoration to occur after
manifest-import?
> 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.
Is upgrade the only problem with this method? Otherwise, it seems to be
exactly what the administrator is asking for by a "backup restore"
request.
I also think there are a few other potential requirements we should sort
out.
- Should snapshots be restored? In general I don't think they need to
be, but the running snapshot is particularly important, and probably
should be. This would require a more extensive format than the
current svccfg archive.
- Should properties not in the backup be deleted? I think so, modulo
properties which represent runtime status or persistent state.
- Does restoration need to be possible before or after the system has
booted? I believe either would suffice.
David
