ylläpitäjän sivunootit

Muiden harrastuksien ohessa teen myös ylläpitoa verkkopalveluille. Kodin lähiverkon lisäksi on ollut vaihteleva määrä kodin ulkopuolisia verkkolaitteita, palvelimia ja virtuaaliresursseja.

Ylläpitämilläni alustoilla on paitsi omia sovelluksia, myös ystävien ja tuttavien verkkopalveluita. Näiden lisäksi vuosien saatossa on ehtinyt olla joitakin lyhytaikaisia projekteja (mm. painikilpailujen web-sivutilat) ja pienyrittäjien hosting-toteutuksia mallia low budged best effort.

Pidempiaikaisista projekteista mainittakoon myös muutama.
2000-luvun alkupuolella oli kristittyjen nuorten parissa suosittu sivusto Radikaali.net. Tuo sivusto, samoin kuin pikkuveljeni ensimmäisen "oman mainostoimiston" juttuja, oli useiden vuosien ajan kotonani harrastuspalvelimillani. Itse asiassa Radikaali.net oli ensimmäinen colo eli co-location palvelu omissa tiloissani, kotonani.
Sittemmin olen toteuttanut tarvittavan palvelinympäristön ja sen ylläpidon jo vuosien ajan Kaaosradiolle (vuodesta 2012). Jaoimme kuluja yksityisistä varoistamme vuosien ajan ja palvelut olivat ensin täysin kotonani, sitten osittain kotonani ja vaiheittain siirsin kaiken jatkuvan käytön resurssit kokonaisuudessaan konesaliin.
Vuoden 2020 helmikuusta alkaen hosting-palveluitani alkoi käyttämään myös Ford-Club Finland Association ry, jolle olen tehnyt jo aikaisemmin palvelinylläpitoa osana harrastustoimintaa (vuodesta 2013).

Vuonna 2008 syntyi hetken mielijohteesta takaa.fi, jonka tarkoituksena oli siirtää ajatustasolla erilleen ulkopuolisille tuotetut palvelut ja omat projektit.
Vuonna 2020 tein projektista virallisemman ja rekisteröin toiminimen terae takaa.fi. Nyt varovasti, saatan lähettää myös laskuja! ;)

Kodin ulkopuolisen infran sydämenä toimii Hetznerin Tuusulan ("Helsinki") konesalista vuokrattu erillispalvelin.
Olen sen verran old school ylläpitäjä, että luotan aikakriittisissä sovelluksissa yhä perinteiseen erillliseen palvelinrautaan enemmän kuin jaettuihin resursseihin.
Myös esimerkiksi varmuuskopiointi palvelimilta suoritetaan yhä perinteisin menoin omalle levytilalle kotiin (ulkopuolisen pilvitallennustilan sijaan).

Hetznerin konesali käyttää Vantaan Energian myymää tuuli- ja vesivoimaa 50/50 suhteessa myytynä. Kotonamme on käytetty 100% vesivoimalla tuotettua sähköä vuosien 2016-2020 ajan ja kesäkuusta 2020 alkaen vähintään kesäkuuhun 2022 asti meille toimitetaan "hiilineutraalia" sähköä.

Perustin yrityksen (toiminimi terae takaa.fi)

Julkaisuaika: 11.03.2020 klo 19:38

Perustin ensimmäisen virallisissa rekistereissä näkyvän yritykseni. Muoto on yksityinen elinkeinonharjoittaja eli tutummin toiminimi.
Pienimuotoista satunnaisluontoista toimintaa olen tehnyt vuosien mittaan omiin nimiin ilman y-tunnusta, mutta nyt on rekisteröinti haettu kaikelle mahdolliselle ja mahdottomalle, mikä avaa tietä tulevaisuuteen.

Näin vuoden 2020 kunniaksi on hyvä tehdä kaikkea, mikä olisi ehkä pitänyt tehdä jo 20 vuotta sitten. Kuten aloittaa yrittäjänä, vaikka olen toki yhä ensisijaisesti palkansaaja päivätyössäni.

Luonnollisesti nykyaikana firma tarvitsee paitsi omat www-sivut, myös Facebook-sivun.
Tietenkin unohtamatta Instagram-tiliä, jollainen piti myös linkittää FB-tilin luonnolliseksi jatkeeksi. Niinpä loin myös sellaiset.

Tämän "uuden alun" kunniaksi kaikki ylläpitohommat (veloitettava tuntityö) -50%.

Retroilua (löysin vanhat web-sivuni vuodelta 1995)

Julkaisuaika: 09.03.2020 klo 19:54

Historia on hyvä muistaa, joten kärsikää...tässä sitä on parin kuvan avulla esitettynä.
Jos haluat tutustua tähän tuulahdukseen 90-luvulta tarkemmin, mene niiden alkuperäiseen sijaintiin: http://pcuf.fi/~tera/ -- mutta muista, olen varoittanut! :D
(Ps. osa linkeistä ei toimi, tiedostoja on kadonnut matkalla.)

Certbot (Let's Encrypt)

Julkaisuaika: 07.03.2020 klo 13:29

Hävettää myöntää, mutta en ollut tutustunut tähän mainioon työkaluun ennen eilistä (pe 6.3.2020 merkittäköön historian kirjoihin).
Sen sijaan olin tehnyt vanhasta tottumuksesta kaikkien SSL-sertifikaattieni hankinnan ja uusimisen käsin SSL For Free-sivuston kautta. Nyt tuntuu nörttinä pahasti jälkeenjääneeltä.

Certbot tulee nykyisin Linux-jakeluiden mukana helposti pakettihallinnan kautta ladattavana ohjelmana.
Olen tykästynyt Debianiin, joten lausuin loitsun
apt-get install certbot python-certbot-nginx
Näistä ensimmäinen paketti on itse certbot, jonka mukana asentuu melkoinen määrä muitakin paketteja. Jälkimmäinen on Nginx-palvelinta varten, jotta portin 80 liikennöinnin kautta voidaan varmistaa automaattisesti oikeus sertifikaatin hankintaan (ACME-protokolla).

Cert-botin käyttö on hyvin yksinkertaista. Sehän on sen kantava idea. SSL kaikille web-sivustoille niin helposti, ettei enää tarvi jättää käyttämättä.
Root-käyttäjänä ("pääkäyttäjä") ajetulla komennolla certbot --nginx (jos Nginx huolehtii portista 80 kuten itselläni) pääsee syöttämään admin contact sähköpostin ja hyväksymään käyttöehdot. Tämän jälkeen jatkossa toimii myös yksinkertainen suoraan vaikkapa skriptistä kutsuttu certbot --nginx -d host.domain.tld muotoinen loitsu.

Jos haluaisi vain luoda uusia varmenteita palvelimella olevalle web-sivutilalle, tämän pystyisi tekemään helposti loppuun asti (sertifikaattien asennusta myöten) esimerkiksi certbot --apache komennolla, jos ei olisi Nginx-etuproxyä käytössä portille 80. Tällöin käynnistäessä Certbot kyselee vain sen, mille kaikille sertifikaatti halutaan luoda. Ja tekee loput loppuun asti, jos konfiguraatiotiedostot on tehty oikein syntaksiltaan ja Certbot osaa asentaa kaiken kohdilleen.

Kuten arvata saattaa, yksinkertaisuudesta seuraa myös muutamia rajoitteita. Kuten se, että jokaista eri nimeä varten tarvii luoda oma sertifikaattinsa. Esimerkiksi www.terae.fi ja terae.fi ovat eri "domainit" (varmenteessa oleva DNS-nimi). Toki useimpia selaimia ei tunnu haittaavan, että sertifikaatti luodaan pelkälle www.terae.fi, jos on vaihtoehtona myös terae.fi josta seuraa redirect https-protokollan yli kohteeseen www.terae.fi.

Sertifikaatit (varmenteet) päätyvät helposti muistettavasti hakemistorakenteeseen seuraavasti:
SSLCertificateFile /etc/letsencrypt/live/www.terae.fi/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.terae.fi/privkey.pem

Käytin esimerkissä Apache2 formaattia ja tämän nettisivun www.terae.fi DNS-nimeä vastaavaa hakemistopolkua. Eli ainoastaan tuo DNS-nimeä vastaava osuus vaihtuu.

Certbotin helppouden ideologiaan kuuluu myös automaattinen uusinta, sillä nämä ilmaiset varmenteet ovat vain 3kk ajan voimassa. Cronjobina ajetaan tavanomaisesti päivittäin tarkitusajot sertifikaatin uusinnan tarpeelle ja mikäli tarpeen on, hankitaan uusi varmenne ennen kuin aikaisempi ehtii vanhentua. Ja täten SSL-käyttö voi jatkua saumattomasti ja huomaamatta päivitysprosessia.

Certbot hakee, kuten mainittu, tuttuja turvallisia Let's Encrypt sertifikaatteja. Näiden käyttö ei rajoitu pelkkiin web-sivutiloihin, vaan samaa sertifikaattia voi käyttää myös muihin tarkoituksiin. Esimerkiksi itselleni loin sähköpostipalvelimen ensisijaista DNS-nimeä ilolan.takaa.fi vastaavan sertifikaatin, jonka asensin MTA ja IMAPs käyttöjä varten.

Synology RackStation RS1219+ (hienosäätöä: tuuletinohjauksen parantelua)

Julkaisuaika: 04.03.2020 klo 23:05

Aikani löin päätä seinään, kunnes löysin etsimäni: tuuletinta ohjataan scemd:llä ja asetukset löytyy tiedostosta /usr/syno/etc.defaults/scemd.xml - sitä siis muokkaamaan mitä pikimiten. :)

Syntaksi on perinteisen yksinkertainen XML.

"Cool mode" on oikealta nimeltään "DUAL_MODE_HIGH" ja "Quiet mode" niin ikään "DUAL_MODE_LOW".

Oheisen ruutukaappauksen mukaisesti muokkailin alkuperäistä matalammat levyjärjestelmän lämpötilan raja-arvot ja suurelta osin myös prosessorin lämpötilojen suhteen oli tarpeen tehdä samaa, jotta lämmönnousu saadaan tarvittaessa nopeasti kuriin.

Käytössäni olevien matalamman tehon hiljaisten tuulettimien vuoksi nostin matalimmat nopeudet 20% tehosta 40% arvoon.
Vastaavasti ensimmäisen raja-arvon ylityksen nopeussäädöt nostin 50% tehosta 60% arvoon ja toisen asteen lisänopeuden noston laskin 99% arvosta 80%, mutta nopeutin reagointia kohden hälytyksen aiheuttavaa 99% arvoa eli täyttä tuuletustehoa ennen mahdollista tarvetta sammuttaa järjestelmä ylikuumentumisen estoksi.

Nopeutin myös muiden asteittaisten nopeuden nostojen ja laskujen reagointinopeutta siten, että viileä järjestelmä reagoi hitaammin ja kuuma sitä nopeammin mitä suurempi lämpötila ja tuuletinnopeus on. Täten riskit on minimoitu ja melu samoin.

Suurimmat sallitut lämpötilat laskin turvallisemmalle tasolle alkuperäisistä tehdasarvoista, jotka olivat lähellä puolijohdetekniikan suurimpia lämpöarvoja ennen piirin sisäistä hätäsammutusta. Täten todellista riskiä ylikuumentumiselle ei ole, vaan järjestelmä sammutetaan jo ennen sitä.

