Nopean WordPressin asennus virtuaaliserverille

MariaDB

Tietokanta pitää sisällään kaikki WordPress-sivujen ja -sisältöjen tiedot. Sinne tallennetaan myös paljon muutakin järjestelmän tarvitsemia asioita. Aina kun kuulet sanaparin dynaaminen sivusto, niin se tarkoittaa sitä, että webpalvelin (Nginx) kysyy palvelulta (WordPress) sivua, ja WordPressin PHP pyytää tietokannalta tiedot, jotka se parsii sivuiksi.

Tietokantoja on useita, joista kolmea käytetään eniten. Web-maailmassa puhutaan niissäkin aina käytännössä kahdesta, MySQL ja MariaDB, jotka ovat käytännössä samoja – paitsi että MariaDB on hieman kuin anabolisia napsinut versio MySQL-tietokantaohjelmasta. Joten asennetaan MariaDB:

apt install mariadb-server

MariaDB (kuin myös MySQL, niissä käytetään pääosin aina samoja komentoja) asennetaan hieman toisin kuin muut ohjelmat. Sillä on tärkeimmille asioille oma komento:

mysql_secure_installation

Kaikka kohdat valitaan enterillä. Kun luodaan root-tunnukselle salasana, niin anna sellainen, mutta älä käytä samaa kuin millä kirjaudutaan terminaaliin. Asetusten jälkeen terminaalisi ikkuna näyttää tältä:


root@demo:/# mysql_secure_installation

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none):
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.

Set root password? [Y/n]
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!

By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n]
... Success!

Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n]
... Success!

By default, MariaDB comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n]
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n]
... Success!

Cleaning up...

All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.

Thanks for using MariaDB!
root@demo:/#

Testaa, että pääset kirjautumaan MariaDB:hen:

mysql -u root

Komentokehoitteen pitäisi muuttua tällaiseksi:


root@demo:~# mysql -u root
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 72
Server version: 10.3.22-MariaDB-1ubuntu1 Ubuntu 20.04

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

Pääset pois antamalla komennon:

exit;

Root ei tarvitse tietokantaan kirjautumiseen salasanaa. Muut eivät kuitenkaan pääse kirjautumaan MariaDB:hen ja unix_socket tunnistaa sinut järjestemään kirjautumisesta rootiksi. Jos et pidä sitä mukavana, niin pystyt pakottamaan salasanakyselyn näin:

mysql -u root
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'tietokannan-salasana';
FLUSH PRIVILEGES;
EXIT;

Nyt tietokantaan kirjautumiseen vaaditaan salasana:

mysql -u root -p

Joskus asiat menevät toisinpäin, ja oivallatkin, että rootin salasana ei sinällään turvaakaan mitään, ja haluat takaisin salasanattomaan, niin se on parilla komennolla hoidettu:

ALTER USER root@localhost IDENTIFIED VIA unix_socket;
FLUSH PRIVILEGES;

Osa ohjelmista ei kuitenkaan pidä siitä, että salasana hävisi. Siinä saa hieman tilanneta parannettua, kun viedään salasana luettavaksi:

nano /root/.my.cnf

Lisää sinne tämä:


[client]
password=ROOTIN-SALASANA

Silti sinulle saattaa tulla ongelmia phpMyAdmin tai Adminerin kanssa, jotka vaativat salasanan. Sanoisin, että niitä varten kannattaa tehdä toinen käyttäjä pelkästään niiden tarpeisiin ja sille annetaan samat oikeudet kuin rootille.

 

Palomuuri UFW

Palomuuri suojelee ulkomaailmalta ja sallii webbisivujen ja muiden palveluiden turvallisen käytön. Se on asennettava ennen kuin mitään päästetään linjoille. Tarkkaan ottan palomuuri on ohjelma nimeltään itables ja ufw on sen käyttöliittymä, mutta usein sanotaan yksinkertaisuuden nimissä, että ufw on palomuuri.

Se on todennäköisesti jo asennettuna, mutta varmistetaan asia:

ufw status

Jos sait vastaukseksi Status inactive niin ufw on paikoillaan, mutta ei käynnissä. Tällä hetkellä kukaan muu kuin sinä ei pääse serverille. Jos sait vastaukseksi, että ufw:tä ei löydy, niin asenna se:

apt install ufw

Nyt on aika avata ovet maailmalle, vaikka ensimmäistäkään sivusto ei ole vielä asetettu. Mutta webserveri ja SSH on kuitenkin käytössä.

Perustasollaan UFW (lyhennys englanninkielisestä nimestä Uncomplicated FireWall, mutkaton palomuuri) on todella helppo säätää. Katsotaan mitä on valmiina odottamassa:

ufw app list

Se näyttää tältä:


root@demo:~# ufw app list
Available applications:
Nginx Full
Nginx HTTP
Nginx HTTPS
OpenSSH

UFW sallii aukaisemisia, sulkemisia ja muuta kulunvalvotaa per portti tai porttialue, saapuvien IP-osoitteiden mukaan tai minkälaista yhteyttä ollaan tekemässä, mutta nyt päästään helpommalla. Käytetään valmiita ratkaisuja asennettujen ohjelmistojen mukaan. Meitä kiinnostaa Nginx FULL, että saadaan nettiliikenne auki tavalliselle http:lle eli porttiin 80 sekä https portista 443. Kun jossain vaiheessa otat SSH:n käyttöön, niin sekin on hyvä mahdollistaa.

Aukaisuun tarvitaan pari yksinkertaista komentoa:

ufw allow 'Nginx Full'
ufw allow OpenSSH

Käynnistetään palomuuri:

ufw enable

Sinulle ilmoitetaan, että käynnistys saattaa katkaista nykyisen SSH-yhteyden. Se ei haittaa, sillä jos et ole jossain välissä itse tehnyt SSH:ta, niin se ei ole edes käytössä. Vastaa y.

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y

Saat ilmoituksen, että palomuuri on käytössä ja se käynnistetään serverin mukana.

Firewall is active and enabled on system startup

Tarkistetaan vielä mikä on nykyinen tilanne:

ufw status

Sinulle kerrotaan mitkä ovat käynnissä:


root@demo:~# ufw status
Status: active

To                  Action       From
--                  ------       ----
Nginx Full          ALLOW        Anywhere
OpenSSH             ALLOW        Anywhere
Nginx Full (v6)     ALLOW        Anywhere (v6)
OpenSSH (v6)        ALLOW        Anywhere (v6)

Fail2ban

Fail2ban on ohjelma, joka seuraa epäonnistuneita kirjautumisia, yrityksiä väärään paikkaan ja kaikkea muuta, joka ei ole sallittua. Kun yrityksiä tulee liikaa, niin Fail2ban estää IP-osoitteen määrätyksi ajaksi kirjoittamalla iptablesiin (siihen aitoon palomuuriin) säännön, joka keiltää pääsyn kokonaan. Hyödyllinen apuväline, koska murtoyrityksiä tulee koko ajan. Joten muista pitää niin serverisi kuin WordPressin päivitykset ajan tasalla.

Asennetaan Fail2ban:

apt install fail2ban

Se ei ole tällaisenaan kovinkaan hyödyllinen, mutta suojaa ainakin SSH:n. Säädetään se myöhemmin avuliaammaksi, kun ollaan saatu sivusto paikoilleen.

Annetaan sen käynnistyä automaattisesti, kun serverikin käynnistyy:

systemctl enable fail2ban

Käynnistetään se:

systemctl start fail2ban

Vilkaistaan saman tien onko se jo pyydystänyt IP-osoitteita, jotka ovat yrittäneet kirjautua serverille:

fail2ban-client status sshd

Minulla tulos oli tällainen, kun droplet oli noin kolmen tunnin ikäinen:


root@demo:~# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 9
| |- Total failed: 45
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 140.143.238.46

Tuo tarkoittaa, että sillä hetkellä oli yksi IP-osoite bannattu ja logissa oli kaikkiaan 45 yritystä, joista 9 oli tutkittavan aikajanan sisällä, mutta yrityksiä ei ollut riittävästi – nuo kaikki määritellään asetuksissa, myöhemmin.

Kokeillaan yhtä komentoa lisää. Katsotaan mistä tuo IP-osoite oli:

whois 140.143.238.46

inetnum: 140.143.0.0 - 140.143.255.255
netname: TencentCloud
descr: Tencent cloud computing (Beijing) Co., Ltd.
descr: Floor 6, Yinke Building,38 Haidian St,
descr: Haidian District Beijing
country: CN

Kiinalainen botti. Noita riittää. Jopa niin paljon, että pystyvät saamaan serverisi jopa kyykistymään. Kiina ja Iran ovat niin pahoja ongelmia, että sinun kannattaa tulevaisuudessa miettiä niiden bannaamista kokonaan. Toki Fail2ban siivoaa niitä minkä ehtii, mutta sinulla on hyvin äkkiä kymmeniä tuhansia IP-osoitteita Fail2bannin sulkulistalla.

Nimipalvelintiedot

Ennenkuin voidaan kertoa Nginxille mitään domaineista, niin DNS- eli nimipalvelintiedot täytyy ensimmäisenä laittaa kuntoon. Se edellyttää, että maailman nimipalvelimet osaavat kytkeä domainisi DigitalOceaniin. Joudut muuttamaan domainiin liitetyt nimipalvelimet DigitalOceanin palvelimiksi. Tämä on tehtävä aina, siihen ei ole poikkeuksia.

Kirjaudu ensimmäiseksi sinne mistä olet domainin ostanut. Sieltä sinun pitäisi löytää paikka, jossa asetetaan nimipalvelimet. Se löytyy kaikilta, eikä sinällään ole merkitystä missä domainisi on säilytyksessä.

