Hi Bob,
Our schedule required us to publish under b101, and not to depend on any
IPS features then missing, broken, or incomplete.
The rbac bit is obvious: IPS does not provide the same support that SVR4
does via i.rbac, the no-op-ness of r.rbac not withstanding. There's a
bug on that--or maybe it's an rfe.
WRT smf: r.manifest does a bunch of work that IPS does not do,
including (1) cleaning up smf's state tables and (2) deleting the
service entirely. Re (1): this omission will probably go unnoticed by
most users, but I did stumble across a corner case where my users in
particular could be adversely affected by it. Re (2): when IPS disables
a service and removes its manifest, the service itself remains
registered with smf, albeit disabled, and may be reenabled with the
command line. Considering that not only is the smf manifest gone, but
that the methods it calls are also probably gone, this seems like a bad
thing. Even if the admins are smart enough not to reenable such a
service, it is disagreeable to leave such cruft lying around after our
removal. I believe that removal of our software should return you to as
close a state as possible to never having been installed.
Further, I could not make delivery of a general smf service for
assembly/tear-down work properly for our optional components. I should
mention that we took the decision not to deliver a new smf service for
each postinstall to be ported, especially when groups of them would be
clones. Our core product does require an initial configuration reboot,
but optional components do not--and, in fact, though they require
postinstall/preremove configuration these steps do not require user
interaction and we may not add such an interaction requirement. So far
I've been able to work around that by incorporating 'register on first
use' in one of our commands. (Fortunately, we have a bottleneck
available.) I consider this inferior to postinstall, however, because
the test must be performed each time the command is run to see if
registration needs have changed. If registration must be done it's the
user's command response time that suffers in order to complete an
install/config action. I've now had to mix what I think of as install or
configuration code in along with behavior code. postinstall/preremove do
the right things exactly once at exactly the right time and don't
interfere with run time behavior of the product. OTOH...what we now have
does work.
hth, --emk
Bob Doolittle wrote:
Hi Nick,
This is timely for me, as I'm investigating converting another product
to IPS packaging. Thanks for sending it out.
I'm interested in these comments in section "2.6.1.2.2.5 Specialty
Handling: (SMF) manifest and rbac":
IPS provides some support for dealing with SMF services, both
pre-existing and being delivered.
However, for our purposes the SMF support for services being
delivered is incomplete,
especially for removal, leading to our removal scripts emulating so
much of r.manifest that we
have elected not to clone that code, but instead use it explicitly
from our own removal scripts.
What specific weaknesses did you see in this area? It appears that
this doc was targeting functionality circa build 105, is that correct?
IMO it would be good to be more explicit about that since you're
discussing evolving functionality.
Thanks,
Bob
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
