Friday, July 29, 2005

Creating an SMF service (Part 3)

If you havn't already read them you might want to start with Part 1 or continue with Part 2.

It took me a bit longer to get this written than I intended, now that I have figured out that textile and code/pre tags don't play well this should easier.



In short however, it does what I need it to do now. The whole thing wouldn't suffer from some more work though.



In particular it is currently very brittle. If my relocatable package is relocated parts of this will break. I particularly don't know what to do with installations on a root server.



The following is the first part of the manifest.



<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<!-- Service manifest for the Sysedge monitoring program(s) -->

<service_bundle type='manifest' name='SUNWsmcsysedge'>

<!-- A milestone to collect dependencies for both sysedge and sysedgeplus -->
<service
name="application/monitoring/sysedge_deps"
type="milestone"
version="1">

<!-- common sysedge dependencies -->
<instance name="default" enabled="false">
<dependency
name='filesystem'
grouping='require_all'
restart_on='none'
type='service'>
<service_fmri value='svc:/system/filesystem/local' />
</dependency>
<dependency
name='network'
grouping='require_all'
restart_on='refresh'
type='service'>
<service_fmri value='svc:/network/initial' />
</dependency>
<dependency
name='sysedge_cf'
grouping='require_all'
restart_on='refresh'
type='path'>
<service_fmri
value='file://localhost/etc/opt/SUNWsmcsysedge/sysedge.cf' />
</dependency>
</instance>

<!-- sysedgeplus dependencies -->
<instance name="plus" enabled="false">
<dependency
name='sysedgeplus'
grouping='require_all'
restart_on='refresh'
type='path'>
<service_fmri
value='file://localhost/opt/SUNWsmcsysedge/plus/sysedgeplus' />
</dependency>
</instance>
<stability value='Unstable' />
</service>


The brief rundown including how I generally read it to myself:



<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<!-- Service manifest for the Sysedge monitoring program(s) -->


This is XML, and the DTD can be found here /usr/share/lib/xml/dtd/service_bundle.dtd.1



<service_bundle type='manifest' name='SUNWsmcsysedge'>


This is a manifest called SUNWsmcsysedge



  <!-- A milestone to collect dependencies for both sysedge and sysedgeplus -->
<service
name="application/monitoring/sysedge_deps"
type="milestone"
version="1">


The first "service" in the manifest is application/monitoring/sysedge_dep and it is a milestone.

(It is a milestone because somewhere the docs said roughly: A milestone is a syntectic service that collects dependencies)



      <!-- common sysedge dependencies -->
<instance name="default" enabled="false">
<dependency
name='filesystem'
grouping='require_all'
restart_on='none'
type='service'>
<service_fmri value='svc:/system/filesystem/local' />
</dependency>


As stated in the comment this is an instance of the service/milestone called default and it has a dependency called filesystem.

The dependency is part of the require_all groups of dependencies it has restart_on=none set which indicates that the local filesystems are reqiured to start the service, but after it is started changes to the filesystem do not require a restart to this service automatically.



This service has multiple instances with different instances being used or re-used to fulfill the requirements pf various other services.



          <dependency
name='network'
grouping='require_all'
restart_on='refresh'
type='service'>
<service_fmri value='svc:/network/initial' />
</dependency>


The second dependency is a requirement for networking support to be enabled. Again it is part of the require_all grouping, however in this case if the network configuration is refreshed the dependent service is restarted. Effectively I believe that this actually propagates down through the dependencies.



      <dependency
name='sysedge_cf'
grouping='require_all'
restart_on='refresh'
type='path'>
<service_fmri
value='file://localhost/etc/opt/SUNWsmcsysedge/sysedge.cf' />
</dependency>


The third dependency in sysedge_defs:default or application/monitoring/sysedge_deps:default is also part of the requireall grouping. Note that the type here is *path*. The path type indicates that the *servicefmri* is pointing at a path that must exist to meet the dependency requirement.



</instance>


The closing instance tag indicates that the first defined instance (In this case named default) is finished.



      <!-- sysedgeplus dependencies -->
<instance name="plus" enabled="false">
<dependency
name='sysedgeplus'
grouping='require_all'
restart_on='refresh'
type='path'>
<service_fmri
value='file://localhost/opt/SUNWsmcsysedge/plus/sysedgeplus' />
</dependency>
</instance>


The second instance exists to validate the sysedgeplus instance.



      <stability value='Unstable' />
</service>


The stability Unstable indicates that I am still making up my mind about how all of this should work and I am apt to change it at any time. (Sun has actual definitions of the different stability levels)



Stay tuned, in our next episode I will define a service that actually runs a process.



topic:{technorati}[Solaris]
topic:{technorati}[SMF]

Wednesday, July 20, 2005

Roller and Posting time

Somehow it appears that two of my posts are out of order...
I don't think I edited them and changed the posting time before trying to get them to show up as expected again.

In any case I am sure that I posted the first two parts of creating an SMF service in order;Part 1 was posted before Part 2.

The entry names make me sure of that as well. Additional posts that have the same subject for the length used to create the permalink appear to have numerals appended.

Creating an SMF service (Part 1)



This is Part 1 of an attempt to document creating a new service in SMF.




Resources:

smf(5) and other related manpages

