Varnish toimii (lähes) pakasta otettuna Apachen kanssa, kunhan ei halua käyttää SSL-sertifikaattia. Liikenne HTTPS:n kautta on kuitenkin suositeltavaa kaikkille sivustoille ja pakollinen verkkokaupoille. Silloin on pakko saada joku väijymään portin 443 kautta tulevaa SSL-liikennettä, koska Varnish ei sitä reverse proxyna hoida. Olen jo kirjoittanut ohjeet miten moinen asennetaan Apache2-serverin avulla, mutta se ei anna nopeampaa HTTP/2 käyttöön. Siinä apuun tulee Hitch, joka on hienommalta nimeltään TCL proxi, eikä hajuakaan mitä tuo tarkoittaa. Silloin Hitch hoitaa SSL-liikenteen, myös HTTP/2 tyyliin, Varnish välimuistin ja Apache2 on webserverinä.

HTTP/2 eroaa ”tavallisesta” http-liikenteestä yhdellä ratkaisevalla erolla. Kun normaalisti kutsut hoidetaan peräkkäin, niin HTTP/2 suoriutuu useammasta kutsusta samaan aikaan tekemällä ne rinnakkain. Jos haluat tutua aiheeseen syvällisemmin, niin Google on ystäväsi.

Minulle riittää muutama asia:

• HTTP/2 on nopeampi
• suurin osa selaimista tukee sitä