Synology RackStation RS1219+ (tuning: lisää nopeampaa muistia ja hiljaiset tuulettimet)

Julkaisuaika: 03.03.2020 klo 12:16

Havaitsin jo laitteen oston yhteydessä todennäköisen tarpeen muistipäivitykseen, sillä laitteen tehdasasennettu muistimäärä oli vain 2GB.
Tällaisessa laitteessa se on nykyaikana vähäinen keskusmuistin määrä. Erityisesti muisti jää ahtaaksi, kun levytilan swap-osio on poistettu käytöstä.

Alkuperäinen muisti oli yksittäinen 2GB DDR3L PC1600 CL11 muistikampa. Muistipaikkoja on kaksi.
Uudeksi muistiksi valikoitui kaupan nopein, suurin ja kaunein Kingston HyperX impact 16GB setti eli 2x8GB DDR3L PC1600 CL9 (Black series).

Havaitsin muistipäivityksellä myös suoria vaikutuksia levyjärjestelmän suorituskykyyn.
Kun tein levyltä lukemisen nopeustestin hdparm-ohjelmalla, sain keskimäärin 11 MB/s ja parhaimmillaan jopa 13 MB/s aikaisempaa enemmän lukunopeutta. Tämä vastaa noin 3-4% parantunutta suorituskykyä.

Mainitsin RS1219+ unboxing yhteydessä myös havainneeni vakiotuulettimet turhan meluisiksi, joten tilasin Noctua NF-A8 FLX-malliset laitettuulettimet.
Alkuperäisten tuuletinten malli oli Y.S.Tech FD128025EB-N ja tuulettimia on 2kpl. Lisäksi virtalähteessä on 40x40x20 tuuletin, jota en kuitenkaan vaihtanut, sillä se ei vaikuta olevan normaalissa rasituksessa lainkaan käytössä ja sen vaihtaminen olisi vaatinut tarpeetonta laitteen osien purkamista.

Y.S.Tech FD128025EB-N on olemassa kaksi eri suorituskyvyn versiota.
Omani on luultavasti 4500 rpm / 59,6 CFM (101 m3/h) / 8,8 H2O / 44 dB(A) suorituskykyarvoin (äänestä päätellen).
Noctua NF-A8 FLX vastaavat arvot ovat 2000 rpm / 50,4 m3/h / 1,96 H2O / 16,1 dB(A).

Vielä pari sanaa tuulettimien ohjauksesta Synologyn DSM 6.2 -järjestelmässä (ja hyvä syy olla käyttämättä quiet mode hiljaista tilaa tuuletinmuutoksen jälkeen).
Tuulettimen ohjaukselle on kolme tilaa: full speed, cool ja quiet mode.
Näissä eri ohjaustiloissa on eri lämpötilan kynnysarvot, joiden perusteella tuulettimen nopeutta nostetaan kahdessa portaassa: ensin 50% ja sitten 99% teholle.

Full speed on nimensä mukainen käyttötila: tuulettimen ohjaus pidetään lämpötilasta riippumatta 99% arvossa.
Tällä ohjauksella CPU core temp vaihteli 45-49°C, kun rasitus oli noin 30% (testikuormana käytin virusskanneria).

Cool mode kytkee lämpötilatarkkailun ja sen mukaisen reagoinnin päälle. Säätöä varten tarkkaillaan prosessorin ja levyasemien korkeinta lämpötilaa.
Levyjen lämpötilat eivät nousseet tarpeeksi, joten alinta tuuletinnopeuden noston rajaa ei saavutettu niiden osalta.
CPU core temp sen sijaan nousi yli rajan, joka näytti olevan 45°C kohdalla. Rasitustestissä CPU-lämmöt pysyivät 48-51°C välillä tässä käyttötilassa.

Quiet mode on muuten vastaava kuin cool modekin, mutta sen lämpörajat ovat korkeammat.
Prosessorin lämpötilan noustessa yli 50°C lähti tuuletinohjaus 50% teholle. Tässä käyttötilassa lämmöt vaihtelivat 48-52°C välillä.

Tein vielä yhden extreme testin rasittamalla järjestelmää cool mode ja full speed käyttötiloissa mahdollisimman paljon.
Ajoin dd if=/dev/zero of=/volume1/test.iso bs=128k count=1M. Tällä tavoin levyt lämpenivät 42°C ja CPU 59°C asti.
Toistolla sain levylämmön nousemaan 44°C ja threshold tuli vastaan hieman ennen nousua 43°C, mutta tuuletinnopeus ei kuitenkaan noussut tässä vaiheessa lisää.
Jokin osa lämpeni kuitenkin selvästi jo liikaa, sillä kuorma lähti pumppaamaan ennemmin kuin CPU-lämpö nousemaan yli seuraavan raja-arvon.


Järjestelmän ollessa levossa lämmöt pysyttelivät seuraavissa arvoissa/vaihteluväleissä:
full speed tilassa 40-43°C (paras lämmönsiirto mihin nämä hiljaiset tuulettimet pystyvät)
cool mode päällä 44-46°C (50% tuuletintehon raja +-1°C)
quiet mode päällä 45-46°C (20% tuuletinteho riittää pitämään rasittamattomana lämmöt tässä)

Näiden ohjaustilojen väliin kaipaisin vielä mahdollisuutta säätää itse raja-arvoja tai ainakin pienintä tuuletinnopeutta.
Jos saisin itse valita, saattaisin laittaa vähimmäistehoksi 30-40%.

Synology RackStation RS1219+ (hienosäätöä: swap ja root)

Julkaisuaika: 29.02.2020 klo 13:58

Vakioasetuksin Synologyn levykehikot ottavat jokaiselle uudelle levylle käyttöön swap-osion RAID1-pakassa; oma järjestelmäni loi täten 2GB osiot kaikille 4kpl SSD ja 2kpl pyöriville levyille ja synkronoi jokaisen kirjoituksen kunkin näistä levyistä kanssa.

Koska järjestelmä luo swap-tilan joka käynnistyksellä uudelleen, päädyin lisäämään /etc.defaults/synoinfo.conf uuden rivin # system options rivien perään:
no_disk_swap="yes"
Varmuuden vuoksi laitoin sen myös /etc/synoninfo.conf vastaavaan kohden, vaikka init-skriptin rc.subr mukaan arvo luetaan tuolta järjestelmän vakioasetuksesta (komennolla /bin/get_key_value /etc.defaults/synoinfo.conf no_disk_swap).

Myös järjestelmän juuriosio / on vakiona luotu raid1-volumeksi (md0) kaikille levyille.
Koska en suinkaan halua turhan päiten rasitella kaikkia levyjä jatkuvalla kirjoittelulla, päädyin muuttamaan konfiguraatiota järkevämmäksi.

Toteutus tapahtui seuraavin taikasanoin konsoliyhteydellä (cli, ssh):
mdadm /dev/md0 --fail /dev/sd[x]1 ([x]=levyn tunnus, itse poistin levyt a,d,e ja f)
mdadm --grow /dev/md0 --raid-devices=2 (vaihdetaan aktiivisten levyjen määrä kahdeksi)

HUOM! Tämä toimenpide tulee toistaa aina, kun asennetaan uusi levy. Uuden osion luonnin yhteydessä raid1-pakka luodaan uusiksi ja siihen lisätään automaattisesti kaikki levyt.

Tämän jälkeen web-pohjaisessa hallinnassa näkyy levyillä olevaksi hajonneita osioita. Automaattinen osioiden korjaaminen (painetaan storage managerin yleisnäkymästä "repair") tekee loput taikomiset itsekseen eli korjaa rikotut osiot ja palauttaa ne spare-levyinä raid1-swappiin.

# mdadm -D /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Sun Jan 19 20:34:05 2020
Raid Level : raid1
Array Size : 2490176 (2.37 GiB 2.55 GB)
Used Dev Size : 2490176 (2.37 GiB 2.55 GB)
Raid Devices : 2
Total Devices : 6
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Sun Mar 1 00:12:31 2020
State : clean
Active Devices : 2
Working Devices : 6
Failed Devices : 0
Spare Devices : 4

UUID : 832eab64:51e43267:c69de3af:22ddbed7
Events : 0.2443

Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1

2 8 1 - spare /dev/sda1
3 8 49 - spare /dev/sdd1
4 8 65 - spare /dev/sde1
5 8 81 - spare /dev/sdf1

Synology RackStation RS1219+ (suorituskyky, testailua)

Julkaisuaika: 28.02.2020 klo 21:45

Ensimmäisessä tätä NAS-levykehikkoa koskevassa kirjoituksessani mainitsin levyjen vajaasta suorituskyvystä tässäkin järjestelmässä.
Nyt olen ehtinyt testailla sen verran, että voin todeta tässäkin olevan vastaava pullonkaula levykäyttöjen kesken kuin aikaisemmassa pienemmän tehon laitteessa: vain yksi levy neljästä suoriutuu täydellä teholla. Nopeus on kuitenkin aikaisempaa RS819 noin 100MB/s korkeampi kaikille levyille.

Hdparm-testailulla lukunopeus on hitaampi levypaikoissa 1, 3 ja 4. Levypaikka 2 saa täyden nopeuden, lähes sen mitä Samsung lupailee:
/dev/sda: Timing buffered disk reads: 1120 MB in 3.01 seconds = 372.71 MB/sec
/dev/sdb: Timing buffered disk reads: 1548 MB in 3.00 seconds = 515.80 MB/sec
/dev/sdc: Timing buffered disk reads: 1120 MB in 3.01 seconds = 372.68 MB/sec
/dev/sdd: Timing buffered disk reads: 1122 MB in 3.00 seconds = 373.54 MB/sec

(Huom. levyjen järjestys vaihdettu aikaisemmasta ja silti samat tulokset. Eli tässäkin eroa eri levypaikkojen välillä, ei levyjen.)

RS819 vastaavat arvot olivat samoille levyille:
sda: Timing buffered disk reads: 1250 MB in 3.00 seconds = 416.41 MB/sec
sdb: Timing buffered disk reads: 796 MB in 3.00 seconds = 265.31 MB/sec
sdc: Timing buffered disk reads: 798 MB in 3.01 seconds = 265.39 MB/sec
sdd: Timing buffered disk reads: 798 MB in 3.00 seconds = 265.62 MB/sec

Pienellä blokkikoolla kopiointi saman RAID5+Btrfs aseman sisällä on hidasta. Järjestelmä tukehtuu.
(Suorituskyky silti paljon parempi kuin aikaisemmilla.)
dd if=/volume1/10Grnd of=/volume1/10G_test.iso
10485760000 bytes (10 GB) copied, 220.824 s, 47.5 MB/s (RS819 tämä arvo oli 34.9 MB/s)

Isommalla blokkikoolla homma sujuu kohtuudella, mutta ei oletetun ripeästi:
dd if=/volume1/10Grnd of=/volume1/10G_test.iso bs=16384
10485760000 bytes (10 GB) copied, 30.1629 s, 348 MB/s

Pelkkä luku (kohteena /dev/null) onnistuu jo kohtuullisella nopeudella pientäkin blokkikokoa käyttäen:
dd if=/volume1/10Grnd of=/dev/null
10485760000 bytes (10 GB) copied, 28.6408 s, 366 MB/s (RS819 tämä arvo oli 209 MB/s)

