Smart-​USVs von APC im Netz­werk

Die­ser Ar­ti­kel be­schäf­tigt sich mit ei­ner Me­tho­de, meh­re­re Ser­ver oder PCs, die ge­mein­sam an ei­ner USV be­trie­ben wer­den, bei Strom­aus­fall ge­ord­net he­run­ter­zu­fah­ren. Der Ar­ti­kel be­zieht sich zwar auf Smart-​USVs von APC und die zu­ge­hö­ri­ge Soft­ware Po­wer­chu­te Bu­si­ness Edi­ti­on in der Ver­si­on 8.0.1, die hier ge­zeig­ten Lö­sungs­an­sät­ze las­sen sich aber auf an­de­re Um­fel­der über­tra­gen.

Hin­ter­grund

Um beim Aus­schal­ten ei­nes Ser­vers oder PCs Da­ten­kon­sis­tenz si­cher­zu­stel­len und die Hard­ware vor Schä­den zu be­wah­ren, darf dem be­tref­fen­den Ge­rät nicht ein­fach die Strom­zu­fuhr ent­zo­gen wer­den, son­dern es muß ge­ord­net he­run­ter­ge­fah­ren wer­den [Link]. Im Fal­le ei­nes plötz­li­chen, un­an­ge­kün­dig­ten Strom­aus­falls ist dies nicht mög­lich, es sei denn, die be­tref­fen­den Ge­rä­te sind an ei­ne un­ter­bre­chungs­freie Strom­ver­sor­gung (USV) an­ge­schlos­sen.

Ne­ben der Über­brü­ckung von Strom­aus­fäl­len ha­ben USVs noch an­de­re Auf­ga­ben wie zum Bei­spiel den Schutz der an­ge­schlos­se­nen Ge­rä­te vor Span­nungs­schwan­kun­gen im Strom­netz.

Es gibt USVs in vie­len Grö­ßen­ord­nun­gen, vom Klein­ge­rät für Ein­zel­platz-​PCs, das ei­nen Strom­aus­fall ge­ra­de so lan­ge über­brü­cken kann, um dem PC ein ge­ord­ne­tes He­run­ter­fah­ren zu er­mög­li­chen, bis hin zu USVs für Re­chen­zen­tren mit Tau­sen­den von Ser­vern, de­ren Ak­kus und Die­sel-​Tanks in gro­ßen Ge­bäu­den mit meh­re­ren Stock­wer­ken un­ter­ge­bracht sind und die meh­re­re Ta­ge oder Wo­chen au­to­no­men Be­trieb er­mög­li­chen [Link].

Es gibt im we­sent­li­chen drei Bau­ar­ten von USVs: Off­line, Line-​In­ter­ac­tive und On­line. Von der Bau­art hängt ab, wie hoch der Wir­kungs­grad ei­ner USV ist, wie schnell sie ei­nen Strom­aus­fall er­kennt und auf Ei­gen­ver­sor­gung um­schal­tet, und ge­gen wel­che Art von Stö­run­gen im Strom­netz sie die an­ge­schlos­se­nen Ver­brau­cher schützt [Link].

Ein wei­te­res ele­men­ta­res Merk­mal zur Un­ter­schei­dung der USVs ist die Lei­stungs­klas­se. Die Lei­stungs­klas­se ei­ner USV wird üb­li­cher­wei­se in Volt­am­pe­re (VA) an­ge­ge­ben; bei der Pla­nung ei­ner USV-​An­la­ge soll­te die Lei­stungs­klas­se je­der USV so ge­wählt wer­den, daß sie un­ge­fähr der ge­mein­sa­men Spit­zen­last al­ler an­ge­schlos­se­nen Ver­brau­cher ent­spricht. Dies sorgt nicht nur für ei­ne sinn­vol­le ma­xi­ma­le Lauf­zeit der USV von min­de­stens ei­ni­gen Mi­nu­ten bei Strom­aus­fall, son­dern die (teu­ren) Wand­ler und Wech­sel­rich­ter müs­sen die an­ge­schlos­se­ne Last eben­falls hand­ha­ben kön­nen.

Bei der Aus­le­gung ei­ner USV ist ge­nau auf die für die An­ga­be der Lei­stungs­klas­se ver­wen­de­te Ein­heit zu ach­ten, je nach Art der an­ge­schlos­se­nen Ver­brau­cher ist zwi­schen Watt (W) und Volt­am­pe­re (VA) um­zu­rech­nen [Link]. Über­di­men­sio­nie­rung scha­det kei­nem Ge­rät, macht die USVs aber teu­rer und sorgt für ei­nen schlech­te­ren Wir­kungs­grad.

Wir emp­feh­len un­se­ren Kun­den für ty­pi­sche Ser­ver­räu­me in klei­ne­ren Un­ter­neh­men in der Re­gel ei­ne Über­di­men­sio­nie­rung um den Fak­tor 1.5, was mei­stens ei­nen gu­ten Kom­pro­miß zwi­schen al­len An­for­de­run­gen dar­stellt: Der Wir­kungs­grad ver­schlech­tert sich nicht merk­lich, die Mehr­ko­sten hal­ten sich im Rah­men, die Lauf­zeit ver­län­gert sich, und wich­ti­ge Klein­ver­brau­cher wie KVM-​over-​IP-​Ge­rä­te, de­ren Funk­tion auch bei Strom­aus­fall es­sen­ti­ell ist, kön­nen spä­ter hin­zu­ge­fügt wer­den.

Aus­gangs­si­tua­ti­on

Vie­le klei­ne­re und mitt­le­re Un­ter­neh­men (KMUs) be­trei­ben nur we­ni­ge Ser­ver, die sich in ein oder zwei 19″-Racks in ei­nem de­di­zier­ten Ser­ver­raum be­fin­den und ge­gen Strom­aus­fall zu si­chern sind. Da der Platz im 19″-Rack kost­bar ist und der Kauf­preis ei­ner USV be­zo­gen auf de­ren Aus­gangs­lei­stung für grö­ße­re USVs im all­ge­mei­nen gün­sti­ger ist als für klei­ne, ist es meist sinn­voll, al­le Ser­ver über ei­ne ein­zi­ge USV ab­zu­si­chern.

Dies al­ler­dings ist oh­ne er­heb­li­che zu­sätz­li­che In­ve­sti­tio­nen mit fast kei­ner USV mach­bar. In der Re­gel wird ei­ne USV über ei­ne se­riel­le oder USB-​Schnitt­stel­le an ei­nen Ser­ver an­ge­bun­den; auf die­sem ar­bei­tet ei­ne Soft­ware, die vom Her­stel­ler der USV ge­lie­fert wird, stets den Zu­stand der USV kennt und bei Be­darf den Ser­ver he­run­ter­fährt. Das Prob­lem liegt darin, daß an­de­re Rech­ner zu­nächst kei­ne Ver­bin­dung zur USV her­stel­len und da­mit nicht auf Strom­aus­fäl­le rea­gie­ren kön­nen.

Die­ses Prob­lem kann auf meh­re­re Ar­ten ge­löst wer­den: Man­che USVs be­sit­zen Ein­schü­be für zu­sätz­li­che se­riel­le oder USB-​Schnitt­stel­len; da­rü­ber las­sen sich zwei (sel­ten auch mehr) Rech­ner voll­wer­tig an die USV an­schlie­ßen. An­de­re USVs be­sit­zen ei­nen Ein­schub für ein Netz­werk­mo­dul, mit dem ent­spre­chen­de Soft­ware kom­mu­ni­zie­ren kann. Dies wä­re ei­gent­lich der Kö­nigs­weg, kann ei­ne sol­che Netz­werk­schnitt­stel­le doch fast be­lie­big vie­le Rech­ner an­bin­den.

Ein sol­ches Mo­dul soll­te das gän­gi­ge Ether­net mit RJ45-​An­schlüs­sen als Me­dium un­ter­stüt­zen, sei­ne Ge­schwin­dig­keit ist da­bei ir­re­le­vant: Be­reits die Da­ten­ra­te des an­ti­ken Stan­dards 10Base-​T liegt grob um den Fak­tor 100 über der ma­xi­ma­len Da­ten­ra­te ei­ner üb­li­chen RS232-​Schnitt­stel­le.

Al­len Nach­rüst-​Op­tio­nen ist je­doch die völ­lig über­zo­ge­ne Preis­vor­stel­lung des je­wei­li­gen Her­stel­lers ge­mein­sam. So ko­sten die Netz­werk-​Mo­du­le oft ähn­lich viel wie die USV, zu­dem las­sen sich die­se Mo­du­le oft nicht mehr mit ko­sten­lo­ser Soft­ware des Her­stel­lers an­spre­chen, son­dern er­wei­ter­te Soft­ware muß er­wor­ben und teu­er be­zahlt wer­den. Die Nach­rüst-​Mo­du­le mit se­riel­len oder USB-​Schnitt­stel­len sind et­was gün­sti­ger und funk­tio­nie­ren meist noch mit der ko­sten­lo­sen Soft­ware des je­wei­li­gen Her­stel­lers, den­noch sind auch sie im­mer noch maß­los über­teu­ert.

Es ver­bleibt ein drit­ter Weg, näm­lich die Lö­sung des Prob­lems per Soft­ware. Da­bei muß der­je­ni­ge Rech­ner, der mit der USV di­rekt ver­bun­den ist, über Soft­ware-​Pro­to­kol­le die an­de­ren Rech­ner über den Zu­stand der USV in­for­mie­ren. Da ent­spre­chen­de Soft­ware von den USV-​Her­stel­lern gar nicht oder wie­der nur ge­gen teu­res Geld an­ge­bo­ten wird, lohnt sich der Blick auf ein klei­nes Pro­jekt, wel­ches wir vor ei­ni­ger Zeit bei ei­nem Kun­den durch­ge­führt ha­ben.

Ziel des Pro­jekts

Ge­ge­ben wa­ren ein Ser­ver mit Mi­cro­soft Win­dows 2003 Ser­ver R2 und zwei Ser­ver mit Li­nux (SuSE SLES, De­bian Len­ny), ei­ne USV mit ei­ner für die drei Ser­ver gut aus­rei­chen­den Aus­gangs­lei­stung so­wie ei­ne TCP/IP-​In­fra­struk­tur, an die al­le Ser­ver an­ge­schlos­sen wa­ren.

Die USV stamm­te aus der Se­rie "Smart-​UPS" des bei KMUs be­lieb­ten Her­stel­lers APC und war mit dem Win­dows-​Ser­ver über ei­ne se­riel­le Schnitt­stel­le ver­bun­den. Auf dem Win­dows-​Ser­ver war die von APC ko­sten­los er­hält­li­che und für den Be­trieb mit der USV vor­ge­se­he­ne Soft­ware "Pow­er­chute Bu­si­ness Edi­ti­on 8.0.1 für Win­dows" in­stal­liert und ord­nungs­ge­mäß kon­fi­gu­riert.

Die­se (auch für Li­nux er­hält­li­che) Soft­ware wird im fol­gen­den mit "PBE" be­zeich­net.

Das Ziel des Pro­jekts be­stand darin, oh­ne An­schaf­fung zu­sätz­li­cher Hard­ware oder Soft­ware si­cher­zu­stel­len, daß nicht nur der Win­dows-​Ser­ver, son­dern auch die bei­den Li­nux-​Ser­ver ge­ord­net he­run­ter­ge­fah­ren wer­den, so­bald ein Strom­aus­fall auf­trat.

Lö­sungs­an­satz

PBE läßt sich de­tail­liert kon­fi­gu­rie­ren; fast je­dem Er­eig­nis, das im Lau­fe des Be­triebs ei­ner USV auf­tre­ten kann, läßt sich ein Pro­gramm zu­ord­nen, das bei Ein­tritt des Er­eig­nis­ses aus­ge­führt wird. Wird hier­für ein Script ver­wen­det, das sich mit den Li­nux-​Ser­vern ver­bin­den und dort die Kom­man­dos zum He­run­ter­fah­ren ab­set­zen kann, ist das Prob­lem ge­löst.

