Solaris 10: Disabling services (svcs) during jumpstart?
Dale Ghent
In the past, to disable services and init scripts during a Jumpstart
build, one would just have to include a simple line in the finish
scripts such as:
mv -f /a/etc/rc2.d/S71rpc /a/etc/rc2.d/s71rpc
etc, etc.
With Solaris 10, many (but yes, not all) of what was in the rc
directories have been moved into the Service Management Facility which
is administered with svcadm(1M).
I'd like to continue to disable services via the finish script, but as I
sit down to fashion one for Solaris 10, I realize that it's not as
straight-forward as it used to be. For instance, how does one tell
svcadm to distinguish between the jumpstart miniroot and the
installation you really want to act on, which is mounted on /a ?
I'd like to stick to using svcadm(1M) for doing this, but if it means
mucking around in some directory under /a, then so be it.
Any ideas?
/dale
Sami Ketola
> I'd like to continue to disable services via the finish script, but as I
> sit down to fashion one for Solaris 10, I realize that it's not as
> straight-forward as it used to be. For instance, how does one tell
> svcadm to distinguish between the jumpstart miniroot and the
> installation you really want to act on, which is mounted on /a ?
>
> I'd like to stick to using svcadm(1M) for doing this, but if it means
> mucking around in some directory under /a, then so be it.
>
> Any ideas?
See /var/svc/profile/generic.xml and create your own site.xml based
on that. Then just in the first boot activate it with
svccfg apply /var/svc/profile/site.xml.
Sami
--
.signature: no such file or directory
Gary Mills
>Dale Ghent <daleg...@elemental.org> wrote:
>> I'd like to continue to disable services via the finish script, but as I
>> sit down to fashion one for Solaris 10, I realize that it's not as
>> straight-forward as it used to be. For instance, how does one tell
>> svcadm to distinguish between the jumpstart miniroot and the
>> installation you really want to act on, which is mounted on /a ?
>See /var/svc/profile/generic.xml and create your own site.xml based
>on that. Then just in the first boot activate it with
>svccfg apply /var/svc/profile/site.xml.
You don't have to activate it. It just has to be there. Using a
profile is a very nice way to enable or disable services.
--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
Casper H.S. Dik
That happens automatically.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Dale Ghent
> You should create your own manifest ala, e.g.,
>
> /var/svc/profile/generic_limited_net.xml
>
> and put it in:
>
> /var/svc/profile/site.xml
Excellent. Thanks, everyone!
/dale
Darren Dunham
> I'd like to continue to disable services via the finish script, but as I
> sit down to fashion one for Solaris 10, I realize that it's not as
> straight-forward as it used to be. For instance, how does one tell
> svcadm to distinguish between the jumpstart miniroot and the
> installation you really want to act on, which is mounted on /a ?
> I'd like to stick to using svcadm(1M) for doing this, but if it means
> mucking around in some directory under /a, then so be it.
Not so much "mucking", but I think the idea is that you create a
'site.xml' file which disables particular services, and you stick it in
/var/svc/profile on the new machine. It would have a similar format to
the other manifests in there. Take a look at one of the ns_* ones to
see simple service enabling.
When it first boots, it'll import that file and act on it.
--
Darren Dunham ddu...@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
Martin Paul
> Dale Ghent <daleg...@elemental.org> writes:
>>I'd like to stick to using svcadm(1M) for doing this, but if it means
>>mucking around in some directory under /a, then so be it.
>
>
> /var/svc/profile/generic_limited_net.xml
>
> and put it in:
>
> /var/svc/profile/site.xml
Hm, if site.xml exists is it read after generic.xml or instead ? Ie.
do I have to list all services from generic.xml or site.xml or can
site.xml contain e.g. just:
<service name='network/finger' version='1' type='service'>
<instance name='default' enabled='false'/>
</service>
to disable this one service ?
My problem is that until now I'm using a set of scripts (which get
called by the finish script) each one doing all things required to modify
the behaviour of a single service. Like a sendmail script which modifies
sendmail.cf and installs /etc/default/sendmail, or a dtlogin-disable
script which disables dtlogin. That's more flexible than one
big script (I think JASS works the same way). Unfortunately having
to install a site.xml which modifies a lot of services would break
this setup, and I'd like to find the best workaround within SMF.
mp.
--
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna
Casper H.S. Dik
>Hm, if site.xml exists is it read after generic.xml or instead ? Ie.
>do I have to list all services from generic.xml or site.xml or can
>site.xml contain e.g. just:
> <service name='network/finger' version='1' type='service'>
> <instance name='default' enabled='false'/>
> </service>
>to disable this one service ?
It's read at the end.
I think you need more xml gunk like the "generic.xml" and such files.
>My problem is that until now I'm using a set of scripts (which get
>called by the finish script) each one doing all things required to modify
>the behaviour of a single service. Like a sendmail script which modifies
>sendmail.cf and installs /etc/default/sendmail, or a dtlogin-disable
>script which disables dtlogin. That's more flexible than one
>big script (I think JASS works the same way). Unfortunately having
>to install a site.xml which modifies a lot of services would break
>this setup, and I'd like to find the best workaround within SMF.
I see what you mean. Let me ponder that for a bit.
Dave Miner
> Casper H.S. Dik <Caspe...@sun.com> wrote:
>
>>Dale Ghent <daleg...@elemental.org> writes:
>>
>>>I'd like to stick to using svcadm(1M) for doing this, but if it means
>>>mucking around in some directory under /a, then so be it.
>>
>>You should create your own manifest ala, e.g.,
>>
>>/var/svc/profile/generic_limited_net.xml
>>
>>and put it in:
>>
>>/var/svc/profile/site.xml
>
>
> Hm, if site.xml exists is it read after generic.xml or instead ? Ie.
> do I have to list all services from generic.xml or site.xml or can
> site.xml contain e.g. just:
>
> <service name='network/finger' version='1' type='service'>
> <instance name='default' enabled='false'/>
> </service>
>
> to disable this one service ?
>
site.xml is the last profile applied; the only caveat here is that the
auto-conversion of inetd.conf entries happens later, so make sure that
inetd.conf doesn't have anything left in it that would contradict your
site profile post-install.
The only thing you'd need to add to the example above is the
service_bundle tag to wrap all of the service declarations.
> My problem is that until now I'm using a set of scripts (which get
> called by the finish script) each one doing all things required to modify
> the behaviour of a single service. Like a sendmail script which modifies
> sendmail.cf and installs /etc/default/sendmail, or a dtlogin-disable
> script which disables dtlogin. That's more flexible than one
> big script (I think JASS works the same way). Unfortunately having
> to install a site.xml which modifies a lot of services would break
> this setup, and I'd like to find the best workaround within SMF.
>
Your site.xml can ise the xml include facility, just as the generic
profiles already do, which may or may not be helpful to your situation.
Dave
Martin Paul
> The only thing you'd need to add to the example above is the
> service_bundle tag to wrap all of the service declarations.
>
> profiles already do, which may or may not be helpful to your situation.
So for example a finger_disable finish script could install a file
named /a/var/svc/profile/disable_finger.xml with this content:
<service_bundle type='profile' name='default'>
<service name='network/finger' version='1' type='service'>
<instance name='default' enabled='false'/>
</service>
</service_bundle>
and then "echo >>" a line like this into /a/var/svc/profile/site.xml:
<xi:include href='file:/var/svc/profile/disable_finger.xml' />
Any other <service>_disable or <service>_modify script could then
do the same without interfering with other services ? That'd be
a viable solution, at least.
The obvious RFE is of course that the SMF configuration commands
(svcadm, inetadm) should support an option or mode to enable/disable/
modify services when running under jumpstart. That would make life
much easier.
Dave Miner
> Dave Miner <dave....@sun.com> wrote:
>
>>The only thing you'd need to add to the example above is the
>>service_bundle tag to wrap all of the service declarations.
>>
>>Your site.xml can ise the xml include facility, just as the generic
>>profiles already do, which may or may not be helpful to your situation.
>
>
> So for example a finger_disable finish script could install a file
> named /a/var/svc/profile/disable_finger.xml with this content:
>
> <service_bundle type='profile' name='default'>
> <service name='network/finger' version='1' type='service'>
> <instance name='default' enabled='false'/>
> </service>
> </service_bundle>
>
> and then "echo >>" a line like this into /a/var/svc/profile/site.xml:
>
> <xi:include href='file:/var/svc/profile/disable_finger.xml' />
>
> Any other <service>_disable or <service>_modify script could then
> do the same without interfering with other services ? That'd be
> a viable solution, at least.
>
Something like that should work, though to valid XML you actually need
the DOCTYPE declaration and the service_bundle elements in the site.xml,
so it's a little more complicated than just "echo >>"
> The obvious RFE is of course that the SMF configuration commands
> (svcadm, inetadm) should support an option or mode to enable/disable/
> modify services when running under jumpstart. That would make life
> much easier.
>
Yes, we need to provide some easy way to do this, the fact that we don't
yet is due as much to not being sure what the requirements were as
anything else. I think we're getting a handle on those, so hopefully
we'll be able to provide something fairly soon.
Dave