NUT + CyberPower USB-UPS Debianilla

Tekninen ohje EnergyHub-sarjaan. Kuvaa, miten CyberPower-luokan USB-HID-UPS otetaan käyttöön Debianilla Network UPS Toolsin (NUT) kanssa niin, että lopputulos on luotettava, fail-safe ja jäljitettävä. Ohje on kirjoitettu kahta tarkoitusta varten: se toimii yleisenä oppaana kenelle tahansa, joka rakentaa saman laiteluokan varaan, ja samalla se on täydellinen palautusreferenssi, josta koko UPS-kokoonpanon saa pystyyn tyhjältä koneelta. Tarkat kynnysarvot ja viiveet pitää aina sovittaa omaan kuormaan ja akkuun.

Tämä ohje on syntynyt EnergyHubin palvelin-UPS:n käyttöönotosta. Tarina siitä, miksi asiat tehtiin näin — ja mitä matkalla meni pieleen — on omassa artikkelissaan. Tämä dokumentti keskittyy tekemiseen ja siihen, että kaikki asetukset ovat yhdessä paikassa.

Ydinajatus on koko ajan sama: UPS ei ole vain akku, vaan ohjattava laite, johon ei kannata luottaa sokeasti. Sekä CyberPowerin oma laiteohjelmisto että USB-väylän tilat voivat käyttäytyä yllättävästi, joten turvallinen ratkaisu rakennetaan hostin omaan, testattavaan logiikkaan — ei UPS:n natiiveihin lupauksiin.

Miksi tämä on myös palautusohje

EnergyHubin päivittäinen varmuuskopio ei kata UPS-automaatiota. Se on tietoinen rajaus: UPS/NUT-kokoonpano on koneen ja käyttöjärjestelmän tason asia (/etc/nut, /usr/local/sbin, systemd-unitit, BIOS-asetus), ei osa EnergyHubin sovellustason dataa, jota nightly-backup käsittelee. Siksi UPS ei palaudu EnergyHubin restore-prosessin mukana, vaan tämä ohje on se lähde, jolla kokoonpano rakennetaan uudelleen. Kaikki tarvittavat arvot on tallennettu tähän dokumenttiin juuri tästä syystä.

Jos siis joudut asentamaan koneen tyhjästä, EnergyHub palautuu omalla restore-prosessillaan ja UPS-osuus tästä ohjeesta. Ne ovat kaksi erillistä palautuspolkua.

Referenssikokoonpano

Tämä ohje on kirjoitettu seuraavan kokoonpanon pohjalta. Yleisenä oppaana lukiessa korvaa arvot omillasi; palautusreferenssinä nämä ovat tuotannon todelliset asetukset.

UPS: CyberPower CP1600EPFCLCD, 1600 VA / 1000 W, pure sine wave
USB: VID:PID 0764:0601, HID product CP1600EPFCLCD
Käyttöjärjestelmä: Debian 13 (trixie)
NUT: 2.8.1-5, usbhid-ups, subdriver CyberPower HID 0.8
Tila: standalone, upsd kuuntelee vain localhostia

Tunnettu hyvä tuotantotila lyhyesti: UPS OL, akku 100 %, battery.runtime ~13300 s (n. 3 h 41 min) noin 30 W kuormalla, nut-driver@cyberpower + nut-server + guard active, nut-monitor masked, upsmon ei käynnissä, offdelay=60, ondelay=0, allow_killpower=0.

Miksi juuri tämä yhdistelmä on kinkkinen

CyberPowerin edullisemmat USB-HID-mallit toimivat NUTin usbhid-ups-ajurilla, mutta niissä on kaksi toistuvaa erikoisuutta, jotka on hyvä tietää etukäteen.

Ensinnäkin natiivien kynnysarvojen kirjoittaminen ei ole luotettavaa. battery.runtime.low-arvon asettaminen epäonnistuu hiljaisesti: kun tähän laitteeseen yritettiin kirjoittaa 600, readback oli 88 (600 mod 256). battery.charge.low yritettiin asettaa arvoon 5, mutta se jäi arvoon 10. Driver-restartin jälkeen arvot säilyivät virheellisinä (88/10).