Daß die Um­set­zung auch ei­nes ein­fa­chen Prin­zips vie­le un­er­war­te­te Fall­stri­cke ber­gen und viel Zeit ko­sten kann, wird im wei­te­ren Ver­lauf des Ar­ti­kels deut­lich.

Ver­bin­dung zwi­schen Win­dows und Li­nux

Prak­tisch auf je­dem Li­nux-​Ser­ver, der aus der Fer­ne ad­mi­ni­striert wer­den kann, ist ein so­ge­nann­ter SSH-​Dae­mon in­stal­liert, meist der open­ssh-​Dae­mon. Die­se Soft­ware er­laubt Be­nut­zern über ei­ne ver­schlüs­sel­te Netz­werk-​Ver­bin­dung ei­nen Log­in und stellt ei­ne Shell zur Ver­fü­gung. Für vie­le Ad­mi­ni­stra­to­ren stellt SSH auf­grund der Si­cher­heit die Stan­dard­me­tho­de zum Zu­griff auf Li­nux-​Ser­ver dar. Un­ter Li­nux wird ein gu­ter Teil der Ad­mi­ni­stra­tion auf der Kom­man­do­zei­le er­le­digt, und so gibt es fast im­mer ei­nen Kom­man­do­zei­len-​Be­fehl zum He­run­ter­fah­ren des Sy­stems.

Das SSH-​Pro­to­koll und der open­ssh-​Dae­mon bie­ten noch ei­ne Un­zahl wei­te­rer Mög­lich­kei­ten. Lei­der kann die­ser Ar­ti­kels nicht aus­führ­lich auf Sub­sy­ste­me, Tun­ne­ling, die ver­schie­de­nen Ar­ten der Au­then­ti­fi­zie­rung und wei­te­re Spe­zia­li­tä­ten ein­ge­hen; es gibt aber ge­nü­gend Li­te­ra­tur da­rü­ber.

Zum Zu­griff auf ei­nen SSH-​Ser­ver von Win­dows aus wird ent­spre­chen­de Cli­ent-​Soft­ware be­nö­tigt. So wie un­ter Li­nux fast im­mer der open­ssh-​Dae­mon als Ser­ver ver­wen­det wird, so hat sich un­ter Win­dows das ko­sten­lo­se, zu­ver­läs­si­ge und voll aus­ge­stat­te­te put­ty als Stan­dard-​Client durch­ge­setzt. put­ty be­herrscht di­ver­se Ter­mi­nal-​Emu­la­tio­nen, kann mit ver­schie­de­nen Zei­chen-​En­co­dings um­ge­hen und kennt na­he­zu al­le Spe­zia­li­tä­ten des SSH-​Protokolls, Tun­ne­ling ein­ge­schlos­sen.

Da­mit ist klar, wie der Re­mote-​Shut­down ei­nes Li­nux-​Ser­vers von Win­dows aus prin­zi­pi­ell ab­lau­fen kann: Li­nux-​Log­in per SSH, Ab­set­zen des shut­down-​Be­fehls.

put­ty als Pro­gramm mit gra­fi­scher Ober­flä­che ist für die Ver­wen­dung auf der Kom­man­do­zei­le aber nur be­dingt ge­eig­net. Es gibt des­halb auch ei­ne Kom­man­do­zei­len-​Ver­sion von put­ty na­mens plink, die sehr gut in Scripts ein­ge­setzt wer­den kann. plink kann SSH-​Ver­bin­dun­gen ini­ti­ie­ren und nach dem Log­in auf dem ent­fern­ten Rech­ner Be­feh­le aus­füh­ren. Ist plink im Ver­zeich­nis c:\program­me\put­ty in­stal­liert, so wird mit dem Kom­man­do

C:\>c:\pro­gram­me\plink -ssh 192.168.20.249 -l shut­down -pw ge­heim \
  /sbin/shut­down -h now

Fol­gen­des er­reicht: plink ver­sucht, ei­ne SSH-​Ver­bin­dung zu 192.168.20.249 auf­zu­bau­en und dort den Be­fehl "/sbin/shut­down -h now" aus­zu­füh­ren, bei­des im Na­men des Be­nut­zers "shut­down" mit dem Paß­wort "ge­heim". Wir ge­hen un­ten noch da­rauf ein, wel­che Schwie­rig­kei­ten auf der Li­nux-​Sei­te der Aus­füh­rung die­ses Be­fehls im We­ge ste­hen kön­nen.

Für obi­gen Code gilt üb­ri­gens: Der Back­slash (\) wird als Zei­chen für die Zei­len­fort­set­zung ge­braucht. Steht der Back­slash als letz­tes Zei­chen ei­ner Zei­le, so ist er beim Ab­tip­pen des Kom­man­dos er­satz­los weg­zu­las­sen und die näch­ste Zei­le oh­ne Zei­len­um­bruch und oh­ne füh­ren­de Leer­zei­chen an­zu­hän­gen. Obi­ges Bei­spiel be­steht dem­nach in Wirk­lich­keit aus ei­ner ein­zi­gen Zei­le (die al­ler­dings zu lan­ge ist für den zur Ver­fü­gung ste­hen­den Platz). Wir wer­den dies im gan­zen Ar­ti­kel so hand­ha­ben.

Win­dows: Ver­wal­tung der SSH-​Schlüs­sel

Wir kom­men nicht um­hin, kurz auf die Ver­wal­tung von SSH-​Schlüs­seln durch put­ty und plink ein­zu­ge­hen. Der Grund da­für wird in den fol­gen­den Ka­pi­teln er­sicht­lich.

Ei­ne SSH-​Ver­bin­dung wird (aus Sicht des An­wen­ders am Cli­ent) auf ei­ne der fol­gen­de Ar­ten auf­ge­baut: Durch di­rek­te An­ga­be von Be­nut­zer­na­me und Paß­wort, durch Über­sen­dung ei­nes elek­tro­ni­schen Zer­ti­fi­kats an den Ser­ver, oder durch au­to­ma­ti­sche Ab­ho­lung der be­nö­tig­ten Log­in-​Da­ten oder Zer­ti­fi­ka­te aus ei­ner In­fra­struk­tur für Au­then­ti­fi­zie­rung und Be­rech­ti­gung (Ac­tive Di­rec­to­ry, SSH-​Agent, Ra­di­us-​Ser­ver) und Über­sen­dung an den Ser­ver.

In der über­wäl­ti­gen­den Mehr­zahl al­ler Fäl­le kommt in KMUs die er­ste Va­ri­an­te zum Ein­satz, weil da­für kei­ne Zer­ti­fi­ka­te ver­wal­tet wer­den müs­sen, weil kei­ne zen­tra­le Au­then­ti­fi­zie­rungs-​In­fra­struk­tur auf­ge­baut oder er­wei­tert wer­den muß, und weil sie ho­he Si­cher­heit bie­tet, zu­min­dest bei Ver­wen­dung von SSH2 als Pro­to­koll und sorg­fäl­ti­gem Um­gang mit den öf­fent­li­chen Schlüs­seln der SSH-​Ser­ver.

In al­len Fäl­len wird die Ver­bin­dung un­ter Ein­satz asym­me­tri­scher Ver­schlüs­se­lung auf­ge­baut. Da­bei tau­schen Client und Ser­ver un­ter an­de­rem öf­fent­li­che Schlüs­sel aus, an­hand de­rer bei­de Ma­schi­nen zu­ver­läs­sig iden­ti­fi­ziert wer­den kön­nen. Die­se Iden­ti­fi­zie­rung ist vor al­lem für die Cli­ent-​Sei­te, al­so den An­wen­der, aus fol­gen­dem Grund sehr wich­tig:

Ge­lingt es ei­nem An­grei­fer, ei­nen An­wen­der auf ei­nen prä­pa­rier­ten SSH-​Ser­ver zu lo­cken (an­stel­le des­je­ni­gen, mit dem sich der An­wen­der ei­gent­lich ver­bin­den woll­te), bei­spiels­wei­se durch ARP-​Spoo­fing oder DNS-​Ma­ni­pu­la­tio­nen, so könn­ten dort die Log­in-​Da­ten des An­wen­ders ab­ge­grif­fen wer­den. Wel­che Kon­se­quen­zen sich da­raus er­ge­ben, hängt von der Art der An­mel­dung (Log­in / Paß­wort oder Zer­ti­fi­kat) und von wei­te­ren Pa­ra­me­tern ab.

Aus die­sem Grund ge­ben put­ty und plink ei­ne War­nung aus, wenn sie ei­ne SSH-​Ver­bin­dung zu ei­nem bis­lang un­be­kann­ten Ser­ver auf­bau­en sol­len. Im Warn­hin­weis ist un­ter an­de­rem der Hash-​Wert des öf­fent­li­chen Schlüs­sels des Ser­vers ent­hal­ten, der den Schlüs­sel ein­deu­tig iden­ti­fi­ziert. Der An­wen­der kann die Iden­ti­tät des Ser­vers an­hand des Hash-​Wer­tes prü­fen, so­fern ihm der kor­rek­te Hash-​Wert vor­ab mit­ge­teilt wor­den ist. Nach Be­stä­ti­gung der War­nung durch den An­wen­der spei­chern plink und put­ty den Hash-​Wert, so daß bei zu­künf­ti­gen Ver­bin­dun­gen zum sel­ben Ser­ver kei­ne Nach­fra­ge mehr er­folgt; oh­ne Be­stä­ti­gung der War­nung bau­en put­ty und plink die Ver­bin­dung nicht auf.

Von zen­tra­ler Be­deu­tung ist nun, daß put­ty und plink die­se Schlüs­sel nur für den­je­ni­gen Be­nut­zer spei­chern, in des­sen Na­men sie ge­ra­de aus­ge­führt wer­den. Die Schlüs­sel wer­den in der Win­dows-​Re­gis­try im Zweig HKEY_CUR­RENT_USER\... ab­ge­legt [Link]. Die­ses Vor­ge­hen ist sinn­voll, weil sich An­wen­der, die den­sel­ben PC nut­zen, an ver­schie­de­ne SSH-​Ser­ver ver­bin­den kön­nen und weil des­halb die War­nun­gen vor un­be­kann­ten Ser­vern pro An­wen­der er­fol­gen soll­ten.

Im Zu­sam­men­spiel mit den an­de­ren für un­ser Pro­jekt be­nö­tig­ten Soft­ware-​Kom­po­nen­ten kön­nen da­durch je­doch un­er­war­te­te Prob­le­me ent­ste­hen, de­ren Na­tur und Lö­sung un­ten be­schrie­ben wird.

Li­nux: Hin­der­nis­se beim shut­down

Na­he­zu je­des Li­nux-​Sy­stem stellt auf der Kom­man­do­zei­le ei­nen Be­fehl zum He­run­ter­fah­ren des Sy­stems zur Ver­fü­gung. Es han­delt sich da­bei um ein ei­gen­stän­di­ges Pro­gramm, meist mit dem Na­men shut­down und oft im Ver­zeich­nis /sbin be­hei­ma­tet.

Die­ses Pro­gramm ist in der Re­gel pri­vi­le­giert: Es kann nur vom Su­per­user aus­ge­führt wer­den, nicht von re­gu­lä­ren Be­nut­zern [Link]. shut­down über­prüft bei sei­nem Auf­ruf, von wem es auf­ge­ru­fen wur­de, und stellt ge­ge­be­nen­falls sei­ne Tä­tig­keit mit ei­ner ent­spre­chen­den Feh­ler­mel­dung ein (bei­spiels­wei­se "You must be root to do this") [Link].

Dies ist sinn­voll, denn an­dern­falls könn­te je­der Be­nut­zer, der Zu­gang zu ei­nem Li­nux-​Sy­stem hat, die­ses ab­sicht­lich oder aus Ver­se­hen he­run­ter­fah­ren und da­mit viel Är­ger ver­ur­sa­chen.

