Épp itt az ideje kicsit foglalkozni a Solaris operációs rendszerek lelki világával, ha már ez lett a szakmán. A SUN elég sok dolgot újragondolt a UNIX-os megszokott világban, az egyik pedig pont a folyamatok kezelése. Amikor folyamatokról beszélek sokkal inkább gondolok a rendszer által kezelendő, indítandó folyamatokról, mintsem egy kósza process-ről. Míg Windows-ban elkülönített részen tudjuk indítgatni leállítgatni a service-ket, addig UNIX-on bevált paradigma a scriptelgetés. Ezt próbálja a SUN újragondolni, és a két világ előnyeit egyesíteni.

Tradicionálisan a Solaris 10 előtt a bootolás folyamata először az init daemon-t hívta meg, ami értelmezte a /etc/inittab fájlt, majd futási szinttől függően, egy csomó (rc) scriptet indított el. Az alapértelmezett futási szint a "3"-as volt , ami többfelhasználós, hálózati üzemmódot jelentett. Ezen túl az inetd daemon számos más daemont indított el amennyiben be volt állítva. Ez pedig így volt "jó", már amennyire.

Ez az elgondolás, bár elég egyszerű volt, mégse volt annyira egyszerű átlátni. Példának okáért, ha egy daemon indítási paraméterét meg akartuk változtatni, meg kellett keresni, hogy mi indítja a deamont, és a start metódusban ki kellett mazsolázni, hogy kell megváltoztatni azokat a bizonyos paramétereket. Egy rc script módosítása elég körülményes volt. Kisebb elírások által a rendszer már nem is bootolt normálisan, vagy éppen egyáltalán. Az rc script tesztelése gyakorlatilag a rendszer újraindítását jelentette, amit megfejelt az, hogy amennyiben hibakeresést is szerettünk volna végezni, szintén a scriptet kellett módosítani. Utolsó negatívumként a rendszer indítása szükségtelenül lassú is volt, mert az rc scriptek egymás után indultak el, még akkor is, ha több indítás esetleg párhuzamosan is futhatott volna.

Aki pedig komolyabban akart RC scripteket integrálni a rendszerébe, ott a függőségek kezelése maga volt a horror. Normális eszközrendszer nincs ennek a problémának a megoldására, így jön a hegesztés.

SMF (Service Management Facility) mint új megoldás

Mit is csinál az SMF?
Alapvetően elrejti előlünk a scripteket, a processeket, és egyetlen egy service névvel definiálja mindezeket.

Mit tudok csinálni egy SMF service-el?
Alapvetően indítani, leállítani, mindezt pedig a függőségek szemelőt tartásával (a service nem indítható el, amíg annak függőségei nem indultak el, illetve ha leállítjuk, az ő tőle függő alkalmazások is le fognak állni). Ezen túl egy service tudja a saját státuszát tesztelni. Jelezni amennyiben hiba állt fel az indítás illetve leállítás alatt, vagy a normális működéstől eltérő állapot fordult elő. Viszont semmiképp sem szabad úgy gondolni egy SMF service-re, mint ami lebutítja Windows service szintre a scriptezést, és teljes mértékben megköti a kezünket. De erről később.

Miből áll egy SMF service?
Először is kell egy method file (/lib/svc/method/), ami majdnem egyenértékű egy RC scripttel. Ez tartalmazza a start, stop hívásokat (és persze más argumentumot is ha szükséges.) Debugolásnál a SMF service log file-ba ennek a scriptnek az errorjai fognak kerülni.
Ezen túl áll egy manifest file-ból. Ez egy xml, ami magát az SMF service-t definiálja. Ezen manifest file-ok tároló könyvtára a /var/svc/manifest/ folder. Ezen manifest file-ok importálásával jön létre a rendszer SMF adatbázisában maga a service. Ez az importálás a rendszer indításakor is lefut automatikusan (az svc:/system/manifest-import által) és természetesen telepítéskor a pkgadd futását követően is. Amennyiben a manifest file-t importáltuk nincs rá többet szükség, viszont nem ajánlatos a Solaris alap manifest file-it bántani.