Toiseksi viiveet voidaan käsitellä minuuttiresoluutiolla. Moni CPS-malli jakaa offdelay/ondelay-arvoja sisäisesti tai pyöristää ne minuutteihin. Liian pienet oletusarvot (esim. ups.delay.shutdown=20, ups.delay.start=30) voivat pyöristyä vaarallisesti.

Kolmas asia ei ole varsinaisesti CyberPower-spesifi mutta osuu juuri tähän yhdistelmään: USB-HID-yhteys jää vikatilaan shutdown.return-syklin jälkeen. Laite näkyy edelleen USB-väylässä, mutta NUT ei enää saa luettua sen string-descriptoreita, eikä pelkkä ajuripalvelun uudelleenkäynnistys korjaa tilannetta. Tähän palataan diagnostiikkaosassa.

Vaihe 1: Sähköinen perustoiminta ennen ohjelmistoa

Lataa UPS täyteen ja testaa perustoiminta ilman mitään automaatiota. Kytke kuorma UPS:n lähtöön, katkaise verkkosähkö noin minuutiksi ja varmista, että kuorma pysyy käynnissä ja verkkosähkön palatessa kaikki normalisoituu.

Tämä vaihe erottaa laiteviat ohjelmistovioista. Jos jokin menee myöhemmin pieleen, tiedät että sähköinen pohja oli kunnossa.

Pysyvä fyysinen periaate:

UPS:n tulo → suoraan verkkosähköön
UPS:n lähtö → suojattava host + valitut verkkolaitteet
USB → host → NUT

Jos käytät testin aikana etäohjattavaa älypistorasiaa (esim. Shelly) katkaisemaan verkkosähköä hallitusti, se on hyvä testiväline mutta huono tuotannon riippuvuus. Älä jätä sitä UPS:n pysyvään syöttöketjuun: verkkokatkon jälkeen sellainen laite voi jäädä tavoittamattomaksi juuri silloin, kun tarvitsisit AC:n palautuvan.

Vaihe 2: NUTin asennus ja USB/HID-tunnistus

Asenna NUT ja sen palvelinosat (referenssikokoonpanossa nut-client 2.8.1-5 ja nut-server 2.8.1-5):

sudo apt install nut-server nut-client

Varmista, että laite näkyy USB-väylässä:

lsusb

CyberPowerin USB-HID-laitteet käyttävät vendor-ID:tä 0764. Huomaa, että lsusb:n oma laitetietokanta saattaa näyttää VID:PID:lle väärän mallinimen — se on vain tietokannan nimi, ei laitteen kertoma malli. Todellinen malli varmistuu HID-descriptoreista ja NUTin skannauksesta:

sudo nut-scanner -U

Aja lopuksi ajuri kertaalleen debug-tilassa, niin näet mitä laite oikeasti kertoo itsestään (terveessä tilassa mm. VendorID: 0764, ProductID: 0601, oikea serial ja Using subdriver: CyberPower HID 0.8). Tämä kannattaa nähdä jo nyt terveessä tilassa vertailukohdaksi.

udev-oikeudet

NUT-ajurin pitää päästä lukemaan ja kirjoittamaan USB-laitesolmua. Lisää udev-sääntö, joka antaa laitteelle nut-ryhmän ja riittävät oikeudet:

ATTR{idVendor}=="0764", ATTR{idProduct}=="0601", MODE="664", GROUP="nut"

Terveessä tilassa laitesolmu näkyy muodossa root:nut oikeuksilla 0664. Tämä on tärkeä todiste myöhemmin: jos NUT valittaa oikeuksista mutta laitesolmu on kunnossa, vika on todennäköisesti muualla (ks. diagnostiikka).

Vaihe 3: NUT-konfiguraatiotiedostot

Nämä ovat palautusreferenssin ydin. Kaikki /etc/nut-tiedostot yhdessä paikassa.

/etc/nut/nut.conf

MODE=standalone

Standalone-tilassa upsd kuuntelee vain localhostia (127.0.0.1 / ::1, portti 3493). UPS-ohjausta ei avata verkkoon — tietoinen turvavalinta yhden koneen suojaukseen.

/etc/nut/ups.conf

Viiveet asetetaan tässä, ei upsrw:llä (ks. vaihe 5). Serial korvataan oman laitteen sarjanumerolla.

maxretry = 3

[cyberpower]

driver = usbhid-ups
port = auto
vendorid = 0764
productid = 0601
serial = OMASARJANUMERO
desc = "CyberPower CP1600EPFCLCD"
offdelay = 60
ondelay = 0