Isommalla blokkikoolla tämä sujuu jo melko joutuisasti:
dd if=/volume1/10Grnd of=/dev/null bs=16k
10485760000 bytes (10 GB) copied, 11.3617 s, 923 MB/s
(Toki tämäkin jää levyjen luvatusta lukunopeudesta huomattavasti, noin puoleen.)

Ison tiedoston luominen tyhjästä sujuu kohtuullisesti:
dd if=/dev/zero of=/volume1/test.iso bs=8k count=1M
8589934592 bytes (8.6 GB) copied, 17.8608 s, 481 MB/s

Isommalla blokkikoolla tämäkin on joutuisampaa, mutta edelleen jäädään kauas suurimmasta näillä levyillä mahdollisesta suorituskyvystä:
dd if=/dev/zero of=/volume1/test.iso bs=64k count=100k
6710886400 bytes (6.7 GB) copied, 10.7383 s, 625 MB/s

Suorituskykyyn voi täten olla samaan aikaan sekä tyytyväinen (se riittää kyllä), että pettynyt (levyjen suorituskyvystä suuri osa jää koskaan käyttämättä).
Puuttumaan jäävällä suorituskyvyn osuudella on merkitystä lähinnä taustalla suoritettaviin tehtäviin ja järjestelmän kuormitukseen ison kirjoituskuorman alla.

Synology RackStation RS1219+ (unboxing)

Julkaisuaika: 27.02.2020 klo 21:38

Aikaisemmin kerroin RS819 ostosta, joka oli selvästi huti monella tapaa. Se oli vaatimustasooni nähden alimitoitettu ja lisäksi saamassani laitteessa oli suorituskykyä heikentävä virhe.
Korvaavaksi laitteeksi valitsin RS1219+ mallin, jossa on Synologylle selvästi tutumpi Intelin arkkitehtuuri (Atom).

Ensikäynnistys on aina jännä juttu. Tällä kertaa se paljasti, että tuotteessa on melko äänekkäät 2kpl 80x80mm tuulettimia.
Se ongelma on helposti korjattavissa, sillä tämän laitteen tuulettimet on tehty helposti vaihdettaviksi ja prosessi on jopa käyttöohjeissa opastettu.
Tilasin välittömästi tuuletintyypin varmistettuani Noctua NF-A8 FLX tuulettimet.

Käyttöönotto jatkui tavanomaisen helppoon Synologyn tapaan: web-selaimesta avataan osoite find.synology.com ja selainpohjainen ohjelma etsii lähiverkosta Synologyn laitteet.
Kun oikea laite on valittu, päästään jatkamaan eteenpäin.

Siirsin vanhassa Synologyn laitteessa käyttöönotetut levyt tähän uuteen kehikkoon, joten se tunnisti siellä olevan tunnetun järjestelmän levyjärjestelmä ja asetukset.

Migraatio sujui yksinkertaisesti parilla napin painalluksella: valittiin halutaanko siirtää vanha järjestelmä sellaisenaan uuteen ja haettiin ohjelmistopäivitys.
Vaihtoehtona olisi ollut myös levyjen alustus ja aloittaminen puhtaalta pöydältä.

Ainoat risut tässä prosessissa tulee siitä, että järjestelmä ei ottanut aikaisempaa asetettua staattista IP-numeroa suoraan käyttöön.
Vanhat verkkoasetukset olivat kuitenkin tallessa ja ne saattoi helposti palauttaa käyttöön web-pohjaisen hallinnan valikosta.

Olen tilannut laitteeseen myös muistipäivityksen. Laitteessa on virallinen tuki 16GB keskusmuistille (DDR3L PC1600 2x8GB).
Todennäköisesti siihen saisi isommankin muistimäärän (prosessorissa ja Linux-ytimessä on laajempi tuki), mutta valmistajalla ei ole tällaista muistipäivityspakettia ohjelmassaan.

Se suorituskyky... Niin. Syy miksi koko vaihtoon lähdin.
En ehtinyt vielä testailla kunnolla, mutta ainakin kaikki 4 levyä levypaikoissa 1-4 saivat keskenään samat DMA-asetukset (myös AHCI AA).
Kaikilta levyiltä onnistui myöskin hdparm-ohjelmalla testata yli 100MB/s nopeammat tulokset kuin aikaisemmin testatussa mallissa.
Testatessani 10GB satunnaisen sisällön lukemista levyosiolta --> /dev/null (dd-testi) ei myöskään esiintynyt levyjen kesken toisistaan poikkeavia suorituskykyarvoja levyjärjestelmän toiminnan tarkkailuun tarkoitetussa hallintapaneelin osiossa.

Toistaiseksi on vielä yksi mysteeri selvittämättä: miksi tässäkin järjestelmässä vain yksi levyistä suoriutuu muita nopeammin, suurin piirtein levylle luvatulla suorituskyvyllä?

/dev/sda:
Timing cached reads: 3246 MB in 2.00 seconds = 1622.61 MB/sec
Timing buffered disk reads: 1130 MB in 3.00 seconds = 376.53 MB/sec

/dev/sdb:
Timing cached reads: 3208 MB in 2.00 seconds = 1603.85 MB/sec
Timing buffered disk reads: 1552 MB in 3.00 seconds = 516.67 MB/sec

/dev/sdd:
Timing cached reads: 3212 MB in 2.00 seconds = 1606.12 MB/sec
Timing buffered disk reads: 1130 MB in 3.00 seconds = 376.15 MB/sec

/dev/sdc:
Timing cached reads: 3186 MB in 2.00 seconds = 1593.50 MB/sec
Timing buffered disk reads: 1124 MB in 3.00 seconds = 374.45 MB/sec

Palaan tähän suorituskykyasiaan myöhemmin. Täytyy testata kunnolla, myös mahdollinen keskusmuistin konfiguraation vaikutus ja vastaavat tekijät.

Suurinta suorituskykyarvoa tärkeämpää on kuitenkin se, että levyt kykenevät toimimaan rinnakkain ilman jatkuvaa IO-jumittelua. Täten levyjärjestelmän suorituskyky ei putoa pohjalukemiin aina levyjen kesken vuorotellessa ja yhden levypaikan pysäytellessä toistuvasti suorittamista pidemmäksi aikaa.

Intel i218/i219 NIC lähetysnopeuden ongelmat Linux-kernelillä 4.19 (4.15 alkaen)

Julkaisuaika: 23.02.2020 klo 17:07

Aloin kummastelemaan miksi palvelimella tulee sisään täydellä Gigabit-nopeudella ja ulos lähtee vain puolikkaalla.
Niinpä tein tukipyynnön Hetznerille ja sain melko pian vastauksen: ehkä kyse olisi tästä https://wiki.hetzner.de/index.php/Low_performance_with_Intel_i218/i219_NIC/en.

Kyllä. Tästä oli kyse ja suorituskyky palautui normaaliksi.
Linux-ytimestä 4.15 alkaen näiden Intelin verkkokorttien ajurissa (e1000e) on ollut DMA-käsittelyä hidastava korjaus puskurin ylivuodon bugiin, joka jättää koko laitteen jumiin mikäli palvelin on runsaasti kuormitettu UDP-liikenteellä ja verkkokaapelia irroitetaan muutamia kertoja.