Hieman varoituksen sanaa. Vieläkin löytyy pieniä (ja poikkeuksellisen halpoja) domain-trokareita, jotka itseasiassa rekisteröivät maksamasi domainin omiin nimiinsä. Ja se on sitten heidän ja he päättävät mitä sille tehdään. Voit välttää tuon käyttämällä isoja ja tunnettuja yrityksiä.

Name.com

Jos ostit domainin Name.com sivustolta, niin kirjaudu sinne.

  • Klikkaa sinistä laatikkoa My Domains
  • Klikkaa domainin kohdalta Quick Links
  • Valitse kohta Manage Nameservers

  • Laita tilalle DigitalOceanin nimipalvelimet: ns1.digitalocean.com, ns2.digitalocean.com ja ns3.digitalocean.com. Minä sain ne suoraan kohdasta Nameserver Templates, mutta en tiedä johtuuko se siitä, että minulla on tuolla useampi domain, joiden kaikkien nimipalvelimet ovat DigitalOceanin.

Louhi

Louhi on kotimainen iso toimija, jolta minulla oli aikoinaan webhotellit. Ne lakkasivat riittämästä minulle ja nykyään minulla on heillä enää muutama domain ja pienin webhotelli sähköpostien backupina – jos omat viritykset hajoavat, niin sitten käytän sitä korvaavana.

Heillä, ja ylipäätään vastaavilla, nimipalvelimet saa muutettu kirjautumalla hallintaan, siirtymällä verkkotunnuksiin, klikkaamalla domainia ja muokkaamalla kohtaa nimipalvelimet.

A-tietue

DNS-tiedoissa kerrotaan mistä domain löytyy. Jos nimipalvelin on kuin iso puhelinluettelo (huono vertaus, jos et ole koskaan puhelinluetteloa käyttänyt), niin DNS:n A-tietue on kuin luettelossa oleva nimi, tässä domain. Puhelinnumeroa vastaisi tieto missä IP-osoitteessa sivut eli webserveri majailee.

DNS-tietueet annetaan DigitalOceanin (tai missä sitten serverisi piileekään) hallinnassa. Jossain piileskelee sellainen kohta kuin DNS records tai vastaava. DigitalOceanilla löydät sen klikkaamalla valikosta Networking ja sitten domainin nimeä.

Sinun täytyy lisätä kaksi A-tietuetta: toinen yleinen @ ja toinen on www.

Lisää @ kohtaan hostname. Will direct to on dropletisi IP-osoite. TTL:n voi jättää ennalleen (yleensä 3600). Sen jälkeen hyväksyt. Tee sama www:lle.

 

Sinulla pitäisi olla kaksi A-tietuetta, toinen example.tld ja toinen www.example.tld, ja kolme nimipalvelinta.

 

Aika, jonka jälkeen maailma löytyy sivustosi (jos sellainen olisi tehtynä) vaihtelee. Joskus se päivittyy minuuteissa, joskus menee tunteja. Koska maailman nimipalvelimet päivittyvät omaan tahtiinsa, niin sinä saatat päästä, mutta naapuri eri operaattorilla ei.

Let’s Encrypt

Kiitos Googlen, niin SSL-sertfikaatti (https-osoitteet) tulivat käytännössä pakollisiksi. Niiden kuvitellaan suojaavan kaikelta maailman pahuudelta ja olevan kuin jokin sivustojen virussuoja. Aidosti SSL tarkoittaa salattua yhteyttä kävijän selaimen ja serverisi välillä, ei muuta. Se suojaa liikennettä siinä tapauksessa, että joku pääsee murtautumaan johonkin kohtaan tiedonsiirtoväylälle. Tuo on enemmän kuin vaikeaa, mutta toki mahdollista taloyhtiöiden jakamoissa.

Sekin on oma juttunsa, että mitä sellaista tietoa siirretään, josta olisi murtautujalle pienintäkään hyötyä. Jos sinulla on verkkokauppa, niin silloin salaamaton yhteys voisikin olla ongelma – mutta yksikään maksunvälittäjä ei toimi, jos verkkokaupan liikenne ei ole SSL-suojattua.

Google pakotti kuitenkin kaikki ottamaan SSL-sertifikaatin uhkaamalla rankaista salaamatonta yhteyttä käyttäviä hakutuloksissa romahtamalla. Jokainen selainvalmistaja lähti leikkiin mukaan ja nyt huudellaan turvattomista yhteyksistä silloinkin, kun vain luetaan sisältöä.

Ei-niin-kauan-sitten SSL-sertifikaatit olivat taloudellinen kysymys. Ne maksoivat aika paljon. Kenttä muuttui sen jälkeen, kun Let’s Encrypt alkoi jakamaan sertifikaatteja ilmaiseksi. Sen takia tällä hetkellä ei ole mitään varsinaista syytä miksi SSL ei olisi käytössä.

Asennetaan Lets Encrypt:

apt install letsencrypt

Nginx kaipaa työkalun, jolla sertifikaatin hakeminen onnistuu ehkä helpommin. Itseasiassa sitä ei ehdottomasti tarvita, mutta haetaan se kuitenkin:

apt install python3-certbot-nginx

Haetaan sivustolle SSL-sertifikaatti. Joudut asettamaan sen www-muotoiselle ja ilman. Samaten saisit kytkettyä samaan kaikki alidomainit, 100 maksimissaan. Esimerkki on aidolla domainilla, joten eksis.dev kannattaa muuttaa.

certbot certonly --nginx -d eksis.dev -d www.eksis.dev
  • Sinulta pyydetään sähköpostiosoitetta tiedotteita varten. Se on pakko antaa.
  • Joudut hyväksymään ehdot. Anna A ja enter.
  • Sinulta kysytään haluatko Electronic Frontier Foundation järjestön, joka tarjoaa Lets Encryptin. uutiskirjeet. Valinta on vapaa. Enkä se kannattaa tilata, ainakin hetkeksi. Vaikka listan aiheet ovat hyvin amerikkalaiskeskeisiä, niin he ajavat internetin riippumattomuutta. Suomalainen EFFi ry. on samaa porukkaa.

Hain sertifikaatin yhdelle domainille ja syöte oli tämän näköistä:


root@demo:~# certbot certonly --nginx -d eksis.dev -d www.eksis.dev
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): jakke.lehtonen@gmail.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at

 
 
 
 
 
 
 
 
 
 
 
 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: A

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: Y
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for eksis.dev
http-01 challenge for www.eksis.dev
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/eksis.dev/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/eksis.dev/privkey.pem
Your cert will expire on 2020-09-02. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

Huomaa: 5x tunnissa/viikossa… siksi domainin täytyy toimia ennenkuin alkaa yrittämään, ainakin jos käyttää –webroot
let’s encrypt limit

 

Virtual hostin luominen

Se mikä mielletään domainiksi, on webservereillä nimeltään virtual host. Virtual hostin asetuksissa kerrotaan mm. mihin domainiin se liittyy, missä tiedostot ovat, kuka saa nähdä mitä jne. Joten nyt aletaan luomaan varsinaista asiaa.

Websivujen hakemistot voivat olla missä tahansa, mutta Ubuntussa ne ovat tyypillisesti hakemistossa /var/www. Yleensä tehdään yksi hakemisto lisää domainin nimellä ja sen alla on public_html, joka pitää sisällään sitten varsinaiset sivuston vaatimat tiedostot, kuten vaikka WordPressin. Tehdään hakemistot.

Käytän tästä eteenpäin esimerkkinä aitoa domainia eksis.dev, joten muuta se.

mkdir -p /var/www/eksis.dev/public_html

Virtual hostien määrittelyt ovat Nginxissä hakemistossa /etc/nginx/sites-available. Virtual hostin nimi saa olla mikä tahansa, mutta usein ne nimetään domainin mukaan – taas kerran selvyyden vuoksi, niin tiedetään mikä on mikäkin. Virtual hostien asetukset, useimmiten puhutaan konffista tai conf-tiedostosta, on tekstitiedosto, joten luominen onnistuu Nanolla:

nano /etc/nginx/sites-available/eksis.dev

Kopioi tämä ja muuta

  • eksis.dev – vaihda jokainen, niitä on useampi
  • server-lohkon IP-numerot oman serverisi IP-osoitteiksi – huomaa: toisessa on IP:n jälkeen :443 ja toisessa :80 ja niiden kuuluukin olla; siinä kerrotaan mistä portista websivuille pääsee
  • 192.168.0.1 kuuluu olla kotisi IP-osoite. Saat sen selville esimerkiksi terminaalista komennolla curl -4 icanhazip.com mutta älä anna sitä ollessasi kirjautuneena serverille, koska silloin se kertoo serverin IP:n. Kirjaudu ensin ulos komennolla exit ja anna sitten tuo. Toinen tapa on kurkata laitteesi virustorjunnasta, sillä sekin usein kertoo mikä IP-osoitteesi on.

Tallenna.

Nginx pitää kahdessa paikassa tiedot virtual hostista. Ensimmäinen on äsken tehty, jolloin hakemistossa /etc/nginx/sites-available ovat kaikki virtual hostit, olivat ne aktiivisia tai eivät. Toinen on /etc/nginx/sites-enabled jossa ovat aktiiviset, linjoilla ja käytössä olevat virtual hostit.

Aidosti hakemistoon sites-enabled ei tehdä muuta kuin symbolinen linkki. Pikakuvake, jos haluat miettiä asiaa Windows-maailman kautta.

