É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.
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.
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.
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
“Solaris 10 SMF servicek” bejegyzéshez 6 hozzászólás