"I219LM and I219V devices can fall into unrecovered Tx hang under very stressfully UDP traffic and multiple reconnection of Ethernet cable. This Tx hang of the LAN Controller is only recovered if the system is rebooted. Slightly slow down DMA access by reducing the number of outstanding requests. This workaround could have an impact on TCP traffic performance on the platform. Disabling TSO eliminates performance loss for TCPtraffic without a noticeable impact on CPU performance." (https://github.com/torvalds/linux/commit/b10effb92e272051dd1ec0d7be56bf9ca85ab927)

Ok, konesalissa kaapelia ei juurikaan kiskota ja DDoS-suojatussa ympäristössä olisi aika harvinaista kärsiä tällaisesta tilanteesta. Näinpä tuo "korjaus" on vain suorituskykyä heikentävä haitta.

Paremman TCP-läpäisyn saavuttamiseksi ongelman voi kiertää poistamalla TCP segmentation offloading -ominaisuuden käytöstä:
ethtool -K <verkkokortin nimi> tso off gso off
Luonnollisesti lisäsin tämän /etc/rc.local, jotta uudelleenkäynnistyksessä ongelman ohitus ei unohtuisi.

Synology RackStation RS819 (ensikokemukset & odottamattomat ongelmat)

Julkaisuaika: 09.02.2020 klo 17:46

Ostettuani 4kpl 860 EVO 1TB m.2 SSD-levyjä 2.5"/SATA3-väyläsinä RAID-pakkaan tajusin, että vanhentuneen mallin QNAP NAS-järjestelmä ei ymmärrä niiden päälle enempää kuin sika hopealusikoiden, jos sitäkään. Vanhassa levyjärjestelmässä on hidas SATA2-väylä ja puuttuu tuki TRIM-ominaisuudelle. Aika ostaa jäykempää ja tuoreempaa rautaa.

Yritän ostaa kaiken uuden tämän kaltaisen raudan 19" räkkiasennettavana, joten päädyin vaihtamaan QNAPista Synologyyn. Kuulemma se on nyt se juttu. Silmiin osui tarjoushintainen RackStation mallimerkinnältään RS819. Halvemman hinnan selittää muusta tuotelinjasta poikkeava ARM-pohjainen infrastruktuuri. Järjestelmä pohjautuu Realtek RTD1296 SoC prosessoriin, kun kalliimpi mallisto luottaa sen sijaan Intel-pohjaisiin tuotteisiin.

Uuden järjestelmän asennus sujui kivuttomasti. Olin juuri lähdössä Teneriffalle viikoksi, kun tuli ilmoitus saapuneesta paketista, jonka hain pikaisesti kotiin ja laitoin vielä viime hetkillä järjestelmän asentumaan. Asensin järjestelmän loppuun lentoa odotellessa etäyhteydellä kännykästä käsin, mikä oli hieman haastavaa pienen näytön vuoksi, mutta onnistui web-hallinnallakin varsin mainiosti siitä huolimatta. Samoin tein etäyhteydellä tylsyyksissäni vanhan levyjärjestelmän tietojen siirron uuteen järjestelmään.

Palattuani kotimaahan aloitin varsinaisesti järjestelmän käytön. Tässä vaiheessa huomasin odottamattomia suorituskykyongelmia. Järjestelmän olisi pitänyt kyetä ongelmitta moninkertaiseen lukunopeuteen ja myös kirjoitusnopeus jäi todella paljon odotetusta.

Valmistajan lupaus suorituskykytasosta kuuluu seuraavasti: "Over 224 MB/s encrypted reading performance".
Itselläni ei ole mitään kryptoja käytössäni ja tuon kuuluisi olla raskaimmassa mahdollisessa levyjärjestelmän asennuksessa saavutettava minimi.

Hyvä esimerkki huonosta suorituskyvystä:
dd if=/volume1/10G_DD.iso of=/dev/null : 10737418240 bytes (11 GB) copied, 51.2981 s, 209 MB/s (yksinkertainen lukunopeustesti levyjärjestelmästä)

Huom: Kyseessä on perusasetuksilla asennettu 4x Samsung SSD 860 EVO 1TB, SHR RAID (RAID5) ja levyt ovat 550MB/s lukunopeuden SATA3-liitännällisiä M.2 muisteja.

Tehdäänpä sitten vielä astetta järeämpi testi eli toistuvaa lukua ja kirjoitusta peräkkäin samalle levyosiolle 4 levyn järjestelmässä:
dd if=/volume1/10G_random_testfile of=/volume1/10G_test : 10485760000 bytes (10 GB) copied, 300.467 s, 34.9 MB/s (!!)

Kuten voi huomata, tästä seuraa ylläri. Homma takkuaa niin pahasti, että levyt vain vuorotellen odottelevat ja juuri mitään ei tunnu tapahtuvan.
Levyjen pitäisi kyetä ottamaan vastaan ja tallentaa noin 520MB/s nopeudella tällaisia datamääriä.

CLI-puolella testailua jatkaen saattaa löytyä vihjeitä siitä, mikä suorituskykyongelmat aiheuttaa; levyt ovat sda, sdb, sdc ja sdd. Näistä vain yhdessä "levypinnalta" lukeminen onnistuu kohtuullisella nopeudella, vaikka jääkin vielä huomattavasti levyvalmistajan nopeuslupauksista ja odotetusta siirtonopeudesta SATA3-väylässä:
sda: Timing buffered disk reads: 1250 MB in 3.00 seconds = 416.41 MB/sec
sdb: Timing buffered disk reads: 796 MB in 3.00 seconds = 265.31 MB/sec
sdc: Timing buffered disk reads: 798 MB in 3.01 seconds = 265.39 MB/sec
sdd: Timing buffered disk reads: 798 MB in 3.00 seconds = 265.62 MB/sec

Kun katsoo systeemin logeja niin dmesg antaa viitteitä ongelmista: joka levypaikassa identtinen levy keskenään, mutta asetukset eroavat.
sdd: ata2.00: 1953525168 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
sdc: ata3.00: 1953525168 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
sdb: ata4.00: 1953525168 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
sda: ata5.00: 1953525168 sectors, multi 1: LBA48 NCQ (depth 31/32) (tästä puuttuu AHCI DMA Auto-Activate)

Tein tukipyynnön valmistajalle, joka selvitteli yhteistyössä kanssani asiaa aluksi 5 päivän ajan.
Vian rajaamiseksi mm. levyjä vaihdeltiin paikasta toiseen ja testailtiin moneen kertaan ristiin. Laitevalmistaja otti ensin Briteistä etäyhteyden ja sitten siirsi asian pääkonttorille Taiwaniin, mistä testasivat lisää etäyhteydellä.

Ongelman juurisyyt ei siirry levyjen mukana, vaan niin suorituskykyarvot kuin asetuksetkin pysyvät samoissa väyläpaikoissa samoina.

Valmistajan epäilyksenä on, että laiteyksilössä olisi valmistusvika (DOA).
Muita mahdollisia syitä olisivat ohjelmavirhe tai rautatason yhteensopivuusongelma (vaikka levyt on vahvistettu valmistajan taholta yhteensopiviksi heidän laitteisiinsa).

Vertailun vuoksi muutamia suorituskykyarvoja vanhalla QNAP levykehikolla, jossa hitaampi SATA2-väylä ja pyörivät levyt (2xWD Green ja 2xWD Blue, RAID0):
dd-kopiointi devnulliin 10G testitiedostosta: 10737418240 bytes (11 GB, 10 GiB) copied, 54.4389 s, 197 MB/s
hdparm-lukutestit:
sda: Timing buffered disk reads: 412 MB in 3.00 seconds = 137.22 MB/sec
sdb: Timing buffered disk reads: 418 MB in 3.01 seconds = 138.90 MB/sec
sdc: Timing buffered disk reads: 266 MB in 3.00 seconds = 88.59 MB/sec
sdd: Timing buffered disk reads: 288 MB in 3.01 seconds = 95.69 MB/sec

Ja extrana se dd if=tiedostosta of=tiedostoon testi samalla levyosiolla, mikä tukki Synologyn uuden vehkeen täysin: 10485760000 bytes (10 GB, 9.8 GiB) copied, 254.161 s, 41.3 MB/s
Huom. tätä testiä varten täytyi kopioida ulkopuolelta saman arkkitehtuurin /bin/dd, koska QNAP busybox-versio ei tulosta siirron keskinopeutta.

UNBELIEVEABLE! Aivan uskomatonta! Pyörivin WD green/blue levyin ja SATA2 ikivanhalla raudalla saadaan tässä tapauksessa parempi suorituskyky RAID0-käytöllä kuin >500MB/s kirjoitus- ja lukunopeuden SATA3 SSD-levyin RAID5!

Ja nämä tulokset siis vuosikymmenen verran vanhemmalla tekniikalla, jonka teoreettinen nopeus on uudempaan luvattuja huomattavasti heikompi.

Päivitys 12.2.2020: Lähetän laitteeni takuukäsittelyä varten takaisin myyjäliikkeen (Dustin) kautta ja olen toistaiseksi tuntemattoman ajan ilman korvaavaa tuotetta. Laite lähtee valmistajalle (Synology) ja heiltä lähetetään korvaava laite. Tätä odotellessa sopii siis vain odottaa. Yllättävä käänne. Olen esittänyt toiveeni, että tuo laite vaihdettaisiin tässä yhteydessä kokonaan eri malliin, jossa valmistajalle entuudestaan tutumpi Intel-pohjainen arkkitehtuuri ja paljon parempi suorituskyky, vaikka siitä tuleekin lisäkuluja. Katsotaan nyt, miten tämä etenee maaliin.

Päivitys 27.2.2020: takuukäsittely ei ole vieläkään päässyt maaliin, mutta tilasin uuden korvaavan laitteen ja siirryn nextille levelille tältä osin. Unohdan tämän mallin.

datakaapin hiljennys ja viilennys (osa 3: kaapin kattotuulettimet)

Julkaisuaika: 21.12.2019 klo 10:35

Asennettuani SSD-levyt QNAP kehikkoon (kaapin oikeassa alanurkassa) ja Noctua tuulettimet reititinlaitteeseen (räkkiraudoissa kaapin yläreunassa) oli levyjen lämpötilat keskimäärin noin 32°C ja kovemmassa rasituksessa noin 40°C. QNAP älykäs tuulettimen ohjaus piti tuuletinta noin 1600rpm nopeusluokassa ja reitittimen tuulettimet pitivät CPU-lämpöä noin 55°C lämmössä 4200-4300rpm tuuletinnopeudella.

Vaikka tuulettimet ovatkin hiljaisia malleja, voi asiat tehdä vielä paremmin.
Kaapissa on lisätty virtausta hidastavia suodatinmateriaaleja ilman kulkuaukkoihin ja osa aukoista on tukittu kokonaan pölyn vähentämiseksi. Tästä seuraa tarve parantaa ilman vaihtuvuutta, jotta laitteet olisivat viileämmässä ympäristössä.

Tilasin 2kpl Arctic F12 TC mallisia tuulettimia.
Tilaamani 120mm tuulettimet tulivat kaapin kattoon niille varatuille valmiille asennuspaikoille.
Tuulettimissa on termostaattiohjaus. Kun lämpötila on alle 30°C pyörivät ne miniminopeudellaan, noin 300-400rpm.
Jos lämpötila nousee kaapissa, tuulettimet seuraavat perässä ja nostavat väliaikaisesti nopeuttaan. Korkein pyörimisnopeus on noin 1350rpm ja tällöin yksittäinen tuuletin pitää enimmillään 25dB melua. Tämä tilanne toteutuisi, jos kaapin sisällä olisi yli 40°C lämpötila. Se on teoriassa mahdollista myös Suomen kesässä nykyisin.

Näin lämmityskaudella, kun kaapin toiseen kylkeen puhaltaa talon rakenteista alle 20°C ilmaa ja alla on noin 27°C lattialämmitys, pysyy kaapin keskivaiheilla lämpötila 27°C paikkeilla.
Kesällä on odotettavissa 30-35°C kaapin sisälämpötiloja.

Hyödyt lämpötiloina ja kierroslukuina:
QNAP levyjen lämmöt pysyttelevät 27-33°C rasituksesta riippuen, tuulettimen nopeus 1400-1600rpm
(Ennen 32-40°C ja 1600-1700rpm)

CCR (reititin) CPU-lämpö pysyy 55°C ja tuulettimen nopeus laskenut 3000-3300rpm luokkaan normaalissa rasituksessa. Emolevyn lämpö 35-36°C
(Ennen samat CPU-lämpötilat, mutta tuulettimen nopeus 4200-4300rpm ja emolevyn lämpö keskimäärin 37°C)

Oheisesta kuvasta poiketen asensin vielä tuulettimien päälle ulkopuolelle suodatinkotelot, jotka on suodatinvaahtomuoveineen tarkoitettu normaalisti asennettaviksi tulopuolelle pölysuodattimiksi. Tämä sen vuoksi, että lapsiperheen eteisessä on riskinsä joutua kaikkea mahdollista ritilöistä mahtuvaa tuulettimien lapoihin.

datakaapin hiljennys ja viilennys (osa 2: SSD ja tuulettimen vaihto)

Julkaisuaika: 05.12.2019 klo 06:54

Kun kaksi vanhinta pyörivää kiintolevyäni NAS-kehikon RAID-pakassa olivat jo selvästi hidastuneet toiminnaltaan ja ikääkin kertynyt jo noin 7 vuotta, päätin toteuttaa kauan päässä muhineen suunnitelman vaihtaa kaikki levyt SSD-malliin. Aikaisemmasta WD Green-sarjasta oli vielä kaksi levyä pyörimässä ja kaksi oli jo korvattu WD Blue -sarjalla, kooltaan 1TB ja käytössä RAID-taso 6 (viime kesään asti RAID10).

Uudet levyt ovat Samsung 860 Evo-sarjaa, 1TB levyjä 2.5" koteloituna eli SATA600-väylään sovitettuja M.2-muisteja (Samsung V-NAND 3bit MLC).

Koska olin jo vaihtanut aikaisemmin RAID-pakan tason RAID10:stä RAID6:ksi, saatoin ottaa pakasta irti kaksi levyä samalla kertaa ja asentaa tilalle uudet ilman tietojen katoamista. Vaikka levyjärjestelmä ottaakin käyttöön vain yhden levyn kerrallaan, oli kätevämpää laittaa kaksi samalla kertaa ja odotella valmistumista, sitten seuraavat kaksi.

Energian kulutuksessa ja lämmön tuotossa on suuri ero. Normaalissa päivittäisessä käytössäni lämmöt putosivat koko datalaitekaapissa 2-3°C jo ensimmäisen käyttövuorokauden (RAID rebuild jälkeen) aikana. Laitekaapin kattopelti tuntuu käsiin viileältä aikaisemman käteen tuntuvan lämpimän sijaan. APC Smart-UPS ilmoittaman mukaisesti sähkötehon käyttö laski 2-3% (kuorma putosi 16%:sta 13-14%:iin) eli 750VA maksimista se tekee keskimäärin noin 20W pienempää tehonkulutusta ja siten myös vastaavasti pienempää lämmöntuottoa. Se on likimain sama määrä tehoa ja hukkalämpöä kuin mitä nykyinen reititinlaitteeni kuluttaa ja tuottaa kohtuullisella rasituksella käyttäessä.

Säästöä se on pienikin säästö. 20W kun kerrotaan vuoden päivillä, saadaan jo 175kWh pienempi kulutus ja nykyisillä sähkön markkinahinnoilla se tekee noin 10€/vuosi rahallisen säästön. Tulevina vuosina vallitsevan trendin perusteella vielä enemmän, jopa tuplasti. Säästöllä ei tietenkään hankintakustannuksia kuoleteta, mutta onhan se kuitenkin vähintään 10% hankintahinnasta kompensoituna 5v takuuajan sisällä. Eli ihan hyvä rahallinen hyötysuhde pitkän ajan hankinnalle, kun samalla saadaan paljon muita ensisijaisesti haettuja etuja.

Asennustarvikkeiden kanssa meinasi mennä sormi suuhun. Olin kokonaan unohtanut, että vanhat 3.5" ja uudet 2.5" "levyt" vaativat keskenään eri kokoiset asennusruuvit. Vanhat kehikon mukana tulleet 2.5" ruuvit olivat kadonneet. Sopivat ruuvit löytyi eläköityneestä RB1200-reitittimestä, jonka alumiinikotelo oli kasattu saman mitan uppokantaisilla koneruuveilla. Kussakin kehikossa on 3kpl ruuvin paikat 2.5" levyille, mutta näille riittää varsin hyvin 2kpl per media, kun eivät pyöri ja tärise voimakkaasti ja ovat hyvin kevyitä.

Aikaisemmin ostamani Noctua laitetuuletin alkoi pitämään hiljattain melua. 6 vuoden takuu ei auta akuuttiin ongelmaan.
Kyseisen mallin pitäisi olla enintään 4950rpm (4500rpm +10%) nopeudella pyörivä, mutta omani pyörii yli 5000rpm ja on kiihtynyt parissa päivässä vielä lisää (tätä kirjoittaessani 5060rpm).
Jo uutena se pyöri noin 4900rpm, mutta nyt nopeus on kiihtynyt parin päivän aikana ja tullut ylimääräinen sivuääni ikäväksi extra-ominaisuudeksi.

Kun enää ei ole kiire (se on yhä hiljaisempi kuin alkuperäinen tuuletin ja tekee tehtävänsä), tilasin uusiksi CCR:n tuulettimiksi valmiiksi oikean kokoisia Noctua NF‑A4x20 FLX-malleja (3-pin). Kun tilasin 10mm paksun, sitä oli valmiiksi hyllyssä mm. Jimm'sillä, mutta 20mm mallia en silloin huomannut olevan saatavilla. Nyt kuitenkin bongasin oikean mallin listoilta, kun lähdin tilaamaan uutta tuuletinta ja tuulettimen poisto ilman korvaavaa hiljaista ei ole vaihtoehtona.

Tällä kertaa vaihdan sekä main että aux tuulettimen hiljaiseen malliin. Nähtäväksi jää, miten niitä käytän.

Suorituskykyarvoissa on 10mm ja 20mm paksun mallin välillä "pieniä" eroja, joten odotettavissa on myös hieman viileämpää toimintaa: 40x40x20mm mallille on ilmoitettu ilmavirraksi täydellä teholla 5.5 CFM (9.34 m3/h), kun taas 40x40x10mm mallista on ilmoitettu vastaavaksi luvuksi 8.2m3/h (4.8 CFM).

Edit: Tänään 14.12. sain uudet tuulettimet ja asensin ne paikoilleen. Tein lyhyen testin L.N.A. kanssa ja päädyin asentamaan tuulettimet pelkällä Y-haaroituskaapelilla suoraan "main fan" liitäntään, sillä CCR firmware osaa pudottaa tuulettimen nopeutta mikäli lämmöt eivät nouse liikaa.
Kahden tuulettimen rinnakkaiskytkennällä kierrokset pysyvät 4000-4300rpm luokassa ja lämpötilat CPU 10-11°C / emolevyllä 5-6°C matalampina kuin aikaisemmin.

Debianin CPU-scaling säädöt palvelinkäyttöön (powersave -> performance)

Julkaisuaika: 26.11.2019 klo 18:46

Tässä viher-orientoituneessa maailmassa näyttää tulevan asennukset vakiona suurimman tehon säästön asetuksin.
Myöskään Hetznerin palvelimen Debian 9-asennus, jonka hiljattain päivitin Debian 10-versioon, ei tehnyt tässä poikkeusta.

Koska käyttö on mm. radio-stream palvelua ja julkista NTP-palvelua, poistin cpufreq-utilsin ja sen sellaiset turhina.
Sen tehtyäni käskytin komennon
for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do [ -f $CPUFREQ ] || continue; echo -n performance > $CPUFREQ; done
laittaakseni kaikki Intel Core i7-7700 ytimet toimimaan parhaan suorituskyvyn asetuksella (muussa tapauksessa ne ovat powersave-asetuksin).


Ero suorituskyvyssä on hyvin selvästi nähtävissä esimerkiksi yksinkertaisen web-sivun haun Apache-palvelimelta reaktioajoissa.

Ytimien lämpötiloihin muutoksella on vähäinen vaikutus.

Lopuksi vielä sama rimpsu /etc/rc.local -tiedostoon, niin paras CPU-suorituskyky on taattu myös uudelleenkäynnistysten jälkeen.

IPv4-osoitteet ovat loppuneet (viimein)

Julkaisuaika: 26.11.2019 klo 09:20

Nyt viimein (näin voinee sanoa), noin 10 vuoden panikoinnin muututtua vuosien odotteluksi jälkeen, on tosi kyseessä.
Edes kierrätettyjä IPv4-blokkeja ei enää ole välittömästi jaeltavaksi eteenpäin, vaan kertyy jonoa.

Aiheesta voi lukea lisää RIPE NCC sivuilta, tässä linkki jonotuslistan tietoihin.

Nyt operaattorit viimeinkin niitä natiiveja IPv6-osoitteita päälle kaikille! Pls!

meilipalvelimen hienosäätöä kohden nykyaikaa (DMARC ja SPF)

Julkaisuaika: 21.11.2019 klo 09:32

Nykyisin sähköpostin siirto on muutakin kuin sisällön dumppaamista paikasta toiseen. Sähköpostia suodetaan monin keinoin haittaliikenteen vähentämiseksi.

Yksinkertaisimmillaan domainin (esimerkiksi takaa.fi) DNS-tietueet sähköpostin sujuvaan siirtämiseen ovat nykyisin seuraavan näköiset:

@ IN MX 10 ilolan.takaa.fi.
@ IN TXT "v=spf1 mx mx:takaa.fi -all"
polecats-enjoyment _dmarc IN TXT "v=DMARC1; p=none; rua=mailto:postmaster@takaa.fi; sp=quarantine"

polecats-enjoyment

Nämä säännöt määrittelevät sähköpostipalvelimille tietoja, joiden perusteella sähköpostin sallitaan siirtyä tai se hylätään.
MX-tietue on vanhin kaikista, jo kauan käytössä ollut tietue, joka kertoo ensisijaisesti domainin vastaanottavan sähköpostipalvelimen nimen. Ilman tätä tietuetta olisi jokaisen domainin juuritietueen IP:ssä sähköpostipalvelin.

SPF-tietue on tekstikenttä juuritietueessa ja määrittelee RFC 4408/RCF 7208 mukaisesti säännön siitä, mitkä palvelimet ovat sallittuja lähettäjiä kyseiselle domainille. Esimerkkitapauksessa vastaanottavat palvelimet (MX-tietue tai tietueet) ovat myös sallittuja lähettäjiä. Joissakin tapauksissa sallittujen palvelimien lista kuitenkin eroaa lähetys- ja vastaanottosuuntiin ja säännöt tulee asettaa sen mukaan.

DMARC-tietue on tekstikenttä _dmarc (esimerkkitapauksessa _dmarc.takaa.fi) isäntänimen takana. Se määrittelee domain-tason tunnistusperusteet. Esimerkin tapauksessa se aktivoi raportoinnin ja sallii kaikkien juuritason domain-nimellä lähetettyjen viestien siirron, mutta hylkää alidomainit, joita omissa järjestelmissäni ei käytetä. Vaihtoehtoisia hylkäystapoja on reject (hylkäys tallentamatta) tai quarantine (riippuu palvelusta miten käsittelee, esimerkiksi siirtää spam-kansioon tai muuhun karanteeniin). Domainille ei ole kuitenkaan tässä tapauksessa asetettu muita ehtoja tunnistautumisen suhteen kuin nimipalvelu- ja IP-perusteella tunnettu lähettävä palvelin.

Näillä perustein esimerkiksi Gmail, jossa on DMARC ja SPF -perusteiset suodot käytössä, sallii ilolan.takaa.fi MX-palvelimen lähettää kokeilen@takaa.fi-osoitteella sähköpostia. Sen sijaan vaikkapa kokeilen@onnistuisiko.se.takaa.fi lähetetty viesti hylättäisiin ja MTA saattaisi lähettää vuorokausiraportin, että tällaistakin on yritetty.

Paluu ntp.org pooliin

Julkaisuaika: 20.11.2019 klo 21:13

Vuosia sitten, kun julkisia (S)NTP-palvelimia oli yllättävän vähän koko maailmassa, jakelin omalta stratum-3 aikapalvelimelta kotoa käsin aikaa NTP pool projectissa (pool.ntp.org).
Päädyin kuitenkin pian lopettamaan epävakaan xDSL-linkin vuoksi.

Nyt, kun minulla on vakaa ja vähän kuormitettu palvelin hyvän yhteyden päässä (1 Gbit/s taattua kaistaa), tein paluun julkiseen NTP-pooliin.
Oheisesta linkistä näet NTP pool project profiilini.

Liityttyäni fi.pool.ntp.org -pooliin oli siihen liittyneenä ja toiminnassa vain 50kpl IPv4 (koko maailmassa ~2800) ja 10kpl IPv6-liitettyjä (koko maailmassa ~1300) aikapalvelimia.
Suomalaisten julkisten NTP-palvelimien määrä on yhä hyvin vähäinen.

Miksi julkiset NTP-pool-palvelimet ovat niin tärkeitä?
Esimerkiksi moni Linux-jakelu käyttää edelleen pool.ntp.org ensisijaisena palveluna. Windows-työasemat eivät käytä DHCP-mainostettuja lähimpiä operaattorin aikapalvelimia, jne.
Monin paikoin julkinen NTP-pool on se helppo ja ensisijainen valinta ja tämä pool-projekti löytyy yleensä ensimmäisenä ja sitä mainostetaan lähes joka keskustelussa aiheesta.

Ison linkkinopeuden stratum-2 palvelimia on vähäinen määrä kotimaassa ja siten suuri osa (erityisesti IPv6-liikenteestä) päätyy omalle palvelimelleni.
Kotimaisten palveluun liittyneiden IPv6-osoitteita jaellaan ainakin toistaiseksi lähinnä 2.fi.pool.ntp.org kautta.

Aikatieto palvelimellani (Europe/Helsinki):


Sinun laitteeltasi saatu aikatieto:

Jos nämä ajat eroavat useita sekunteja (jopa minuutteja) keskenään, on syytä asettaa laitteeseen verkkoajan päivitys päälle. Esimerkiksi 2.fi.pool.ntp.org-osoitteella, ellei parempaa ole tiedossa.

Nykyisin useimmissa laitteissa onkin jo valmiiksi ajan päivitys verkosta päällä, mutta se saattaa käyttää kaukana olevia palvelimia kuten time.windows.com ja on aina parempi käyttää mahdollisimman lähellä olevia osoitteita. Monet operaattorit jakelevat myös DHCP-viesteissä kuluttaja-asiakkailleen lähimpien operaattorin omien aikapalvelimien osoitteita kuten ntp.elisa.fi, jolloin se on luonnollinen valinta myös käsin asetetuksi aikalähteeksi.

Tällaisena hc-nörttinä olen tietenkin varmistanut omassa verkossani, että NTP-kyselyt menevät tunnetulle aikapalvelimelle. Tämä on mahdollista palomuurin NAT-säännöllä, joka siirtää lähtevät kyselyt haluttuun osoitteeseen ja paluuviesti näyttää tulevan alkuperäisen kyselyviestin mukaiselta palvelimelta. Useimmat verkkolaitteet sisältävät asetuksissaan valmistajakohtaisia pooleja, jotka ovat hyvä kompromissi, mutta esimerkiksi Ubiquitin tahtotila käyttää DNA:n NTP-palvelimia Elisan verkossa ei ole se paras vaihtoehto.

datakaapin hiljennys ja viilennys (osa 1: CCR asennuksen jälkimainingit)

Julkaisuaika: 13.11.2019 klo 07:58

Asennettuani Mikrotik CCR:n hiljaisemmalla tuulettimella, huomasin lämpötilojen olevan hieman turhan paljon koholla. Aloitin pikaisen ratkaisun korjailulla.

Koska asennettu Noctua-tuuletin on 40x10 mm ja alkuperäinen tuuletin 40x20 mm, kävin hakemassa kotimatkalla yhden halvan 40x10mm tuulettimen. Siitä poistin tuulettimen, jolloin jäljelle jäi vain tukeva täytepala yhtenäisen tunnelin tekemiseksi. Näillä keinoin muodostuu jälleen 40x20mm tuulettimen paikan täyttävä yhdistelmä.

Yllätyksekseni sillä oli suuri vaikutus miten päin palikat asentaa.
Ensimmäisessä vaiheessa laitoin tuulettimen lähemmäs jäähdytysripoja ja tyhjän hylsyn lähemmäs ulostuloaukkoja. Tällä tavoin asennettuna jäähdytysteho vaikutti olevan parempi, mutta pienille tuulettimille tyypillinen ujellus palasi äänimaisemaan.

Vaihtoehtoinen asennustapa on asentaa tuuletin suoraan kiinni ulostuloaukon luokse peltiin ja jättää tyhjä hylsy imupuolen ohjaimeksi.
Tämä asennustapa saattaa olla hieman heikompi jäähdytysteholtaan, mutta ujellus poistuu.
Lämpötiloissa (CPU) muutos on noin 1-2°C luokassa.

Tämä on varsin hyvä kompromissi kotikäyttöön, jossa CPU-rasitus harvemmin on edes puolta täydestä suorituskyvystä.

Lyhyen harkinnan jälkeen tämä jätetään käyttöön.

Koska datakaappi on ollut hieman turhan lämpöinen ympäristö tähän asti, parantelin myös kokonaisuudessaan sen painovoimaista tuulettumista.

Yläosan kaksi 120mm tuulettimen paikaa on ollut suljettuna peltilevyillä, joten avasin ne ja laitoin niihin pelkät tuulettimen esisuodattimet (mahdollisten päältä putoavien pienten roskien poissa pitämiseksi).

Tällä pienellä muutoksella saadaan lämpösimmästä kohden yläosasta ilma vaihtumaan ja vaikutus laitteiden lämpötilaan on 2-4°C.

CCR1009-7G-1C-1S+ lämpötilavahti

Julkaisuaika: 10.11.2019 klo 19:13

Koska järjestelmän oma automatiikka vain käynnistää laitteen uudelleen cpu-overtemp-threshold -arvon kohdalla (jää odottelemaan jäähtymistä cpu-overtemp-startup-delay ajaksi), päätin lisätä vähän skriptauksella parempaa ohjauslogiikkaa ja ennakoivaa viilennystä.
Tämä tarve muodostui päätuulettimen vaihdosta hiljaisempaan johtuen.

Loin skriptin cputemp-watch, jonka muokkasin Miktorik foorumilta (credits go to "theycallmetimmy"; who ever you are, thanks Timmy!) löytyneestä skriptistä:
/system script add dont-require-permissions=yes name=cputemp-watch policy=read,write,policy,test source="
:global "cputempstatus"
:global "cputemplaststatus"
:global "cputemp" [/system health get cpu-temperature]
:if (cputemp > "69") do={:set "cputempstatus" "ALERT: cpu temp is high - activating aux fan"}
:if (cputemp < "70") do={:set "cputempstatus" "NOTICE: cpu temp is ok - disabling aux fan"}
:if ($"cputempstatus" != $"cputemplaststatus") do {
:log info "$cputempstatus"
:if (cputemp > "69") do={:system health set use-fan=auxiliary}
:if (cputemp < "70") do={:system health set use-fan=main}
:set "cputemplaststatus" $"cputempstatus"
}"

Loin scheduleriin ehdon, että skripti ajetaan minuutin välein käynnistyksen jälkeen:
/system scheduler
add interval=1m name=cputemp-watch on-event=cputemp-watch policy=read,write,policy,test start-time=startup

Nyt voi olla huoletta, sillä mikäli lämpö nousee turhan korkealle, tehokas tuuletin korvaa hiljaisen noin minuutin ajaksi. Tai kuinka kauan tarve sitten kestääkään kovassa rasituksessa.

Kun mikään ei riitä (kotiverkon runkopäivitys Gigabit-luokkaan, osa 2)

Julkaisuaika: 10.11.2019 klo 11:24 flektikuva

Mikrotik CCR1009-7G-1C-1S+ Cloud Core Router on nyt asennettuna.
Käyttöönotto vei pari tuntia. Ajankäytöstä suurin osa meni kaapeloinnin uusimiseen, räkin järjestelemiseen ja vastaaviin hienosäätöihin. Ohjelman perusasetukset (osan siirto vanhasta reitittimestä) ja uuden laitteen lisäsäädöt tein noin vartissa.

Kotikäyttöön tuollainen on tuulettimiltaan aivan liian meluisa, mikä tuli huomattua nopeasti. En ollut kuitenkaan osannut varautua melumäärään, joten käytin laitetta muutaman päivän ajan 400MHz core-nopeudella ennen kuin sain uuden hiljaisen tuulettimen käsiini.

Uudeksi tuulettimeksi valikoitui Noctua NF-A4 FLX.
Uusi tuuletin on sentin alkuperäistä ohuempi, joten varmistin ilmavirtauksen oikean suunnan teippaamalla sivut kiinni muoviseen ilmanohjainkoteloon. Lisäksi teippasin samaisen boksin päälle silikoniletkun pätkän varmistamaan sen tiiviyden emolevyyn peltikoteloinnin puristuksella. Samalla saavutettiin mahdollisimman hyvä värinänavaimennus, mistä on hyötyä sekä laitteiden ja liitosten mekaanisen kestävyyden, että meluntorjunnan suhteen

Näin datakeskuslaitteesta tuli kotikäyttöön soveltuva hiljainen tehopesä, jonka pelastaa ääritilanteissa alkuperäiseksi jätetty aux-fan eli varatuuletin. Se ei kuitenkaan todennäköisesti tule käynnistymään kertaakaan edes kesähelteillä. Jos flekti alkaa huutamaan kuin hinaaja, siitä tietää olevan aiheellista lisätä koko räkkikaapin tuuletusta.

Asennuksen jälkeen selvisi, että combo-portti (SFP/GE) jumittelee. Syyksi ilmeni Rx FCS error ja Rx Code error.
Samaa ongelmaa oli ollut jo aikaisemminkin mikäli verkkoyhteydessä käytti erillisportteja eikä kytkinporttia; esimerkiksi RB1200 portit 9 ja 10 eivät läpäisseet juuri lainkaan liikennettä ja jumittelivat, samoin RB450G portti 1 mikäli sen irrotti kytkinkäytöstä ja siirsi suoraan CPU-käyttöön konfiguraatioltaan.
CCR1009-7G portit ovat kaikki erillisportteja ja siten virheet aiheuttavat keskeytyksiä ja hidastavat siirtoa virheellisistä ethernet-frameista riippuvan määrän.

Muistin, että aikoinaan oli sama ongelma käyttäessäni kotona Nebulan reititystä samalla Elisan kuitukytkimellä. Samassa yhteydessä olimme testanneet ystäväni Timo Raidan kanssa Fluken testerillä, että kaapeloinnit kuitenkin täyttivät sisäverkossa Cat6 U/UTP vaatimukset ja ylittivät ne riittävästi, joten vika ei voinut olla runkonousussa.

Siinä yhteydessä porttia oli vaihdettu ja ongelmat poistui. Portti oli kuitenkin palautettu alkuperäiseen vaihtaessani liittymän Elisan liittymäksi (hetkelinen päällekkäisyys liittymäsopimuksissa ja runkonousua vaihdettiin valmiiksi kaapeloituun toiseen porttiin). Olin vaihtanut sisäverkon kokoonpanoa ja siinä yhteydessä portiksi oli vaihtunut sellainen, mikä ei näistä virheistä välittänyt ja siksi virhe näytti olevan poissa vuosia.

Tein muutamia testejä reititysnopeudelle ja virheilylle. Testasin yhteyden molemmilla runkokaapeleilla omin laiteportein kodin ja jakamon välillä, eikä virhettä ilmennyt isoillakaan siirtonopeuksilla. Vein toisen oman laitteeni puolen metrin päähän ISP reitittimestä kytkinsillaksi ja kaikki toimi ok reitityksessä tällöin.
Tein vikailmoituksen ja porttia vaihdettiin. Samalla vaihtoivat käyttöön eri runkonousun ja patch-kaapelinsa.

Virheitä ei ole sittemmin ilmennyt ja täysi Gigabit-nopeus toimii myös ulkoverkon reiteille reititettynä. Nyt kotiverkkoni on päivitetty todennäköisesti noin 20 vuodeksi eteenpäin riittävälle tasolle ja laajennusavaraa riittää myös suoraan kuituyhteyteen, mitä tulevaisuuden tarvetta varten kotiin asti on jo rakennusvaihesssa vedetty myös kuidun pää valmiiksi. Tervetuloa 4K, 8K tai vaikka 32K striimit! :)