HTTP/2 täytyy olla SSL-salattua. Ei kai se ehdoton edellytys ole, mutta selainvalmistajat ovat tehneet siitä pakon. Silloin tarvitaan SSL-sertifikaatti ja suurimmalla osalla tavallisemmista saiteista se tarkoittaa Let’s Encryptiä. Kun koko paletti on rakennettu porttiin 443 Nginx/Apache2, sitten Varnish väliin ja Apache2 taakse, niin on aivan sama mitä SSL-liikennettä hoitavalle webserverille asentaa: HTTP/2 ei onnistu. Sen aiheutti tai oli aiheuttamatta sellainen hirviö kuin ALPN, joka ottaa TLS-protokollan käyttöön websivuliikenteessä (sama tuttu kuin sähköposteissa, ainakin periaatteessa. Ja kun käytetään Let’s Encryptiä, niin ALPN ei onnistu, koska käytetty OpenSSL ei tue sitä.

Juu, minäkin nyökyttelin tietävän näköisenä kun luin tuota. Mutta noin kuuden tunnin urakan jälkeen annoin periksi: HTTP/2 ei onnistu. Voit käydä KeyCDN:n sivustolla testaamassa oman saittisi tilanteen. Jos se sanoo, että sinulla on HTTP/2 ja ALPN käytössä, sekä proxy hoitaa välimuistin, niin kaikki pitäisi olla ihan hyvin.

Sivuhyppy aiheessa HTTP/2.

Jos/kun sinulla on Varnish, niin älä edes yritä asentaa HTTP/2 tukea Varnishin takana olevalle serverille. Varnishin liikenne tulee aina HTTP/1.1 muodossa, eikä siinä edes ole tarpeen HTTP/2. HTTP/2 tulee hoitaa sillä serverillä, joka ottaa asiakkaan liikenteen vastaan ja siirtää sen sitten Varnishille. Ja tässä piilee ongelma. Jos/kun Apache2 ottaa portissa 443 SSL-liikenteen vastaan ja sitten sama Apache2 hoitaa Varnishin liikenteen, niin yritys hoitaa HTTP/2 liikenne vaikuttaa suoraan myös siihen porttia 80 kuuntelevaan HTTP/1.1 osaan. Toki HTTP/2 tuki kerrotaan per virtual host, ei ”globaalisti” apache2.conf tiedostossa, mutta siitä huolimatta kaikki mitä tein, vaikutti myös välillä Varnish – Apache2 liikenteeseen.

On toinenkin syy miksi Nginx ja Apache2 eivät kykene hoitamaan ns, pakasta revityllä LAMP/LEMP asennuksella HTTP/2-liikennettä, vaikka jollain ilveellä ALPN-ongelma ratkaistaisiinkin. PHP käyttää sellaista kummajaista kuin mpm_prefork – älä kysy mitä se tekee, mutta se ei suostu toimimaan HTTP/2 kanssa ja tipauttaa HTTP/1.1:een. Tuon pystyy ratkaisemaan ottamalla PHP-FPM:n käyttöön ja sitten tekemään pari muutosta, jotka vaihtavat mpm:n. Googleta, sillä minä en sitä neuvo. Kokeilin kaksi kertaa ja sain serverin rikki.

Kun HTTP/2 ei löydy, niin siihen on olemassa ratkaisu. Asennetaan Hitch ”terminoimaan” SSL-salaus ja tarjoilemaan HTTP/2.

Hitch hyvin lyhyesti

Hitch tekee saman kuin Apache2 (portti 443) – Varnish – Apache2 ketju. Mutta Hitch on työssään nopeampi kuin Apache2 tai nginx, ja mahdollistaa HTTP/2 käytön. Plus toimii saumattomasti Varnishin kanssa – koska sen on tehnyt sama firma ja nimenomaan Varnishin kylkeen.

Hitch on nopeampi SSL-salatun liikenteen hoitamisessa kuin web-serverien johtokaksikko. Osa myös väittää, että se on kevyempi. Se ei todellakaan pidä paikkaansa, vaan vie tehoja enemmän – kuten aina, niin mitään ei saada ilmaiseksi. Jos saitti jaksaa pyörittää prosessorinsa suhteen web-serveriä ja Varnishia, niin se jaksanee hyvin Hitchin, kunhan ei tule älytöntä yleisöryntäystä.

Yksinkertaistaen. Kun Apache/nginx/mikä-tahansa odottaa HTTPS-liikennettä hoitaen sen http/1.1 systeemillä, niin jokainen kutsu hoidetaan yksi kerrallaan vuorollaan. Joten riippumatta kyselyjen määrästä, niin ne hoidetaan yksi kerrallaan. Työtaakka pysyy samana, mutta jono hidastuu.

Kun töissä on Hitch ja käytetään HTTP/2:ta, niin kutsuja hoidetaan samaan aikaan rinnakkain. Aivan kuten vaikka isossa marketissa kun kassoja on paljon. Jonot ovat lyhyempiä ja asiakkaita saadaan läpi huomattavasti nopeammin – mutta tarvitaan niitä työntekijöitä. Serverillä se tarkoittaa prosessoritehoa. Hitchissä voidaan asettaa useampi duunari (worker) töihin ja usein suositellaan käytettäväksi samaa määrää kuin on ytimiä käytössä. Minulla on nykyisellä (tätä kirjoitettaessa) DigitalOceanin dropletissa kuusi prosessoria käytössä, joten olen laittanut asetuksiin kuusi workeria.

Jos haluat selittää miten vcpu ei ole sama kuin aito cpu, niin kerro kommenteissa – minä aidosti olen vain loppukäyttäjä ja täysin eksyksissä.

Kuitenkin. Kun ennen oli

• jonossa: 1,2,3,4,5 > apache2 – varnish – apache2

niin nyt on

• 1 > Hitch
• 2 > Hitch
• 3 > Hitch – Varnish – apache2
• 4 > Hitch
• 5 > Hitch

Etu ei Hitchin kanssa ollut tolkuton, mutta selvä. Kun Pingdomin mielestä aikaisemmin HTTP/1.1:llä latausaika oli lähelle 4 sekuntia, niin nyt se on HTTP/2:lla alle 2 sekuntia, kun Varnish on mukana. Ilman välimuistia hyöty oli ”vain” sekunnin verran.

Lähtötilanne

Minulla oli alunperin DigitalOceanin 40 USD kuussa maksava droplet yhdelle saitille. Asensin siihen seuraavien ohjeiden mukaan Hitchin ja homma toimi. Ei suoraan, koska taas kerran ohjeissa ei kerrottu kaikkea, koska kyllähän jokainen nyt perusasiat tietää – minä en tiennyt, että komennon certbot certonly --standalone antaessa virheilmon, että kukaan ei kuuntele porttia 80, tarkoittikin sitä, että Varnish täytyy pysäyttää, jotta kukaan ei todellakaan kuuntelisi porttia 80. Tai että kun Hitch ei pystynyt käynnistymään, niin se johtui siitä, että Apache kuunteli edelleen porttia 443 ja Hitch ei tykännyt. Tuollaisia, ihan perusjuttuja.

Uskalsin kuitenkin ottaa käyttöön pykälää suuremman dropletin ja siirtää siihen kaikki sivustoni – kyllä, munat yhteen koriin ja lisää kuormaa serverille. Samalla sain eräällä tavalla neitseellisen asennuksen, eikä vanhat email-serverikokeilut sun muut kiusanneet.

• 6 vcpu, 16 gigaa RAM
• Ubuntu 18.04
• Apache2
• Varnish 6.1.1
• Lets Encrypt

Oletan, että sinulla on Apachessa virtual hostit asennettuna. Kuin myös Varnish, joten kerron vain niihin tulevat muutokset. Jos sinulla ei kuitenkaan ole Varnishia asennettuna, niin se on näin helppoa:

sudo apt update
sudo apt install varnish

Minulla meni toisella asennuskerralla koko hommaan alle vartti, että sain kaikki sivustot taas linjoille. Jos olet paatunut loppukäyttäjä, kuten minä, niin tunti voi olla ihan realistinen ensimmäisellä kerralla. Jos homma hakkaa vastaan, niin siinä on äkkiä yö selällään.

Apache2

Virtual hostit vaativat pienen hienosäädön. Jos sinulla on live-saitti, jossa on Let’s Encryptin SSL asennettuna, niin ensimmäiseksi ne täytyy ottaa pois päältä. Koska en ymmärrä sudon käyttöä, niin kaikki esimerkit ovat oletuksella, että ollaan liikkeellä ssh:lla ja rootina. Joten jos et käytä root-tunnusta, niin muista sudo tai su.

example.com on tietysti vain esimerkki ja vaihda se itsellesi sopivaksi. Sama juttu web-hakemiston sijainnin kanssa, joten muuta polku /var/www/html omalla saitillasi olevaksi.

Poistetaan ssl

a2dissite example.com-le-ssl

Muokataan domainin conf-tiedostoa.

nano /etc/apache2/sites-available/example.com.conf

Muuta porttia, jota virtual host kuuntelee. Halutaan, että se on 127.0.0.1:8080 – jos sinulla on jo Varnish asennettuna, niin sinulla on jo tämä luultavasti paikoillaan. Muistathan, että minä käytän porttia 8080 – sinä voit käyttää mitä haluat, kunhan se ei ole mikään maailmalle ulospäin auki oleva tai jonkun muun käytössä.

Sinulla pitäisi olla alussa näin:

<VirtualHost 127.0.0.1:8080>

Jos työstät WordPress-sivustoa, niin varmista, että tämä löytyy conf-tiedostosta:

<Directory /var/www/html/>
     Options -Indexes +FollowSymLinks -MultiViews
     AllowOverride All
     Require all granted
</Directory>

Jos haluat, että .htaccess-tiedostoa ei käytetä, jonka estäminen onkin vain järkevää virtuaalipalvelimilla, niin muuta AllowOverride All muotoon AllowOverride none.

Tallenna conf-tiedosto.

Koska liikennettä porttiin 443 tulee kuuntelemaan Hitch, niin ei päästetä Apachea kuuntelemaan samaa porttia. Sama juttu portin 80 kanssa, koska siitä vastaa Varnish. Sen sijaan portti 8080 on Apachen heiniä.

nano /etc/apache2/ports.conf

Muuta ports.conf -tiedosto tällaiseksi:

#Listen 80
Listen 127.0.0.1:8080

<IfModule ssl_module>
# Listen 443
</IfModule>

<IfModule mod_gnutls.c>
# Listen 443
</IfModule>

En tiedä onko mod_gnutls.c ehdottomasti estettävä kuuntelemasta porttia 443, mutta ilman kommentointia minulla ei Hitch suostunut yhteistyöhön. Kaipa se jotenkin liittyy HTTP/2 vaativaan TSL-prtokollaan – tai sitten ei, en ole selvittänyt.

Varnish

Kerrotaan Varnishille mitä portteja se kuuntelee:

• 80 ulkomaailmasta tulevaa HTTP-liikennettä
• 6086 Hitchiltä tulevaa HTTPS-liikennettä

systemctl edit --full varnish

Etsi [service] -lohkon alta rivi, joka alkaa ExecStart ja kommentoi se risuaidalla.

Lisää sen alle tämä:

ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :80 -a localhost:6086,proxy -f /etc/varnish/default.vcl -p feature=+http2 -S /etc/varnish/secret -s malloc,3G

• -a :80 – Varnish kuuntelee maailmalle porttia 80
• -a localhost:6086,proxy – Varnish kuuntelee Hitchiä portissa 6086
• -p feature=+http2 – sallitaan HTTP/S ja ALPN
• -s malloc,3G – miten muistia käytetään ja paljonko sitä on saatavilla; itsellä on 3 gigaa ja Katiska täytti aika nopeasti 1 gigaa

Käynnistetään demoni uudestaan.

systemctl daemon-reload

Let’s Encrypt

Let’s Encrypt vaatii oman .vcl -tiedosto. Tehdään sellainen.

nano /etc/varnish/letsencrypt.vcl

Liitä sinne tämä:

vcl 4.1;

backend certbot {
     .host = "127.0.0.1";
     .port = "8080";
}

sub vcl_recv {
     if (req.url ~ "^/\.well-known/acme-challenge/") {
          set req.backend_hint = certbot;
     return(pipe);
     }
}

sub vcl_pipe {
     if (req.backend_hint == certbot) {
          set req.http.Connection = "close";
     return(pipe);
     }
}

Tallenna.

default.vcl

Varnish haluaa myös omat asetuksensa kuntoon.

nano /etc/varnish/default.vcl

Liitä tämä alkuun heti rivin vcl 4.1; jälkeen (jos sinulla on 4.0 niin muuta se, tai muuta letsencrypt.vcl -tiedostossa muodoksi 4.0):

include "/etc/varnish/letsencrypt.vcl";

Jos sinulla ei vielä ole rakennettuna default.vcl -tiedostoa, niin voit käyttää tätä .vcl -tiedostoa. Tai voit kopioida tämän, joka ei tee yhtään mitään, se vain on. Laitoin siihen valmiiksi edellä esitetyn includen.

## Jakke Lehtonen
## by several sources
## Varnish default.vcl for multiple vitual hosts
## Just very simple and plain, mostly for testing
#
# Lets's start caching
 
#
 
# Marker to tell the VCL compiler that this VCL has been adapted to the 4.0 format.
vcl 4.1;

include "/etc/varnish/letsencrypt.vcl";
 
backend default { # use your servers instead default if you have more than just one
     .host = "127.0.0.1"; # IP or Hostname of backend
     .port = "8080"; # Apache or whatever is listening
}
 
 
############### vcl_recv #################
sub vcl_recv {
 
     # Your lifeline: Turn OFF cache
     # For caching keep this commented
      return(pass);
 
}

Sallitaan Varnish, jos tämä on ensiasennus:

systemctl enable varnish

Ja käynnistetään se ensiasennuksessa:

systemctl start varnish

Me kokeneemmat Varnishin käyttäjät teemme uudelleenkäynnistyksen:

systemctl restart varnish

Hitch

HItchin asennus on aina yhtä helppoa:

apt update

apt install hitch

Hitch ei tee itselleen minkäänlaista conf-tiedostoa ja jos sen yrittää nyt käynnistää, niin saa virheen. Joten tehdään sellainen.

nano /etc/hitch/hitch.conf

Kopioi tämä:

## Basic hitch config for use with Varnish and Lets Encrypt
# Listening
frontend = "[*]:443"
ciphers = "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"

# Send traffic to the Varnish backend using the PROXY protocol backend = "[127.0.0.1]:6086"
backend = "[127.0.0.1]:6086"
workers = 1
write-proxy-v2 = on
alpn-protos = "h2,http/1.1"
tls-protos = TLSv1.0,TLSv1.1,TLSv1.2
ocsp-dir = "/etc/hitch/ocsp"
ocsp-verify-staple = on

#List of PEM files, each with key, certificates and dhparams
pem-file = "/etc/letsencrypt/live/EXAMPLE.COM/hitch-bundle.pem"
#pem-file = "/etc/letsencypt/live/EXAMPLE2.COM/hitch-budle.pem"

Huomaa, että

• pem-tiedoston polku on väärä; itseasiassa koko tiedostoa ei ole vielä. Laita silti siihen jo valmiiksi domainisi
• kommentoituna on toinen example.com; näin lisäät muut domainit, jos niitä on useampi
• workers on oletuksella 1; jos tiedät montako prosessoria sinulla on käytössä, niin laita niiden määrä

Nyt laitetaan OCSP paikalleen. Sillä on jotain tekemistä sertifikaattiin liittyvän sisäisen kommunikoinnin kanssa tai jotain. Mutta jos se ei ole, niin Let’s Encryptin SSL-sertifikaattien uusiminen käy vaikeaksi. Googleta lisää, jos olet utelias. Mutta paikalleen se kuitenkin laitetaan:

install -d /etc/hitch/ocsp -o _hitch -g _hitch

Let’s Encrypt

Jotta saataisiin SSL-sertifikaatit, niin täytyy tehdä ensin yksi tiedosto, joka hoitaa pem-tiedostot kelpaavaan muotoon:

nano /usr/local/bin/hitch-deploy-hook

Kopioi tämä:

#!/bin/bash
# Full path to pre-generated Diffie Hellman Parameters file
dhparams=/etc/hitch/dhparams.pem

if [[ "${RENEWED_LINEAGE}" == "" ]]; then
   echo "Error: missing RENEWED_LINEAGE env variable." >&2
   exit 1
fi

umask 077
cat ${RENEWED_LINEAGE}/privkey.pem \
${RENEWED_LINEAGE}/fullchain.pem \
${dhparams} > ${RENEWED_LINEAGE}/hitch-bundle.pem

Tuosta on tehtävä suoritettava tiedosto:

chmod a+x /usr/local/bin/hitch-deploy-hook

Sitten täytyy… tuota… että saataisiin käyttöön joku Perfect Forward Secrecy, niin luodaan OpenSSL:n käyttämä Diffie Hellman Parametri. Ei pienintäkään hajua mitä tuo on suomeksi, mutta se on salaukseen liittyvää, joten tehdään se:

openssl dhparam -rand - 2048 | tee /etc/hitch/dhparams.pem

Minulla tuo ei vaan toiminut. Joku palikka varmaan puuttuu jostain, jonka kaikki muut tietävät, ja minä ainoana en. Mutta ohitin sen. Kun ottaa randin, joka lienee jossain kampuksessa satunnaislukujen kanssa, pois, niin toimii – enkä usko, että SSL silti on murrettavissa. Mutta jos kuitenkin aiheutin jonkun suunnattoman turvallisuusaukon, niin olisi kiva jos siitä vaikka kerrottaisiin kommenteissa – eikä heti mustahattuiltaisi saittejani palvelemaan kyberrikollisuutta.

Joten tämä toimi minulla:

openssl dhparam 2048 | tee /etc/hitch/dhparams.pem

Tässä välissä voidaan sallia Hitch:

systemctl enable hitch

Älä käynnistä sitä, koska se antaa vain virheen. Se kaipaa SSL-sertifikaattia.

Certbot

Jos sinulla ei ole asennettuna certbottia, niin sinulle ei koskaan ole ollut Lets Encrypt käytössä. Jos sinulla on jo SSL-sertifikaatti Lets Encryptiltä, niin sinulla on certbot käytössä. Simppeliä.

Mutta se asennetaan näin:

apt update
apt install certbot

SSL sertifikaatti haetaan näin:

certbot certonly --standalone --preferred-challenges http --http-01-port 8080 -d example.com -d www.example.com --deploy-hook="/usr/local/bin/hitch-deploy-hook" --post-hook="systemctl reload hitch"

Muistaa vaihtaa oma domainisi tilalle. Tämä ei kylläkään toiminut minulle. Se vain vinkui portista 8080, kuinka kukaan ei kuuntele. Tappelin aika monta tuntia ihmetellen, että miten niin ei kuunnella. Apache2 oli ihan nätistä siellä. Koitin vaihtaa 8080 muotoon 80, eikä iloa. Sitäkään ei kukaan kuunnellut, vaikka Varnish oli siellä.

Tuo johtui siitä, että en tiennyt mitä --standalone tarkoittaa. Certbot haluaa portin 8080 vapaaksi, jonka takia Apache pitää sammuttaa. Sitten certbot pistää pystyy ihkaoman pienen web-serverin, käy sopimassa Lets Encryptin kanssa sertikaateista ja sulkee itsensä. Sain sen toimimaan, kun ensin antoi komennon:

systemctl stop apache2

Tosin, Apache piti sertifikaatin hakemisen jälkeen käynnistää käsin uudestaan:

systemctl start apache2

Tuo oli hieman hankalaa, enkä tiedä miten moisen saisi automatisoitua, ilmeisesti säätämällä --post-hook juttua, mutta ei riitä tietotaito eikä into kokeilla.

Minusta mukavammin toimii tämä, koska mitään ei tarvitse sammutella:

certbot certonly --webroot --preferred-challenges http -d example.com -d www.example.com --deploy-hook="/usr/local/bin/hitch-deploy-hook" --post-hook="systemctl reload hitch"

Ensimmäisen domainin kohdalla --post-hook="systemctl reload hitch" antoi tosin virheen, eikä käynnistynyt, koska minulla oli hitch.conf -tiedostossa pem väärässä polussa. Mutta koska Hitchiä ei ole vielä käynnistetty, niin se antanee virheen sinullekin, jos seuraat tätä ohjetta. Tuolla ei ole merkitystä ja seuraavan domainin kanssa se toimii – älä yritä sitä kuitenkaan vielä.

Kun certbot kysyy webrootia, niin se on verkkosivujen polku. Esimerkiksi

/var/www/EXAMPLE.COM/public_html

Kun certbot kysyy www-alkuisen kohdalla, että käytetäänko samaa webrootia vai annatko uuden, niin käytät tietenkin samaa.

certbot-renew

Ns. normaalissa asennuksessa cron hoitaa sertifikaatin uusimisen. Tai ainakin pitäisi, ei sekään ole ihan aina automaattisesti toiminut. Kun hoidin SSL-terminoinnin Apachella Varnishin kanssa, niin en saanut ylipäätään Lets Encryptiä keskustelemaan certbotin kanssa. Se johtui siitä, että olin ohjannut liikenteen kokonaan porttiin 443 enkä päästänyt sisälle porttiin 80 normaalia http-liikennettä – tarkkaan ottaen tuon ohjauksen oli aikoinaan tehnyt certbot. Mutta se suostuu uusimaan SSL-sertfikaatin vain ja ainoastaan HTTP-liikenteenä portin 80 kautta. Minä ratkaisin tuo helpoimmalla tavalla sallimalla portin 80 ja koska minulla oli Woocommerce-pohjainen verkkokauppa, niin pakotin WordPressissä kassan SSL:lle. Varnish sitten hoiti omassa cachessaan niin 80 kuin 443 kautta tulleet samaan välimuistiin. Ei elegantein tapa, mutta ihan sama, sillä se toimi.

En tiedä vielä miten Hitchin kanssa SSL:n uusiminen onnistuu, koska asennus on liian tuore. Yritän muistaa editoida tämän sitten kun tiedän paremmin. Mutta ohjeiden mukaan pitäisi käynnistää munakello, timer, siihen duuniin. Joten sallitaan se ensin:

systemctl enable certbot-renew.timer

Tietenkään tuo ei toiminut minulla. Minulla ei ilmeisesti ole samaa repoa kuin ohjeen tekijällä. Tai jotain. Google auttaa.

Ensimmäiseksi on syytä koittaa, että onko uusiminen edes teoriassa mahdollista.

certbot renew --dry-run

Se kertoi minulle, että deploy-hook jätettiin ajamatta, kuten kuuluikin, mutta muutoin kaikki domainit menivät läpi. Joten minä olen good to go kuten jenkit toteaa. Nyt tehdään tuo timer.

Tarkistetaan ensin, että ollaan menossa oikeaan hakemistoon.

ls /etc/systemd/system

Jos tuolta löytyy nippu .service loppuisia, niin kelpaa. Jos ei, niin etsi missä moiset voisivat olla. Timer täytyy tehdä samaan paikkaan.

Tehdään käytettävä komento:

nano /etc/systemd/system/certbot-renewal.service

Kopioi tämä sinne:

[Unit]
Description=Certbot Renewal

[Service]
ExecStart=/usr/bin/certbot renew --post-hook "systemctl reload hitch"

Tuossa ymmärtääkseni saisi muutettua kommennon haluamakseen, mutta minulla ei riitä rohkeus moiseen.

Tehdään ajastin:

nano /etc/systemd/system/certbot-renewal.timer

Kopioi tämä:

[Unit]
Description=Timer for Certbot Renewal

[Timer]
OnBootSec=300
OnUnitActiveSec=4w

[Install]
WantedBy=multi-user.target

Timer laukeaa aina buutista 300 sekunnin kuluttua ja muutoin 4 viikon välein. Tuota 300 sekuntia täytyy hieman kypsytellä. Harvemmin koko järjestelmää täytyy useamman kerran viikossa käynnistää, mutta Lets Encrypt hermostuu, jos sertikaatin uusi yli 5 kertaa viikossa. Mutta olkoot toistaiseksi noin.

Sitten sallitaan ja käynnistetään.

systemctl enable certbot-renewal.timer
systemctl start certbot-renewal.timer

Ei omituisia virheilmoja. Näyttää hyvältä, ja se hermostuttaa. Kokeillaan:

systemctl list-timers

Lista näyttää, että vajaan 4 viikon päästä ajetaan certbot renewal. Ongelma on vain siinä, että minulla kahdeksan tunnin kuluttua ajetaan certbot.timer. Sammutetaan se.

systemctl stop certbot.timer

Onnistui. Mutta en disabloi sitä. Vielä. En ennenkuin tiedän johtuiko certbot.timer siitä, että asensin sertifikaatit werootille, en standalonena, vai onko tämä tyypillinen tapaus, jossa googletettu ohje ei muista kertoa kaikkea asiaan liittyvää. certbot.timer saisi muuten olla, mutta se ei osaa käynnistää Hitchiä uudestaan sertifikaatin uusimisen jälkeen – ja se pitää tehdä.

Lopputarkistus

Jos kävit kurkkaamassa latautuuko sivustosi, niin kaikki on kunnossa. Jos ei, niin sitten alkaa tarkastus.

systemctl status apache2
systemctl status varnish
systemctl start hitch
systemctl status hitch

Kaikkien pitäisi näyttää vihreää (muuten, noista ikkunoista pääsee pois painamalla q).

• Jos Apache2 ei toimi, niin syy löytyy luultavasti virtual hostin conffista
• Jos Varnish ei toimi, niin syy on jommassa kummassa vcl-tiedostossa
• Jos Hitch ei toimi, niin syy on ports.conf -tiedostossa tai SSL-sertfikaateissa tai niiden poluissa on jotain pielessä

Jos kaikki on kunnossa, niin sinulla on järjestelmä, jossa

• Hitch ottaa porttiin 443 vastaan https-liikenteen HTTP/2 muodossa ja ohjaa sen Varnishille
• Varnish ottaa porttiin 80 tavallisen http-liikenteen ja kikkailee sen sekä Hitchin tarjoaman välimuistiin
• Apache2 antaa verkkosivun sisällön aina kun Varnish sitä pyytää