Vannak-e tradicionális rc scriptek Solaris 10-ben?
Igen vannak. Ezek továbbra is az /etc/rc?.d folderben találhatóak és a megfelelő szekvencia szerint hívódnak meg. Ezen scriptek Legacy néven az SMF adatbázisában is szerepelnek. Tehát láthatóak ha lekérjük a service-ek listáján, "lrc:" névvel. Ezen service-ek esetében nincs hibaellenőrzés, se automatikus újraindítás.

Mi van az inetd-vel?
Az inetd.conf már nem központi konfigurációs állomány hanem a Solarisba beépített inetd szolgáltatások az smf-et használják. Szerencsére van eszköz az előző Solaris verziókról upgrade-nél az inetconv parancs automatikusan konvertálni smf-be az inetd.conf tartalmát. Szerencsére boot közben figyelmeztető üzenet jön, ha van konvertálatlan bejegyzés még.

Hogy illeszkedik az SMF a Solaris rendszerébe?
Alapesetben a bootolás igen "halk", elég kevés log képződik. A boot -m verbose opcióval az SMF minden egyes induló szolgáltatás esetén kiír egy sort, így meggyőződhetünk róla, hogy tényleg minden működik bootoláskor. Azok a napok mindenesetre elmúltak, amikor a /var/adm/messages file-ban vadászhattunk bootolás közbeni hibaüzenetekre, remélve, hogy a hiba bejegyzésre kerül a hibás szolgáltatás nevével együtt. Ehelyett mostantól minden szolgáltatásnak megvan a saját állandó log file. Ezek többsége a /var/svc/log könyvtárban van, kivétel ez alól a single-user mód elérése elõtti szolgáltatások logja, amik a /etc/svc/volatile alatt tartózkodnak (illetve svcs -x is kiírja a service-hez tartozó log file helyét is). A rendszerben hamarabb kerül elénk a konzol login prompt, mert csak azok a szolgáltatások indulnak el előtte amik a loginhoz szükségesek. Amennyiben hibás boot áll fent, használjuk a boot -m milestone=none indítást. Ezek után manuálisan egyesével tudjuk magunk indítgatni és debug-olni a serviceket. A felbootolt rendszer alól az svcadm milestone all paranccsal tudjuk újra engedélyezni az összes service indítását.

Mi az a milestone és mire jó?
A milestone az SMF service-k egy gyűjtő csoportja. Ez helyettesíti a futási szinteket. Mi is kitalálhatunk és csinálhatunk milestone-okat, amiben megadjuk hogy akkor milyen service-ek induljanak el, de a Solaris a régi RC futási szintekhez alapból társít úgynevezett major milestone-okat. Ilyen a milestone/singleuser,
milestone/multi-user, milestone/multi-user-server.

Na és mi van a zónákkal?
A zónáknak saját SMF adatbázisa van, így saját service környezete van függetlenül mindentől. Ezen zóna service-ek inicializálását a global zóna zone smf service kezdi meg. Ahogy lenti képen is látszik.

Akkor innen pedig jöjjenek konkrét példák a fent említett parancsokra, és arra hogy is működik az SMF:

Sokkal csendesebb és gyorsabb boot folyamat:

SunOS Release 5.10 Version Generic 64-bit
Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Hostname: demobox
NIS domain name is testlab.example.com
checking ufs filesystems
/dev/rdsk/c1t0d0s7: is logging.
demobox console login:

Részletes boot: (boot -m verbose):

SunOS Release 5.10 Version Generic 64-bit
Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
[ network/loopback:default starting (loopback network interface) ]
[ system/filesystem/root:default starting (root file system mount) ]
[ network/pfil:default starting (packet filter) ]
[ network/physical:default starting (physical network interfaces) ]
...

svcs parancs:
● List enabled or all (-a) instances, sorted by state, time
● Explanations for errors/states (-x)
● Show dependencies (-d) and dependents (-D)
● Show member processes (-p), additional details (-v/-l)