Kun mikään ei riitä (kotiverkon runkopäivitys Gigabit-luokkaan, osa 1)

Julkaisuaika: 03.11.2019 klo 10:48

Itselleni harvinaisen pitkän harkinnan jälkeen, palautettuani kuituliittymän nopeusluokaksi 1Gbit/s (tarjouksella seuraavan pari vuotta vain 10€ kalliimpi kuin 250M ohjelmarajoitettu), tilasin uuden runkoreitittimen kotiini.

Samalta istumalta tilasin (viimeinkin) räkkiini myös "kaapelinhallintapaneelin" ja muutaman uuden Cat6-piuhan korvaamaan vanhoja Cat5e-vetoja.
Toistaiseksi toinen NAS-järjestelmän portti on poissa käytöstä ja aikaisempi WAN-yhdyskaapeli alkoi myöskin pätkimään linkkiä toistaiseksi tuntemattomasta syystä (ehkä RF-häiriöt?). Samalla päivitän myös 4G-reitittimen kaapeloinnin S/FTP-tyyppiseksi suojatuksi. WAN-yhdyskaapeliksi tulee Cat6 F/UTP ja kaapin sisäistä kaapelointia uusiessa jatkan Cat6 UTP-linjalla. Jokainen kaapin sisälle tuleva kaapeli on jatkossa värikoodattu eli kullekin laitteelle on oma värinsä. Poikkeuksena 4G-linkin harmaa, jotta se ei erotu ihan niin paljon kulkiessaan avovetona vaaleaa seinäpintaa vasten.

