That post also led to a few others enough to a very brief introduction.
In fact SMF is much much bigger and powerful than just that.
This time I'll touch on a useful feature related to configuration profiles.
For instance, it's very useful to:
Despite the existent on-line documentation, at this moment, there may be a bug, an undocumented or a misunderstanding of mine regarding how the extraction process is to be performed for an specific and customized FMRI because, at least in my opinion it doesn't seem to work as expected.
In face of the difficulty presented on the previous paragraph I'll devised what most probably can be considered as an work-around though not yet fully bullet-proof acknowledged. Nevertheless I'm rather confident it's OK.
The idea is based on the fact that SMF information is organized into four layers, two of which vendor-provided on top of which two more are administratively customizable. The layers are arranged as follows:
- admin ➜ administrative customizable
- site-profile ➜ administrative customizable (↑)
- system-profile ➜ vendor-provided (↑)
- manifest ➜ vendor-provided (↑)
The additional key information one needs to know is that the current (or all) layer designation means the combined result of all four layers previously described.
Thus to know (in XML format) just what has been administratively customized if suffices to compute the difference in relation to the vendor-provided configuration information. Now it's clear, simple and obvious, isn't it?
Let's see an example about obtaining certain naming services configuration.
I'll refer to another post about zone cloning involving NIS services.
# svccfg extract -l manifest,system-profile \
network/nis/domain > /tmp/nis-domain-vendor
# svccfg extract -l all \
network/nis/domain > /tmp/nis-domain-custom
# diff /tmp/nis-domain-{vendor,custom}
...
< <propval name='domainname' type='hostname' value=''/>
---
> <propval name='domainname' type='hostname' value='business.corp'/>
> <property name='ypservers' type='host'>
> <host_list>
> <value_node value='nis-2'/>
> <value_node value='nis-3'/>
> </host_list>
> </property>
# svccfg extract -l manifest,system-profile \
system/name-service/switch > /tmp/nss-vendor
# svccfg extract -l all \
system/name-service/switch > /tmp/nss-custom
# diff /tmp/nss-{vendor,custom}
...
< <propval name='default' type='astring' value='files'/>
---
> <propval name='default' type='astring' value='files nis'/>
> <propval name='printers' type='astring' value='user files nis'/>
> <propval name='netgroup' type='astring' value='nis'/>
And so on... (see the full list for NIS in Zone cloning)
For a certain technology or functionality it's necessary to refer to the on-line manuals and references in order to know the associated services. Of course this has already been done at this point as I assume there exists customizations to each of those services.