Hier al­ler­dings ist das ge­nann­te Ver­hal­ten hin­der­lich. Wie oben ge­zeigt, soll von Win­dows aus per plink ei­ne SSH-​Ver­bin­dung zum Li­nux-​Ser­ver auf­ge­baut und dort der Be­fehl zum He­run­ter­fah­ren ab­ge­setzt wer­den. Da­zu muß plink auf ent­spre­chen­de Log­in-​Da­ten zu­grei­fen, die als Kom­man­do­zei­len-​Pa­ra­me­ter di­rekt beim Auf­ruf an plink über­ge­ben (wie in obi­gem Bei­spiel) oder auf an­de­re Wei­se auf dem Win­dows-​Sy­stem hin­ter­legt wer­den müs­sen.

Der SSH-​Log­in auf dem Li­nux-​Sy­stem und die Aus­füh­rung von shut­down er­fol­gen dann im Na­men des ent­spre­chen­den Be­nut­zers. Nun wird kein Li­nux-​Ad­mi­ni­stra­tor die Zu­gangs­da­ten des Su­per­users für sein Sy­stem he­raus­ge­ben, erst recht nicht für den Zweck der Hin­ter­le­gung in Scripts auf Win­dows-​Ma­schi­nen. Dies be­deu­tet Ar­beit auf der Li­nux-​Sei­te:

Zu­nächst emp­fiehlt es sich, dort ex­clu­siv für den hier ge­schil­der­ten Zweck ei­nen neu­en Be­nut­zer mit Stan­dard­rech­ten und dem Be­nut­zer­na­men "shut­down" an­zu­le­gen; des­sen Paß­wort soll­te wie im­mer nicht zu er­ra­ten sein. Die Log­in-​Da­ten die­ses Be­nut­zers kön­nen auf Win­dows-​Sei­te be­den­ken­los hin­ter­legt wer­den, weil er auf dem Li­nux-​Sy­stem kei­ne be­son­de­ren Zu­griffs­rech­te be­sitzt.

Ge­nau dies be­wirkt aber, daß die Aus­füh­rung von shut­down durch die­sen Be­nut­zer zu­nächst schei­tert. Es gibt meh­re­re Lö­sun­gen für die­ses Prob­lem, von de­nen zwei hier kurz vor­ge­stellt wer­den sol­len.

Lö­sun­gen ...

Die schnell­ste (und un­sau­ber­ste) Lö­sung be­steht darin, den Su­per­user zum Be­sit­zer des Pro­gramms /sbin/shut­down zu ma­chen und den Be­rech­ti­gun­gen für die­se Da­tei das set­uid-​Bit hin­zu­zu­fü­gen. Er­ste­res ist in der Stan­dard-​In­stal­la­ti­on von Li­nux meist oh­ne­hin der Fall, Letz­te­res be­deu­tet, daß das Pro­gramm stets im Na­men des Be­nut­zers aus­ge­führt wird, der es be­sitzt, und nicht im Na­men des Be­nut­zers, der es auf­ruft [Link].

Da­mit ist ein gra­vie­ren­der Nach­teil die­ser Lö­sung klar: Je­der Be­nut­zer, der Shell-​Zu­gang auf dem Sy­stem hat, könn­te das Sy­stem he­run­ter­fah­ren, weil /sbin/shut­down nun im­mer im Na­men des Su­per­users aus­ge­führt wird. Falls /sbin/shut­down zu­dem auf­grund von Ab­sicht oder auf­grund ei­ner Si­cher­heits­lü­cke in der La­ge wä­re, Da­tei­en zu ma­ni­pu­lie­ren, so könn­te je­der Be­nut­zer, der es auf­ru­fen kann, ent­spre­chen­de Ma­ni­pu­la­tio­nen mit al­len Be­rech­ti­gun­gen des Su­per­users durch­füh­ren.

Die­se Lö­sung kann sehr ein­fach im­ple­men­tiert wer­den:

fen­rir:/# ls -l /sbin/shut­down
-rwxr-xr-x 1 root root 18196 2008-08-12 16:09 /sbin/shut­down
fen­rir:/# chmod u+s /sbin/shut­down
fen­rir:/# ls -l /sbin/shut­down
-rwsr-xr-x 1 root root 18196 2008-08-12 16:09 /sbin/shut­down

Ei­ne weit bes­se­re, aber et­was auf­wen­di­ge­re Lö­sung be­steht in der Nut­zung des su­do-​Me­cha­nis­mus. Die­ser Me­cha­nis­mus er­laubt es, ge­nau zu kon­fi­gu­rie­ren, wel­cher Be­nut­zer wel­ches Pro­gramm in wes­sen Na­men aus­füh­ren darf. Auf die Kon­fi­gu­ra­tion des su­do-​Me­cha­nis­mus kann hier nicht de­tail­liert ein­ge­gan­gen wer­den, aber nach Stu­di­um der ent­spre­chen­den Hand­bü­cher soll­ten kei­ne un­über­wind­ba­ren Prob­le­me da­bei auf­tre­ten.

So könn­te dem Be­nut­zer shut­down die Be­rech­ti­gung er­teilt wer­den, aus­schließ­lich das Pro­gramm /sbin/shut­down im Kon­text der Su­per­user-​Iden­ti­tät aus­zu­füh­ren. Der Be­nut­zer shut­down könn­te da­nach das Sy­stem auf fol­gen­de Wei­se he­run­ter­fah­ren:

fen­rir:/# su­do /sbin/shut­down -h now

Zur Durch­füh­rung der ge­nann­ten Än­de­run­gen an den Da­tei­at­tri­bu­ten von /sbin/shut­down oder der Kon­fi­gu­ra­tion des su­do-​Me­cha­nis­mus wer­den Su­per­user-​Rech­te be­nö­tigt. Even­tu­ell muß der Ad­mi­ni­stra­tor des Li­nux-​Sy­stems die ge­wünsch­ten Än­de­run­gen durch­füh­ren.

Im Rah­men un­se­res Pro­jekts ha­ben wir uns für die Va­ri­an­te 1) ent­schie­den. Beim be­tref­fen­den Kun­den ist si­cher­ge­stellt, daß au­ßer dem Ad­mi­ni­stra­tor (und dem neu­en Be­nut­zer "shut­down") kei­ne an­de­ren Be­nut­zer Shell-​Zu­gang auf das Sy­stem ha­ben oder auf son­sti­ge Wei­se Pro­gram­me star­ten kön­nen. An­dern­falls hät­ten wir Va­ri­an­te 2) ge­wählt.

... und Irr­we­ge

Ei­ne wei­te­re Idee wä­re, die Su­per­user-​Grup­pe zum Be­sit­zer des Pro­gramms shut­down zu ma­chen und des­sen Aus­füh­rungs­be­rech­ti­gun­gen als set­gid zu set­zen. Er­ste­res ist bei ei­ner Stan­dard-​In­stal­la­ti­on von Li­nux wie­de­rum meist be­reits der Fall, Letz­te­res be­deu­tet, daß das Pro­gramm mit den Be­rech­ti­gun­gen der Grup­pe aus­ge­führt wird, die es be­sitzt, und nicht im Na­men der Grup­pe, der der Be­nut­zer an­ge­hört, der es auf­ruft.

Von die­sem Vor­ge­hen ist drin­gend ab­zu­ra­ten:

Er­stens bringt es schlicht nicht den ge­wünsch­ten Er­folg. Bei un­se­ren Tests auf ei­ner Stan­dard-​In­stal­la­ti­on von De­bian Len­ny hat sich /sbin/shut­down ge­wei­gert, sei­ne Ar­beit zu tun, so­fern es nicht vom Su­per­user auf­ge­ru­fen wur­de. Dies galt auch, wenn die aus­führ­ba­re Da­tei auf set­gid ge­setzt war und der auf­ru­fen­de Be­nut­zer der Su­per­user-​Grup­pe an­ge­hör­te.

Zwei­tens müß­te der Be­nut­zer, der das Pro­gramm aus­füh­ren kön­nen soll, noch der Su­per­user-​Grup­pe hin­zu­ge­fügt wer­den. Zwar könn­te dann nicht mehr je­der Be­nut­zer mit Shell-​Zu­gang das Sy­stem he­run­ter­fah­ren, aber der be­tref­fen­de Be­nut­zer er­hiel­te Su­per­user-​Rech­te auf ei­nen Teil des Sy­stems, da er nun zur Su­per­user-​Grup­pe ge­hör­te und die­je­ni­gen Tei­le des Sy­stems le­sen und ma­ni­pu­lie­ren könn­te, auf die die­se Grup­pe Zu­griffs­rech­te be­sitzt.

Der Voll­stän­dig­keit hal­ber sei trotz­dem die Im­ple­men­tie­rung die­ser Lö­sung ge­zeigt:

fen­rir:/# ls -l /sbin/shut­down
-rwxr-xr-x 1 root root 18196 2008-08-12 16:09 /sbin/shut­down
fen­rir:/# chmod g+s /sbin/shut­down
fen­rir:/# ls -l /sbin/shut­down
-rwxr-sr-x 1 root root 18196 2008-08-12 16:09 /sbin/shut­down
fen­rir:/# user­mod -g root shut­down

Eben­falls ins Lee­re führt der oft ge­le­se­ne Rat [Link], die Da­tei /etc/shut­down.al­low an­zu­le­gen und den shut­down-​Ein­trag in /etc/init­tab auf be­stimm­te Wei­se zu än­dern: Dies hat nur Aus­wir­kun­gen, wenn der Rech­ner durch ei­nen Af­fen­griff an der lo­ka­len Kon­so­le he­run­ter­ge­fah­ren wer­den soll. Beim Auf­ruf von /sbin/shut­down auf der Kom­man­do­zei­le in ei­ner Shell ha­ben we­der der Pa­ra­me­ter -a noch die Da­tei /etc/shut­down.al­low ir­gend­ei­nen Ein­fluß [Link].

Er­ste Tests

Ab hier ge­hen wir da­von aus, daß /sbin/shut­down auf dem Li­nux-​Sy­stem als set­uid ge­setzt ist. Le­ser, die sich statt­des­sen für die Nut­zung des su­do-​Me­cha­nis­mus ent­schie­den ha­ben, müs­sen den Be­feh­len, die auf der Li­nux-​Sei­te aus­ge­führt wer­den, je­weils den su­do-​Be­fehl vo­ran­stel­len. Dies gilt nicht nur für die fol­gen­den Bei­spie­le, son­dern auch für die spä­ter ge­zeig­ten Batch-​Da­tei­en.

Star­ten Sie nun auf dem Win­dows-​Ser­ver put­ty und bau­en Sie ei­ne SSH-​Ver­bin­dung zu Ih­rem Li­nux-​Ser­ver auf, wo­bei Sie die Log­in-​Da­ten des Be­nut­zers shut­down ver­wen­den. Wenn Sie jetzt Be­feh­le (wie "date") ein­ge­ben kön­nen und die­se ei­ne sinn­vol­le Aus­ga­be (wie das ak­tu­el­le Da­tum) lie­fern, fah­ren Sie mit dem näch­sten Test fort.

Miß­lingt der Ver­bin­dungs­auf­bau oder er­hal­ten Sie kei­ne Mög­lich­keit zur Ein­ga­be, so liegt der Feh­ler auf Li­nux-​Sei­te in der Kon­fi­gu­ra­tion des SSH-​Ser­vers, der Be­nut­zer oder der Zu­gangs­sy­ste­me; im Rah­men die­ses Ar­ti­kels kön­nen wir da­rauf nicht ein­ge­hen.

Ver­su­chen Sie nun he­raus­zu­fin­den, wo das shut­down-​Pro­gramm ab­ge­legt ist (meist in /sbin), und füh­ren Sie die­ses Pro­gramm auf fol­gen­de Wei­se aus:

fen­rir:/# /sbin/shut­down -h now

Ach­tung: Das Li­nux-​Sy­stem soll­te nun he­run­ter­fah­ren. Füh­ren Sie die­sen Test nicht auf Pro­duk­ti­ons­sy­ste­men oder nur zu un­kri­ti­schen Zei­ten aus.

Fährt das Li­nux-​Sy­stem he­run­ter, ge­hen Sie zum näch­sten Test über. An­dern­falls be­ob­ach­ten Sie et­wai­ge Feh­ler­mel­dun­gen und ver­su­chen Sie zu er­mit­teln, ob der Be­nut­zer shut­down wirk­lich die Be­rech­ti­gung zum He­run­ter­fah­ren des Sy­stems be­sitzt.