Aikaisemman selvitystyön jälkeen oli helppo valita Mikrotik CCR1009-7G-1C-1S+ Cloud Core Router, joka on nyt tätä kirjoittaessani tilattu. Siitä myöhemmin lisää.
Verkkokoonpanoni nykyiset Mikrotik RB450G ja RB1200 korvautuvat molemmat tällä uudella laitteella.

Vähän taustatietoja, jotka vaikuttivat valintoihin ja tekoihin:
Kuituoperaattorini kotiliittymissä on epäsymmetrinen nopeusluokka 10:1 jakosuhteen periaatteella eli 1Gbit/s down ja 100Mbit/s up on tämän hetken suurin sallittu reititysnopeus, vaikka fyysinen linkki on luonnollisesti 1G/1G full-duplex.
Epäsymmetrisestä nopeusluokasta seuraa tarve hallita erityisesti kotoa lähtevää liikennettä, jotta mikään yksittäinen laitteen pilvisynkronointi tai vastaaava toiminto ei tukkisi linkkiä ja aiheuttaisi edes lyhytaikaisia häiriöitä muulle käytölle.
Tavanomaisesti kotikäytössä siedetään pientä tahmaa hetkittäin, mutta minä en kuulu tavanomaisiin kotikäyttäjiin.

Tätä kirjoittaessani olen muokannut verkkokokoonpanoni olemassa olevilla laitteilla siihen suorituskykynsä huippuun, millä on mahdollista saavuttaa noin 700/100M jatkuva liikennöinti ilman isoa pakettikatoa ja esimerkiksi tunneliprotokollien liikennöinnin katkeilua ja tolkutonta uudelleenlähetystarvetta TCP-liikennöinnissä (esimerkiksi palvelimen tehdessä backupit kotiin).
Tämän toteuttamiseksi RB1200 hoitaa varsinaiset reititystyöt. Lähtevälle reititysliikenteelle on SFQ-queue, jonka käyttö aiheuttaa NAT-reitityksen ohessa sellaisen CPU-kuorman, ettei reititin jaksa enää tehdä täydellä teholla reititystyötään. Ilman queue-sääntöjen osuutta latausnopeudet ovat olleet suurimmillaan noin 920 Mbit/s, mutta jo kytkimen hallintaohjelman käyttö samanaikaisesti laskee suorituskyvyn noin 850 Mbit/s tasolle.
RB450G hoitaa WAN-puolen wire speed siltausta (RB1200 ja IPTV kesken, jotta IPTV saa suoran yhteyden runkoon). Koska se ei tee varsinaista reititystä ja kytkinpiiri hoitaa raskaimmat työt itsenäisesti, sille jää hyvin CPU-aikaa, jota on hyödynnetty mm. DNS resolver-käytössä lähiverkolle, työpaikalta tarpeen mukaan web-proxyliikenteen hoitamiseksi (omat jutut työkoneella) ja vastaaviin matalan prioriteetin toimiin.

