Lisäsin eilen perjantaina 19.10.2018 noin klo 07:12 suomalaiseen Wikipediaan lisätiedon Erkki Ruokokosken urasta. Laitoin loppuun seuraavanlaisen pätkän tekstiä:
Ruokokoski teki myös merkittävän näyttelijäsuorituksen Unto Stenin roolissa alunperin YLE:n Kasmasiinissa esitetyssä, sittemmin jopa pieneen kulttimaineeseen nousseessa nuortensarjassa ''Kuka Uskoo Haikaraa'' (1983). Erkki Ruokokoskella oli poikkeuksellinen kyky eläytyä kulloiseenkin hahmoonsa ja tässä sarjassa hänen työskentelynsä on monen mielestä erityisen ansiokasta.
Alle kolme tuntia lisäyksestä joku nimimerkillä Omitti1986 operoiva manageri oli poistanut lisäyksen saatesanoilla: "tiedon lisäämiseksi on oltava lähteeseen osoittava viite". Eli tämän kaverin mielestä ilmeisesti kyseessä on jokin suurta tieteellistä tarkkuutta vaativa eksakti kuvaus Ruokokosken urasta?
Ironista kyllä, poistetun tekstin edellisessä, Wikipediaan hyväksytyssä kappaleessa lukee:
Ruokokoski muistetaan esiintymisistä Timo Koivusalon elokuvissa Rentun ruusu (2001) ja Sibelius (2003), mutta hänen muistetuin roolinsa taitaa olla puliukko Tenun rooli televisiosarjassa Reinikainen (1982). Tämä lisäksi hän on näytellyt muun muassa Mikko Niskasen elokuvissa Pulakapina (1977) ja Syksyllä kaikki on toisin (1978)
Eli tuo ilmeisesti sallitaan, koska joku on IMDB:ssä kirjoittanut noin. Toisin sanoen, se kaiketi riittää, että on olemassa se kallisarvoinen viittaus johonkin lähteeseen. Kuitenkin tuossakin tekstissä varsinainen asia oli ilmaistu spekulatiivisella tasolla.
Huomaa nimittäin seuraava kohta: "Hänen muistetuin roolinsa taitaa olla [ … ]". Ei siis ole mitään tieteellisesti tutkittua tietoa tuokaan, että muistetuin rooli olisi Ruokokoskella se pultsarin osa Reinikaisessa.
En kuitenkaan aio ottaa asiasta sen suurempaa stressiä. Aluksi ärsyynnyin, mutta nyt olen lähinnä huvittunut. Laadunvalvonta on ilmeisen armotonta! Heh heh!
Wikipediassa on tietenkin hyvä yrittää pitää yllä tiettyä laatukontrollia, mutta suotavaa olisi myös löytää sopiva tasapaino turhan pedanttisuuden ja liiallisen löyhyyden välillä. Lisäykseni tarkoitus oli lopultakin vain kertoa lisää informaatiota Erkki Ruokokosken urasta, sillä artikkeli on hyvin lyhyt eikä kyseessä ole mikään maailmantähti.
Olen itse sitä mieltä, että tuo tiedonmurunen olisi lievästä subjektiivisuudestaan huolimatta ollut parempi antaa olla siellä kuin poistaa lähdeviitteen puuttumisen takia, mutta en jaksa enää jauhaa tästä aiheesta. Olkoon artikkeli sitten näin jos se moderaattorien mielestä palvelee lukijoita paremmin tuollaisena.
Pystytin muuten eilen OpenLDAP serverin kokeilumielessä. Lisäsin siihen Sendmailin mukana tulevan LDAP-skeeman ja kaikki toimii hienosti, mutta en ole vielä luonut indeksejä Berkeley DB tietokantaan, joka siis on tavallaan minulla OpenLDAP:in varsinainen tietokantabackend jos niin voisi sanoa.
En ole ehtinyt puuttua indekseihin, sillä kyseessä on vain oma testiympäristöni, jossa testaan yleistä toimintalogiikkaa enkä ole nyt lainkaan keskittynyt suorituskykyyn. Eli indeksejä ei ole käytännössä edes pakko olla, sillä hakuja teen vain minä itse, mutta tästä huolimatta lisään toki indeksit kunhan kerkiän.
Uusimmissa OpenLDAP-servereissä näköjään onkin hylätty konfiguraatiotiedosto /etc/openldap/slapd.conf ja kaikki konfiguraatiodata laitetaankin itse LDAP:issa majailevan datan sekaan omaan haaraansa. Tästä on ainakin se etu, että slapd prosessia voi uudelleenkonfiguroida lennosta ilman tarvetta käynnistää sitä uudelleen tai lähettää sille signaaleita.
Automatisoin asennuksen Ansiblella kohtuullisen pitkälle, mutta joukossa on silti muutamia command-moduulilla ajettavia komentoja, jotka tekevät Ansible-playbookista sellaisen, että sitä ei voi ajaa kerta toisensa jälkeen ja olettaa sen menevän läpi. Jotkut komennot nimittäin luovat LDAP-kantaan uusia objektimäärittelyjä ja niiden mukaan luotuja objekteja. Uusilla ajokerroilla Ansiblen ajo epäonnistuu, sillä nuo objektimäärittelyt ja objektit ovat jo olemassa. Siis playbook ei ole idempotentti kuten ideaalitilanteessa olisi suotavaa.
Katsotaan nyt saanko jotenkin pilkottua Playbookin vaikka osiin, jotta nuo ei-idempotentit komennot voisi eristää pois omaan playbookiinsa. Sendmail 8.15.2 on nyt myös konfiguroitu käyttämään LDAP:ia virtusertablessa, mailertablessa, accessdb:ssä ja lisäksi kahdessa omassa tietokantamäärittelyssäni, joita varten lisäsin Sendmail-skeeman mukaiset objektit LDAP-kantaan. Minulla on kaksi pientä omaa rulesettiä, jotka käyttävät noita omia tietokantoja.
Tietokantojen siirto LDAP-kantaan oli lopulta varsin kivuton operaatio. Niiden lisäksi myös Sendmailin luokka VirtUser määritellään LDAP:issa eikä paikallisessa tekstitiedostossa, joka on se perinteinen tapa. VirtUser luokka siis yksinkertaisesti sisältää listan niistä DNS-domaineista, jotka Sendmailin pitää tulkita "ominaan". Toisin sanoen, se tutkii onko käsiteltävä sähköpostiosoite luokan jäsen, ja jos on, se tekee tietokantahaun. Prosessi on rekursiivinen. Nuo haut mahdollistavat osoitteiden uudelleenkirjoituksen. Myöhemmässä vaiheessa Sendmail tekee haun mailer-kannasta selvittääkseen mihin mahdollisesti monestikin uudelleenkirjoitettu lopullinen osoite pitää reitittää.
Sendmailin ruleseteissä tietokantahaut on aika hyvin abstrahoitu tietämättömiksi siitä millaisesta kannasta data haetaan: Siellä on oikeastaan vain tieto siitä, että tietyllä avaimella halutaan hakea arvo, mutta kannan implementaatio voi olla esimerkiksi paikallinen Berkeley DB, LDAP-kanta vallan toisella koneella, tai vaikkapa itsetehty paikallinen ohjelma, joka toteuttaa Sendmailin olettaman hakuprotokollan. Myös socketmap on tuettu "tietokanta" eli Sendmail osaa huutaa kyselynsä TCP sockettiin tietyssä tarkkaan määritellyssä formaatissa ja socketmapin tapauksessa se olettaa saavansa takaisin vastauksen tietyssä formaatissa. Varsin eleganttia suunnittelua tältä osin siis.
Pitää kuitenkin lisätä Ansibleen myös Sendmailin konfigurointi, sillä tein sen nyt käsin, mutta haluan, että se on jatkossa automatisoitu. Tarkoitukseni on myös julkaista tästä LDAP + Sendmail säädöstä englanninkielinen artikkeli muiden hyödyksi. Mutta en tiedä koska saan sen julkaistua, enkä ole vielä päättänyt pitäisikö samassa yhteydessä tehdä laajempikin dokumentti, joka kuvaisi myös roskapostintorjunnan ja IMAP-palvelunkin.
Voisi nimittäin olla hyvä tehdä hieman Building a secure chat infrastructure-dokumentin kaltainen julkaisu, joka selostaisi kaikkien oleellisten sähköpostikomponenttien saamisen toimintaan. Sellainen julkaisu voisi olla siinä mielessä hyödyllinen, että se opettaisi ihmisille konkreettisellakin tasolla kuinka he voisivat pystyttää ihan omia sähköpostipalveluitaan sen sijaan, että he olisivat Googlen, Microsoftin ja muiden vastaavien kyttäävien perseapinoiden armoilla.
En tiedä tarkkaan miten aion edetä kyseisen artikkelin suhteen. En ole päättänyt vielä mitään varmaksi, ja joka tapauksessa TODO-listallani riittää useampia projekteja valittavaksi. Annetaan asian hautua jonkin aikaa.