* Peter Tribble <peter.tribble at gmail.com> [2007-10-08 21:24]: > On 10/8/07, Stephen Hahn <sch at sun.com> wrote: > > * Peter Tribble <peter.tribble at gmail.com> [2007-10-08 20:43]: > > > (There are some annoyances with the svccfg archive output. > > > Identical systems - or even the same system at different times - > > > create different output, so you need to eyeball any differences > > > to see if they're significant.) > > > > Let's improve archive (or introduce archive --strict) to not do that: > > do you have some diffs of this kind that you could share? > > The differences I've stumbled across (based on S10U3): > > There seems to be an md5 checksum for the manifests. Eg. > > <property_group name='var_svc_manifest_system_console-login_xml' > type='framework'> > <propval name='md5sum' type='opaque' > value='86cf97cf476e3e2c66b04d87ce7db740'/> > </property_group> > > Now, the checksum seems to incorporate both file contents > and the timestamp. Different timestamps generate different > checksums, even if the file content is the same. So you have > to go check. > > (svc:/network/rpc-100235_1/rpc_ticotsord:default shows this as well.) > > The other thing is that these checksums only seem to exist for > manifests that were present at boot. This means that the result > of svccfg archive changes after a reboot, even though the > configuration didn't change (assuming that the manifest had > been imported before reboot). And identically configured systems > look different as a result if some have been rebooted and others > haven't. > > (As I recall the manifests are scanned at boot to see if any need > importing. Is mfstscan the correct way to check for discrepancies > between the current state and the state after next boot?)
Yes, which suggests that it should be documented and stabilized, unless there are projects planning to modify it. > The general concept is pretty close, it's just a couple of minor > nits like this that prevent it from being fully automated. So we should mark the hash property groups with a different type, so that we can exclude them from the archive. SUNW,svccfg_nonarchive might work. Doing it this way prevents too much special knowledge from hitting svccfg. I'm surprised there isn't ordering instability from the svc.configd/libscf query that iterates through the services. It's also a bit surprising that no other timestamping/runtime state has leaked in. - Stephen -- sch at sun.com http://blogs.sun.com/sch/