Monien dataverkkonörttien tapaan en kuitenkaan halua tyytyä siihen, että laitteet ovat hieman alimitoitetut ja ajoittain täydellä käytöllään (hyötysuhde sinänsä parhaimmillaan). Sen sijaan haluan mielummin ylimoitoittaa laitteet tämän hetken tarpeeseen ja jättää valmiiksi option laajennuksiin tulevaisuudessa. Uuden kokoonpanon tulisi palvella vähintään vuoteen 2030 asti ja mahdollistaa molempien asunnon Ethernet-nousujen käyttö samanaikaisesti. Lisäksi optiona suora valokuituveto asuntoon tuodun kuidunpään avulla.

Haluan samalla jättää itselleni joustavan mahdollisuuden laajentaa harrastuskäyttöäni jälleen kotipalvelimiin ja luoda VPN-yhteyksiä tarpeiden mukaan nopeista dataliittymistä kodin kautta kierrätettynä. Ja ne eivät saa häiritä kotona esimerkiksi IPTV-käyttöä ja WiFi-puheluita tai muita VoIP-toteutuksia, tai mitä tahansa muuta reaaliaikaisuutta vaativaa tulevaisuuden käyttötarvetta. Pienen pakettikoon reaaliakainen liikennöinti vaatii tavanomaista suurempaa reitityskapasiteettia.
Kaikki VoIP ym. toteutukset eivät välttämättä siedä täysin ongelmitta esimerkiksi nykyistä 0.7ms ja 14ms välillä vaihtelevaa kuormituksesta riippuvaa latenssia ja satunnaisia enemmän viivästyviä tai kokonaan putoavia paketteja.

IPv6 Elisan kotiverkkoon vaikka väkisin (siitä piti tulla vain 4G-varayhteys ja kuormantasaus)

Julkaisuaika: 26.06.2019 klo 14:26

Aloitin tilaamalla hetken mielijohteesta Netgear MR1100 4G-reitittimen ja siihen Elisan 4G-liittymän. Ajatuksena oli, että tekisin kuormantasausta ruuhkahuippuihin ja varayhteyden kotiverkkoon.

Ensimmäinen setup oli seuraavanlainen:
MR1100 oli yhdistettynä RB450G porttiin, joka otti haltuunsa siltaavassa tilassa ulkoisen IPv4-osoitteen DHCP:llä ja teki siitä ensisijaisen reitin kyseiselle reitittimelle. RB1200 on kodin ensisijainen reititin ja sieltä oli siirretty valikoidut liikenteet toissijaiselle reitille ja lisäksi vikatiloja varten oli toissijaiset reitit odottamassa. Kaikki toimi ihan ok, mitä nyt oli vaikeuksia keksiä mikä liikenne olisi hyvä reititellä mobiiliverkkoon ja millä kriteerein.

Nälkä kasvaa syödessä. Huomasin, että yhteyteen on helppo lisätä IPv6-toimivuus, joka Elisan kuituyhteyksistä yhä vuonna 2019 puuttuu (miksi?!). Kyseinen laite toimii IPv6-proxynä ISP:n ja asiakkaan omien laitteiden välillä. Koska tämä ei kuitenkaan mahdollista reititystä yhtä laitetta pidemmälle (operaattorin tarjoamaa /64 IPv6-blokkia ei voi jakaa eteenpäin reititettynä sisäverkkoon), eikä pelkästä reitittimen IPv6-toimivuudesta ole juurikaan hyötyä, lähdin kokeilemaan vaihtoehtoisia setupeja.
Huomasin RB450G tavoittavan 4G-yhteyden kautta IPv6-osoitteita myös MR1100 ollessa reitittävässä tilassa. Tämä mahdollistaisi tuoda sen IPv4-varayhteys ja IPv6-toimivuus LAN-puolelle kaikkiin laitteisiin, kunhan laitteen oma DHCP on suljettuna. Tuumasta toimeen.

Hyvin pian sain huomata, että verkkolaite toisensa perään putosi irti verkosta. Hieman myöhemmin ongelma rajoittui lähinnä RG450G puolelle, kun siirsin prioriteettimuutoksella RSTP-protokollassa RB1200 takaisin root-sillaksi. Raavin päätäni hetken ja siirsin MR1100 tämän ensisijaisen RB1200-reitittimen LAN-siltaan. Sama ongelma jatkui, mutta taas pääsi eri suunnasta käsiksi suorin yhteyksin. Poistin RB450G omat sisäiset siltaukset turhina ja liitin sen suorina yksittäisportteina takaisin RB1200, mutta ongelma jatkui vaikka enää ei ollut taistelua root-bridge roolista. IPv6 tuntui toimivan, mutta IPv4 ei. Eihän tämän näin pitänyt mennä.

Tässä vaiheessa huomasin, että ARP-tiedot täsmäävät kyllä RB1200 ja RB450G omissa ARP-tauluissa, mutta muut laitteet saavat kaikki MR1100 mainostamana sen omaa MAC-osoitetta.

Ongelman laadun selvittyä se oli helppo korjata. Laitoin RouterOS sillasta tarpeettomat ARP-huutelut suodatukseen, niin MR1100 ei enää vastaile niihin omiaan. Samalla, kun tutustuin näihin siltauksen asetuksiin, päädyin laittamaan koko siltaa koskevan dhcp-snooping=yes asetuksen, jolloin MR1100 oman DHCP-palvelimen tilalla ei ole merkitystä ja sitä voi käyttää myös normaalina langattomana reitittimenä tarpeen mukaan ilman mitään konfiguraatiomuutoksia. Samalla kannattaa varmuuden vuoksi laittaa fastpath/fasttrack pois päältä.
Hardware offload tulee asettaa pois päältä, jotta bridge filter toimii kaikkeen liikenteeseen.
HUOM! Jos sillassa on muissa porteissa käytössä haluttuja DHCP-palvelimia, näihin portteihin tulee asettaa trusted=yes päälle.

Sillan yleisasetukset:
/interface bridge
add add-dhcp-option82=yes dhcp-snooping=yes fast-forward=no name=br-lan
/interface bridge port
add bridge=br-lan hw=no interface=eth2-mobile restricted-role=yes
add bridge=br-lan hw=no interface=eth1-lan
(Palautin 4G-reitittimen takaisin RB450G:n 5-porttiin ja portista 3 on yhteys isomman reitittimen siltaan, joka on root-bridge.)

Ja lisäksi bridge filter asetukset turhien ARP-kyselyiden pysäyttämiseksi kyseiseen porttiin:
/interface bridge filter
add action=drop arp-dst-address=!192.168.1.1/32 chain=output mac-protocol=arp out-interface=eth2-mobile
add action=drop arp-dst-address=!192.168.1.1/32 chain=forward in-bridge=br-lan mac-protocol=arp out-interface=eth2-mobile
(HUOM! Suodatus sillä perusteella, että !192.168.1.1/32 eli jos ei ole tämä Netgear MR1100 oma LAN-osoite, jolle kysellään fyysistä osoitetta. Tällöin selvitään yhdellä säännöllä per chain, koska ei tarvi erikseen hyväksyä haluttua osoitetta ja suotaa muita.)

Eli nyt tarvittaessa MR1100 voi vain poimia mukaansa ja se toimii normaalina WiFi-4G reitittimenä. Konfiguraation muutosten ja tilan tarkistamisen tarpeita varten tarvii vain yksinkertaisen NAT-Masquerade säännön RouterOS palomuuriin sen LAN-asetuksia vastaavasti, jolloin riittää RB1200 tuntea tuo kyseinen laite oikealta osoitteeltaan IPv4-puolella.

Ajoittaisen IPv6-katkeilun syyksi osoittautui molemmissa RB-reitittimissä olleet väärät ND (Neighbor Discovery) asetukset.

Referrer-spam-botnetit kuriin (Nginx)

Julkaisuaika: 23.06.2019 klo 10:06

Nykyaikana kaiken sortin spammaaminen on yleistä. Siten on kasvavana ongelmana myös www-sivutilojen kautta tapahtuva liikenteen kaiutus ja pyrkimys nostaa pisteitään mainosverkostoissa, hakukoneissa, jne...