Star­ten Sie jetzt un­ter Win­dows die Kom­man­do­zei­le und ge­ben Sie den be­reits oben ge­zeig­ten Code ein, wo­bei Sie die IP-​Ad­res­se und das Paß­wort an Ih­re Ge­ge­ben­hei­ten an­pas­sen (bit­te be­ach­ten Sie wie­der das Zei­chen zur Zei­len­fort­set­zung):

C:\>c:\pro­gram­me\plink -ssh 192.168.20.249 -l shut­down -pw ge­heim \
  /sbin/shut­down -h now

Wie­der soll­te das Li­nux-​Sy­stem he­run­ter­fah­ren. Ge­schieht dies nicht, so liegt ver­mut­lich ein ein­fa­cher Tipp­feh­ler vor oder ei­ne fal­sche IP-​Ad­res­se vor. Es ist fast un­mög­lich, daß die oben ge­nann­ten Tests mit put­ty das ge­wünsch­te Er­geb­nis lie­fern, die­ser Test je­doch ver­sagt.

Kön­nen Sie mit­hil­fe des oben ge­zeig­ten Co­des Ih­re Li­nux-​Sy­ste­me zu­ver­läs­sig von Win­dows aus he­run­ter­fah­ren, so ist die Kon­fi­gu­ra­tion auf Li­nux-​Sei­te ab­ge­schlos­sen.

Win­dows: Kon­fi­gu­ra­tion von Po­wer­Chu­te Bu­si­ness Edi­ti­on 8.0.1

In­stal­la­ti­on hui, Kon­fi­gu­ra­tion und Do­ku­men­ta­ti­on pfui

Die In­stal­la­ti­on von PBE ist un­prob­le­ma­tisch. Im Prin­zip wird le­dig­lich ein Dienst in­stal­liert, der Agent ge­nannt wird. Der Agent kom­mu­ni­ziert über ei­ne der oben ge­nann­ten Schnitt­stel­len mit der USV, stellt mit­hil­fe ei­nes in­te­grier­ten Web­ser­vers per HTTP(S) die Ver­bin­dung zur Au­ßen­welt her, so daß die Ab­fra­ge von In­for­ma­tio­nen und die Kon­fi­gu­ra­tion mit­hil­fe ei­nes Brow­sers mög­lich sind, und führt beim Ein­tre­ten be­stimm­ter Er­eig­nis­se Ak­tio­nen aus, die die­sen zu­ge­ord­net wor­den sind.

Als wi­der­spen­stig er­weist sich hin­ge­gen die Kon­fi­gu­ra­ti­on. Das Kon­zept ist um­ständ­lich, die Hil­fe­tex­te auf der Kon­fi­gu­ra­ti­ons­ober­flä­che nicht vor­han­den oder auf dem Ni­veau der Hil­fe­tex­te ei­nes ty­pi­schen PC-​BIOS ("Choose Yes to en­able the op­tion; Choose No to dis­ab­le the op­tion"). Die Do­ku­men­ta­ti­on ist ei­ne Un­ver­schämt­heit, nir­gends las­sen sich die grund­le­gen­den und so wich­ti­gen In­for­ma­tio­nen zum Zu­sam­men­spiel der zeit­li­chen Ab­läu­fe zwi­schen den nor­ma­len Er­eig­nis­sen und dem Shut­down-​Vor­gang fin­den. Glei­ches gilt für die Web­site des Her­stel­lers.

Es ist ge­ra­de­zu ein Ar­muts­zeug­nis für APC, daß über­dies ei­ni­ge Hil­fe­tex­te auf den Kon­fi­gu­ra­tions­sei­ten und Stel­len in der Do­ku­men­ta­ti­on gra­vie­ren­de Feh­ler auf­wei­sen. Do­ku­men­ta­ti­on für in hoch­sen­sib­len Be­rei­chen ein­zu­set­zen­de Ge­rä­te ei­nes Her­stel­lers, der das pro­fes­sio­nel­le Um­feld be­die­nen möch­te, hat wahr­lich an­ders aus­zu­se­hen.

Dies ist ein gro­ßes Prob­lem:

Der Ad­mi­ni­stra­tor muß sich in mü­he­vol­ler Klein­ar­beit selbst her­lei­ten, auf wel­che Wei­se der Agent wohl be­rech­net, ob die ge­wähl­te Kon­fi­gu­ra­tion der Er­eig­nis­se und des Shut­down-​Vor­gangs zu­läs­sig ist, ob al­so die Ka­pa­zi­tät der Bat­te­rien die kon­fi­gu­rier­ten zeit­li­chen Ab­fol­gen und Zeit­span­nen über­haupt er­laubt. Na­tür­lich muß die er­ar­bei­te­te Ver­mu­tung dann in wei­te­rer zeit­in­ten­si­ver, zer­mür­ben­der Klein­ar­beit gründlich ge­te­stet wer­den; schließ­lich geht es hier um die Kon­fi­gu­ra­tion der Le­bens­ver­si­che­rung für das wert­voll­ste Gut ei­nes Un­ter­neh­mens, näm­lich sei­ne Da­ten.

Fer­ner kann die Be­ach­tung falscher Aus­sa­gen im Hand­buch und der Hil­fe den Arg­lo­sen zu ei­nem im ent­schei­den­den Au­gen­blick ver­sa­gen­den USV-​Sy­stem füh­ren.

Wir wer­den des­halb im fol­gen­den das Soft­ware-​Kon­zept grob er­klä­ren und auf ei­nen schlim­men Feh­ler in der Do­ku­men­ta­ti­on hin­wei­sen. So­bald Sie die hier vor­ge­stell­te Kon­fi­gu­ra­tion ver­än­dern möch­ten, sind gründ­li­che Tests mit mög­lichst vie­len Feh­ler­si­tua­tio­nen un­er­läß­lich. Es ist wahr­schein­lich, daß die Do­ku­men­ta­ti­on noch wei­te­re schwe­re Feh­ler ent­hält.

Shut­down und Er­eig­nis­se

In der Ter­mi­no­lo­gie von PBE ist mit dem Be­griff Shut­down nicht nur das He­run­ter­fah­ren des Ser­vers ge­meint, son­dern der Shut­down um­faßt den ge­sam­ten Pro­zeß vom He­run­ter­fah­ren des Be­triebs­sy­stems bis zum Ab­schal­ten der USV.

Selbst­ver­ständ­lich kann kon­figu­riert wer­den, un­ter wel­chen Be­din­gun­gen der Shut­down aus­ge­löst wird und in wel­cher zeit­li­chen Ab­fol­ge die ver­schie­de­nen Stu­fen statt­fin­den. Nach sei­nem Start kann der Shut­down even­tu­ell wie­der an­ge­hal­ten wer­den, wenn die aus­lö­sen­den Be­din­gun­gen weg­fal­len. Das Ab­schal­ten der USV am En­de des Shut­down läßt sich nach un­se­rer Kennt­nis nicht ver­hin­dern, es kann aber ein­ge­stellt wer­den, un­ter wel­chen Be­din­gun­gen die USV sich wie­der ein­schal­tet.

Es ist un­se­res Wis­sens nicht mög­lich, dem Agent den Shut­down kom­plett zu un­ter­sa­gen. Die Shut­down-​Se­quenz läßt sich in der Kon­fi­gu­ra­ti­ons­ober­flä­che zwar kon­fi­gu­rie­ren, aber nicht de­ak­ti­vie­ren. Daß dies so auch sinn­voll ist, zeigt der näch­ste Ab­schnitt.

We­sent­lich uni­ver­sel­ler kön­nen Er­eig­nis­se ver­wen­det wer­den. Prak­tisch für je­des Er­eig­nis, das wäh­rend des Be­triebs ei­ner USV auf­tre­ten kann, kann fest­ge­legt wer­den, wel­che Be­nach­rich­ti­gun­gen und Ak­tio­nen es nach sich zie­hen soll. Da als Ak­tion auch die Aus­füh­rung ei­nes Pro­gram­mes mög­lich ist, steht ein mäch­tiges Sy­stem zur in­di­vi­du­el­len Kon­fi­gu­ra­tion zur Ver­fü­gung. Des­sen Nut­zung wird al­ler­dings durch die in­dis­ku­tab­le Do­ku­men­ta­ti­on er­schwert.

Kein Er­eig­nis muß zwin­gend mit ei­ner Ak­tion ver­bun­den wer­den.

Be­trach­tet man das Ge­samt­sy­stem et­was ab­strak­ter, so kann der Shut­down als ei­ne Ak­tion be­trach­tet wer­den, die ei­nem Er­eig­nis "Shut­down" zu­ge­ord­net ist, das sich von den an­de­ren Er­eig­nis­sen in ei­ni­gen Punk­ten un­ter­schei­det: Es ist nicht in der Li­ste der Er­eig­nis­se ent­hal­ten, son­dern wird über ei­ge­ne Me­nüs kon­fi­gu­riert, und es ist zwin­gend min­de­stens mit der Ak­tion "Shut­down" ver­bun­den.

Aus die­ser Sicht er­scheint es na­tür­lich, daß auch der Ein­tritt des Er­eig­nis­ses "Shut­down" mit dem Ver­sand von Be­nach­rich­ti­gun­gen oder dem Auf­ruf von Pro­gram­men ver­bun­den wer­den kann. Daß dies für das Ge­lin­gen man­chen Pro­jekts ent­schei­dend ist, wird im näch­sten Ab­schnitt klar.

Grund­prin­zip der Kon­fi­gu­ra­tion

Un­ser Ziel be­stand zu­nächst darin, da­für zu sor­gen, daß bei Ein­tritt ei­nes Strom­aus­falls die bei­den Li­nux-​ und der Win­dows-​Ser­ver nach we­ni­gen Mi­nu­ten he­run­ter­ge­fah­ren wür­den. Die ma­xi­mal mög­li­che Lauf­zeit der USV soll­te da­bei nur zu ei­nem ge­rin­gen Teil ge­nutzt und die USV nach dem He­run­ter­fah­ren der Ser­ver nicht ab­ge­schal­tet wer­den.

Bei­des dien­te dem Zweck, an­de­re wich­ti­ge Klein­ge­rä­te, die eben­falls von der USV ver­sorgt wur­den, mög­lichst lan­ge funktionsfähig zu hal­ten, da­run­ter ei­ne klei­ne Te­le­fon­an­la­ge, ein DSL-​Rou­ter und ein Ether­net-​Switch. Da ein re­gu­lä­rer Shut­down oh­ne an­schlie­ßen­de Ab­schal­tung der USV nicht mög­lich war, ha­ben wir dies über die Zu­ord­nung ei­nes Scripts zu ei­nem ge­eig­ne­ten Er­eig­nis rea­li­siert.

Da­bei han­delt es sich um ein Er­eig­nis, wel­ches ein­tritt, so­bald die USV die an­ge­schlos­se­nen Ver­brau­cher für ei­ne be­stimm­te Zeit lang un­un­ter­bro­chen aus ih­ren Bat­te­rien ver­sorgt hat, im all­ge­mei­nen al­so zu ei­nem be­stimm­ten Zeit­punkt nach Ein­tritt ei­nes Strom­aus­falls, so­fern in der Zwi­schen­zeit die re­gu­lä­re Strom­ver­sor­gung nicht wie­der­ge­kehrt ist.

Mit die­sem Vor­ge­hen al­lei­ne blie­ben je­doch be­stimm­te Son­der­si­tua­tio­nen un­be­han­delt, von de­nen ei­ne exem­pla­risch ge­nannt wer­den soll:

Wür­de die USV, et­wa auf­grund rhyth­mi­scher Strom­aus­fäl­le, wie­der­holt zwi­schen Bat­te­rie­ver­sor­gung und re­gu­lä­rem Be­trieb um­schal­ten, so könn­ten sich ih­re Bat­te­rien ent­lee­ren, oh­ne daß das Script aus­ge­führt wür­de, al­so oh­ne daß die von der USV ver­sorg­ten Ser­ver he­run­ter­ge­fah­ren wür­den.

