Learning to hate SMF

Some of you may recall my recent putback of the removal of in.tnamed.

Well, there has been some nasty fallout, thanks to SMF and the upgrade process. snv64 (which will have to be respun as a result of this nastiness) was hanging during upgrade, thanks to chicken and egg dependencies in the upgrade script.

I fixed the hang, but there is a warning message coming from inetd that I can't seem to locate.

Along the way, I've found references to the network/tname service in a few surprising places. The things I've had to edit, thanks to SMF:

usr/src/tools/scripts/bfu.sh
usr/src/pkgdefs/SUNWcsr/postinstall
usr/src/cmd/svc/profile/generic_net_limited.xml
usr/src/cmd/svc/prophist/prophist.SUNWcsr
usr/src/cmd/cmd-inet/usr.sbin/tname.xml (removed)

And *still* we see a warning from inetd. See 6556092 in bugster for more info.

Anyway, I'm waiting for folks to decide whether to allow the warning to stay, or to backout the change to remove in.tnamed. If the later is taken, I will run screaming from the process, and just leave in.tnamed alone.

In my opinion, removing the tname.xml should have been sufficient. But thanks to SMF's binary databases, it creates a major headache. Can someone from the SMF team please unravel this maze?

Comments

Popular posts from this blog

SP (nanomsg) in Pure Go

An important milestone

The Hand May Be Forced