Kun haluat sivuston näkyviin, niin komennat:

ln -s /etc/nginx/sites-available/eksis.dev /etc/nginx/sites-enabled/eksis.dev

Tarkista, että kaikki on pääosin kunnossa:

nginx -t

Sen jälkeen ladataan Nginx uudestaan käyttöön (muistatko latauksen ja uudelleenkäynnistyksen erot, tästä oli alussa juttua…):

systemctl reload nginx

Tarkistetaan, että palomuuri on auki ja domain löytyy. Varsinaista sivusisältöähän ei vielä ole. Jos sinulla on mahdollisuus vain yhteen terminaaliin, niin kirjaudu ulos. Nyt yhteytesi ulkomaailmaan tapahtuvat omasta kotiverkostasi. Anna seuraava komento:

ping eksis.dev

Jos saat pingejä (teksti voi vaihdella, mutta aina täytyy näkyä aika):


root@demo:~# ping eksis.dev
PING eksis.dev (134.209.253.188) 56(84) bytes of data.
64 bytes from 134.209.253.188 (134.209.253.188): icmp_seq=1 ttl=64 time=0.022 ms
64 bytes from 134.209.253.188 (134.209.253.188): icmp_seq=2 ttl=64 time=0.054 ms
64 bytes from 134.209.253.188 (134.209.253.188): icmp_seq=3 ttl=64 time=0.073 ms

niin ulkoa pääsee palomuurin läpi ja virtual host löytyy. Kaikki se toimii ainakin vielä kuten kuuluukin.

Saat pingaamisen loppumaan ctrl-C – tuota ei sitten kannata jättää koputtelemaan vierasta serveriä, sillä se täyttää jatkuvana pingaamisena tietoliikennehäirinnän tunnusmerkit.

Jos haluat virtual hostin pois linjoilta, niin symbolinen linkki katkaistaan eli se pikakuvake poistetaan hakemistosta sites-enabled:

unlink /etc/nginx/sites-enabled/eksis.dev
systemctl reload nginx

WordPressin nopein asennus

WordPressin omia asennusohjeita ei kannata noudattaa, vaan nyt hyödynnetään niitä etuja, jotka virtuaaliserveri tarjoaa. Yksi sellainen on nopein WordPress-asennus minkä olet koskaan tehnyt. Kuuluisa 5 minuutin asennushan on aidosti enemmän ja jos joudut lisäksi siirtämään WordPressin tiedostot FTP:llä, niin aika venahtaakin huomattavasti pidemmäksi. Mutta nyt puhutaan aidosti lyhyestä ajasta.

Jos ajatuksesi oli siirtää jo oleva sivusto, niin malta mielesi. Kokeile ensin uuden asentamista, niin pääset asioiden kanssa tutummaksi. Voit myöhemmin jyrätä nyt asennettavan ja tehdäkin sitten muuton – siihenkin löytyy ohjeet.

WP CLI

Ennenkuin asennetaan WordPress, niin tarvitaan aputyökalu: WP CLI. Se on komentorivityökalu, jolla voi tehdä helposti (no, suhteellisen helposti) monia WordPressin asioita – mutta tehokkaammin ja ilman lisäosia.

WP CLI asennetaan hieman eri tavalla kuin mitä yleensä apt install avulla tehtäisiin.

Siirrytään /tmp hakemistoon.

cd /tmp

Ladataan WP CLI.

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

Tehdään siitä suoritettava skripti.

chmod +x wp-cli.phar

Muutetaan nimi käytössä mukavampaan muotoon wp ja siirretään se hakemistoon, josta komento voidaan ajaa riippumatta missä itse ollaan.

mv wp-cli.phar /usr/local/bin/wp

Kokeillaan, että se toimii.

wp --info

Koska WP CLI tekee töitä webhakemistoissa, niin sen pitäisi tiedostojen 0mistajuuksien takia kuulua ryhmään www-data – oikeammin, sinun pitää kuulua, koska komennat WP CLI:tä. Se on helppo asia järjestää:

usermod -aG www-data $USER

WP CLI:n komentoja ei saisi ajaa rootina, koska se on vaarallista, koska root voi tehdä mitä vaan ja jos joku murtautuu rootin tunnukselle, niin sitten hän voi tehdä mitä vaan. Niin voi, se on root-tunnuksen idea. Siksi toiseksi WP CLI:n ajamista ei voida estää rootilta, vaan sitä vaikeutetaan pakottamalla käyttämään aina komennon mukana vipua --allow-root. Asia, jonka WP CLI ystävällisesti jopa kertoo erikseen joka kerta, jos sen unohtaa. Se mitä en ymmärrä, että miksi on turvallisempaa komentaa WP CLI:tä tuolla vivulla kuin ilman? Tai miksi mahdollinen murtautuja ei sitten osaisi samaa vipua käyttää?

Niin tai näin, niin sen antaminen joka hemmetin kerta on suunnattoman ärsyttävää, joten korjataan se. Samalla opitaan uusi asia nimeltään alias. Alias on kuin nimeäisi jonkun komennon tai komentoketjun uudestaan – niin no, sitähän alias nimenomaan tarkoittaa.

Avataan se tiedosto, johon aliakset tehdään:

nano ~/.bashrc
  • tilde eli aaltoviiva tarkoittaa sen käyttäjän kotihakemistoa, joka sinä olet sillä hetkellä. Jos olet kirjautunut rootina, niin ~/ tarkoittaa samaa kuin /root/. Jos olisit joku muu käyttäjä, niin se olisi /home/käyttäjätunnus/

Kelaa alaspäin niin kauan kunnes löydät kohdan # some more ls aliases. Laita niiden perään tämä:

alias wp='wp --allow-root'

Kirjaudu terminaalista ulos ja takaisin sisään. Nyt sinulla on aina automaattisesti mukana --allow-root, kun annat wp komennon.

Tietokannan luominen

WordPressin asentaminen alkaa aina tietokannan luomisella. Kirjaudu MariaDB:hen:

mysql -u root -p
  • Jos sallit rootille kirjautumisen ilman salasanaa, niin voit jättää -p pois.

Luodaan tietokanta. Vaihda wordpress haluamaksesi.

CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Luodaan käyttäjä. wordpress on oltava sama minkä äsken loit ja vaihda tunnus sekä salasana haluamiksesi.

GRANT ALL ON wordpress.* TO 'tunnus'@'localhost' IDENTIFIED BY 'salasana';

Kerrotaan muutokset MariaDB:lle ja poistutaan.

FLUSH PRIVILEGES;
EXIT;

WordPressin lataaminen

Siirry virtual hostisi hakemistoon. WP CLI komennot on ajettava siinä hakemistossa, jossa on tai johon tulee WordPress.

cd /var/www/eksis.dev/public_html

Ladataan WordPress. Siihen menee yleensä luokkaa pari sekuntia. Hakkaa FTP:n 5-0.

wp core download --locale=fi

Luodaan wp-config.php:

wp core config --prompt

Asennus kysyy sinulta muutamia asioita:

  • dbname = tietokannan nimi
  • dbuser = tietokannan käyttäjä
  • dbpass = tietokannan käyttäjän salasana
  • dbhost = localhost
  • dbprefix= wp_ (voi olla haluamasi ja muista alaviiva, se helpottaa)
  • dbcharset = utf8
  • dbcollate = utf8_swedish_ci
  • locale = fi
  • lopuissa hyväksy enterillä oletukset

Saat tehtyä saman asian yhdellä komennollakin. Muokkaa tiedot oikeiksi.

wp core config --dbname='tietokanta' --dbuser='db-käyttäjä' --dbpass='db-salasana' --dbhost='localhost' --dbprefix='wp_' --dbcharset=útf8 --dbcollate='utf8_swedish_ci' --locale='fi'

Ekstraa:

Jos sinulla on tietokantakäyttäjä, jonka rooli sallii tietokannan luomisen, niin sinun ei tarvitse erikseen tehdä tietokantaa, vaan se tehdään samalla kertaa kuin wp-config.php tiedoston luominen. Silloin keksit ensin tietokannan nimen, annat moisen käyttäjän tunnuksen kohtaan db-käyttäjä ja sen salasanan kohtaan db-salasana. Silloin tietokanta luodaan automaattisesti, kun annat komennon wp db create WordPressin asennuksen jälkeen.

Jos käytät moista vain omassa hallussasi oleville sivustoille, niin siinä ei ole mitään ongelmaa. Mutta älä käytä sitä asiakkaiden tai jonkun muun kolmannen asennuksiin, koska he näkevät moisen ”superkäyttäjän” tunnuksen ja salasanan wp-config.php tiedostosta. Jos heillä ei ole pääsyä MariaDB:hen, niin ei se niin tolkuton ongelma ole – mutta silti moiset asiat tavataan pitämään salaisina, koska niiden vuotamisessa on tietoturvariski.

Saat luotua minkä tahansa tietokannan luomisen osaavan tunnuksen kirjautumalla MariaDB:hen ja komentamalla:

GRANT ALL ON *.* TO 'tunnus'@'localhost' IDENTIFIED BY 'salasana';

WordPressin asettaminen

WordPress on vielä asetettava. Silloin kysytään tutut kysymykset urlista, blogin nimestä, adminin sähköpostiosoitteesta jne.

wp core install --prompt

Tässäkin tiedot voidaan antaa suoraan komennolle:

wp core install --url='https://www.example.com' --title='Blogin nimi' --admin_user='admin-tunnus' --admin_password='salasana' --admin_email='email@example.com'