Amennyiben az svcs kimenetelében az állapot után csillag (*) karakter látszik, az azt jelenti hogy az az állapot elérése épp folyamatban van. Teszem azt online* = épp elindul de még nem indult el teljesen, offline* = leáll éppen de még nem állt se sikeresen.

$ svcs
STATE STIME FMRI
....
online 18:18:30 svc:/network/http:apache2
online 18:18:29 svc:/network/smtp:sendmail
....
$ svcs -p sendmail
STATE STIME FMRI
online 18:18:29 svc:/network/smtp:sendmail
18:18:29 100180 sendmail
18:18:29 100181 sendmail
$ svcs -d sendmail
STATE STIME FMRI
online 18:17:44 svc:/system/identity:domain
online 18:17:52 svc:/network/service:default
....

svcadm parancs:
● Enable, disable, refresh, restart service instances
● Mark in special states (maintenance)
● Synchronously wait for changes (-s)

paraméterei:
● enable: allow service to start once its dependencies are satisfied
● disable: stop service and do not allow it to start again
● enable/disable -t: enable/disable until the system is rebooted
● refresh: reload service configuration and run the refresh method (if any)
● restart: stop the service, then allow it to start once its dependencies are satisfied (no configuration change made)

$ grep lianep /etc/user_attr
lianep::::auths=solaris.smf.modify,solaris.smf.manage
$ svcs apache2
STATE STIME FMRI
- ? svc:/network/http:apache2
$ # create /etc/apache2/httpd.conf
$ svcadm enable apache2
STATE STIME FMRI
online 19:19:01 svc:/network/http:apache2
$ # edit /etc/apache2/httpd.conf
$ svcadm refresh apache2
$ svcs apache2
STATE STIME FMRI
online 19:19:33 svc:/network/http:apache2
$ svcadm disable apache2
$ svcs apache2
STATE STIME FMRI
disabled 19:20:07 svc:/network/http:apache2

svccfg parancs:
● Import, export manifests; apply, extract profiles
● Interactive mode for modifying properties

$ grep lianep /etc/user_attr
lianep::::auths=solaris.smf.modify,solaris.smf.manage
$ svccfg -v import /var/svc/manifest/network/http-apache2.xml
svccfg: Refreshed network/http:/apache2
svccfg: Successful import.
$ svccfg
svc:> select network/http:apache2
svc:/network/http:apache2> listprop
...
general framework
general/enabled boolean false
...
start method
start/exec astring "/lib/svc/method/http-apache2 start"
start/timeout_seconds count 60
start/type astring method
svc:/network/http:apache> editprop
[$EDITOR launches, allows direct editing of properties]
svc:/network/http:apache2> exit
$ svcadm refresh apache2 # read changed config
$ svcadm restart apache2 # restart with changed config

svcprop parancs:
● List properties of services and instances
● Fetch in convenient forms for scripting
● View running or current props (-c), uncomposed (-C)

$ svcprop network/http:apache2
...
physical/entities fmri svc:/network/physical:default
physical/grouping astring optional_all
physical/restart_on astring error
physical/type astring service
start/exec astring /lib/svc/method/http-apache2\ start
start/timeout_seconds count 60
start/type astring method
stop/exec astring /lib/svc/method/http-apache2\ stop
stop/timeout_seconds count 60
stop/type astring method
restarter/auxiliary_state astring none
restarter/next_state astring none
restarter/state astring disabled
restarter/state_timestamp time 1102030556.737590000
$ svcprop -p enabled network/http:apache2
false

inetadm parancs:
● List services managed by inetd
● View (-l) and modify (-m) inetd-specific properties

$ inetadm
...
enabled online svc:/network/ftp:default
enabled online svc:/network/finger:default
disabled disabled svc:/network/login:eklogin
disabled disabled svc:/network/login:klogin
enabled online svc:/network/login:rlogin
disabled disabled svc:/network/rexec:default
enabled online svc:/network/shell:default
$ inetadm -l ftp
SCOPE NAME=VALUE
name="ftp"
endpoint_type="stream"
proto="tcp6"
isrpc=FALSE
wait=FALSE
exec="/usr/sbin/in.ftpd -a"
user="root"
...
default tcp_wrappers=FALSE