/usr/share/lib/xml/dtd/service_bundle.dtd.1

BigAdmin SelfHealing Site

BigAdmin Developer SMF Intro

BigAdmin SMF QuickStart

docs.sun.com Solaris 10 Admin Guide

Ben Rockwood's SMF Manifest Cheatsheet




The goal is to create a SMF manifest to start a monitoring daemon. (maybe one of those mugs as well)




Before going doing much poking around. I was expecting that I would create a binary instance and a script instance. I would like to be able to have a single manifest that contains all of the services/instances/bits I need.




There are two complementary functions a binary and a script. Recently the script has been modified it now has two operation modes. A "Full" mode and a compatability mode.




I will try to document the problems I run into and the solutions I find.



Part 2


topic:{technorati}[Solaris]
topic:{technorati}[SMF]

Tuesday, July 19, 2005

Live Upgrade Rocks


I know that live upgrade has been available for a while...What I don't
know is why I never really used it before.







Conceptually it makes sense but it was cool how easy it was to upgrade.
I need to see it in larger environemnts with complex application
deployments, but so far so good







# lucreate -c "Nevada16" -m /dev/dsk/c0d0t4:/:ufs -n "Nevada18"
# lustatus (see output below)
# lofiadm -a /var/tmp/solarisdvd.iso /dev/lofi/1
# mount -F hfsf /dev/lofi/1 /mnt
# luupgrade -u -n "Nevada18" -s /mnt
# luactivate Nevada18
# init 6
# lustatus (See output below)




Before:

lustatus
Boot Environment Is Active Active Can Copy
Name Complete Now On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
Nevada16 yes yes yes no -
Nevada18 yes no no yes -



After:

lustatus
Boot Environment Is Active Active Can Copy
Name Complete Now On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
Nevada16 yes no no yes -
Nevada18 yes yes yes no -



topic:{technorati}[Solaris]
topic:{technorati}[liveupgrade]

Monday, July 18, 2005

Creating an SMF service (Part 2)

If you haven't alreay read it you might be interested in statrting with Creating an SMF service (Part 1)



The first major problem...the DTD



Or maybe not so much a problem with the DTD as with my understanding of the
DTD.



Which generally means that I have either been lucky before when writing
Validated XML or I knew and forgot it.



I spent a good 30 minutes trying to figure out what I was doing wrong.

I had valid XML but it didn't validate.

My first thought was that I was miss-remembering the DTD occurrence syntax.



W3 Schools: DTD Elements Indicates:




When children are declared in a sequence separated by commas,
the children must appear in the same sequence in the document.




Error message line breaks for readability.



svccfg validate sysedge.xml
sysedge.xml:94: element service: validity error :
Element service content does not follow the DTD, expecting (create_default_instance? , single_instance? ,
restarter? , dependency* , dependent* , method_context? , exec_method* , property_group* , instance* ,
stability? , template?), got (instance create_default_instance instance stability )
svccfg: Document is not valid.



Now, that error is clear. I have my children out of order (The above error is synthetic).



I have come up with the following "services":




svc:/application/monitoring/sysedgedeps:plus
svc:/application/monitoring/sysedge
deps:default
svc:/application/monitoring/sysedge:default
svc:/application/monitoring/sysedge:concord
svc:/application/monitoring/sysedge:compat
svc:/application/monitoring/sysedge:plus




sysedge_deps:* are classified as milestones



I don't understand why sysedge:default exists with
<create_default_instance enabled='false'/> set. Or is that just "The default instance will be created but not enabled"?



I may try and reduce the possible confusion and break the regular and plus
code into different services instead of instances. Particularly since I
want/need to set <single_instance/> for sysedgeplus.



It also seems that "application property groups" might do some good things.



I may also see if I can figure out how Dan Price
did his dependency graphing. Stephen Hahn has a cool example of smf dependency
graphing




Part 1

Part 3




Since I wrote this I have split the services and done a bunch of package integration.

I will go into details of the design and implementation in future installments.





topic:{technorati}[Solaris]
topic:{technorati}[SMF]

Monday, July 11, 2005

Unfortunate Power Outage









Had a power outage at home this weekend. I wasn't there so I don't know
how long it was.





I do however know that it was long enough to run down my APC 2200.





The problem here is that the old flaky hardware that I have been using
for my main server appears to have lost it's powersupply.





sigh




topic:{technorati}[lame]

Monday, July 4, 2005

Tour De France


So with the Sun shutdown I am all set to watch the first week of the
tour!


Friday, July 1, 2005

What not to do with your Lab v20z






...at least when someone starts using it while you are messing with the
Service Processor Sensor settings.






 sensor set -i ambienttemp -c 29.23 -w 29.24 -W 29.26 -C 29.27
 


Particularly when the operating temprature is ~29 - 31 deg C. We got a
bunch of SNMP traps as the temp. bounced between the thresholds. The
goal was to make sure we were receiving traps properly. Then we got a
platform state change trap...system power off.





A coworker started working with the system during this time and after
turning it on began to create a flar. Naturally after a short time the
system shut down again.





He came over and asked if I shut the system down. My answer: No





I told him that if he would give me a moment I would reset the sensors
so it would shut itself down again.





In any case it all worked as expected.




topic:{technorati}[v20z]