Das er­wähn­te Er­eig­nis, von dem das Script ak­ti­viert wird, tritt näm­lich wie ge­schil­dert erst ein, wenn die USV für ei­ne be­stimm­te Zeit un­un­ter­bro­chen im Bat­te­rie­be­trieb ar­bei­tet; die Bat­te­rien wer­den bei auf­ein­an­der­fol­gen­den, kur­zen Strom­aus­fäl­len je­doch ge­nau­so ent­leert wie bei ei­nem ein­zi­gen mit ins­ge­samt gleicher Zeit­dau­er. Dies gilt zu­min­dest, wenn zwi­schen den Strom­aus­fäl­len nicht ge­nü­gend Zeit zum Wie­der­auf­la­den der Bat­te­rien liegt.

Der fol­gen­de Me­cha­nis­mus wür­de die­ses und al­le wei­te­ren Prob­le­me ähn­li­cher Na­tur zu­ver­läs­sig lö­sen: Das He­run­ter­fah­ren al­ler von der USV ver­sorg­ten Ser­ver wä­re ein­zu­lei­ten, so­bald die Rest­lauf­zeit der Bat­te­rien ein ge­wis­ses Maß un­ter­schrit­te. Ge­nau dies ist nun aber das Kri­te­ri­um, auf­grund des­sen der Agent das im vor­he­ri­gen Ab­schnitt er­wähn­te Er­eig­nis "Shut­down" aus­löst.

Da­mit ist ein si­che­rer USV-​Be­trieb mög­lich: Zu­nächst ist die für den Shut­down be­nö­tig­te Zeit für je­den der von der USV ver­sorg­ten Ser­ver un­ter Worst-​Case-​Be­din­gun­gen zu er­mit­teln und da­rauf ein ge­wis­ses Si­cher­heits­pol­ster auf­zu­schla­gen. Dann wird der Shut­down so kon­fi­gu­riert, daß daß er so früh be­gon­nen wird, daß die Rest­lauf­zeit der Bat­te­rien auf je­den Fall zum voll­stän­di­gen He­run­ter­fah­ren al­ler an­ge­schlos­se­nen Ser­ver ge­nügt.

Das Prin­zip un­se­rer Kon­fi­gu­ra­tion läßt sich so be­schrei­ben: Es gibt zwei Er­eig­nis­se, die bei­de zum He­run­ter­fah­ren der Ser­ver füh­ren. Das er­ste die­ser Er­eig­nis­se tritt ein, so­bald die USV die an­ge­schlos­se­nen Ver­brau­cher für ei­ne be­stimm­te Zeit un­un­ter­bro­chen aus ih­ren Bat­te­rien ver­sorgt hat; das zwei­te tritt ein, wenn die USV im Bat­te­rie­be­trieb ar­bei­tet und die ver­blei­ben­de Stütz­zeit un­ter die zum Shut­down al­ler Ser­ver be­nö­tig­te Zeit sinkt.

Ger­ne hät­ten wir hier­für aus­schließ­lich das zwei­te Er­eig­nis ver­wen­det, weil es oh­ne­hin nicht de­ak­ti­viert wer­den kann, aus den oben ge­nann­ten Grün­den un­ver­zicht­bar ist und für den ge­nann­ten Zweck aus­rei­chen wür­de. Lei­der ist es aber un­wei­ger­lich mit der kom­plet­ten Ab­schal­tung der USV am En­de des Shut­down ver­bun­den; zu­min­dest wir ha­ben kei­nen Weg ge­fun­den, die­se zu ver­hin­dern.

Aus die­sem Grund ha­ben wir zu­sätz­lich das er­ste Er­eig­nis ver­wen­det, das dem Shut­down vor­ge­schal­tet ist, des­halb in al­ler Re­gel ei­nen Strom­aus­fall ab­fängt und nicht zwangs­wei­se die Ab­schal­tung der USV nach sich zieht. Der Shut­down wird da­mit nur noch in ei­ner der oben ge­nann­ten, sehr un­wahr­schein­li­chen Son­der­si­tua­tio­nen ein­tre­ten; der ein­zi­ge Scha­den be­steht dann in der Ab­schal­tung der USV am En­de. De facto ist die­ser Fall bis­lang noch nie ein­ge­tre­ten.

Fall­stri­cke

Das oben ge­schil­der­te Sy­stem ver­sagt nur noch in ei­ner ein­zi­gen Si­tua­ti­on, näm­lich wenn die USV samt der von ihr ver­sorg­ten Ser­ver mit Bat­te­rien ge­star­tet wird, de­ren Ka­pa­zi­tät nicht mehr zur voll­stän­di­gen Durch­füh­rung des Shut­down-​Vor­gangs aus­reicht, und wenn un­mit­tel­bar nach dem Start ein Strom­aus­fall auf­tritt. Dies kann pas­sie­ren, wenn die USV von vorn­he­rein un­ter­di­men­sio­niert ist oder mit teil­ent­leer­ten oder nach lan­ger Nicht­be­nut­zung ge­schwäch­ten Bat­te­rien ge­star­tet wird.

Ei­ne Schwä­chung der Bat­te­rien wäh­rend des re­gu­lä­ren Be­triebs stellt hin­ge­gen kein Prob­lem dar. Sinkt die Rest­lauf­zeit un­ter den be­nö­tig­ten Wert, so tre­ten wei­te­re Er­eig­nis­se ein, die zu Ein­trä­gen im Log des Agent oder zum Ver­sand ent­spre­chen­der Be­nach­rich­ti­gun­gen füh­ren kön­nen, so daß der Ad­mi­ni­stra­tor auf al­tern­de Bat­te­rien und sich ver­kür­zen­de Rest­lauf­zeit zeit­nah auf­merk­sam wird.

Um dies zu lei­sten, muß der Agent die Bat­te­rie­lauf­zeit ken­nen. Die­se kann bei Kennt­nis der theo­re­ti­schen Ka­pa­zi­tät der Bat­te­rien und de­ren Ent­la­de­kur­ven aus der zu be­die­nen­den Ge­samt­last er­rech­net wer­den, die der Agent je­der­zeit von der USV ab­fra­gen kann. Der so er­mit­tel­te Wert kann je nach Al­ter und Gü­te der Bat­te­rien al­ler­dings von der Rea­li­tät ab­wei­chen [Link]; dies gilt auch, wenn an­stel­le der vom Her­stel­ler emp­foh­le­nen Bat­te­rien Bil­lig­mo­del­le von Dritt­her­stel­lern ver­wen­det wer­den.

Des­halb soll­te ein­mal bis zwei­mal pro Jahr ei­ne Lauf­zeit­ka­li­brie­rung der USV vor­ge­nom­men wer­den, eben­so nach grö­ße­ren Än­de­run­gen der Ge­samt­last, die die USV zu be­die­nen hat. Bei die­sem Vor­gang ver­sorgt die USV die an­ge­schlos­se­nen Ge­rä­te so lan­ge wie mög­lich aus ih­ren Bat­te­rien, schal­tet (hof­fent­lich) kurz vor der Ent­lee­rung der Bat­te­rien wie­der auf die re­gu­lä­re Span­nungs­ver­sor­gung um und merkt sich die ge­mes­se­ne ma­xi­ma­le Stütz­zeit.

Die Be­la­stung der Bat­te­rien ist da­bei sehr hoch, weil die­se fast ent­la­den wer­den [Link]; der Vor­gang soll­te des­halb nicht ge­ra­de wö­chent­lich durch­ge­führt wer­den. Aus na­he­lie­gen­den Grün­den soll­te auch nicht ge­ra­de ein Ge­wit­ter am Him­mel ste­hen, wenn die Lauf­zeit­ka­li­brie­rung ge­star­tet wird.

Die Her­stel­lung ei­ner Worst-​Case-​Si­tua­ti­on für die Be­rech­nung der be­nö­tig­ten Zeit zum Shut­down kann sich als kom­ple­xes Un­ter­fan­gen er­wei­sen. Es genügt je­den­falls nicht, auf je­dem der be­tei­lig­ten Ser­ver mög­lichst al­le be­nutz­ten An­wen­dun­gen zu star­ten und dann die zum He­run­ter­fah­ren be­nö­tig­te Zeit zu mes­sen. Viel­mehr muß be­dacht wer­den, daß die zum He­run­ter­fah­ren ei­nes Ser­vers be­nö­tig­te Zeit sich un­ter be­stimm­ten Um­stän­den sig­ni­fi­kant ver­län­gern kann, ge­ra­de wenn et­wa auf­grund ei­nes Strom­aus­falls an­de­re Kom­po­nen­ten der EDV-​In­fra­struk­tur aus­ge­fal­len sind.

So ver­län­gert sich zum Bei­spiel die zum He­run­ter­fah­ren be­nö­tig­te Zeit un­ter man­chen Be­triebs­sy­ste­men schein­bar ins Un­end­li­che, wenn der be­tref­fen­de Ser­ver kei­ne Ant­wor­ten auf DNS-​An­fra­gen mehr er­hält oder sich von noch an­ge­mel­de­ten Cli­ents ver­ab­schie­den möch­te, zu de­nen die Netz­werk­ver­bindung un­ter­bro­chen ist. Wer hier si­cher ge­hen möch­te, kommt um ei­ne gründ­li­che Ana­ly­se der vor­han­de­nen Si­tua­ti­on und um Än­de­rung der Kon­fi­gu­ra­tion an di­ver­sen Stel­len nicht he­rum.

Ein wei­te­res Prob­lem stel­len die enor­men Sprün­ge in der Lei­stungs­auf­nah­me dar, die bei mo­der­nen Ser­vern auf­tre­ten kön­nen. Der Agent kann die ver­blei­ben­de Stütz­zeit der USV nur aus der je­weils ak­tu­el­len Ge­samt­last ab­schät­zen; düm­pelt et­wa ein Ser­ver mit meh­re­ren Pro­zes­so­ren oder Ker­nen zum Zeit­punkt der Ab­fra­ge im Re­gel­be­trieb mit ge­rin­ger Aus­la­stung vor sich hin, so soll­te beim He­run­ter­fah­ren kein Pro­gramm ge­star­tet wer­den, wel­ches al­le Pro­zes­sor­ker­ne, Fest­plat­ten und Spei­cher­mo­du­le voll aus­la­stet, die Lei­stungs­auf­nah­me des Ser­vers ver­dop­pelt und da­mit die Prog­no­se des Agent über die ver­blei­ben­de Stütz­zeit ins Lee­re lau­fen läßt.

Im Ex­trem­fall könn­te dies da­zu füh­ren, daß die USV die Ver­sor­gung der an­ge­schlos­se­nen Ver­brau­cher ab­schal­ten muß, be­vor der be­tref­fen­de Ser­ver kom­plett he­run­ter­ge­fah­ren ist. Da­ge­gen hilft nur ein groß­zü­gi­ger Si­cher­heits­auf­schlag bei der An­ga­be der für den Shut­down be­nö­tig­ten Zeit in der Kon­fi­gu­ra­ti­ons­ober­flä­che des Agent.

Kon­fi­gu­ra­tion der Er­eig­nis­se

Die fol­gen­de Ab­bil­dung zeigt ei­nen klei­nen Aus­schnitt aus der Li­ste der Er­eig­nis­se mit ih­ren zu­ge­ord­ne­ten Ak­tio­nen in der Kon­fi­gu­ra­ti­ons­ober­flä­che des Agent. Sie ge­lan­gen dort­hin, in­dem Sie nach der An­mel­dung in der Kon­fi­gu­ra­ti­ons­ober­flä­che im lin­ken Me­nü "Events", dann "Ac­tions" wäh­len. Aus dem ge­zeig­ten Aus­schnitt ist er­sicht­lich, daß wir für je­des Er­eig­nis al­le zur Ver­fü­gung ste­hen­den Be­nach­rich­ti­gun­gen ak­ti­viert ha­ben:

