Ticket #41 (closed defect: fixed)

Opened 17 years ago

Last modified 12 years ago

BCFG2 on Solaris

Reported by: [email protected] Owned by: desai
Priority: major Milestone: Bcfg2 1.0.0 Release
Component: bcfg2-client Version: 1.0
Keywords: solaris Cc:


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.'/> <Package simplefile='SUNWkvm.v' name='SUNWkvm.v' version='11.10.0,REV=2005.'/> <Package simplefile='' name='' version='11.10.0,REV=2005.'/>

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


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 ( Ideally, bcfg2 would provide its own implementation of what PCA can do.


Change History

comment:1 Changed 17 years ago by desai

  • Status changed from new to assigned
  • Reporter changed from anonymous to [email protected]
  • Milestone Bcfg2 0.8.1 Release deleted

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.'/>

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

<Package simplefile='' name='' version='11.10.0,REV=2005.'/>


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?

comment:2 Changed 17 years ago by desai

comment:3 Changed 17 years ago by desai

  • Status changed from assigned to closed
  • Resolution set to fixed

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.

comment:4 Changed 14 years ago by anonymous

  • Status changed from closed to reopened
  • Resolution fixed deleted

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...

comment:5 Changed 14 years ago by solj

  • Version set to 1.0
  • Milestone set to Bcfg2 1.0 Release

comment:6 Changed 13 years ago by desai

  • Status changed from reopened to closed
  • Resolution set to fixed

This last issue can be addressed with altsrc.

comment:7 Changed 12 years ago by

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


WARNING! You need to establish a session before you can create or edit tickets. Otherwise the ticket will get treated as spam.


Add a comment

Modify Ticket

Change Properties
<Author field>
as closed
The resolution will be deleted. Next status will be 'reopened'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.