Virheestä /usr/sbin/sendmail ei tarvitse piitata. Se johtuu vain siitä, että sähköposteja välittävää järjestelmää ei ole vielä asennettu.

Oikeudet kuntoon

Tehdään vielä pakolliset kevätjuhlaliikkeet tiedosto- ja hakemisto-oikeuksien kanssa.

Varmistetaan, että webhakemiston omistaa webserveri.

chown -R www-data:www-data /var/www/eksis.dev/public_html
  • Jos saat WordPressin hallinnassa, asetuksia säätäessä tai lisäosia asetettaessa, pyynnön antaa FTP-tunnukset, niin kyse on siitä, että wp-admin ja wp-contest hakemistojen omistajuus on jäänyt tai muuttunut rootille.

Varmista, että olet edelleen virtual hostin hakemistossa. Jos et ole, niin siirry sinne:

cd /var/www/eksis.dev/public_html

Asetetaan luku- ja kirjoitusoikeudet:

find . -type f -exec chmod 644 {} \;; find . -type d -exec chmod 755 {} \;

Kirjaudu WordPressin hallintaan ja muuta osoiterakenne. Testitilanteessakin on ehkä helpointa kun käyttää suoraan artikkelin nimeä ilman kategorioita sun muita.

Lisäosien asennus massana

Lisäosia on helppo asentaa massana, mutta siihen tarvitaan pieni skripti.

nano /usr/local/bin/wp-plugins

Kopioi siihen tämä:

Tehdään siitä suoritettava:

chmod 755 /usr/local/bin/wp-plugins

Skriptissä on yksi kohta, joka on muutettava. Laita riville WPPATH=/var/www/html virtual hostisi oikea polku – minulla se olisi esimerkiksi /var/www/eksis.dev/public_html

