Johdanto
Kuvaan tässä dokumentaatiossa tuotannossa olevan www-palvelimeni käyttöjärjestelmäpäivityksen vaiheet. Aluksi kuvaan, miten toteutin varmuuskopioimisen ja päivitystä edeltävät vaiheet. Lopuksi kuvaan korjaukset niihin ongelmiin, joita päivityksen jälkeen esiintyi.
Päivitys tapahtui Ubuntu 16.04 -versiosta LTS-versioon 18.04.3.
Varmuuskopiointi
Ennen päivitystä otin ensiksi talteen kaikki WordPress-sisältöni. Tämä tapahtui WordPressin hallintapaneelista navigoimalla Tools > Export >All Content > Download Export File. Työkalu lataa tiedot XML-muodossa.
Tämä varmuuskopioi ainoastaan WordPressin sisällön siitä WordPress-asennuksesta, johon olen kirjautuneena. Minulla on samalla palvelimella kolme eri verkkosivustoa omilla WordPress-asennuksillaan. Otin WP-sisällön talteen vain niistä tärkeimmältä, ja otin seuraavaksi koko palvelimesta snapshot-varmuuskopion. Palvelimen kannattaa datan eheyden kannalta olla sammutettuna samalla, kun snapshot otetaan. Kirjauduin palvelimelleni SSH-yhteydellä ja ajoin komennon:
sudo poweroff
Kirjauduin DigitalOceaniin, josta vuokraan Ubuntu virtuaalipalvelintani. Navigoin sieltä Droplets > markuspyharanta.com > Snapshots > Take snapshot.
Snapshot tallentaa palvelimen tilan kokonaisuudessaan, ja voin käyttää sitä tarpeen vaatiessa täysin identtisen palvelimen pystyttämiseen samoilla konfiguraatioilla ja tiedostoilla. Snapshotin luomisessa kesti jonkin aikaa.
Kun snapshot oli valmis, näkymä oli tällainen:
Päivitystoimenpiteet
Varmuuskopionti oli hoidettu, joten käynnistin palvelimen hallintapaneelista.
Kun palvelin oli päällä, otin siihen konsoliyhteyden DigitalOceanin hallintapaneelin yläreunasta. SSH-yhteys saattaa reistailla päivityksen aikana, joten on huomattavasti turvallisempaa suorittaa päivitystoimenpiteet konsoliyhteyden kautta.
Kirjauduin tunnuksillani sisään. Palvelimeni ilmoitti heti, että 106 pakettia olisi päivitettävänä, joista yksi on tietoturvapäivitys. On sanomattakin selvää, etten hetkeen ole päivittänyt palvelintani, vaikka pitäisi.
Aivan ensimmäisenä päivitin pakettivarastot komennolla:
sudo apt-get update
Sitten päivitin jo asennetut paketit komennolla:
sudo apt-get upgrade
Kesken pakettien päivityksen sain ilmoituksen “A new version of /boot/grub/menu.lst is available, but the version installed currently has been locally modified. What would you like to do about menu.lst?”.
Vastausvaihtoehdot olivat:
- install the package manager’s version
- keep the local version currently installed
- show the differences between the versions
- show a side-by-side difference between the versions
- show a 3-way difference between the available versions
- do a 3-way merge between all available versions (experimental)
- start a new shell to examine the situation
Googlasin asiaan liittyen ja totesin, että menu.lst voidaan ylikirjoittaa pakettiylläpitäjän julkaisemalla versiolla. Vastasin siis “install the package manager’s version“.
Paketit päivittyivät, jonka jälkeen ajoin vielä toisen komennon pakettien päivitykseen liittyen:
sudo apt-get dist-upgrade
Komento tekee muuten saman kuin sudo apt-get upgrade, mutta se ottaa huomioon myös ohjelmistoriippuvuudet ja kykenee siten päivittämään paketteja, joihin upgrade-komento ei välttämättä kykene.
Komento meni nätisti läpi ilman valituksia. Osa asennuksista edellytti uudelleenkäynnistyksen, joten käynnistin palvelimen uudelleen komennolla:
sudo shutdown -r now
Palvelin käynnistyi uudelleen, ja kirjauduin takaisin sisään. Näin, että kaikki aiemmin ehdotetut pakettipäivitykset oli asennettu.
Sitten siirryin päivittämään Ubuntun versiota. Tämä on se vaihe, joka todennäköisimmin aiheuttaa ongelmia. Siksi varmuuskopioista tulee huolehtia, eikä komentoa kannata ajaa, ellei ole luottavainen kykyynsä palauttaa tiedostoja ja palveluita tarvittaessa.
Versiopäivitys komennolla:
sudo do-release-upgrade
Hetken kuluttua minulta kysyttiin, haluanko ylikirjoittaa sources.list -tiedoston. Vastasin “y” eli kyllä.
Päivitystoimintojen alustaminen jatkui, ja hetken päästä minulta kysyttiin haluanko varmasti aloittaa päivityksen. Kuulemma kolme pakettia tullaan päivityksen yhteydessä poistamaan, 123 uutta pakettia asennetaan ja 460 pakettia päivitetään.
Vastasin “d” eli “Details”, jotta näin, mitä ollaan poistamassa.
Poistettavat paketit liittyivät mm. Perliin, joten en nähnyt tässä ongelmaa.
Painoin “q“, jotta pääsin takaisin vastausvaihtoehtoihin. Sitten painoin “y” eli “Yes”.
Ubuntu päivitteli pitkään, kunnes se kysyi “What do you want to do about modified configuration file sshd_config?” Vastausvaihtoehdot olivat:
- install the package maintainer’s version
- keep the local version currently installed
- show the differences between the versions
- show a side-by-side comparison between the versions
- start a new shell to examine the situation
Tiesin, että olin itse tehnyt muutoksia sshd_config-tiedostoon, enkä halunnut niitä ylikirjoitettavan. Valitsin täten “keep the local version currently installed“.
Päivitysohjelma jatkoi päivitystoimenpiteitään, kunnes se kysyi “Remove obsolete packages?“. Ohjelma löysi 108 pakettia, jotka olivat uudessa versiossa turhia.
Vastasin “d” eli “Details”, jotta näen, mitä olen mahdollisesti poistamassa.
Joukossa oli mm. PHP7.0, jota tarvitsen www-palvelimeni LAMP-pinon toimintaan. Annoin ohjelman kuitenkin poistaa sen, ja päätin asentaa PHP:n uusimman version sitten jälkeenpäin.
Painoin “q“, jotta pääsin takaisin vastausvaihtoehtoihin. Sitten painoin “y” eli “Yes” ja sallin luvan pakettien poistamiselle. Päivitysohjelma alkoi poistamaan paketteja, kunnes se ilmoitti päivityksen valmistumisesta ja pyysi uudelleenkäynnistämään järjestelmän. Kyseisessä ruudussa näkyi myös, että se ei poistanut /etc/php/7.0/-hakemiston sisältöä, sillä se ei ollut tyhjä. Tämä olikin hyvä, sillä sain myöhemmin vanhat konfiguraatiotiedostoni siirrettyä sieltä suoraan PHP:n uuteen hakemistoon.
Painoin “y“, jolloin järjestelmä käynnistettiin uudelleen. Palvelimen käynnistyttyä kirjauduin takaisin sisään ja totesin käyttöjärjestelmän olevan versiossa Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-58-generic x86_64).
Testasin heti ensiksi verkkosivujeni toiminnan, mutta sain 503-errorin:
Tämä oli toki luontevaa, sillä PHP poistettiin päivityksen yhteydessä. Tällöin dynaamiset WordPress-sivuni ovat alhaalla. Varmistin virheen johtuvan PHP:sta Apachen lokitiedoista komennolla:
sudo tail -f /var/log/apache2/error.log
Sivuston uudelleenlatauksen yhteydessä lokiin kirjautui aina uusi virheilmoitus proxy_fcgi-virheestä, sillä yhdistäminen PHP-FPM:n käyttämään unix-sockettiin epäonnistui. Korjasin ongelman asentamalla PHP:n ja sen tarvitsemani lisäosat uudelleen.
Ensiksi päivitin pakettivarastot:
sudo apt-get upgrade
Sitten etsin PHP-FPM:n uusinta versiota komennoilla:
sudo apt-cache search php-fpm
Uusimmat paketit olivat versiota 7.2. Asensin tarvittavat paketit PHP-FPM ja LAMP-pinon toimintaan:
sudo apt-get install php libapache2-mod-php php7.2-fpm php7.2-mysql
Tarkistin hakemistosta /etc/apache2/mods-enabled/, että PHP-FPM:n tarvitsemat Apache-lisäosat olivat yhä käytössä. Sen jälkeen kopioin PHP-FPM poolien konfiguraatiotiedostot uuteen hakemistoon vanhasta:
sudo cp /etc/php/7.0/fpm/pool.d/markus.conf /etc/php/7.2/fpm/pool.d/
Muokkasin kutakin siirtämääni konfiguraatiotiedostoa ja päivitin unix-socketin nimeen oikean PHP7.2-version. Esimerkki:
Käynnistin PHP-FPM-palvelun uudelleen:
sudo service php7.2-fpm restart
Sitten muokkasin vielä Apachen konfiguraatioita hakemistossa /etc/apache2/sites-available/ ja korjasin sinne sockettien uudet nimet Set-Handler-kohtaan:
Käynnistin Apachen uudelleen:
sudo service apache2 restart
Sivustoni olivat taas toiminnassa:
TÄTÄ DOKUMENTTIA SAA KOPIOIDA JA MUOKATA GNU GENERAL PUBLIC LICENSE (VERSIO 3 TAI UUDEMPI) MUKAISESTI. HTTP://WWW.GNU.ORG/LICENSES/GPL.HTML
MARKUS PYHÄRANTA