Ist "Log­ging" ak­ti­viert, so wird das be­tref­fen­de Er­eig­nis in den Logs des Agent auf­ge­zeich­net, die an an­de­rer Stel­le ein­ge­se­hen wer­den kön­nen (lei­der aber nicht in der Er­eig­nis­an­zei­ge von Win­dows).

Ist "No­ti­fi­ca­tion" ak­ti­viert, so wird bei Ein­tritt des be­tref­fen­den Er­eig­nis­ses ei­ne Nach­richt über den Nach­rich­ten­dienst von Win­dows an ei­nen kon­fi­gu­rier­ba­ren Kreis von Emp­fän­gern oder an al­le PCs des be­tref­fen­den Sub­net­zes ge­sen­det; der Nach­rich­ten­dienst muß hier­für auf dem sen­den­den Ser­ver und auf den emp­fan­gen­den PCs lau­fen. Die neue­sten Ver­sio­nen von Win­dows ent­hal­ten die­sen Dienst al­ler­dings nicht mehr, so daß die­se Mög­lich­keit nur mehr sel­ten ge­nutzt wer­den kann.

Ist "E-​mail" ak­ti­viert, so wird bei Ein­tritt des ent­spre­chen­den Er­eig­nis­ses ei­ne E-​Mail an ei­ne kon­fi­gu­rier­b­are Grup­pe von Emp­fän­gern ge­sen­det, wo­für die An­ga­be ei­nes SMTP-​Ser­vers und ei­nes pas­sen­den Be­nut­zer­kon­tos er­for­der­lich ist. Op­tio­nen zur Au­then­ti­fi­zie­rung oder Ver­schlüs­se­lung ste­hen hier nicht zur Ver­fü­gung, even­tu­ell muß al­so ein in­ter­ner SMTP-​Ser­ver ver­wen­det wer­den.

Die Emp­fän­ger­krei­se und SMTP-​Op­tio­nen wer­den glo­bal ein­ge­stellt. Pro Er­eig­nis exi­stie­ren zu­sätz­lich nur we­ni­ge wei­te­re Ein­stel­lun­gen, da­run­ter, wie oft "No­ti­fi­ca­tions" wie­der­holt wer­den sol­len. Die­ses Sy­stem ist gut zu hand­ha­ben, ver­ständ­lich und in der Pra­xis sinn­voll.

Noch wich­ti­ger und in­te­res­san­ter sind die letz­ten bei­den Spal­ten. Ist "Shut­down" ak­ti­viert, so star­tet der Agent bei Ein­tritt des be­tref­fen­den Er­eig­nis­ses den Shut­down. Es ist mög­lich und oft sinn­voll, für kei­nes der Er­eig­nis­se den Shut­down zu ak­ti­vie­ren. Den­noch wird die­ser, un­ab­hän­gig von der Kon­fi­gu­ra­tion der Er­eig­nis­se, un­ter be­stimm­ten Um­stän­den durch­ge­führt. Ge­naue­re Er­läu­te­run­gen hier­zu fin­den sich im vo­ri­gen Ab­schnitt.

Ist "Com­mand" ak­ti­viert, so wird bei Ein­tritt des be­tref­fen­den Er­eig­nis­ses ein Pro­gramm ge­star­tet. Hier­für kann ei­ne be­lie­bi­ge aus­führ­ba­re Da­tei ge­wählt wer­den, al­so auch ein Script. Die­ses muß be­stimm­te An­for­de­run­gen er­fül­len, die wei­ter un­ten er­läu­tert wer­den.

Das Ziel, die drei von der USV ver­sorg­ten Ser­ver he­run­ter­zu­fah­ren, so­bald die USV die­se für ei­ne be­stimm­te Zeit­span­ne un­un­ter­bro­chen aus den Bat­te­rien ver­sorgt hat, kann nun er­reicht wer­den. Als ge­eig­ne­tes Er­eig­nis steht "Time On Bat­te­ry Thre­shold Ex­cee­ded" zur Ver­fü­gung; die­sem wird ein Script zu­ge­ord­net, wel­ches für das He­run­ter­fah­ren der Ser­ver sorgt.

Das ge­nann­te Er­eig­nis wur­de kon­figu­riert wie folgt (es ist nur der hier re­le­van­te Aus­schnitt der Op­tio­nen dar­ge­stellt):

Die bei­den er­sten Op­tio­nen sind selbst­er­klä­rend; als zu star­ten­des Pro­gramm ha­ben wir ein Script ge­wählt, auf des­sen In­halt wir im näch­sten Ab­schnitt ein­ge­hen.

Mit­hil­fe der drit­ten Op­ti­on wird dem Agent mit­ge­teilt, wie lan­ge die Aus­füh­rung die­ses Scripts dau­ern wird. Dies ist nicht die rei­ne Lauf­zeit des Scripts selbst, son­dern die Zeit­span­ne vom Start des Scripts bis zur voll­stän­di­gen Be­en­di­gung al­ler Ak­tio­nen, die von die­sem di­rekt oder in­di­rekt aus­ge­löst wer­den. Un­ter wel­chen Um­stän­den sich die rei­ne Lauf­zeit des Scripts von die­ser Zeit­span­ne un­ter­schei­den kann, wird in näch­sten Ab­schnitt er­läu­tert.

Ein Script be­steht aus ein­zel­nen Kom­man­dos, die der Rei­he nach ab­ge­ar­bei­tet wer­den. Ein Kom­man­do, wel­ches die Lauf­zeit des Scripts nicht spür­bar er­höht, wä­re et­wa das Schrei­ben ei­nes Ein­trags in ei­ne Log­da­tei. Hin­ge­gen wür­de die Lauf­zeit Scripts um meh­re­re Mi­nu­ten er­höht, wä­re da­rin ein Kom­man­do zum Ko­pie­ren ei­ner 20 GB gro­ßen Da­tei ent­hal­ten.

Der Agent be­nö­tigt die An­ga­be der Lauf­zeit, um, auch im re­gu­lä­ren Be­trieb, lau­fend zu be­rech­nen, ob die zur Ver­fü­gung ste­hen­de Rest­lauf­zeit der Bat­te­rien noch den An­for­de­run­gen ge­nügt. Die Min­dest­an­for­de­rung aus Sicht des Agent lau­tet in un­se­rem Fall: Die Rest­lauf­zeit der Bat­te­rien ab dem Start­zeit­punkt des Scripts muß min­de­stens so hoch sein wie die an­ge­ge­be­ne Lauf­zeit des Scripts zu­züg­lich der für den Shut­down (hier ist der Shut­down im Sin­ne des Agent ge­meint) be­nö­tig­ten Zeit.

Dies mag in un­se­rem Fall wi­der­sin­nig er­schei­nen, weil die Ser­ver nach ei­nem Strom­aus­fall in der Re­gel be­reits vom Script he­run­ter­ge­fah­ren wer­den und in­so­fern die Zeit zum Shut­down nicht be­nö­tigt wird. Ge­nau dies kann dem Agent aber nicht be­kannt sein; er be­sitzt kei­ne Mög­lich­keit, das ei­nem Er­eig­nis zu­ge­ord­ne­te aus­führ­ba­re Pro­gramm auf sei­nen Zweck hin zu un­ter­su­chen.

Un­ser Script soll­te meh­re­re Ser­ver he­run­ter­fah­ren, von de­nen auch im schlech­te­sten Fall kei­ner län­ger als 3 Mi­nu­ten hier­für be­nö­tig­te. Da das He­run­ter­fah­ren auf je­dem Ser­ver gleich­zei­tig ge­star­tet wer­den konn­te, ha­ben wir die Aus­füh­rungs­zeit für das Script mit 5 Mi­nu­ten an­ge­ge­ben. Im Üb­ri­gen wur­den auf je­dem der Ser­ver Maß­nah­men ge­trof­fen und ge­te­stet, die un­ge­bühr­li­che Ver­zö­ge­run­gen beim He­run­ter­fah­ren (aus wel­chen Grün­den auch im­mer) ver­hin­dern.

Der Voll­stän­dig­keit hal­ber sei nun exem­pla­risch ei­ner der Feh­ler in der nicht mehr zu un­ter­bie­ten­den Do­ku­men­ta­ti­on be­legt. Die fol­gen­de Ab­bil­dung zeigt ei­nen Aus­schnitt aus der Sei­te zur Kon­fi­gu­ra­tion un­se­res Er­eig­nis­ses "Time On Bat­te­ry Thre­shold Ex­cee­ded", wel­ches ver­mut­lich ei­nes der am häu­fig­sten be­nutz­ten Er­eig­nis­se ist:

Hier wird al­len Ern­stes be­haup­tet, die­ses Er­eig­nis tre­te ein, wenn die USV die an­ge­schlos­se­nen Ge­rä­te aus ih­ren Bat­te­rien ver­sor­ge und die Rest­lauf­zeit der Bat­te­rien un­ter die an­ge­ge­be­ne Zeit­span­ne sin­ke. In Wirk­lich­keit und wie auf­grund des Na­mens zu er­war­ten, tritt das Er­eig­nis je­doch ein, so­bald die USV die an­ge­schlos­se­nen Ge­rä­te für die an­ge­ge­be­ne Zeit­span­ne un­un­ter­bro­chen aus ih­ren Bat­te­rien ver­sorgt hat. In der Re­gel ist dies die Zeit­span­ne seit Ein­tritt ei­nes Strom­aus­falls.

We­he dem Ad­mi­ni­stra­tor, der die­ser Do­ku­men­ta­ti­on glaubt: er wür­de in be­stem Ge­wis­sen hier ei­ne um­so hö­he­re Zeit­span­ne ein­tra­gen, je mehr Si­cher­heit er be­nö­tigt. In Wirk­lich­keit je­doch wür­de da­durch das Er­eig­nis um­so spä­ter ab Auf­tritt des Strom­aus­falls aus­ge­löst und da­mit das sorg­fäl­tig aus­ge­ar­bei­te­te Kon­zept nutz­los.

Kon­fi­gu­ra­tion des Shut­down

Der Un­ter­schied zwi­schen nor­ma­len Er­eig­nis­sen und dem Er­eig­nis "Shut­down" wur­de wei­ter oben be­reits dis­ku­tiert, eben­so die Grün­de da­für, in un­se­rem Fall das Er­eig­nis "Time On Bat­te­ry Thre­shold Ex­cee­ded" zu­sätz­lich zum Er­eig­nis "Shut­down" zu be­nut­zen.

Des­halb ge­hen wir an die­ser Stel­le nur noch kurz auf die Kon­fi­gu­ra­tion des Er­eig­nis­ses "Shut­down" ein. Sie ge­lan­gen dort­hin, in­dem Sie in der Kon­fi­gu­ra­ti­ons­ober­flä­che des Agent in der links be­find­li­chen Me­nü­lei­ste zu­erst "Pro­tect­ed Sy­stem", dann "Shut­down Set­tings" wäh­len, da­nach in der Zu­sam­men­fas­sung rechts un­ten den Link "Con­fig­ure".

Die fol­gen­den Ab­bil­dun­gen zei­gen den re­le­van­ten Teil der Ein­stel­lun­gen:

Der Shut­down wird ge­star­tet, wenn die USV im Bat­te­rie­be­trieb ar­bei­tet und nur noch 20 Mi­nu­ten Lauf­zeit ver­blei­ben ("Run­time Re­mai­ning Thresh­old"). Die Op­ti­on ("Low Bat­te­ry Sig­nal"), üb­ri­gens nicht in der Hil­fe er­wähnt, scheint fest­zu­le­gen, wann das Er­eig­nis "Low Bat­te­ry" aus­ge­löst wird; die­ses ist in der Li­ste der an­de­ren Er­eig­nis­se ent­hal­ten und kann dort wei­ter kon­figu­riert wer­den.

In un­se­rer Kon­fi­gu­ra­tion soll­te "Low Bat­te­ry Sig­nal" kei­ne Rol­le spie­len. Der Aus­lö­se­zeit­punkt wur­de des­halb so ein­ge­stellt, daß es nie ein­tritt, näm­lich auf 10 Mi­nu­ten ver­blei­ben­der Bat­te­rie­lauf­zeit; dies ent­spricht 10 Mi­nu­ten nach Be­ginn des Shut­down, der bis da­hin längst be­en­det sein soll­te.

