Enda O'Connor ( Sun Micro Systems Ireland) writes:
> Hi
> I am looking at a patchadd failure and the problem is that
> the patch is running a script that runs
> svccfg import console-login.xml ( full path to xml deleted here for
> brevity )
> and this fails with
>
> svccfg: Conflict upgrading svc:/system/console-login (property
> "ttymon/terminal_type" has different values).
Did the import fail, or did it succeed and just issue this warning?
>
> problem being that I have changed
> "ttymon/terminal_type" to xterm from sun.
>
> Is there any way around this without resorting to having a customer
> manually massaging things.
> This is generic as patches import manifests depending on the patch,
> mainly Kernel patches though, and it appears that any custom
> configuration will lead to this situation.
>
> Plus any upgrade ( LU/jumpstart etc ) will almost certainly lead to the
> same scenario.
>
> Any way to get svccfg to import the config and keep any customisations
> as well.
>
> Enda
> _______________________________________________
> smf-discuss mailing list
> smf-discuss at opensolaris.org
If an administrator has changed a property value and the new manifest has
changed the same property in a different way, the import will not override
the administrator's changes. In this case it issues the warning message
that you see above. The import still succeeds, but the property that has
been changed by the administrator does not get changed.
Here is an example. I created a manifest for a service called bogus_1 with
4 properties. Here are the properties and my plans for them in this
experiment.
ttymon/cmd_change - Will be changed using the svccfg command.
ttymon/man_change - Will be changed in the manifest
ttymon/no_change - Will not be changed at all.
ttymon/terminal_type - Will be changed with svccfg and in manifest
When I import the original manifest, here are the initial values for
these properties as shown by svcprop.
ttymon/cmd_change astring original
ttymon/man_change astring abc
ttymon/no_change astring forever
ttymon/terminal_type astring krang
I then used svccfg to change the cmd_change and terminal_type properties:
$ sudo svccfg
svc:> select bogus_1
svc:/system/bogus_1> setprop ttymon/cmd_change = changed
svc:/system/bogus_1> setprop ttymon/terminal_type = crung
svc:/system/bogus_1> quit
$ sudo svcadm refresh bogus_1
Here are the current property values:
ttymon/man_change astring abc
ttymon/no_change astring forever
ttymon/cmd_change astring changed
ttymon/terminal_type astring crung
Next I edit the manifest changing the property values for man_change and
terminal_type:
man_change 'abc' -> 'dev'
terminal_type 'krang' -> 'vt100'
Next I reimported the manifest using the -v option of svccfg to get verbose
output:
$ sudo svccfg -v import bogus_1.xml ; echo $?
svccfg: Taking "previous" snapshot for svc:/system/bogus_1:default.
svccfg: Upgrading properties of svc:/system/bogus_1 according to instance
"default".
svccfg: svc:/system/bogus_1: Upgrading property "ttymon/man_change".
svccfg: Conflict upgrading svc:/system/bogus_1 (property
"ttymon/terminal_type" has different values).
svccfg: Taking "last-import" snapshot for svc:/system/bogus_1:default.
svccfg: Refreshed svc:/system/bogus_1:default.
svccfg: Successful import.
0
Notice that I did get the same conflict warning that you did. The import
did succeed, howerver, and exited with 0. As we will see the import did
not override the administrator's customizations. That is the reason for
the warning. We will also see the man_change property did get changed by
the import shince there was no conflict. Here are the values after the
import:
ttymon/no_change astring forever
ttymon/cmd_change astring changed
ttymon/terminal_type astring crung
ttymon/man_change astring def
tom
