BCFG2 on Solaris

[[email protected]…]

As of BCFG2 0.8.1, here are observed bugs and problems from our Solaris environment:

Architecture specific packages

---

Solaris 10 SYSV can have multiple packages for supporting the various sparc architectures. Examples of this is SUNWcakr, SUNWcar, SUNWced, SUNWkvm. Using SUNWkvm as a test case, our Pkgmgr/* definitions for the S10 1/06 release originally looked like this:

<Package simplefile='SUNWkvmt200.v' name='SUNWkvmt200.v' version='11.10.0,REV=2005.08.10.02.13'/> <Package simplefile='SUNWkvm.v' name='SUNWkvm.v' version='11.10.0,REV=2005.08.04.12.25'/> <Package simplefile='SUNWkvm.us' name='SUNWkvm.us' version='11.10.0,REV=2005.01.20.17.25'/>

When Solaris is installed via jumpstart, one of these packages will be picked depending on processor type, and the resulting package name as seen by pkginfo is simply 'SUNWkvm'. bcfg2 will be unable to bind to this because it knows nothing about a 'SUNWkvm' package, and will want to remove or update the package. One workaround is to create a group for the processor type and add the specific package definition to it, changing the name= to name='SUNWkvm'. It's not clear whether this is something bcfg2 should deal with internally. Overall, there is probably a better way to deal with it.

Service Management Facility

---

SMF does not manage what are referred to as legacy_run services. These are traditional /etc/init.d scripts that have not been converted to the new XML based format. Since SMF does not manage these, bcfg2 doesn't know how to deal with them properly (sometimes it thinks it should try to enable or disable them). Here's a non-definitive list from one of our Solaris machines:

# svcs -a | grep legacy legacy_run Mar_28 lrc:/etc/rc2_d/S10lu legacy_run Mar_28 lrc:/etc/rc2_d/S20sysetup legacy_run Mar_28 lrc:/etc/rc2_d/S42ncakmod legacy_run Mar_28 lrc:/etc/rc2_d/S72autoinstall legacy_run Mar_28 lrc:/etc/rc2_d/S73cachefs_daemon legacy_run Mar_28 lrc:/etc/rc2_d/S81dodatadm_udaplt legacy_run Mar_28 lrc:/etc/rc2_d/S89PRESERVE legacy_run Mar_28 lrc:/etc/rc2_d/S94ncalogd legacy_run Mar_28 lrc:/etc/rc2_d/S98deallocate legacy_run Mar_28 lrc:/etc/rc2_d/S99audit legacy_run Mar_28 lrc:/etc/rc3_d/S16boot_server legacy_run Mar_28 lrc:/etc/rc3_d/S81volmgt

bcfg2 should at the very least ignore these for the time being, or better yet gain smarts that they should be dealt with in a more traditional /etc/rc?.d manner

Patches

---

Regardless of which patch mechanism you make use of, patches present a problem for bcfg2, and it doesn't support any type of patching under Solaris at the moment The basic problem is that a core SYSV package might get updated as part of a patch, such as a kernel patch. This will change the version number for that package, and that will require a manual change to the Pkgmgr/* definition for that package. Otherwise, bcfg2 will try to downgrade the package based on the install media, and that can have disasterous consequences. Then there is the issue of manual vs. automatic patching. It would be nice if bcfg2 supported a way to do both. In the case of automatic patching, it should update the Pkgmgr/* definition automatically. bcfg2 should know how to interface with the Sun supplied 'smpatch' CLI, or the third party PCA tool (​http://www.par.univie.ac.at/solaris/pca/). Ideally, bcfg2 would provide its own implementation of what PCA can do.

[desai]

So, it looks like there are three issues here

• architecture specific packages
• legacy run services
• patch management

I think that the first one could be dealt with using a group category for sparc sub-architectures. This would allow you to say something like: <Group name='sparc-v'>

<Package simplefile='SUNWkvm.v' name='SUNWkvm.v' version='11.10.0,REV=2005.08.04.12.25'/>

</Group> <Group name='sparc-us'>

<Package simplefile='SUNWkvm.us' name='SUNWkvm.us' version='11.10.0,REV=2005.01.20.17.25'/>

</Group>

and so forth. This will work now.

For the legacy service stuff, I think that I can get that code grafted into place. We use something fairly similar for debian/ubuntu.

Finally, for the patching, we should settle on a user interface. One idea is to include patch subelements in package entities. Do you think that would work reasonably?

[desai]

I think that we are now good on all solaris issues. The 0.8.3 release will have everything in the above list dealt with.

[anonymous]

with respect to the architecture specific packages, while a given system will install the appropriate package (e.g.; SUNWkvm.v), a pkginfo on SUNWkvm.v will fail, as the OS knows the package only as SUNWkvm

At least on Solaris 10...

[desai]

This last issue can be addressed with altsrc.

[https://me.yahoo.com/a/USt8Gv93svzpHHC3kECASwE33g--#fdc1d]

with respect to the architecture specific packages, while a given system will install the appropriate package (e.g.; SUNWkvm.v), a pkginfo on SUNWkvm.v will fail, as the OS knows the package only as SUNWkvm

Http://commissionoverloadx.com