Kohdassa WPPLUGINS=( on listattuna asennettavien lisäosien slugit. Slug on sama kuin lisäosan hakemiston nimi tai jos kurkkaat wordpress.org sivustolta lisäosaa, niin slug on urlissa. Esimerkiksi Akismetin url on https://fi.wordpress.org/plugins/akismet/ jolloin sen slug on akismet.

Listaa saa muuttaa. Esimerkissä ovat ne pluginit, jotka lisään aina kaikkiin omiin projekteihini. Sinulla saattaa olla toiset tarpeet.

Kun annat komennon wp-plugins niin lisäosat annetaan ja aktivoidaan.

Urakka on valmis?

Nyt sinulla on WordPress asennettuna ja loppu on sitä mihin meneekin aikaa: teeman asettaminen ja säätäminen, lisäosat jne. Puhumattakaan siitä oleellisimmasta: sisällön tekeminen.

Kun saat tekemiseen hieman varmuutta, niin tämä on ehdottomasti nopein ja mutkattominen tapa asentaa WordPress. Aikaa nollasta kirjautumisvalmiiseen WordPressiin menee muutama minuutti.

Seuraavaksi aletaan tekemään nopeutta.

Cachet

Katsotaan ensin mikä on lähtötilanne. Kyseessä on 5 USD kuussa maksana 1G/1CPU dropletti, joka on asennettu näiden ohjeiden mukaan. WordPressissä ei ole muuta sisältöä kuin Hello World postaus (jonka kautta mittaus tehtiin), eli sekin on täysin muokkaamaton. Kävijöiden määrää nostettiin tasaisesti minuutin aikana 250 samanaikaiseen kävijään.

 

Kuten näkyy, niin serveri hidastui samaan tahtiin kävijämäärän kasvun kanssa. Kun sivustolla oli 50 yhtäaikaista kävijää katsomassa yhtä sivua, niin latausajat olivat lähes 2,5 sekuntia. Tuo on vielä siedettävää. Mutta 100 yhtäaikaisella oltiinkin jo lähemäpänä 5 sekuntia, ja se alkaa olla hidasta. Google alkaa hermostumaan 7 sekunnin jälkeen ja se saavutettiin noin 180 samanaikaisella. Hakutuloksista alkaisi tippua, kun ylitetään 12 sekuntia. Testi onneksi loppui, kun 250 samanaikaista oli paikalla ja siinä vaiheessa latausajat olivat 10 sekunnin luokkaa.

Jotain on siis tehtävä. Ensimmäinen asia on tietysti ostaa isompi droplet, eli enemmän muistia ja useampi prosessori. Mutta se on kilpavarustelussa tuppaa häviämään rahat ja silti ei ole koskaan ensimmäisenä maalissa. Joten otetaan käyttöön välimuistit, cachet.

Redis

Redis on objektivälimuisti. Tuo termihirviö tarkoittaa yksinkertaistettuna, että Redis välimuistittaa esimerkiksi PHP-kutsuja, joita tehdään tietokannalle, kun sivua rakennetaan. Jos Googletat WordPress + Redis, niin löydät melkoisia hehkutuksia miten sivustot ovat nopeutuneet tuhasia prosentteja. En tiedä miten he ovat sen mitanneet, sillä Redis ei nopeuta sivustoja. Redis vähentää teeman ja lisäosien vaatimien kutsujen määrää, mutta edelleen joudutaan kuitenkin muodostamaan tietokantayhteys. Jos mietitään perustana olevaa tekniikkaa, niin webserverin ja PHP:n yhteys tietokantaan on merkittävin hidastava kapeikko.

Redis helpottaa kuormaa, jolloin sivusto saattaa pysyä paremmin pystyssä.

Asennetaan se, jo kohtuullisen tutulla tavalla:

apt install redis-server

Siirretään Redisin asetustiedosto turvaan:

mv /etc/redis/redis.conf /etc/redis/redis.conf.backup

Tehdään uusi conf-tiedosto:

nano /etc/redis/redis.conf

Avaa tiedosto ja kopioi sisältö. Siitä ei tarvitse sen enempää muuttaa, mutta jos/kun sinulla on riittävästi muistia (lue: 4 gigaa tai yli), niin etsi kohta maxmemory 64mb ja voit nostaa sen vaikka 128 megaan. Todella kiireisillä ja isoilla servereillä sitä kannattanee nostaa vieläkin enemmän.

Sallitaan Redisin käynnistyminen serverin mukana:

systemctl enable redis-server

Käynnistetään Redis:

systemctl start redis-server

WordPress ei osaa suoraan hyödyntää Redisiä, joten siihen tarvitaan lisäosa. Varmista, että olet edelleen hakemistossa /var/www/eksis.dev.

Asennetaan lisäosa WordPressiin:

wp plugin install redis-cache

Muokataan wp-config.php tiedostoa:

nano wp-config.php

Kopioi tämä alkuun, heti <?php jälkeen seuraavalle riville:

Otetaan lisäosa käyttöön:

wp plugin activate redis-cache

Käynnistetään myös PHP-FPM uudestaan:

systemctl restart php7.4-fpm

Kirjaudu WordPressin hallintaan. Mene kohtaan Apuohjelmat > Redis ja ota Redis käyttöön klikkaamalla sinistä painonappulaa Enable Object Cache.

Nyt sinulla WordPress osaa hyödyntää Redisiä.

Nginx ja sivukohtainen välimuisti

Jos etsit WordPressiin cache-lisäosaa, niin paras on ehdottomasti WP Rocket. Se muodostaa dynaamisesta sisällöstä staattisia valmiita sivuja, jotka sitten tarjoillaan kävijälle. Webhotelliasiakkaille se on ehdoton hankinta ja nopeuttaa sivustoa huomattavasti. Ei tarvita enää tietokantakutsuja ja PHP:tä, koska sivut on tehty valmiiksi odottamaan käyttöä.

Itse käytän sitä myös serveritason cache-ratkaisujen kanssa. Nopeuttaa entisestään.

Virtuaalipalvelimella voidaan mennä astetta pidemmälle, ja ilmaiseksi. Annetaan Nginxin olla ns. reverse proxy. Tuo on suomeksi ehkä käänteinen välimuisti. Proxy suhtautuu eräällä tavalla muuhun maailmaan yhtenä ja tarjoaa kuin yhdelle kävijälle erilaista sisältöä. Reverse proxy tarjoaa samaa välimuistitettua sisältöä usealle eri kävijälle – siksi se on käänteinen.

Suomeksi: Nginx tekee välimuistiin kopion jo käydystä sivusta eikä päästä kävijää webpalvelimelle. Tässä Nginx on hieman jakomielitautinen, koska se itse on niin cache kuin webpalvelinkin – mutta pointti on siinä, että säästetään kaikki se aika, joka sivun tekemiseen menisi.

Ero esimerkiksi WP Rockettiin tulee siinä, että kun kävijä haluaa katsoa jotain sivua, niin webpalvelin kysyy ensin WordPressiltä onko moista, jolloin WP Rocket (ja muut cache-lisäosat) astuu esiin ja sanoo, että hänellä on moinen, koska koko sisältö on rakennettu taustalla staattiseen muotoon. Se sitten siirretään kävijälle.

Kun Nginx on cachenä, niin kävijän halutessa  sivua Nginx ei kysele keneltäkään mitään, vaan antaa sen omasta muististaan. WordPressin näkökulmasta ketään ei ole koskaan käynytkään. Mutta sivu voidaan tarjota cachestä vain, jos joku on jo katsonut sitä. Ensimmäinen hakee aina sivun WordPressistä (jonka takian WP Rocket hieman nopeuttaa, ainakin yhdelle ihmiselle, myös reverse proxyn kanssa).

Vilkaistaan mitä Nginxin proxy tekee dropletille.

Edellisessä testissä käyttäjälle siedettävän latausajan raja oli noin 50 yhtäaikaisessa kävijässä ja silloin puhuttiin 2,5 sekunnista. Testi oli rajattu 250 yhtäaikaiseen minuutin kuluessa, koska noin 300 kohdalla alkoi tulla muistin loppumisen takia niin paljon virheitä yhteyksissä, että moisessa ei ollut mitään järkeä.

Nyt käytössä oli Redis ja Nginxin cache. Laitoin maksimiksi yhtäaikaisten kävijöiden määräksi 1000, joka saavutettiin minuutissa. Ero on huomattava. Ensimmäiset ovat saaneet 0,4 sekuntia, kun cache lämmitettiin. Sen jälkeen pysyttiinkin tasaisesti latausajoissa noin 0,2 sekunnissa aina 500 kävijään asti, jonka jälkeen muistia kului hitusen lisää ja latausajat vakiintuivat noin 0,3 sekuntiin.

Ilman cacheä 50 samanaikaista sai 2,5 sekunnin latausajan ja cachellä 1000 samanaikaista odotteli 0,3 sekuntia. Miten on, asennetaanko cache?

Testi ei tietenkään kuvaa aitoa maailmaa. Tuossa käytettiin vain yhtä sivua, ja reaalimaailmassa saattaakin tulla 50 kävijää yhtä aikaa, joista jokainen lataa eri sivun, eikä cache pääse mukaan. Mutta kävijäpiikkejä se tasaa tehokkasti.

Koska kaikki asennusohjeet, mukaanlukien tämäkin, esittelevät aina ns. blankkoa WordPress-asennusta, jossa ei ole sisältöä, ei lisäosia, ei page builderia, ei mitään, niin laitetaan näkyviin hieman realistisempi testi. Ajoin saman EksisONE sivuston etusivulle. Käytössä on teema Kallyas (mukava, mutta ei kevyt) ja sisältökin kiertää Basepress FAQ-lisäosan kautta. Cache on kylläkin Varnish, ei Nginxin sisäinen, mutta sillä ei ole käytännön merkitystä tässä.

Kun välimuistia ei ollut, niin 25 samanaikaisellä latausaika oli kahdessa sekunnissa. Kun päästiin 125 samanaikaiseen latausajan ollessa yli 8 sekuntia, niin serveri romahti. Siinä meni rasituksen yläraja 8 GB/4 CPU dropletilla, jossa oli testin lisäksi muilla sivustoilla ehkä noin pari sataa aitoa ihmistä.

Laitetaan cache päälle:

Ero on… dramaattinen lienee sopiva kuvaus. Cachen avulla yhden minuutin aikana saapuneen 250 kävijän kanssa latausajat pysyivät alle 0,8 sekunnissa. Ajoin toisen testin, jossa sivustolle ajettiin minuutin aikana 10 000 kävijää. Latausajat menivät yli 2 sekunnin noin 750 kävijällä. Ensimmäiset ongelmat alkoivat tulla noin 4500 kävijän paikkeilla, jolloin tuli ensimmäiset time-ot virheet, latausajat olivat hieman yli 8 sekuntia. 5000 kävijän kohdalla joka viides sai jo time-outin ja noin 5200 samanikaisen kohdalla serveri ei enää kestänyt. Kaatuminen tuli liian monesta auki olevasta yhteydestä ja hoituisi osaksi useammalla prosessorilla, osaksi hieman säätämällä.

Tuo kaikki tarkoittaa muutamaa asiaa:

  • yksikään kuluttajatason webhotelli ei milloinkaan selviä kävijäryntäyksestä ja kuolinpiste tulee aiemmin, jos käytetään mitä trahansa page builderia (tai edes Jetpackiä; älä käytä sitä, koskaan). Minulla raja meni aikoinaan noin 40 yhtäaikaisessa aidossa ihmisessä, kun WordPressissä pyöri samaan aikaan Woocommerce ja verkkokoulutuksia. Ihmiset eivät pidä satunnaisista, vaikkakin lyhytaikaisista, sivusto on saavuttamattomissa -ilmoituksista
  • kuormitusta vastaan voi taistella rahalla, mutta sitä palaa melkoisesti. Cachen kanssa selviää vähemmällä. Itseasiassa aivan jokainen maailman hiukankaan suositusta sivustosta joutuu käyttämään jotain load balancer ratkaisua.
  • mitä suositummaksi saat sivustosi, niin sitä enemmän joudut maksamaan. Hyväksy tämä heti, niin myöhemmin on helpompaa. Yksi syy siihen miksi sinun on pakko saada harrastelijasivustokin tuottamaan edes hiukan. Tai sitten maksat itse harrastuksena sen, että ihmiset saavat kuluttaa sisältöäsi. Tilanne on kuitenkin yksinkertainen: joko annat arvan ratkaista kuka pääsee sisään tai maksat enemmän. Lompakonavaushetkeä pystyy siirtämään cachellä, mutta se tulee taatusti vastaan.

Joten kun tuo kaikki on summattu, niin avataan Nginxin asetukset ja tehdään cache.

nano /etc/nginx/nginx.conf

Etsi alhaalta lohko Cache settings. Poista kommentointi fastcgi_cache_key ja add_header riveistä eli poista risuaita #.

Kohdan pitäisi näyttää tältä:


##
# Cache Settings
##

fastcgi_cache_key "$scheme$request_method$host$request_uri";
add_header Fastcgi-Cache $upstream_cache_status;

Tehdään uusi virtual host:

nano /etc/nginx/sites-available/eksis.dev.cache

Lisää tämä. Muista muuttaa IP-osoitteet sekä eksis.dev.

Nyt löytyy kaksi virtual hostia. Toisessa ei ole cache käytössä ja toisessa on. Nopein tapa ottaa cache pois, tai laittaa se takaisin päälle, muuttaa tiedostonimeä. Toki saman saa tehtyä Nginxin komennoilla, joilla otetaan virtual host pois tai otetaan käyttöön, mutta minusta tämä on nopein tapa. Plus varmistaa, että koskaan ei ole vahingossakaan käytössä samalle virtual hostille kahta konffia.

Helppouden nimissä, jos et vielä ole server-available hakemistossa, niin siirrytään sinne. Silloin ei tarvitse antaa polku tiedostonimen mukana.

cd /etc/nginx/sites-available

Tarkista, että sinulta löytyy nyt kaksi conf-tiedostoa, eksis.dev ja eksis.dev.cache: komento on ls

Nyt halutaan cache päälle. Tehdään se uudelleennimeämällä

  • eksis.dev tiedostoksi eksis.dev.normaali ja
  • eksis.dev.cache nimelle eksis.dev
mv eksis.dev eksis.dev.normaali && mv eksis.dev.cache eksis.dev

Jos jossain vaiheessa haluat ottaa cachen pois päältä, vaikka jonkun ongelman takia, niin tehdään sama toisinpäin.

mv eksis.dev eksis.dev.cache && mv eksis.dev.normaali eksis.dev

Vinkki: Jos et ole vielä tullut ajatelleeksi, niin uudelleennimeämiset onnistuvat FTP-ohjelmalla melkoisen paljon jouhevammin. Ainakin minulla.

Koska aiemmin säädettiin myös nginx.conf tiedostoa, niin nyt Nginx on pakko uudelleenkäynnistää. Mutta varmistetaan ensin, että ei ole kirjoitusvirheitä.

nginx -t
systemctl restart nginx

Mitä tehtiin

fastcgi_cache_path /var/www/eksis.dev/cache levels=1:2 keys_zone=eksis.dev:100m inactive=60m;
  • polku kertoo mihin Nginx kirjoittaa välimuistitetut sivut. Minulla se on eksis.dev hakemistossa samassa tasossa kuin public_html, jolloin se ei sekaannu varsinaisiin sivuston tiedostoihin, mutta on kuitenkin samassa paikassa kuin sivuston muutkin asiat. Toinen tapa olisi tehdä var/www hakemistoon cache-hakemisto, jonka alla olisi erikseen jokaisen serverin sivuston cachet – silloin polku merkittäisiin /var/www/cache/eksis.dev – älä mieti tätä liian kauan, koska nuo ovat muutettavissa myöhemminkin, ja kyseessä on vain sinun tottumuksiisi ja mukavuuteesi liittyvä asia.
  • inactive on aika, jonka jälkeen sivu poistetaan cachestä, jos sitä ei ole kukaan käyttänyt. Taas niitä asioita, joille ei ole oikeaa eikä väärää ratkaisua, vaan se mietitään tilanteiden ja tarpeiden mukaan. Nämä säädöt ovat jatkokurssimateriaalia ja 60 minuuttia on hyvä kesto aloittaa.
eksis.dev.cache
  • WordPressissä on paljon osia, joita ei voida välimuistittaa, koska ne ovat käyttäjäkohtaisia. Sisäänkirjautuneita ei saa välimuistittaa, sama juttu verkkokaupan asiakastilin, ostoskorin tai kassasivun kanssa. Nyt käytössä oleva esimerkki ei ole täydellisen kattava ja saatat joutua lisäämään jotain. Esimerkiksi jos käytät bbPress-foorumia, niin sitä ei kannata välimuistittaa.
  • Kommentoinnit kertovat mihin mikäkin kohta vaikuttaa.
  • Suljettavat urlit ovat aika itseäänselittäviä, kun muistaa, että ne ovat aina urlin osia. Jos osoite sisältää kielletyn merkkijonon, niin sitä ei välimuistiteta. Samankaltaisia osoitteita voidaan laittaa samaan sääntöön, kuten esim. (cart|checkout|my-account). Silloin pystyviiva, jota kutsutaan usein sen muun toiminnan takia pipeksi, on sama kuin tai.
  • Esimerkin säännöt eivät välimuistita etusivua index.php. Ensinnäkin se on usein melkoisen dynaaminen, eli siellä esittellään uusimmat tai suosituimmat postaukset jne. Se on myös useimmiten sivuston turhin ja vähiten käytetty sivu, eikä siihen kannattaisi muutenkaan sen suurempia panostaa – mutta tuo on jo hieman eri asia.
  • Cacheissa määrittellään usein TTL-aika, joka on jotakuinkin sama kuin parasta ennen päiväys eli kuinka kauan sivu tai objekti pidetään välimuistissa, ennen kuin pakotetaan hakemaan tuoreempi. Se on esimerkissä asetettu samaksi kuin nginx.conf tiedoston sääntö, joka määrää kuinka pitkän käyttämättömyysajan jälkeen on haettava tuore versio eli 60 minuttia: fastcgi_cache_valid 60m;. Cachen aikojen säätely on taiteenlajinsa ja selvästi muuttumattomille asioille, kuten vaikka kuville, kannattaa laittaa pitkät ajat luokkaa vuosi. Mutta tuo on jatkokurssiasiaa ja lähde liikkeelle tunnista.

Voit tarkistaa cachen toimivuuden. Koska etusivua ei päästetä välimuistiin, niin kokeillaan Moikka maailma postauksella. Anna komento:

 curl -I https://www.eksis.dev/moikka-maailma/

Jos se ei toimi, vaan pitäisi käyttää artikkelinumeroa malliin ?p=1 niin käy muuttamassa osoiterakenne. Jo siksikin, että Nginx ei laita cacheen osoitteita, joissa on kysymysmerkki mukana.

Ensimmäisellä kerralla saatat saada tällaisen:


HTTP/2 200
server: nginx
date: Sat, 06 Jun 2020 11:18:03 GMT
content-type: text/html; charset=UTF-8
x-pingback: https://www.eksis.dev/xmlrpc.php
link: <https://www.eksis.dev/wp-json/>; rel="https://api.w.org/"
link: <https://www.eksis.dev/?p=1>; rel=shortlink
strict-transport-security: max-age=31536000
fastcgi-cache: MISS

MISS tarkoittaa, että sivua ei haettu cachestä. Aja tiedosto uudestaan ja viimeisen rivin pitäisi muuttua muotoon

fastcgi-cache: HIT

Se tarkoittaa, että sivu haettiin cachestä, kuten kuuluukin.

On kolmaskin ilmoitus: BYPASS. Se tulee silloin kun Nginx tietää, että periaatteessa url olisi haettavissa cachesta, mutta koska olet kirjautuneena (jolloin cachea ei käytetä), niin tehdään välimuistin ohitus ja haetaan serveriltä aito ja oikea.

Cachen tyhjennys

Cache joudutaan aika ajoin tyhjentämään kokonaan. Englanniksi termit ovat yleensä flush tai purge.. Joko jotain oleellista muuttuu tai on virhetilanne, kuten väärä uudelleenohjaus on livahtanut välimuistiin. Esimerkin ohjeilla moiset virheet poistuvat itsestään tunnin päästä, mutta aina ei ole aikaa odottaa. Cache voidaan tyhjentää kahdella tavalla:

  • koko cache kertalaakista käsipelillä
  • automaattisesti, kun WordPressissä julkaistaan jotain

Nginxin cachen nollaaminen

Koska cache on hakemisto, niin cache tyhjenee poistamalla hakemisto. Tarkista komento aina kahteen kertaan, koska poisto ei varmistele eikä kysy. Jos unohdat komennosta asteriksin * niin poistat myös koko sivustosi.

rm -rf /var/www/eksis.dev/cache/*

WordPressin uudet postaukset

Kun julkaiset uuden postauksen, niin cache on syytä tyhjentää. Valikot ovat saattaneet muuttua tai jonkun widgetin sisältö. Laitetaan uuden jutun julkaisu tyhjentämään cache automaattisesti. Ja kuten arvata saattaa, niin siihen tarvitaan lisäosa.

Varmista, että olet virtual hostin public_html hakemistossa ja komenna:

wp plugin install nginx-cache

Otetaan lisäosa käyttöön:

wp plugin activate nginx-cache

Kirjaudu WordPressin hallintaan. Mene Työkalut > Nginx cache.

Sinun pitäisi antaa lisäosalle tiedoksi Cache Zone Path. Se on sama kuin minkä laitoit virtual hostin konffissa aivan ensimmäiseksi riviksi ja joka kertoo missä cache on. Jos olet seurannut näitä ohjeita, niin se on /var/www/eksis.dev/cache (ja tietysti omalla domainillasi).

Laita rasti ruutuun Purge Cache ja tallenna.

Nyt aina kun julkaiset jotain uutta, niin Nginxin cache tyhjennetään automaattisesti. Voit tehdä tyhjennyksen myös käsin klikkaamalla punaista nappulaa Purge Cache.

Redis

Redis ei periaatteessa tarvitse cachen tyhjennystä ja cache-aikakin on tyypillisesti lyhyt. Esimerkissä on käytetty 900 sekuntia eli 15 minuuttia ja sekin on osan mielestä turhan pitkä, koska puhutaan PHP:hen liittyvistä asioista. Silti tulee aika ajoin tilanteita, että cache kannattaa tyhjentää.

Aikoinaan Redis aiheutti melkoisestikin ongelmia. Lisäosat eivät muka olleet päivittyneet ja hallinnan valikot palautuivät johonkin vanhempaan muottiin. Tuo kaikki johtui välimuisteista. Nyttemmin tilanne on korjaantunut, mutta silti hyvä taktiikka on tyhjentää aina Redisin välimuistit, kun mitä tahansa WordPressin koodissa muuttuu. Tarkoittaa sitä, että kun teemat, lisäosat tai WordPress päivittyvä, niin lopuksi tyhjennettään Redis.

Redis tyhjenee komentoriviltäkin:

redis-cli flusall

Kun on päivittänyt WordPressin WordPressissä, niin on hieman tylsää siirtyä cachen tyhjentämisen takia shelliin. Cachen saa tyhjennettyä Redisin lisäosastakin Apuohjelmat > Redis, mutta aina helpompaa olisi, kun asiat ovat kädenojennuksen päässä.

Jos sinulla on WordPressin hallinnan yläpalkissa tilaa, niin sinne saa valikkokohdan, joka tyhjentää Redisin cachen. Lisää tämä Snippets -lisäosaa (tai lapsiteeman functions.php tiedostoon, mutta se on aina huono idea).

Lisää tämä:

Nyt sinulla on helpoiten asennettavat cachet nopeuttamassa ja tehostamassa WordPressin (ja serverin) toimintaa. Loppu on muiden perusasioiden asentamista.

Cron

Cron on järjestelmän ajastettu toiminto. Oikeammin, se käynnistää sille kerrottuja toimintoja. WordPressissä on sisäinen cron, mutta sen on (surkea) hätäapuviritys varmistamaan tilanteita, jolloin aitoon croniin ei päästä tai se ei toimi. WordPressin oma cron käynnistyy aina kun joku tulee sivuille. Se tarkoittaa kahta asiaa. Jos kukaan ei tule, niin mitään ajastettua – kuten varmuuskopiointeja, ajastettujen artikkelien julkaisuja tai sähköpostien lähettämistä – ei tehdä. Jos taasen kävijöitä on paljon, niin cron liipaistaan käyttöön joka ainut kerta, kun joku avaa jonkun sivun ja silloin tehdään paljon turhaa työtä serverillä.

Servereillä on oma croninsa, joten käytetään sitä.

Useimmat ohjeet neuvovat tekemään webpalveluihin – eli esim. WordPressiin – liittyvän cronin www-data käyttäjän nimissä. Toiset neuvovat tekemään cronin omalle käyttäjätunnukselleen. Kummatkaan ohjeet eivät kerro, että jos käynnistettävän palvelun tai siihen liittyvän hakemiston (kuten vaikka wp-admin hakemisto) omistajuus onkin yli cronille käytetyn roolin, niin cron ei toimi. Esimerkiksi hakemiston omistajuus on helppo muuttaa FTP-ohjelmalla, jotka lähes järjestään toimivat root-oikeuksilla.

Ainoa oikea, ja turvallinen, ratkaisu on tehdä omalla serverillään cron root-tunnukselle.

crontab -u root -e

Jos muokkaat cronia ensimmäisen kerran, niin sinua pyydetään valitsemaan käytettävä editori. Lienee fiksua valita Nano, koska se on jo tuttu.

Nyt ei kannata nähdä vaivaa alkuperäisen varmuuskopiointiin, mutta jos halut tehdä sen, niin crontab-tiedostot löytyvät hakemistosta /var/spool/cron/crontabs ja ovat tavallisia tekstitiedostoja.

Poista kaikki. Kopioi tämä ja liitä tilalle:

Vaihda ensimmäiselle riville sähköpostiosoitteesi. Sitä käytetään oletuksena, jos sallit vaikka komennon epäonnistumisesta kerrottavan sähköpostilla.

Ei mennä nyt syvemmin cronin toimintaa ja rakennetta läpi, mutta katsotaan silti tärkeimmät asiat:

  • */1 * * * * tarkoittaa, että cron pyörähtää joka minuutti. Perusteltua esimerkiksi aktiivisille foorumeille tai verkkokaupoille. Sen voi muuttaa esimerkiksi */5 jolloin cron ajetaan joka viides minuutti – verkkokaupoissa tuo tarkoittaisi, että asiakkaan sähköpostit lähtisivät maksimissaan 5 minuuttia tilauksen jälkeen.
  • php -q /var/www/eksis.dev/public_html/wp-cron.php tarkoittaa, että PHP ajaa wordpressin oma cronin wp-cron-php ja -q tarkoittaa, että turhia höpistä työn aikana eli ilmoituksia koodin suorittamisesta ei tule – no, eikä niitä kukaan ole lukemassakaan, kun tapahtuvat taustalla.
  • >/dev/null 2>&1 ohjaa kaikki koodin suorittamisesta tulevat viestit Suureen Nimettömään eli tuhoaa ne, myös virheilmoitukset. Jos olet epävarma cronin toimivuudesta, niin tämä kannattaa poistaa. Muutoin sillä estetään turhat ilmoitukset. Sen päällä pitämistä edes virhetilojen takia kannattaa harkita kahteen kertaan. Ajattele, jos cronin käynnistämä koodi on syystä tai toisesta mennyt rikki nukkumaan mentyäsi ja päätät nukkua seuraavana aamuna pitkään – sähköpostissasi on aika monta postia, kun cron on kertonut ongelmistaan 12 tunnin aikana jokaikinen minuutti. Tarkkaan ottaen sinulla olisi 720 uutta lukematonta viestiä.

Melkoinen osa toiminnoista luottaa croniin. Esimerkissä katsotaan joka kuun 15. päivä, onko WP CLI saanut päivityksiä. Alimpana on kommentoituna geo-eston päivitykset (koska sitä ei ole asennettu, vielä).

Jokainen domain tarvitsee cronin, ainakin jos se on tehty WordPressillä (itseasiassa jokainen julkaisujärjestelmä käyttää cronia). Et pysty tekemään sääntöä, että ajetaan tämä jokaiselle domainille, tai vielä vähemmän niin, että se ajettaisiin jokaiselle WordPress-asennukselle. Joudut laittamaan cronin erikseen ja käsin. Hyvät uutiset ovat, että se täytyy tehdä vain kerran.

Esimerkissä on kaksi vaihtoehtoista tapaa ajaa cron WordPress-sivustolle, tässä /var/www/eksis.dev/public_html. Toisessa se ajetaan PHP:llä, toisessa WP CLI:n komennolla. Kummatkin ovat oikein ja molemmat toimivat. Itse en käytä WP CLI:tä siksi, että se voi mennä rikki, mutta silti kaikki muu toimisi. Sen sijaan jos PHP menee rikki, niin mikään ei toimi ja cron on viimeinen huolenaihe.

Jos googletat, niin löydät melkoisestikin esimerkkejä, joissa cron ajetaan käyttämällä komentoja wget ja curl. Niissä on pari puutetta, jostain kumman syystä niin suosittuja kuin ovatkin. Niiden ongelmat johtuvat siitä, että molemmat ajetaan webserverin läpi. Se taasen tarkoittaa kahta asiaa. Webserverin rajoitukset ovat mukana ja se saattaa tuoda hankaluuksia, kuten time-out virheitä, jos vaikka siirrät satojen megojen backuppia Amazonin serverille. Minulle, nyt myös sinulle, jos olet mennyt ohjeen mukaan, suurin este kummallekin on cache. On tehtävä erillinen sääntö, jonka kautta kutsu saadaan menemään sivustolle asti ilman cachea. Me haluamme saada cronin toimimaan, emme saada tallennettua vastausta Nginxiltä jostain, joka tehtiin kauan sitten.

Molemmat, niin PHP kuin WP CLI, ajetaan palvelimen ”sisällä” eikä webserveri liity niiden toimintaan mitenkään.

Fail2ban, asetukset

Fail2bannin asettaminen vaatii hieman enemmän kuvioita, mutta ei se mikään vaativa juttu. Ei sen kummempi mitä tähänkään asti on tehty. Tehdään Fail2banin asettaminen ilman sen suurempia kuviokellunnan teorian opskeluja. Voit lukea jutun Fail2banin asennuksesta, jos haluat ymmärtää paremmin mitä on tehty.

Kokeillaan onko sinulla sellainen apulainen, jolla saadaan siirrettyä tarvittavat Githubista, jossa on kopio omasta (toimivasta) asennuksesta:

git --version

Jos sait versionumeron, niin kaikki on hyvin. Jos et, niin asennetaan se:

apt install git

Pysäytetään Fail2ban:

systemctl stop fail2ban

Laitetaan asentamasi Fail2ban talteen:

mv -T /etc/fail2ban /etc/fail2ban.orig

Siirry hakemistoon /etc:

cd /etc

Kloonataan Githubista viritetty versio:

git clone https://github.com/eksiscloud/fail2ban.git

Muokataan asetuksia:

nano /etc/fail2ban/jail.local
  • Lisää rivin ignoreip = 127.0.0.1/8 ::1 loppuun välilyönneillä erotettuna kaksi IP-osoitetta: dropletin IP sekä koti-IP:si
  • Vaihda lohkon Actions alusta oikeiksi:
    destemail = admin@example.tld
    sender = fail2ban@example.tld

Tehdään yksi mukamas-logi:

mkdir /var/log/custom
touch /var/log/custom/manual-ip.log

Sammutetaan pari sellaista, jolla et tee mitään:

mv /etc/fail2ban/jail.d/varnish-420.conf /etc/fail2ban/jail.d/varnish-420.conf.stop
mv /etc/fail2ban/jail.d/varnish-666.conf /etc/fail2ban/jail.d/varnish-666.conf.stop

Varmistetaan, että ei ole kirjoitusvirheitä:

fail2ban-client -t

Käynnistetään Fail2ban:

systemctl start fail2ban

Katsotaan tila:

fail2ban-client status

Nyt sinulla on pari vahtikoiraa lisää.

Nginx ja botit

Botit, olivat ne sitten koputtelijoita tai sisältöä varastavia SEO-yrityksiä, aiheuttavat usein enemmän kuormaa kuin kävijät. Kun sivustolla, jolla ei ole estetty botteja, alkaa olla kuormitusongelmaa, niin ensimmäiseksi kuuluisi hoitaa ötökkäongelma pois päiväjärjestyksestä. Mutta yhdelajin fakta myös on, että kun botit ja käyttäjät alkavat yhdessä aiheuttaa ongelmia, niin ensimmäisenä päivänä siirretään kaikki virtuaaliserverillä ja toisena päivänä estetään botit.

Nginx on tehnyt bottien estämisen todella helpoksi. Lisäksi se tekee sen kustannustehokkaasti: Nginx ei kerro boteille, että pääsy on kieletty, vaan katkaisee niiltä mykkänä yhteyden ja jättää botit roikkumaan tyhjän päälle tuhlaamaan aikaansa. Kun tuo yhdistetään lisäksi Fail2banniin, niin yritettyään kerran turhaan, niin niiden IP-osoite estetään palomuurissa ja seuraavalla kerralla ne eivät pääse edes Nginxille saakka.

Ensin tarvitaan lista, josta Nginx näkee mitkä on estettävä:

nano /etc/nginx/conf.d/blockbots.conf

Kopioi sinne itse käyttämäni lista.

Muokataan virtual hostin konffia:

nano /etc/nginx/sites-available/eksis.dev

Lisää tämä ensimmäiseen server -lohkoon heti logien asettamisen jälkeen:


# Estetään pahat botit
if ($bad_bot = 1) {
return 444;
}

Jos haluat sallia jonkun kieltolistalla olevan, niin kommentoi rivi risuaidalla #.

Tuossa on yksi puute. Se estää komentojen wget ja curl käytön myös sinulta omalla serverillä. Se ei ole välttämättä haluttua. Ne saadaan vapautettua yhdellä ei-niin-tyylikkäällä tempulla. Nginxissä on nimittäin melkoisen vaikea sallia user agentia määrätyllä IP-osoitteelle (yksi syy miksi itse käytän Varnishia; toinen on se, että se on tehokkaampi cache kuin Nginx).

Kumpaankin komentoon saa liitettyä haluamansa user agentin. Joten tehdään alias:

nano ~/.bashrc

Etsi paikka, johon lisäsit wp komennon aliaksen. Lisää sen jälkeen nämä:


alias curl='curl -A \"kurl\"'
alias wget='wget -U \"vget\"'
alias wgett='wget'
alias curll='curl'

Jos sinulle tulee joskus muistikatkos, etkä enää ole varma mitä alias-komentoja sinulla on, niin komenna shellissä alias. Se kertoo.

Monit

Tarvitset järjestelmän, joka vahtii systeemiä ja sen palveluja. Olisi hyvä tietää mahdollisimman nopeasti, jos webserveri tai koko systeemi on kaatunut. Maksullisia palveluja löytyy tolkuttoman paljon, mutta pelkästä perusprosessien seurannasta on täysin turha maksaa kuussa luokkaa 20 – 200 euroa. Asia muuttuu jos ehdottomasti tarvitset niiden mukana tulevia muita analyysityökaluja. Silloin kannattaa vilkaista vaikka New Relic, mutta se ei ole halpa. Eikä helppo.

Pelkkään valvontaan löytyy simppeli työkalu, Monit. Sen asennus on… aika tuttua:

apt install monit

Siirretään koko asennus syrjään:

 mv /etc/monit /etc/monit.backup

Käydään hakemassa minulla toimiva paketti:

cd /etc
git clone https://github.com/eksiscloud/monit.git

Siirrytään hakemistoon:

cd /etc/monit && ls

Avaa Monit asetukset, sillä siellä on jonkun verrankin muutettavaa:

nano /etc/monit/monitrc

Ensimmäisellä rivillä on set daemon 60. Arvo in sekunteja ja 60 tarkoittaa, että palveluiden tila tarkistetaan kerran minuutissa. Voit muuttaa sitä halusi mukaan. Minä olen ehkä hieman hysteerinen ja aika monet käyttävät esimerkiksi arvoa 300 eli 5 minuuttia. Eräälle asiakkaalleni riittää 900 eli 15 minuuttia. Kysymys on lähinnä siitä, että kuinka nopeasti haluaa tiedon. Jos tietää, että ei pääse heti korjaustoimiin, jos jokin hajoaa, niin turhahan tilaa on silloin tolkuttoman usein tarkistaa. Lisäksi osa palveluista niiaa ihan muuten vaan tai netti hidastelee, jolloin minuutin tai lyhyemmillä ajoilla saa enemmän ilmoituksia. Pidemmällä ajalla moisia ei huomata, ellei se satu osumaan juuri sille hetkelle, kun tilaa tarkistetaan. Mutta minä haluan tietää kuinka paljon on lyhyitäkin katkoksia.

Etsi rivi from: monit@eksis.eu – se löytyy lohkosta, jossa säädellään ilmoituksena lähetettävän sähköpostin muotoa. Voit muokata sitä ja ainakin kääntää suomeksi, jos haluat, mutta lähettäjän sähköpostiosoite kannattaa laittaa kohdalleen. Mallissa oleva malliosoite tulee ”päädroplettini” hallinnasta, mutta sinä varmaan haluat siihen jonkun muun.

Hieman alempana on tämä:


set mailserver email-smtp.eu-west-1.amazonaws.com port 587 # If the region is Ireland
username "a lot of characters"
password "even longer one"

Tässä asetetaan sähköpostipalvelimen tiedot, jonka kautta ilmoituksia lähetetään sinulle. Jos sinulla on ne jo tiedossa, niin aseta vastaavat. Jos, tai kun, sähköpostin välittämistä ei ole vielä asennettu serverille, niin kommentoi rivit risuaidalla # ja palaa takaisin myöhemmin muokkaamaan ne.

Rivi set alert admin@example.tld not on { instance, action } kertoo mistä syistä ilmoitus lähetetään ja mihin osoitteeseen. Korvaa samantien osoite admin@example.tld sillä sähköpostiosoitteella, johon haluat (tulevaisuudessa) ilmoitukset lähetettävän.

Vaihda tähän allow example.com se domain, jonka alta haluat Monitin webhallinnan löytyvän. Jos sinulla ei ole kuin yksi, niin valinta on helppo. Jos haluat Monitin graafisemman liittymän näkyvän IP-osoitteella, niin voit vaikka kommentoida tämän.

Tämä rivi on syytä muokata: allow joedoe:"passwd". Siinä asetetaan käyttäjätunnus ja salasana web-hallintaan. Vaihda joedoe halumaksesi, kuin myös salasana passwd.

Vaihda riville check system 104.248.141.204 dropletisi IP-osoite.

Tallenna ja ollaan valmiita säätämään monitoreita.

Monitin käytössä olevat monitorit voivat olla kahdessa hakemistossa: conf.d ja conf-enabled. Historiallisista syistä minulla hakemistojen käyttö ei ole ehkä loogisin mahdollinen, mutta minulla on seurattavat sivustot hakemistossa conf.d ja monitoroitavat palvelut hakemistossa conf-enabled. Hakemisto conf-available on varasto.

On ihan se ja sama miten nimeät monitorit, kunhan ne ovat jommassakummassa hakemistossa. Jos halut ottaa käyttöön jonkun muun hakemiston, niin tee sellainen ja kerro sen sijanti monitrc tiedostossa ihan lopussa.

Monitoreita voi ottaa käyttöön ja poistaa käytöstä samalla tavalla kuin Nginxissä virtual hosteja eli tekemällä hakemistosta conf-available symbolisen linkin hakemistoon conf-enabled. Minusta tuo on hankalaa ja saam tehtyä saman ihan vaan raahaamalla tiedostoja FTP:ssä hakemistosta toiseen tai käyttämällä mv komentoa.

Siirry monitorien hakemistoon, jossa nyt on sivustoja:

cd /etc/monit/conf.d

Poista kaikki paitsi yksi. Minä teen sen FTP:llä mutta jos haluat poistaa komentoriviltä, niin komento on rm -f <tiedosto>. Muuta jäljelle jääneen nimi – itse tekisin sen shellissä esimerkiksi komennolla mv eksis.one eksis.dev – mutta aidosti muuttaisin nimenkin FTP:llä, koska olisin juuri poistanut turhat domainit FileZillalla.

Avaa monitori:

nano eksis.dev

Muuta ensimmäiselle riville check host eksis.one with address www.eksis.one oikea url. Minä siis vaihtaisin www.eksis.one tilalle www.eksis.dev. Tee sama muutos riveille

  • with http headers [Host: www.eksis.one, Cache-Control: no-cache]
  • and request /pong/ with content = "www.eksis.one"

Lyhyesti sanottuna tuo tarkastaa löytyykö portista 443 sivua pong (samalla tarkistetaan SSL-sertifikaatin ikä) ja jos löytyy, niin kaikki on hyvin. Porttia 80 ei tarkasteta, koska sitä kautta ei ketään päästetä sisälle, vaan tehdään uudelleenohjaus https-porttiin 443.

Nyt täytyy tehdä sivu pong. Tehdään se WordPressin sivuna, niin silloin saadaan samalla testattua, että toimiiko PHP ja WordPress – pelkkä tekstitiedosto kertoisi vain, että Nginx toimii.

Tee normaalisti sivu WordPressissä. Jos osoitemuotosi on joku muu kuin pelkkä sivun nimi, eli siihen tuleekin esim. kategoria mukaan, niin muokkaa siltä osin monitoria – nyt etsitään osoitetta https://www.eksis.dev/pong/.

Pelkkä tyhjä sivu ei riitä, vaan sieltä on löydyttävä monitorin määräämä teksti www.eksis.dev – joka asetettiin rivillä and request /pong/ with content = "www.eksis.dev".  Yleensä tavalliset kävijät eivät linkittämättömille sivuille eksy, mutta varmuuden vuoksi olen käyttänyt tämän tapaista tekstiä:

Tämä on tekninen sivu, jolla ei muuta tarkoitusta kuin sanoa: www.eksis.dev

Tee vastaavat kaikille domaineillesi, jos sinulla on useampi. Pystyt valvomaan myös muualla olevia sivustoja, joten pystyt tekemään monitoroinnin vaikka joltain toiselta dropletilta.

Siirrytään palveluiden muokkaamiseen:

cd /etc/monit/conf-enabled

Siirrä ainakin monitorit apache2 ja varnish hakemistoon /etc/monit/conf-available. Jos/kun sinulla ei ole vielä Postfixiä asennettuna, niin siirrä sekin. Palauta se kun olet asentanut sähköpostin välityksen.

Niissä ei ole sinällään mitään muokattavaa, vaan toimivat sellaisinaan – kunhan sinulla on palvelut asennettu ja otettu käyttöön systemctl enable komennolla. PHP-FPM on muokattava, jos sinulla on jokin muu PHP:n versio kuin 7.4.

Varmistetaan vielä, että tiedoston monitrc oikeudet ovat oikein.

chmod 0700 /etc/monit/monitrc

Monit tarvitsee itselleen palomuurin portin. Aukaistaan se.

ufw allow 2812

Varmistetaan, että Monitkin käynnistetään serverin käynnistyessä:

systemctl enable monit

Varmistetaan, että ei ole kirjoitusvirheitä:

monit -t

Käynnistetään Monit:

systemctl start monit

Nyt voit vilkaista tilaa

  • komentorivillä komennolla monit status
  • selaimessa osoitteessa http://<ip-osoite>:2821
Monit komentoriviltä

Jos selaimessa IP-osoitteen käyttö on tylsää, niin voit liittää sen myös domainiisi. Yksi reunaehto on: sinulla ei voi silloin olla monit-nimistä kategoriaa, artikkelia tai tagia, jos nimi on juuressa. Se johtuu siitä, että Monit näkyy osoitteessa https://example.tld/monit

Avaa virtual hostin konffi:

nano /etc/nginx/sites-available/eksis.dev

Lisää ennen cachen määrityksiä eli ennen riviä tämä. Vaihda IP-osoite dropletisi osoitteeksi:


location /monit/ {

   rewrite ^/monit/(.*) /$1 break;
   proxy_ignore_client_abort on;
   proxy_pass http://161.35.23.171:2812;
   proxy_redirect http://161.35.23.171:2812 /monit;
   proxy_cookie_path / /monit/;
}

Tarkistetaan, että ei tullut kirjoitusvirheitä:

nginx -t

Ladataa Nginx uudelleen:

systemctl reload nginx

Nyt Monitin statukset näkyvät osoitteessa https://www.eksis.dev/monit/

 

Sivut: 1 2 3
Avainsanat: , , , ,

Jakke Lehtonen

Teen B2B-markkinoille sisällöntuottoa sekä UX-testauksia. Samaan liittyy myös koulutukset yrityksille ja webmaailman kanssa muutoin painiville. Serverien sielunelämää on joutunut ohessa opettelmaan. Toinen puoli toiminnasta on koirien ravitsemuksen ja ruokinnan suunnittelua sekä varsinkin omistajien kouluttamista hoitamaan koiriaan oikein ja vielä paremmin. Profiili: Jakke Lehtonen

Keskustele foorumilla Meta/KATISKA