offdelay = 60 antaa hostin alasajolle aikaa ennen kuin UPS katkaisee lähdön. ondelay on nykyisessä tuotantotilassa 0. Huomaa, että aiemmassa käyttöönottovaiheessa arvona oli 120; tuotannon nykyarvo on 0, ja tämä on se arvo, joka palautetaan. Tee viivemuutokset aina tähän tiedostoon, älä laitteen kirjoituspolulle.

Serial-suodatin on hyödyllinen, jos koneessa on useampi samanlainen laite — mutta huomaa, että juuri se tekee myöhemmin kuvatusta descriptor-viasta näkyvän: jos NUT ei saa luettua sarjanumeroa, serial-match epäonnistuu ja laite hylätään.

/etc/nut/upsd.conf

Standalone-oletukset riittävät; upsd sidotaan localhostiin. Palauta tiedosto sellaisena kuin se oli — pidä kuuntelu vain localhostissa, älä avaa LISTEN-riviä ulkoverkkoon.

/etc/nut/upsd.users

Tämä sisältää upsd-käyttäjät ja salasanat. Palauta turvallisesti — älä koskaan julkaise tätä tiedostoa eikä sen salasanoja. Normaalikäytössä tässä ei tarvita instant-command-oikeuksia lainkaan (guard ei käytä upsd-käyttäjää; se lukee NUTia). Instant-komentojen testikäyttäjät luodaan vain tilapäisesti (ks. testijärjestely) ja poistetaan heti.

/etc/nut/upsmon.conf

Referenssikokoonpanossa upsmonia ei ajeta (ks. vaihe 8). Jos upsmon.conf on olemassa mutta ilman MONITOR-riviä, palvelu kaatuu virheeseen ”insufficient power configured” — siksi palvelu maskataan. Palautuksessa joko jätä tiedosto sellaisenaan ja maskaa palvelu, tai luo se täsmälleen samanlaisena kuin tuotannossa.

Vaihe 4: Viiveiden auditointi (offdelay / ondelay)

Tarkista read-only, mitä NUT raportoi viiveiksi:

upsc cyberpower@localhost | grep delay

Jos näet oletusarvoja kuten ups.delay.shutdown = 20 ja ups.delay.start = 30, älä hyväksy niitä sokkona. Aseta turvalliset arvot ups.conf-tasolla ja ota ajuri uudelleen käyttöön:

sudo systemctl restart nut-driver@cyberpower.service
upsc cyberpower@localhost | grep delay

Ota varmuuskopio ennen jokaista muutosta (esim. ups.conf.pre-delays-<aikaleima>). Ajuripalvelun uudelleenkäynnistyksessä shell voi hetkellisesti näyttää ”Job canceled”, vaikka journal osoittaa puhtaan stop/start-syklin ja lopputila on active, NRestarts=0. Tarkista aina journalista todellinen tila, älä pelkästä shellin tulosteesta.

Vaihe 5: Älä kirjoita natiiveja kynnysarvoja

Tämä on ohjeen tärkein yksittäinen varoitus. Älä yritä säätää battery.runtime.low– tai battery.charge.low-arvoja upsrw:llä. Kirjoitus epäonnistuu hiljaisesti:

battery.runtime.low → yritä 600, readback 88 (600 mod 256)
battery.charge.low → yritä 5, readback jää 10

Myöskään ”turvallinen palautus” johonkin muuhun arvoon ei ole turvallista: sama muunnos voisi tehdä 300:sta arvon 44. Jätä natiivikynnykset rauhaan.

Natiivi LB (low battery) on siis vain advisory-varoitus, ei ohjaussignaali. Varsinainen sammutuspäätös tehdään host guardilla.

Vaihe 6: Host guard — fail-safe-sammutuspäätös

Koska UPS:n natiiveihin rajoihin ei voi luottaa, sammutuslogiikka on erillisessä host guard -komponentissa, joka lukee NUTia säännöllisin väliajoin ja tekee päätöksen omilla, testattavilla kriteereillä. Guard on systemd-palvelu energyhub-ups-guard.service (enabled), ja itse scripti sijaitsee polussa /usr/local/sbin/energyhub-ups-guard.py.

Tuotantoon suunniteltu kriteeri (referenssiarvot):

