> Quoth Derek Diget on Fri, Feb 13, 2009 at 03:29:56PM -0800: > > I am not sure if this the correct forum to ask my question, but > > I could not find an appropriate forum on forums.sun.com. (The one > > link on the OpenSolaris SMF page no longer exists.)
Thanks. > Technically this forum is not for Solaris 10, but your issue is also > relevent to OpenSolaris, so it's acceptable to discuss here. Would it be better if I continued this thread over in that forum? > I've fixed the forum link on the OpenSolaris SMF page. > > > I know I can export the existing network/shell, add the "ekshell" > > instance and load it back it, but I don't believe that is the > > "supported" way. > > > > So, my question is what is the best way to add this instance, but > > still be "supported"? > > One way to do this is to create the instance with > svccfg commands. It > would be something like > > $ svccfg -f - <<END > select network/shell > add ekshell > select ekshell > <addpg & setprop for instance-specific properties> > END > $ svcadm refresh network/shell:ekshell > $ svcadm enable network/shell:ekshell Yup, but would any patches/upgrades have the potential to wipe out this addition? (That is my main goal...I want to make local changes that are safe from any patches/upgrades undoing our change.) > Another way to do this is to place a service manifest into > /var/svc/manifest which instructs SMF to create a > network/shell:ekshell service instance. This, however, is vulnerable to > 6517953 (multiple manifests delivering the same service/instance can > stomp all over each other). > > To avoid 6517953, you can place a service manifest which creates your > instance with your own service name, such as site/network/shell . You > won't be able to inherit properties from network/shell, and SMF won't > consider your service as satisfying any dependencies on > "svc:/network/shell", though that doesn't seem like a problem in your > case. This solution (creating a site service manifest) seems like the best in preventing a support response of 'the local site modified "private/internal" files and those changes are not "protected" during patches/updates' problem. :) > The first and third methods are supported, as far as I know. I'll defer > to others on how supported the second is. Thanks. For now, I think that I will explore the site based service manifest unless I hear otherwise. I see the same/similar issue with ftp (missing a -a option instance) and telnet (missing a -a valid option instance) and will thus need to make those as well. I think the long term fix is to have the "ekshell" instance in the native OpenSolaris distribution (and any OSes that are built from that foundation :). With that in mind I did open a bug requesting that the "ekshell" instance be added to the default network/shell manifest. -- This message posted from opensolaris.org