Aus den oben ge­nann­ten Grün­den be­nö­tigt der Agent die An­ga­be, wie lan­ge der Shut­down dau­ert ("OS Shut­down De­lay"). Hier ist die Zeit­span­ne ein­zu­tra­gen, die das Be­triebs­sy­stem zum He­run­ter­fah­ren be­nö­tigt, oh­ne die Zeit­span­ne, die für die Ab­ar­bei­tung der aus­führ­ba­ren Pro­gram­me be­nö­tigt wird, die dem Shut­down zu­ge­ord­net sind.

Die Op­ti­on "OS Shut­down Ty­pe" legt fest, wie das Be­triebs­sy­stem he­run­ter­ge­fah­ren wer­den soll. Zur Wahl ste­hen der Ru­he­zu­stand und das He­run­ter­fah­ren oh­ne oder mit Aus­schal­ten des Ser­vers.

Mit­hil­fe der näch­sten Op­tio­nen wird fest­ge­legt, wie weit die Bat­te­rien der USV nach ei­nem Shut­down min­de­stens wie­der auf­ge­la­den sein müs­sen, be­vor die USV ih­re Aus­gän­ge wie­der mit Lei­stung be­auf­schlagt ("UPS Turn On Bat­te­ry Ca­pac­i­ty"), wie lan­ge nach dem Er­rei­chen die­ser La­dung da­mit ge­war­tet wer­den soll ("UPS Turn On De­lay"), und ob das Be­triebs­sy­stem des vom Shut­down he­run­ter­ge­fah­re­nen Ser­vers da­nach wie­der au­to­ma­tisch star­ten soll ("En­able OS Re­boot").

Die er­ste die­ser drei Op­tio­nen ist wich­tig, stellt sie doch die ein­zi­ge Mög­lich­keit dar, ein Auf­star­ten mit Bat­te­rien zu ver­mei­den, die von vorn­he­rein nicht ge­nü­gend Stütz­zeit für ei­nen Shut­down lie­fern wür­den; die­ses Prob­lem wur­de in den vor­her­ge­hen­den Ab­schnit­ten be­reits dis­ku­tiert. Wa­rum das Drop-​Down-​Feld für die­se Op­ti­on nur Wer­te bis 90% ent­hält (und so­mit kei­ne Mög­lich­keit be­steht, die USV erst bei voll ge­la­de­nen Bat­te­rien wie­der ein­schal­ten zu las­sen), bleibt das Ge­heim­nis von APC.

Auch der Sinn der Op­ti­on, das An­schal­ten der USV nach dem La­den der Bat­te­rien auf den ge­wünsch­ten Grad noch ver­zö­gern zu kön­nen, er­schloß sich uns nicht.

Die Op­ti­on, das Be­triebs­sy­stem nach Wie­der­an­schal­ten der USV au­to­ma­tisch hoch­zu­fah­ren, wird nur dann die ge­wünsch­te Wir­kung zei­gen, wenn BIOS und Win­dows sau­ber zu­sam­men­spie­len. Der Agent muß hier­für von Win­dows aus dem BIOS mit­tei­len, ob der be­tref­fen­de Rech­ner nach dem näch­sten Ab­schal­ten bei Wie­der­kehr der Strom­ver­sor­gung au­to­ma­tisch neu star­ten soll oder eben nicht. Dies wird in den we­nig­sten Fäl­len funk­tio­nie­ren.

Auch der Shut­down muß­te noch mit ei­nem Script ver­knüpft wer­den, das das He­run­ter­fah­ren der Li­nux-​Ser­ver be­wirk­te; der Shut­down an sich be­wirkt nur das He­run­ter­fah­ren des Win­dows-​Ser­vers. Die letz­ten drei ge­zeig­ten Op­tio­nen le­gen fest, ob ein ("En­able Com­mand File Ex­e­cu­tion") und wel­ches ("Choose Com­mand File Name") Pro­gramm beim Shut­down aus­ge­führt wer­den soll und wie lan­ge die Aus­füh­rung die­ses Pro­gramms dau­ert ("Com­mand File Exe­cu­ti­on Du­ra­tion").

Der Shut­down läuft ins­ge­samt so ab: Sinkt die Rest­lauf­zeit der Bat­te­rien un­ter den kon­fi­gu­rier­ten Wert, wird das an­ge­ge­be­ne Script ge­star­tet. Nach­dem die an­ge­ge­be­ne für die Ab­ar­bei­tung des Scripts be­nö­tig­te Zeit ver­gan­gen ist, ge­mes­sen ab Start des Scripts, wird das He­run­ter­fah­ren des Be­triebs­sy­stems ein­ge­lei­tet. Nach­dem die hier­für an­ge­ge­be­ne be­nö­tig­te Zeit ver­gan­gen ist, ge­mes­sen ab Be­ginn der He­run­ter­fah­rens, wird die USV ab­ge­schal­tet.

Die Scripts, die dem Shut­down und dem Er­eig­nis "Time On Bat­te­ry Thre­shold Ex­cee­ded" zu­ge­ord­net wur­den, un­ter­schei­den sich leicht. Er­ste­res darf nur das He­run­ter­fah­ren der bei­den Li­nux-​Ser­ver be­wir­ken, weil beim Shut­down der Win­dows-​Ser­ver oh­ne­hin be­reits durch den Agent he­run­ter­ge­fah­ren wird; Letz­te­res hin­ge­gen muß das He­run­ter­fah­ren al­ler drei Ser­ver be­wir­ken, weil das be­tref­fen­de Er­eig­nis nicht mit dem Shut­down ver­knüpft ist.

Win­dows: In­halt der Scripts, Pro­zes­se im Hin­ter­grund

Die Scripts, die vom Agent beim Ein­tritt von Er­eig­nis­sen auf­ge­ru­fen wer­den, müs­sen in ei­nem be­stimm­ten Ver­zeich­nis in­ner­halb des Da­tei­sy­stems lie­gen. Wie in ei­ni­gen der obi­gen Ab­bil­dun­gen sicht­bar, er­folgt die Aus­wahl ei­nes Scripts per Drop­down-​Feld, das aus­schließ­lich den In­halt die­ses Ver­zeich­nis­ses an­zeigt. Es ist nicht mög­lich, zu ei­nem an­de­ren Ver­zeich­nis zu na­vi­gie­ren. In un­se­rem Fall lau­te­te das Ver­zeich­nis "C:\Pro­gram­me\APC\Po­w­er­Chute Bu­si­ness Edi­ti­on\agent\cmd­files".

Der Pro­zeß des He­run­ter­fah­rens darf kei­nes­falls durch die auf­ge­ru­fe­nen Scripts ver­zö­gert oder gar blo­ckiert wer­den. An­dern­falls wä­ren die Lauf­zeit­be­rech­nun­gen des Agent nicht zu­tref­fend, oder die be­tref­fen­de Ma­schi­ne wür­de über­haupt nicht he­run­ter­fah­ren. In bei­den Fäl­len könn­te die Strom­zu­fuhr ent­zo­gen wer­den, wäh­rend die Ser­ver noch ar­bei­ten, und da­mit ge­nau der Fall ein­tre­ten, der durch die USV ver­hin­dert wer­den soll.

Des­halb müs­sen die Scripts ei­nen ge­wis­sen Auf­bau be­sit­zen. Ent­schei­dend ist er­stens, daß die Scripts kei­ne Pro­gram­mier­feh­ler ent­hal­ten, die zu ei­ner Blo­ckie­rung oder Ver­zö­ge­rung füh­ren. Zwei­tens darf ein Script nie auf Rück­mel­dun­gen oder Be­en­di­gung ei­nes Be­fehls war­ten, der von die­sem Script auf­ge­ru­fen wird. Viel­mehr ist je­der Be­fehl so auf­zu­ru­fen, daß er in ei­nem ei­ge­nen Pro­zeß oder Fen­ster im Hin­ter­grund ge­star­tet wird und die wei­te­re Ab­ar­bei­tung des Scripts nicht be­ein­flußt.

Wir ha­ben die Scripts zwei­stu­fig auf­ge­baut: Das vom Agent auf­zu­ru­fen­de Script liegt im oben ge­nann­ten Ver­zeich­nis und hat als Wrap­per-​Script die ein­zi­ge Auf­ga­be, ein zwei­tes Script, das die ei­gent­li­che Ar­beit er­le­digt, im Hin­ter­grund, al­so in ei­nem ei­ge­nen Pro­zeß, auf­zu­ru­fen. Der Vor­teil liegt darin, daß das kri­ti­sche Wrap­per-​Script, in dem sich je­der Feh­ler fa­tal aus­wir­ken könn­te, ex­trem ein­fach ge­hal­ten wer­den kann; in un­se­rem Fall genügt ei­ne ein­zi­ge Pro­gramm­zei­le.

Ei­ne ein­fa­che Mög­lich­keit, Scripts un­ter Win­dows Ser­ver 2003 im Hin­ter­grund zu star­ten, be­steht in der Ver­wen­dung des Be­fehls "start". Im Rah­men die­ses Ar­ti­kels kön­nen wir auf die­sen Be­fehl nicht tie­fer ein­ge­hen; zu ei­nem er­sten Über­blick ver­hilft "start /?". Un­se­re Scripts, die für das He­run­ter­fah­ren bei ei­nem "nor­ma­len" Strom­aus­fall ver­ant­wort­lich sind, be­sit­zen nun fol­gen­den In­halt (bit­te be­ach­ten Sie wie­der die Be­deu­tung des Zei­len­fort­set­zungs­zei­chens \):

Wrap­per (C:\Pro­gram­me\APC\Pow­er­Chute Bu­si­ness Edi­ti­on\agent\cmd­files\wrap­per-​all.cmd):

start "" "c:\batch\shut­down-​all.cmd"

Haupt-​Script (C:\Batch\shut­down-​all.cmd):

SET USER=​shut­down
SET PASS­WORD=​sec­ret

SET PLINK=c:\pro­gram­me\put­ty\plink.exe
SET SHUT­DOWN=​c:\win­dows\sy­stem32\shut­down.exe


@echo off

start "Fen­rir­Len­ny­Fire­wall-​Shut­down" "%PLINK%" -ssh 192.168.20.249 \
  -l %USER% -pw %PASS­WORD% /sbin/shut­down -h now
start "Fen­rir­Len­ny­Main-​Shut­down" "%PLINK%" -ssh 192.168.20.28 \
  -l %USER% -pw %PASS­WORD% /sbin/shut­down -h now
start "Ga­rak-​Shut­down" "%SHUT­DOWN%" /s /t 30

Da das Haupt-​Script vom Wrap­per-​Script be­reits im Hin­ter­grund auf­ge­ru­fen wird (aus der Sicht des Agent), wird sich der Le­ser viel­leicht fra­gen, wa­rum das Haupt-​Script selbst eben­falls sämt­li­che kri­ti­schen Be­feh­le im Hin­ter­grund auf­ruft. Die Ant­wort da­rauf zeigt, wie wich­tig ei­ne sorg­fäl­ti­ge Worst-​Case-​Ana­ly­se der Si­tua­ti­on ist und welch schwer­wie­gen­de Fol­gen durch ei­nen schein­bar harmlosen Feh­ler ver­ur­sacht wer­den kön­nen:

Das Haupt-​Script soll zu­erst die bei­den Li­nux-​Ser­ver und dann den Win­dows-​Ser­ver he­run­ter­fah­ren. Falls nun ein Strom­aus­fall auf­tritt und bei­spiels­wei­se der er­ste Li­nux-​Ser­ver kei­ne Netz­werk­ver­bindung an­nimmt, so be­en­det sich plink erst nach Ab­lauf min­de­stens des TCP/IP-​Time­outs, der durch­aus im Halb­mi­nu­ten-​ oder Mi­nu­ten­be­reich lie­gen kann; ver­schie­de­ne Be­triebs­sy­ste­me be­nut­zen hier ver­schie­de­ne Stan­dard-​Ein­stel­lun­gen.