Parametri	Arvo
UPS	`cyberpower@localhost`
POLL_SECONDS	5
RUNTIME_LIMIT_SECONDS	600
CHARGE_LIMIT_PERCENT	5
REQUIRED_CONSECUTIVE	3
Nykyinen action	LOG_ONLY
Native LB	warning_only

Toimintalogiikka: OB-tilassa runtime ≤ 600 s ja/tai charge ≤ 5 % kasvattaa critical-laskuria. Kolme peräkkäistä 5 s näytettä tuottaa WOULD_SHUTDOWN vain kerran. OL nollaa tilan. NUT-kommunikaatiovirhe ei aiheuta sammutusta, vaan guard lokittaa fail-safe-tilassa vain COMM_ERRORin.

Kriittinen periaate: fail-safe on tärkeämpää kuin aggressiivinen sammutus. Jos NUT-yhteys katkeaa mutta viimeisin varma tila oli OL, pelkkä yhteysvirhe ei saa aiheuttaa sammutusta.

Guard ajaa toistaiseksi LOG_ONLY-tilassa — se kirjaa ”olisin sammuttanut” -päätöksiä mutta ei vielä oikeasti sammuta konetta. Guard-scripti ei sisällä shutdown- eikä UPS-control-komentoja lainkaan.

Testatut skenaariot, jotka palautuksen jälkeen kannattaa toistaa:

Positiivinen dry-run (esim. TEST_THRESHOLD=14000): OB → kolme näytettä → WOULD_SHUTDOWN. Varmista että se tulee vain kerran.
Negatiivinen tuotantoraja (600 s): lyhyt OB (n. 25 s) täydellä ~13000 s runtimella → ei CRITICAL/WOULD_SHUTDOWN.
Systemd LOG_ONLY tilapäisellä 14000 s rajalla: kolme näytettä → WOULD_SHUTDOWN, palautus 600 s automaattisesti.
Kommunikaatiovirhe: katkaise NUT-yhteys → yksi COMM_ERROR, ei sammutusta.

Säilytä guard-scriptin SHA256 dokumentaatiossa, niin tiedät että ajossa on juuri se versio, jonka testasit.

Vaihe 7: BIOS — automaattinen käynnistys sähkön palatessa

Koko recovery-ketju kaatuu, jos kone ei käynnisty itsestään kun UPS palauttaa lähdön. Tämä on BIOS-asetus, ei tiedostobackup — sitä ei voi palauttaa arkistosta, vaan se on asetettava manuaalisesti jokaisella koneella.

Referenssikoneessa asetus on After Power Loss = Power On. Testaa fyysisesti: aja hallittu sammutus, irrota ja palauta AC-syöttö ja katso käynnistyykö kone. Ensimmäisellä referenssikoneen testillä oletusasetus ei käynnistänyt konetta uudelleen — asetuksen muutoksen jälkeen kone nousi heti pystyyn. Älä oleta tätä toimivaksi ilman koetta.

Vaihe 8: nut-monitor — maskaa, älä pelkästään disabloi

Jos et käytä upsmon-pohjaista sammutusta (referenssikokoonpano ei käytä), huomaa systemd-ansa: vaikka nut-monitor.service olisi disable-tilassa, nut.target voi Wants-riippuvuudella yrittää käynnistää sen bootissa. Jos upsmon.conf:ssa ei ole MONITOR-riviä, upsmon kaatuu virheeseen ”insufficient power configured”.

Ratkaisu on maskata palvelu:

sudo systemctl mask --now nut-monitor.service
sudo systemctl reset-failed nut-monitor.service

Terveessä tilassa /etc/systemd/system/nut-monitor.service on symlinkki /dev/null:iin, upsmon-prosessia ei ole, ja NUTin ajuri sekä palvelin ovat silti active.

Palautuksen tarkistuslista (tyhjältä koneelta)

Kun rakennat kokoonpanon uudelleen, käy nämä läpi järjestyksessä. Tämä on se osa, jota EnergyHubin nightly-restore ei tee puolestasi.

Paketit ja tiedostot:

