Puolen sivun päivitysmanuaali
Tapahtui eräässä asiakasprojektissa vuosia sitten
Initech-yhtiö teki eräänlaisia informaatiojärjestelmiä. Heillä oli muutamia erilaisia sulautettuja masiinoita, jotka osasivat verkottautua keskenään. Pinnan alla oli itse asiassa ihan tavallista pc-rautaa, joka oli vain kääritty vähän poikkeavanlaisiin koteloihin. Purkeissa pyöri Debian Linux ja varsinaiset softat oli tehty Javalla.
Ohjelmistoihin tuli tietysti aika ajoin päivityksiä. Ne piti saada jotenkin ajettua sisään. Mutta eiväthän Initechin omat tyypit niitä käyneet päivittämässä, koska järjestelmiä oli toimitettu asiakkaille sekä Suomeen, muualle Eurooppaan ja vähän pidemmällekin.
Asiakkaiden omat pertti perusinsinöörit, jotka eivät muuten ymmärtäneet ohjelmistoista tai linuxeista hölkäsen pöläystä, joutuivat aina romaanin paksuisten oppaiden kanssa päivityshommiin. Oppaiden piti olla ns. rautalankamallia. Niissä ei saanut esimerkiksi olettaa, että asiakkaan päässä tiedetään, mikä on usb-portti.
Päivitystoimet olivat työläitä, koska laitteita saattoi olla useita kymmeniä. Ne piti käydä päivittämässä aina yksitellen.
”Tyhmät päätteet” – ja tyhmä keskusyksikkö
Omalla vastuullani oli järjestelmän keskusyksikkö, joka komensi ja hallinnoi samassa verkossa olevia muita laitteita.
Tuotantoympäristössään se olisi pakattuna ehkä ahtainpaan ja hankalimpaan paikkaan, mitä kuvitella saattaa. Päivityksiä tehtiin läppärillä kökön selainkäyttöliitymän kautta.
Tässä vaiheessa sinullakin varmaan heräsi sama kysymys mikä minulla aikoinaan – ainakin jos vähänkään tunnet Debiania:
Miksi he eivät hyödyntäneet käyttöjärjestelmän tarjoamia valmiita paketinhallintatyökaluja (apt-repot jne.)?
No enpä kuule tiedä. Sen sijaan he olivat alkaneet koodata omaa pakettimanageria.
Pakko olla parempikin keino
Aloin panna asioita omalta osaltani ruotuun. Ensin varmistin, että kaikki järjestelmän tarvitsemat ohjelmat olivat siististi ja oikeaoppisesti käännettynä deb-paketeiksi.
Koska yksittäisessä laitteessa saattoi olla useampi softa ajossa, tein myös laitekohtaiset meta-paketit, joiden nimet olivat muotoa laitetyyppi.deb. Tällä tavalla oli uutta laitetta kasatessa helppo päätellä, mikä paketti siihen kuului asentaa.
Yksittäisten softien nimiä ei tarvinnut tietää, koska meta-paketin riippuvuusmäärittelyt hoitivat niiden asentamisen.
Keskusyksikköön pystytin apt-repon, jonne kokosin kaikkien laitetyyppien kaikki tarvittavat ohjelmapaketit. Tämän repon lisäsin muiden laitteiden repolistaan, ja asetin ne ajamaan kerran päivässä apt-get update && apt-get upgrade -kombon.
Automaattipäivitys myös keskusyksikölle
Keskusyksikkö tietysti piti saada myös itsessään päivitettyä, jotta ohjelmistojen automaattipäivitykset saataisiin käyttöön. Se ei kuitenkaan ollut mikään ihan kevyt toimenpide.
Ei tuntunut järkevältä ohjeistaa sellaisia ihmisiä komentorivin ääreen, joilla ei siitä ollut mitään hajua. Vaikka ohjeissa olisi täsmälliset komennot, yksikin pieni näppäilyvirhe johtaisi epäonnistumiseen ja pahimmassa tapauksessa koko systeemin jumittumiseen.
Keksin tähänkin mielestäni aika nerokkaan ratkaisun.
Ensin hioin kehitysympäristössä uuden keskusyksikön konfiguraation kuntoon. Otin kovalevyn sisällön talteen levyimageksi.
Seuraavaksi asensin minimaalisen Linux-distron usb-muistitikulle ja kopion myös tuon levyimagen sinne. Lisäksi kirjoittelin muutamia skriptejä, jotka ajettaisiin boottauksen yhteydessä ja joiden avulla varsinainen taika tapahtui.
Kun päivityssyteemi oli valmis, oli sen käyttäminen varsin yksinkertaista:
- muistitikku laitettiin kiinni sammutetun keskusyksikön etupaneelissa olevaan usb-porttiin
- virrat laitettiin päälle ja odotettiin noin 15 minuttia, kunnes vilkkuva led-valo sammui
- valmista tuli
Pinnan alla tapahtui tiivistetysti seuraavaa:
- Koneen BIOS etsi käyttöjärjestelmää ensisijaisesti usb-tikulta, vähän niinkuin ennen wanhaan korpulta tai cd:tä. Koska muistitikku oli kiinni, käynnistyi sille asentamani minimaalinen Linux-distro.
- Kun masiina oli käynnistynyt, se mounttasi sekä varsinaisen kiintolevynsä että muistitikulla olevan uuden levyimahgen väliaikaisiin hakemistoihin.
- Keskusyksikön ohjelmistojen konfiguraatiot ja järjestelmän asetukset (mm. sisäverkon ip-osoitteet jne.) luettiin talteen ja ne päivitettiin mountatun levyimagen kautta uuteen asennukseen.
- Muistitikun levyimagella kirjoitettiin keskusyksikön kovalevyn vanha sisältö (”dd if=foo.img of=/dev/sda”)
- Muistitikku komensi käyttöjärjestelmän boottaamaan siten, että se käynnistyisi sillä kertaa (ja vain sillä yhdellä kertaa) joka tapauksessa kovalevyltä, vaikka muistitikku olisi kiinni.
Tästä kaikesta kirjoittamani ohjeistus asentajille oli alun perin puolen A4-sivun mittainen.
Initechin tekniikkapomo kuitenkin halusi varmuuden vuoksi hieman paksumpaa rautalankaa, joten lopullinen versio oli lisättyine kuvineen noin puolitoista sivua pitkä. Siitäkin huolimatta se oli huima parannus vanhaan tapaan nähde. Tarina kertoo, että eräänkin laitteen päivittämiseen olisi tarvittu 18 sivua pitkä manuaali.
Käyttöliittymäsuunnittelua ei ole ainoastaan se, että vain ehostaa ja tehostaa vanhaa ohjelmistoa, mutta pysyy ennalta asetettujen raamien sisällä. Joskus parempaan lopputulokseen pääsee sillä, että tarkastelee asioita hieman laajemmasta näkulmasta. Silloin näkee paremmin, mitä järjestelmällä oikeasti yritetään saada aikaan.