Wür­de plink im Vor­der­grund auf­ge­ru­fen, so wä­re die wei­te­re Ab­ar­bei­tung des Scripts für län­ge­re Zeit blo­ckiert, und die fol­gen­den, es­sen­ti­ell wich­ti­gen Be­feh­le wür­den zu spät und im Ex­trem­fall gar nicht mehr aus­ge­führt. Daß die­ses Sze­na­rio nicht nur Pa­ra­noia ent­springt, son­dern re­al ein­tre­ten kann, wird klar, wenn man die Ba­na­li­tät der Grün­de be­trach­tet, aus de­nen Ser­ver kei­ne Netz­werk­ver­bin­dun­gen an­neh­men: Der Ser­ver könn­te ab­ge­schal­tet oder ab­ge­stürzt sein, ei­ne Netz­werk-​Kom­po­nen­te könn­te de­fekt oder funktionslos sein (ins­be­son­de­re bei Strom­aus­fall).

Grund­sätz­lich ist an­zu­ra­ten, das Worst-​Case-​Sze­na­rio mit Sorg­falt zu er­stel­len, no­to­ri­sche Quer­den­ker da­ran zu be­tei­li­gen, in den be­tei­lig­ten Scripts al­le Be­feh­le im Hin­ter­grund auf­zu­ru­fen und das Ver­hal­ten bei Strom­aus­fall auch in un­wahr­schein­li­chen Si­tua­tio­nen zu te­sten.

Win­dows: In­ter­ak­ti­on zwi­schen Dienst und Script

Trotz kor­rek­ter Kon­fi­gu­ra­tion des Agent und trotz kor­rek­ter Scripts, die bei ma­nu­el­lem Auf­ruf wie er­war­tet ar­bei­te­ten, fuh­ren die Ser­ver bei Strom­aus­fall zu­nächst nicht kor­rekt he­run­ter; es schien, als wür­den die Scripts vom Agent schlicht nicht auf­ge­ru­fen. Kurz­zei­tig ver­mu­te­ten wir ei­nen Feh­ler im Agent; erst bei ei­ner De­bug­ging-​Sit­zung wur­de die wah­re Ur­sa­che er­kannt:

Der Agent ist un­ter Win­dows als Dienst im­ple­men­tiert, was die ein­zig sinn­vol­le Wahl dar­stellt. Je­der Dienst ar­bei­tet im Kon­text ei­nes be­stimm­ten Be­nut­zer­kon­tos und erbt des­sen Be­rech­ti­gun­gen, zum Bei­spiel zur Ma­ni­pu­la­ti­on von Da­tei­en. In der Dien­ste­ver­wal­tung von Win­dows kann ein­ge­stellt wer­den, un­ter wel­chem Be­nut­zer­kon­to wel­cher Dienst läuft; im all­ge­mei­nen ist je­doch da­von ab­zu­ra­ten, die Stan­dard­ein­stel­lungen zu ver­än­dern.

Ruft ein Dienst wei­te­re Pro­gram­me auf, so lau­fen auch die­se im Kon­text des Be­nut­zer­kon­tos die­ses Dien­stes. Glei­ches gilt, wenn ein so auf­ge­ru­fe­nes Pro­gramm wei­te­re Pro­gram­me auf­ruft; in der Re­gel wird der Be­nut­zer-​ und Si­cher­heits­kon­text stets vom auf­ru­fen­den Pro­zeß auf den auf­ge­ru­fe­nen Pro­zeß ver­erbt. Es gibt Grün­de und Me­cha­nis­men, dies zu um­ge­hen, dies­be­züg­li­che Er­läu­te­run­gen wür­den den Rah­men die­ses Ar­ti­kels aber spren­gen.

In un­se­rem Fall je­den­falls wur­den der Agent, sämt­li­che von ihm auf­ge­ru­fe­nen Scripts und die da­rin ent­hal­te­nen Be­feh­le im Kon­text des Kon­tos "Lo­ka­les Sy­stem" aus­ge­führt. Dies trifft ins­be­son­de­re auch für die Auf­ru­fe von plink zu.

Wie oben er­läu­tert, for­dert plink bei erst­ma­li­gem Kon­takt mit ei­nem Ser­ver ei­ne Be­stä­ti­gung des Be­nut­zers be­tref­fend die Echt­heit des öf­fent­li­chen Schlüs­sels des Ser­vers. Oh­ne die­se Be­stä­ti­gung baut plink die Ver­bin­dung nicht wei­ter auf, und beim näch­sten Wunsch nach ei­ner Ver­bin­dung zum be­tref­fen­den Ser­ver be­ginnt das Spiel von vorn. Die­se Be­stä­ti­gung muß pro Ser­ver (ge­nau­er: pro öf­fent­li­chem Schlüs­sel) und pro Be­nut­zer ein­ma­lig er­fol­gen.

Na­tür­lich hat­ten wir un­se­re Scripts zum Te­sten zu­nächst im Kon­text un­se­res Be­nut­zer­kon­tos ab­lau­fen las­sen und nicht im Kon­text des Kon­tos, un­ter des­sen Kon­text der Agent ar­bei­tet. Beim erst­ma­li­gen ma­nu­el­len Auf­ruf der Scripts for­der­te uns plink wie er­war­tet zur Be­stä­ti­gung der Kor­rekt­heit der Schlüs­sel auf. Glei­ches wä­re beim er­sten Auf­ruf der Scripts durch den Agent zu er­war­ten ge­we­sen, da die Ve­ri­fi­zie­rung der Schlüs­sel pro Be­nut­zer er­fol­gen muß.

Ei­ne ent­spre­chen­de Auf­for­de­rung be­ka­men wir je­doch nicht zu Ge­sicht, weil Si­cher­heits­me­cha­nis­men von Win­dows dies ver­hin­dern: In der Re­gel dür­fen Dien­ste nicht mit dem Desk­top in­ter­agie­ren. In un­se­rem Fall woll­te plink bei den Auf­ru­fen sei­tens des Agent sehr wohl die Be­stä­ti­gung über die Echt­heit der Schlüs­sel ein­ho­len; die ent­spre­chen­de Dia­log­box wur­de aber nicht an­ge­zeigt, weil plink im Kon­text des Agent-​Dien­stes ab­lief und Win­dows dem­ent­spre­chend die In­ter­ak­ti­on mit dem Desk­top, näm­lich die An­zei­ge der Dia­log­box, ver­hin­der­te.

Für die­ses Prob­lem exi­stie­ren meh­re­re Lö­sun­gen. Die ein­fach­ste, sau­ber­ste und von uns emp­foh­le­ne be­steht darin, dem Agent-​Dienst vo­rü­ber­ge­hend die In­ter­ak­ti­on mit dem Desk­top zu ge­stat­ten; in der Dien­ste-​Ver­wal­tung von Win­dows ist hier­für in den Ei­gen­schaf­ten ei­nes je­den Dien­stes ein Schal­ter vor­ge­se­hen. Mit et­was mehr Auf­wand ver­bun­den, aber sy­stem­tech­nisch ge­nau­so sau­ber wä­re es, die Scripts ein­ma­lig ma­nu­ell im Kon­text des Agent-​Dien­stes auf­zu­ru­fen. Ei­ne drit­te Lö­sung wä­re es, die Schlüs­sel ma­nu­ell in der Re­gi­stry ein­zu­tra­gen und plink da­mit vor­zu­gau­keln, daß sie be­reits be­stä­tigt wä­ren; hier­von ist al­ler­dings we­gen der Ge­fahr von Feh­lern ab­zu­ra­ten.

Mit gu­tem Grund gibt es üb­ri­gens kei­ne Mög­lich­keit, die vom Au­tor an­ge­bo­te­ne Ver­si­on von plink zum Ver­zicht auf die Be­stä­ti­gung öf­fent­li­cher SSH-​Schlüs­sel zu be­we­gen. plink ist je­doch Open-​Sour­ce-​Soft­wa­re; der be­tref­fen­de Pro­gramm­teil könn­te al­so ent­fernt wer­den. Wir ra­ten aus Grün­den der Si­cher­heit da­von ab – das Er­zwin­gen die­ser Be­stä­ti­gun­gen hat sei­nen Sinn.

Im Fal­le von Si­cher­heits-​Up­gra­des auf den Li­nux-​Sy­ste­men oder son­sti­gen Än­de­run­gen, in de­ren Rah­men der öf­fent­li­che SSH-​Schlüs­sel der be­tref­fen­den Ser­ver ge­wech­selt wird, muß die­se Pro­ze­dur wie­der­holt wer­den. Die Ad­mi­ni­stra­to­ren der Li­nux-​Sy­ste­me soll­ten Än­de­run­gen der öf­fent­li­chen SSH-​Schlüs­sel den Ad­mi­ni­stra­to­ren des Win­dows-​Ser­vers zeit­nah mit­tei­len. Letz­te­re soll­ten un­ab­hän­gig da­von re­gel­mä­ßig prü­fen, ob die öf­fent­li­chen SSH-​Schlüs­sel der durch die USV ge­si­cher­ten Li­nux-​Ser­ver gleich ge­blie­ben und so­mit ei­nem vom Agent auf­ge­ru­fe­nen plink noch be­kannt sind.

Fa­zit

Die­ser Ar­ti­kel zeigt, wie meh­re­re Ser­ver, die ge­mein­sam von ei­ner USV aus der Rei­he "Smart-​UPS" von APC ver­sorgt wer­den, bei Strom­aus­fall kon­trol­liert he­run­ter­ge­fah­ren wer­den kön­nen, oh­ne daß in teu­re Hard­ware-​ oder Soft­ware-​Op­tio­nen in­ve­stiert wer­den muß. Die dar­ge­stell­te Lö­sung be­sitzt klei­ne­re Nach­tei­le, mit de­nen die mei­sten KMUs al­ler­dings gut le­ben kön­nen:

Der kon­trol­lie­ren­de Win­dows-​Ser­ver muß im­mer ak­tiv sein, so­lan­ge dies auch min­de­stens ei­ner der an­de­re von der USV ge­schütz­ten Ser­ver ist. Läuft der Win­dows-​Ser­ver bei Auf­tre­ten ei­nes Strom­aus­falls nicht, so er­fah­ren die an­de­ren Ser­ver nichts von dem Prob­lem. Ih­re Lauf­zeit wird dann zwar ver­län­gert, so­lan­ge die USV nicht ab­schal­tet, aber so­bald dies ge­schieht, wird ih­nen plötz­lich die Strom­zu­fuhr ent­zo­gen, wo­mit ge­nau der Fall ein­tritt, der ver­mie­den wer­den muß.

Die Kom­mu­ni­ka­ti­on zwi­schen den Ad­mi­ni­stra­to­ren der be­tref­fen­den Sy­ste­me muß ver­läß­lich statt­fin­den. Auf dem Win­dows-​Ser­ver muß plink stets die ak­tu­el­len öf­fent­li­chen SSH-​Schlüs­sel der Li­nux-​Ser­ver für den Be­nut­zer als be­stä­tigt hin­ter­legt ha­ben, in des­sen Kon­text der Agent-​Dienst läuft.

Für un­ser Pro­jekt wa­ren die­se Nach­tei­le ir­re­le­vant, da mit an­de­ren Mit­teln si­cher­ge­stellt und über­wacht wur­de, daß der steu­ern­de Win­dows-​Ser­ver im Dau­er­be­trieb ar­bei­tet, und weil die­sel­be Per­son für die Ad­mi­ni­stra­tion der Li­nux-​ und des Win­dows-​Ser­vers zu­stän­dig war.

Bei an­de­ren Kun­den hin­ge­gen war dies nicht ak­zep­ta­bel, hier führ­te kein Weg am Kauf der ge­nann­ten Hard­ware-​ und Soft­ware-​Op­tio­nen vor­bei. Auf je­dem Ser­ver ar­bei­te­te dann ei­ne voll­wer­ti­ge Soft­ware des be­tref­fen­den USV-​Her­stel­lers, und je­der Ser­ver kom­mu­ni­zier­te un­ab­hän­gig von den an­de­ren mit dem in der USV nach­ge­rü­ste­ten Netz­werk-​Mo­dul.