Asenna nut-client + nut-server (referenssi 2.8.1-5)
Palauta /etc/nut/nut.conf, ups.conf, upsd.conf, upsd.users, upsmon.conf
Palauta /usr/local/sbin/energyhub-ups-guard.py ja mahdollinen testwriter /usr/local/sbin/energyhub-ups-d1-test-writer.py
Palauta late-shutdown-hook /usr/lib/systemd/system-shutdown/energyhub-ups-d1-dry-run
Palauta guardin unit /etc/systemd/system/energyhub-ups-guard.service
Lisää udev-sääntö (0764:0601, MODE 664, GROUP nut)

Systemd-tila:

energyhub-ups-guard.service → enabled
nut-server.service → enabled
nut-driver@cyberpower.service → enabled (driver-enumeraattori regeneroi drop-in-tiedostot hakemistoon nut-driver@cyberpower.service.d/; nämä syntyvät automaattisesti, niitä ei tarvitse palauttaa käsin)
nut-monitor.service → masked (symlink /dev/null)
upsmon → varmista ettei käynnissä

NUT-arvot ja varmennus:

offdelay = 60, ondelay = 0
allow_killpower = 0, /etc/killpower ei käytössä
Älä kirjoita battery.runtime.low / battery.charge.low
Varmenna: ups.status = OL, battery.charge ~100, viiveet oikein

BIOS (manuaalinen):

After Power Loss = Power On, testattu fyysisesti

Tunnetun hyvän perustilan tarkistus

Normaalikäytössä nämä pitäisi olla kunnossa:

systemctl is-active nut-driver@cyberpower.service     # active
systemctl is-active nut-server.service                # active
systemctl is-active energyhub-ups-guard.service       # active
systemctl is-enabled nut-monitor.service              # masked
pgrep -a upsmon || echo none                          # none
upsc cyberpower@localhost ups.status                  # OL
upsc cyberpower@localhost battery.charge              # ~100
upsc cyberpower@localhost | grep delay                # offdelay 60 / ondelay 0

Diagnostiikka: USB/HID jää stale-tilaan shutdown.return-syklin jälkeen

Tämä on se kinkkisin vika, ja se ansaitsee oman osionsa, koska sen virheilmoitus on harhaanjohtava.

Oire

shutdown.return-komennon ja lähdön katkaisun jälkeen usbhid-ups alkaa saada nut_libusb_get_interrupt: Input/Output Error -virheitä ja yrittää reconnectia parin sekunnin välein. Lokin yhteenveto sanoo:

Could not open any HID devices: insufficient permissions on everything

Tämä viesti johtaa harhaan. Vika ei todennäköisesti ole oikeuksissa.

Sulje oikeudet pois nopeasti

lsusb                                  # laite näkyy?
ls -l /dev/bus/usb/BUS/DEV             # omistaja root:nut, mode 0664?
sudo -u nut cat /dev/bus/usb/BUS/DEV   # nut pystyy lukemaan?

Jos laitesolmu on root:nut 0664 ja nut pystyy lukemaan sen, oikeudet ovat kunnossa — huolimatta siitä mitä NUTin yhteenvetoviesti väittää. Huomaa myös, ettei pelkkä nut-driver-palvelun restart korjaa tätä: myös upsdrvctl yrittää käynnistää ajurin turhaan, mikä osoittaa ettei kyse ole vanhan driver-prosessin jumista.

Ratkaiseva askel: aja ajuri -DD debug-tilassa

sudo systemctl stop nut-driver@cyberpower.service
sudo /lib/nut/usbhid-ups -a cyberpower -DD

Vikatilassa näet jotain tällaista:

Checking device ... (0764/0601)
nut_libusb_open get iManufacturer failed, retrying...
nut_libusb_open get iProduct failed, retrying...
nut_libusb_open get iSerialNumber failed, retrying...
Manufacturer: unknown
Product: unknown
Serial Number: unknown
match_function_regex: failed match of Serial: (null)
Device does not match - skipping

Tässä on todellinen juurisyy: NUT/libusb ei saa luettua USB:n string-descriptoreita, vaikka lsusb ja sysfs lukevat ne normaalisti. Koska ups.conf:ssa on serial-suodatin, Serial=(null) johtaa match-failiin ja laite hylätään. Lopun ”insufficient permissions” -viesti oli vain yhteenveto muiden USB-laitteiden access-denied-havainnoista, ei tämän laitteen todellinen vika.

Korjaus: USB-uudelleenenumerointi

Pelkkä ajuripalvelun restart ei korjaa tätä. Descriptorit palautuvat vasta fyysisellä uudelleenenumeroinnilla:

Pysäytä ajuri hallitusti
Irrota UPS:n USB-kaapeli ~10 sekunniksi
Kytke takaisin (device-numero vaihtuu, esim. 003 → 004; udev luo uuden solmun)
Aja -DD uudelleen — nyt pitäisi näkyä oikeat VendorID / ProductID / Serial ja ”Device matches”; driver lukee normaalisti akun, runtimen, jännitteet, offdelay/ondelay ja ups.status OL
Käynnistä tuotantoajuri takaisin

Miksi tämä on diagnostisesti tärkeää: uusi enumerointi erottaa NUT/libusb-tilavian fyysisestä UPS-viasta. Jos replug korjaa tilanteen, kyse oli väylän/descriptorien tilasta, ei rikkoutuneesta laitteesta.

Huomaa myös, että production-driverin uudelleenkäynnistys tämän jälkeen voi hetkellisesti tuottaa lisää virhelokia — se ei ole uusi UPS-vika vaan odotettu seuraus siitä, että testidriver lopetettiin ennen production-driverin uutta käynnistystä.

Käytännön seuraus suunnitteluun: älä ota automaattista shutdown.return-pohjaista tuotantosammutusta käyttöön ennen kuin tämä reconnect-käyttäytyminen on ratkaistu omalla laitteellasi ja koko ketju on testattu end-to-end host oikeasti UPS:n takana.

Turvallinen testijärjestely instant-komennoille

Kun testaat vaarallisia instant-komentoja (shutdown.return, beeper.* yms.), käytä minimioikeuksia:

Luo väliaikainen upsd-käyttäjä, jolle sallitaan vain tarvittava komento (beeper-testikäyttäjälle vain beeper.disable/enable/mute; shutdown-testikäyttäjälle vain shutdown.return + shutdown.stop)
Älä anna SET-, load.off-, load.on– tai killpower-oikeuksia testikäyttäjälle
Pidä salasana root-only-passfilessä
Palauta konfiguraatio ja poista testikäyttäjä heti testin jälkeen

shutdown.return-testissä kannattaa lisäksi irrottaa suojattava host UPS:n lähdöstä testin ajaksi (kytke se suoraan seinään, mutta pidä USB kiinni), jotta lähdön katkaisu ei sammuta oikeaa konetta. UPS:n lähdössä olkoon vain harmiton näkyvä testikuorma.

Älä tee ilman erillistä suunnitelmaa

Älä käytä upsrw:tä low-threshold-arvojen muuttamiseen — kirjoitus on epäluotettava
Älä unmaskaa nut-monitoria tai lisää MONITOR-riviä pelkäksi kokeeksi
Älä anna guardille tai yleiselle käyttäjälle load.off / driver.killpower / shutdown.stayoff -oikeuksia
Älä jätä etäohjattavaa älypistorasiaa UPS:n pysyvään AC-syöttöketjuun
Älä ota guardin oikeaa sammutus-actionia käyttöön ennen täyttä end-to-end-testiä host oikeasti UPS:n takana
Älä tulkitse pientä ups.load = 0 -lukemaa kuormattomuudeksi — prosenttikuorman resoluutio on karkea
Jos NUT jää shutdown.return-syklin jälkeen stale-tilaan, älä oleta oikeusvikaa — tarkista descriptorit -DD:llä ja tee tarvittaessa USB-uudelleenenumerointi

Yhteenveto

Luotettava CyberPower + NUT -asennus Debianilla ei synny laitteen natiiveihin lupauksiin luottamalla vaan rakentamalla turvallisuus hostin omaan, testattavaan logiikkaan. Testaa sähköinen pohja ensin, auditoi viiveet mallikohtaisesti, jätä natiivikynnykset rauhaan, tee sammutuspäätös fail-safe-guardilla, maskaa nut-monitor jos et sitä käytä, ja varmista BIOSin automaattikäynnistys fyysisellä kokeella.

Ja koska UPS-kokoonpano ei kulje EnergyHubin varmuuskopion mukana, tämä dokumentti on sen palautusreferenssi: kaikki arvot, tiedostopolut ja systemd-tilat ovat tässä, jotta kokoonpanon saa pystyyn tyhjältä koneelta ilman että mitään tarvitsee muistaa ulkoa.