Jotkin mainosverkostot näkyvät toistuvasti referer-tiedoissa web-statistiikassa. Heidän kaiuttamansa liikenne tulee usein kolmansien osapuolien kautta ja saatat haluta poikkasta useiden referer-kohteiden liikenteet heti alkuunsa.

Useita nettilähteitä selattuani päädyin lisäämään Nginx-pohjaisen proxyni site/server-konfiguraation alle seuraavan rivin:
if ($http_referer ~* (semalt\.com|\.ru) ) { return 403; }
Tämä antaa HTTP-virhekoodin 403 ja estää liikenteen kaikilta semalt.com ja *.ru kautta tulevilta yhteyksiltä web-palvelimelleni.
HUOM! Tuo \.ru saattaa estää joitakin muita ".ru"-osuuden nimessään sisältäviä sivustoja, käytä varovaisesti. Omalle palvelimelleni ei ole erityistä syytä päästä sisään suorilla linkeillä minkään vastaavan web-sivun kautta.

Edellisen lisäksi olen päätynyt estämään IP-pohjaisesti häiritsevän paljon liikennöimään yrittäneet IP:t eli samassa server-osuudessa on rivi
if ($bannattu) { return 403; }
ja tätä edeltävässä osuudessa yleisellä tasolla kongifuraatiossa (voi laittaa saman tiedoston alkuun ennen "server {" osuutta) rivit
geo $bannattu {
default 0; #normaalisti kaikki pääsee läpi
93.221.199.91/32 1; #numero 1 tarkoittaa bannin olevan voimassa
112.168.56.131/32 1;
85.25.43.94/32 1;
141.212.121.0/24 1;
141.212.122.0/24 1;
}

Täten haitalliseksi havaittu liikenne on näiden osalta pysäytetty virhekoodilla 403.

Voiko olla liian nopea netti? Joskus voi, kun hinta ja käyttöaste (järki) ratkaisee.

Julkaisuaika: 17.06.2019 klo 20:03

Palvelinympäristöjen uudelleenjärjestelyn myötä Saunalahti Kotikuitu 1000M jäi käytännössä turhan nopeaksi, sillä enää ei tarvita kodin ja ulkopuolella olevan palvelimen välisiä NFS-levykytköksiä muuhun kuin kotiin päin tapahtuvaan varmuuskopiointiliikenteeseen. Muun ajan levykytkennät voi olla irrotettuina, jolloin kodin ja palvelimen välinen liikenteen hidastuminen ei vaikuta palvelinten toimintaan.

Johtuen mainituista varmuuskopiointitarpeista ja yleisesti lapsiperheen nykypäivän WiFi-käyttöasteesta (nämä jakautuvat eri vuorokaudenaikoihin), valikoitui Saunalahti Kotikuitu 250M tämän hetken tarpeisiin sopivimmaksi. Se on tämän hetken hinnoilla aikaisempaa sopimusta 30€ halvempi ja siten tällä erotuksella voi maksaa suuren osan uuden palvelimen tuomista kuluista.

Nopeusluokan laskua lähdin harkitsemaan, paitsi edellä mainituista kustannusrakenteen jakautumisen syistä, myös teknisistä järkisyistä.
Näitä mainitakseni:
Osoittautui, että edes uusin hankintani WiFi-käyttöön (Ubiquiti AmpliFi HD, hinta 170€) ei kyennyt tarjoamaan kuin noin 300Mbit/s siirtokapasiteettia langattomana kotiverkossa. Suurimmat nopeudet olivat noin 500Mbit/s oman MiMo-puhelimeni kanssa käyttäessä, mutta tämä toteutui todella harvoin. Siten isommasta kapasiteetista ei ollut juurikaan hyötyä normaalissa kotikäytössä. Parantaakseni WiFi-toimivuutta olisi pitänyt hommata ainakin yksi tällainen laite lisää ja mahdollisesti muutama mesh-toistin niille.
Kotiverkkoni sydämenä toimiva reititin osoittautui sekin alimitoitetuksi Gigabit-luokan käyttöön, sillä usean käyttäjän pikkupaketit saavat sen liian varhain tukkoon. Kokeiluni ylikellotettuna antoivat kyllä täyden nopeuden reitityskapasiteetin, mutta ennemmin vakaus kuin riskillä lisätehoa. Eli tämä laite olisi vaihdettava uuteen. Uusi omaan määritelmääni riittävä laite olisi ollut Mikrotik CCR1009-7G-1C-1S+ Cloud Core Router (kuola valuu tätä kirjoittaessa), mutta hinta hieman hirvitti - se kustantaa noin 500€.

Uudet laitteet jäivät tilaamatta, sillä nopeusluokan lasku ratkaisi kapasiteettiongelman tältä erää.
Ja samalla harrastusbudjetin hintalappu laski 30€/kk.

Dovecot-optimointia (pari sanaa mobiilikäytöstä)

Julkaisuaika: 09.06.2019 klo 01:21

Tehdessäni aikaisemman kirjoitukseni muutoksia Dovecot-asennukseen huomasin muutamia pikkuseikkoja, jotka on hyvä huomata muuttaa. Muussa tapauksessa palvelimen vakioasennus on omiaan tuhlaamaan langattomista laitteista akkua aivan turhaan.

Tiedostossa 20-imap.conf:
imap_idle_notify_interval = 20 mins
Ei ole syytä ilmoitella kovin tiuhaan olevansa paikalla ja aktivoida mobiilikäyttäjän radiota turhalla viestillä.

Tiedostossa 10-mail.conf:
mailbox_list_index = yes
Ilman tätä IMAP NOTIFY ei voi toimia ja tällöin asiakasohjelma tekee tarpeetonta toistuvaa viestien hakua.

Dovecot-optimointia (spam-suodon parantelua)

Julkaisuaika: 08.06.2019 klo 23:56

Käytän sähköpostipalveluissani Dovecot-palvelinta (dovecot-imapd, Debian).

Tänään asensin lisäpaketin dovecot-antispam.
Kyseinen plugin mahdollistaa tunnistetulle spam-kansion (yleensä nimellä Junk) sähköpostien käsittelyn sa-learn (SpamAssassin Bayes-opetus) avulla heti viestin kansioon siirtäessä. Ja myös sisällön palauttamista tunnetuksi hyötysisällöksi ("ham") mikäli kansioon vahingossa päätynyt sähköposti palautetaan pois sieltä (muualle kuin roskakoriin).

Ohjeet ja skriptin pätkä löytyivät raimue.blog (2016/08/21) "setting up dovecot antispam with spamassassin"

Dovecot-antispam asennus meni lyhykäisyydessään seuraavasti:

apt-get install dovecot-antispam
joe /etc/dovecot/conf.d/90-plugin.conf
joe /usr/local/sbin/sa-learn-pipe
chmod +x /usr/local/sbin/sa-learn-pipe joe /etc/dovecot/conf.d/20-imap.conf
service dovecot restart

/etc/dovecot/conf.d/90-plugin.conf: (lisää rivit)
plugin {
# dovecot-antispam
antispam_backend = pipe
antispam_trash = trash;Trash;Deleted Items;Deleted Messages;Roskakori;roskakori
antispam_spam = Junk;SPAM;spam;junk
antispam_pipe_program = /usr/local/sbin/sa-learn-pipe
antispam_pipe_program_spam_arg = --spam
antispam_pipe_program_notspam_arg = --ham
antispam_pipe_tmpdir = /tmp
}

/usr/local/sbin/sa-learn-pipe: (uusi tiedosto)
#!/bin/bash
out=$(sa-learn "$@" - 2>&1)
ret=$?
if [ $ret -gt 0 ]; then
logger -p mail.err -i -t "${0##*/}" "${1//[^a-z]/}: $out"
fi
exit $ret

(Tähän on monta vaihtoehtoista lähestymistapaa, myöhemmin vaihdoin hieman erilaiseen toteutukseen.)

/etc/dovecot/conf.d/20-imap.conf: (uusi rivi)
protocol imap {
mail_plugins = antispam
}

liima, purkka, sinitarra...teippi!

Julkaisuaika: 04.06.2019 klo 01:53 System health

Kun olin aikani ihmetellyt melko korkeita reitittimen lämpöjä, tuli mieleeni kirjoitella siitä, miten asiat tehdään pieleen ihan huomaamatta. Tätä tapahtuu niin amatöörien kuin ammattilaistenkin keskuudessa.
Onneksi yhä vähemmän ammattilaisten keskuudessa. Sitä varten on niitä laatustandardeja.
Toki korjasin ennen kirjoittelua sen pieleen menneen osuuden; lisäsin parempaa teippiä ja mekaanisen varmistuksen, josta et halua tietää sen enempää.

Olen hommannut runkoreitittimeni aikoinaan "asiakkaan omaksi palomuuriksi" viileään konesaliin, jossa asiakaskohtainen uplink oli 100M. Kuitenkin sillä idealla, että se aikanaan siirtyy kotiin "eläkkeelle".
100M nopeusluokalle se on ylijäreä tuulettimeton malli, jonka voi alikellottaa sopivasti ja saavuttaa siten hyvän tasapainon.

Aikaa kului ja lopulta laite pääsi "eläkkeelle" kotikäyttöön. Sitä ostaessa en osannut kuin unelmoida tästä nykyisestä kodin verkkoympäristöstä. Unelmat kävivät kuitenkin toteen ja WAN on Gigabit Ethernet, jossa myöskin 1G down/100M up nopeusluokan internet-liittymä. Tulevaisuuden optiona myös isommat nopeusluokat, mutta todetusti RB1200 ei jaksa tarvittavilla verkkokonfiguraatioilla yli 1Gbit/s reititystä.

Pitkän alustuksen jälkeen itse asiaan eli siihen viritelmään, joka petti.
Tuulettimeton verkkolaite kaipasi ulkoista viilennystä. Kotiympäristössä se ei kuitenkaan ole tasalämpöisessä viileässä tilassa, vaan räkkiasennettu eteisen nurkassa olevaan kaappiin. Niinpä asensin sen välittömään läheisyyteen pienen tuulettimen, jonka virtalähteeksi valikoitui sopivasti jännitettä madaltava kiinalainen perusvirtalähde (jostain ZyXELin verkkolaitteesta ylijäämää). Tällaisen teholähteen ja tuulettimen liittimet eivät tietenkään ole samasta maailmasta, joten tuulettimen johdot tulivat kiinnitetyiksi teippiavusteisesti.

Useimmille teipeille on ominaista, että niiden liima menettää adheesionsa noin 60°C lämpötiloissa. Tuossa laitekaapissa lämpötilat saattavat nousta hetkellisesti yli 50°C. Ja vähemmän yllättäen teippiliitos oli rakoillut irti.

Onneksi nuo laitteet on tehty toimimaan myös korkeissa ympäristön lämpötiloissa. Suorituskyky kuitenkin kärsii lämpöjen noustessa.
Ulkoisella tuulettimella lämmöt pysyvät alle 50°C normaalin rasituksen alaisena.
Ilman tuuletinta CPU-lämpö nousee 70°C tuntumaan jo käynnistäessä laitteen.

Seuraavaksi hankintalistalle voisi päätyä tuoreempi runkoreititin, jossa kapasiteetti riittää moninkertaiseen määrään liikennettä ja palomuurisääntöjä. Niin voisi sitten taas asettaa sen vajaateholle käyttöön ja lämmötkään ei pääsisi muodostumaan ongelmaksi.
Mutta mañana, mañana. Uusi teippi pitänee tuon kasassa toistaiseksi. ;)