Välillä teknistä latinaa. Tai ehkä paremmin lätinää. Oli aika päivittää serverini, Ubuntu 10_04 LTS, jonka 5 vuoden tuki päättyi tämän vuoden huhtikuussa. Uusin Ubuntun ”pitkän ajan tuen” -versio on tällä hetkellä 14_04 LTS. Päivitys vaikutti helpolta komentamalla vain terminaalissa ”do-release-upgrade”. Suoraan 10_04:sta 14_04:ään ei kuitenkaan voinut päivittää, vaan oli ensin päivitettävä versioon 12_04.

Alkuvalmisteluiksi päivitin ensin 10_04 ohjelmat ajan tasalle: sudo aptitude update ja sudo aptitude upgrade. Samalla varmistui, että internet yhteys oli kunnossa. Sen jälkeen siivosin /boot -osion vanhemmista kerneleistä: sudo aptitude purge linux-image-xxx. Joskus muinoin tuli osioitua  bootti vain 100MB kokoiseksi, joka on nykyisin turhan pieni. Boottia ei voi isontaa manuaalisesti, koska levyn muut osiot on formatoitu XFS tiedostojärjestelmällä, jota ei, puolestaan, voi pienentää, jotta levylle saisi lisätilaa bootille. Jos bootissa ei ole tarpeeksi tilaa, asennus saattaa tyssätä keskenkaiken siihen ja koko systeemi voi olla sen jälkeen peruuttamattomasti sekaisin. Pelkoa siitä ei do-release-upgradea käytettäessä kuitenkaan ollut, koska ohjelma ilmoitti tilantarpeesta ennen kuin mitään vahinkoa ehti syntyä.

Muita alkuvalmisteluita en tehnyt, en muuttanut esim. pakettivarastoja (repository) vaan komensin ”do-release-update” suoraan. Ja ilman sudoa, mutta ohjelma kysyi root -salasanan siitä huolimatta. Ohjelma vielä huomautti, ettei päivitystä voi keskeyttää, jos sen aloittaa ja kysyi jatketaanko, kyllä vai ei? Vastasin ”kyllä”. Päivitysohjelma alkoi juosta, korjasi pakettivarastot automaattisesta uutta versiota vastaaviksi ja alkoi lataamaan tiedostoja. Ajo kesti yhteensä varmaan parisen tuntia. Tein välillä muita juttuja ja kävin silloin tällöin katsomassa missä vaiheessa päivitys oli. Muutaman kerran päivitys pysähtyi kysymään haluanko pitää vanhat asetukset joissakin asetustiedostoissa, vai päivitetäänkö uuteen. Oletuksena oli vanhojen asetusten säilyttäminen. Yleensä onkin viisainta jättää ne entiselleen, koska monia asetuksia on täytynyt itse tuunata. Jos asentaa niiden päälle uuden oletusversion, joutuu asetukset säätämään uudelleen.

Do-release-upgrade meni sinänsä läpi ongelmitta ja lopuksi koneen uudelleenkäynnistys. Eipä tietenkään bootanut, vaan jumittui virheilmoituksiin ”Could not log bootup: address already in use”,  ”Init: Plymouth main process terminated with status 69”, ”Mount: Too many levels of symbolic link”. Googlettamalla selvisi, että /var/run ja /run -hakemistot olivat jostain syystä linkatut ristiin /var/run -> /run ja /run -> /var/run. Asian korjaaminen onnistui helpohkosti, koska koneen sai kuitenkin bootattua ”recoverymodeen”. Recovery -valikosta valitsin aluksi komentotulkin, mutta siinä ei voinut tehdä mitään, koska tiedostot oli kirjoitussuojattu. Toisella kerralla valitsin ”DGBG – option” ja pudottauduin siitä komentotulkkiin painamalla CTRL + C, jolloin tiedostoja pystyi muokkaamaan. Sen jälkeen komennot cd /,   jonka jälkeen rm run, jonka jälkeen mkdir -p run, jonka jälkeen koneen uudelleenkäynnistys onnistui. Serveri pelasi normaalisti, paitsi, että sudo ei toiminut. Selvisi, että, toisin kuin vanhassa versiossa, jossa piti tarvittaessa muokata ”sudoers” tiedostoa, nyt käyttäjä täytyi lisätä SUDO – ryhmään, jonka jälkeen sudo toimi normaalisti.

Seuraava päivitys alkutoimineen 12_04:stä 14_04:ään meni läpi nopeammin, periaatteessa samalla tavalla kuin ensimmäinenkin. Uudelleen käynnistys  onnistui, mutta Apache2 ei käynnistynyt, herjaten ”httpd.conf – tiedostoa ei löydy /etc/apache2/ hakemistosta”. Päivitys oli omin päin säveltänyt asetuksia. Aikaisemmissa versioissa mainittu tiedosto oli /etc/apache2/conf-available/  -hakemistossa. Ongelmia oli myös joidenkin Apachen moduulien kanssa, joita piti poistaa tai lisätä.

Kun Apachen vihdoin sai käynnistymään, niin blogi -sivua ei näkynyt, ”Access denied”. Sen sai korjattua virtualhostin hakemistodirektiivillä: Option Indexes FollowSymlinks Allow Override None Require all Granded.  Nyt blogi näkyi, mutta huomasin, ettei mm. ”luettu” – laskuri enää toiminut. Se johtui siitä, että versioon 5.5.43 päivittyneen MySQL:n käskykanta oli uudistunut, eikä mm. sessiokohtainen @mysql_query – käsky enää toiminut. WordPressin omat tietokantafunctiot toimivat, mutta niillä on hankalaa toteuttaa INSERT ON DUPLICATE KEY UPDATE  – tehtävää. Ensimmäinen korjausyritykseni ”pissi” pahasti ja nollasi juttujen laskurit harmillisesti ja esim. Luetuimmat jutut – palkki meni täysin sekaisin. Varmuuskopio oli toisella serverin kovalevyllä, jonka huolimattomuudessani pudotin tietokoneen päältä pöydälle, niin, että se kolahti kunnolla ja nyt systeemi tilttaa, jos levyn kytkee koneeseen. Se saattaa käydä vähän aikaa ja sitten kuuluu ”klonks” ja serveri hyytyy. En vielä tiedä, saanko kopioita palautettua, vai joutuuko katselukertojen ”keräämisen” aloittamaan alusta. Eipä se kai mitään, onhan tuota elämässä muissakin asioissa joutunut aloittaa kaikki alusta.

Pari päivää myöhemmin. Sain kuin sainkin kolahtaneen kovalevyn toimimaan toisessa koneessa ja kopioitua WordPressin tietokannan varmuuskopion sieltä pois koneelleni. Tarvitsin kuitenkin vain omatekemäni ”postviews” taulua. Se saaminen onnistui siten, että latasin Webmin -hallintaohjelman avulla mainitun wordpressin varmuuskopion tilapäiseen ”testi” -tietokantaan. Sen jälkeen varmuuskopioin vain ”postviews” taulun serverin hakemistoon, josta latasin sen wordpressin tietokantaan. Se onnistui ja sain kuin sainkin aikaisemmat ”luettu” -lukemat palautettua takaisin!