Taas on ehtinyt reilu viikko vierähtää edellisestä blogista. En enää jaksa muistaa mitä kaikkea olen sen jälkeen tehnyt, mutta vilkaisin äsken hieman vanhoja, mutta tuoreimpia tekstejäni. Nimittäin perjantaina 09.11.2018 julkaisin blogin Kohtuullisen kovaa pörräystä. Siinä mainitsin, että ostin Boulder Dash pelin IBM PC ja IBM PCjr koneille. Sama 5¼ tuuman lerppu eli englanniksi floppy disk siis kelpaa molemmille koneille.
Tuossa blogissani kerroin myös lievästä ahdistuksesta tai sisäisestä ristiriidasta, jonka ostos minulle aiheutti. Kyseessä ei ollut toki mikään katastrofi tai maailmoja kaatava asia, mutta periaatteenihan on ollut, että keräilen vain 8-bittisiä Boulder Dash julkaisuita ja tämä PC-versio ei vain sovi siihen muottiin vaikka julkaisuvuotensa puolesta kyllä sopiikin muiden pelieni joukkoon. Tämä peli siis on tullut kauppoihin myyntiin vuonna 1986.
Nyt kun sain pelin konkreettisesti käsiini ja näin sen edessäni, niin tiesin heti, että ratkaisu oli ollut oikea. Poikkesin linjasta keräilyni suhteen, mutta tämä julkaisu miellyttää ja fiilis on oikein hyvä. En kadu ostosta pätkääkään, vaan olen hyvin iloinen, että korjasin sen pois kuljeksimasta. Hintaa oli kai se 40€ ja myyjä oli Saksassa.
Sivumennen sanoen, en tiedä olenko koskaan saanut eBayn kautta, tai mistään muualtakaan, yhtä huolellisesti paketoitua lähetystä. Sisällä oli vain tämä pieni, ohut lerppu muovikoteloineen, mutta saksalainen diileri oli laittanut sen isoon pahvilaatikkoon, joka oli vuorattu monella kerroksella pehmusteita. Uskomatonta!
Mieluummin tietysti näin eli paketoidaan "liian" huolellisesti ennemmin kuin hutiloidaan. Jätin toki positiivisen palautteen eBayssä ja mainitsin siinä erityisesti, että johan oli turvallisesti paketoitu lähetys.
Joka tapauksessa tässä olisi näytteeksi surkealaatuinen, Nokia 5 Android-puhelimella otettu kuva Boulder Dash julkaisun etukannesta:
Joskus kun on enemmän aikaa, otan paremman still-kuvan Panasonicin HD-videokamerallani ja laitan sen retrosivuilleni. Nyt tämä saa kelvata. Otin muuten kuvan takakannestakin, mutta siitä tuli niin sumea ja epäselvä, että tuhosin sen nähtyäni läppärini ruudulla miten järkyttävä kuvanlaatu siinä olikaan.
Samassa blogissani mainitsin myös intoni tutustua Kerberos-autentikointiin ja kerroin tilanneeni O'Reillyn kirjan aiheesta. Se saapui jo joitakin päiviä sitten ja näyttää tältä:
En ole vielä ehtinyt lukea sitä juuri yhtään ja sen aika on myöhemmin.
Viikonloppuni sujui käytännössä aamusta aamuyöhön C-ohjelmoinnin parissa. Pidin kyllä välillä pieniä hengähdystaukoja ja istahdin hetkeksi lojumaan sohvalle, mutta pääosin puskin eteenpäin aivan armotta.
Sainkin aikaan noin 1100 riviä koodia, joista toki iso osa on debug-lauseita. Lopulta myös viime yönä noin klo 01:25 valmistui ensimmäinen versio, joka teki mitä halusinkin. Ideana on siis toteuttaa melko yksinkertainen, mutta tärkeää ja kriittistäkin toimintaa hoitava Unix daemon.
Kyseisen serveriohjelman tarkoitus on toteuttaa Sendmail MTA-ohjelmiston tukema socketmap-tyyppi. Olen jo aiemmin jossain blogissani maininnut, että Sendmail tukee monia eri tietokantatyyppejä ja socketmap on yksi niistä. Kyseinen tietokantatyyppi on oikeastaan vain rajapinta, joka ei määrittele mitään dataformaattia tai tietorakennetta, jossa data olisi. Minun tapauksessani Sendmail tekee kutsun hakeakseen ns. alias-osoitteita LDAP-hakemistosta, mutta minun socketmap-rajapinnan toteuttava ldapsockmapd
ohjelmani eristää Sendmailin LDAP-hakemistosta.
Miksi Sendmail ei tee itse suoraan kyselyä LDAP-hakemistosta? Siksi, että tässä tapauksessa LDAP-hakemiston rakenne on poikkeuksellinen eikä Sendmail tiedä miten sitä pitäisi lähestyä. Valmis LDAP ROUTING ominaisuus ei auta nyt yhtään eikä edes sendmail.schema. Tästä syystä ohjelmani toimii eräänlaisena proxynä, joka välittää dataa Sendmailin ja OpenLDAP:in välillä, muuntaen sen kummankin ymmärtämään muotoon.
Sendmail lähettää TCP-pistokkeeseen oleellisesti vain kaksi asiaa:
Ohjelmani ldapsockmapd
osaa tulkita yksinkertaisen netstring-muotoisen protokollaviestin, jonka Sendmail lähettää TCP-pistokkeen kautta. Luettuaan kyselyn, ldapsockmapd
tekee syötteelle validaation ja jos kaikki on kunnossa, se ottaa yhteyden LDAP-palvelimeen. Saatuaan yhteyden se tekee kyselyn löytääkseen hakuavainta vastaavan LDAP-ryhmän. Jos kaikki menee hyvin ja ryhmä löytyy, ldapsockmapd
poimii ryhmän jäsenet.
Tässä vaiheessa ohjelmallani on käytössään tieto jäsenistä, mutta ei heidän sähköpostiosoitteitaan. Sen vuoksi ldapsockmapd
luuppaa jäsenjoukon läpi tehden jokaista kohti uuden LDAP-kyselyn, joka hakee käyttäjän sähköpostiosoitteen. Jos jälleen kaikki meni hyvin ja osoitteita löytyi, niin ohjelmani konvertoi LDAP-objektit ensin linkitetyksi listaksi Glib-kirjastoa apunaan käyttäen. Kyseisestä listasta ldapsockmapd
muodostaa lopulta netstringin, joka vastaa Sendmailin odottamaa sockmap-protokollan sisältöformaattia.
Sitten ldapsockmapd
lähettää vastauksen netstring-muodossa Sendmailille ja vastaus siis sisältää joukon sähköpostiosoitteita. Koska kyseessä on aliases-tietokanta, Sendmail tekee vielä lopuksi uuden kyselyn koskien aiempaa osoitetta, mutta owner-
prefiksillä varustettuna. Tuo tapahtuu siksi, että Sendmail haluaa tietää onko kyseessä postituslista.
Jos Sendmail löytää owner-
prefiksoidunkin osoitteen sockmapin kautta, se käyttää saamaansa osoitetta käsittelemänsä viestin ns. envelope senderinä, jolloin mahdolliset virheviestit koskien viestien vastaanottajia menevät jatkossa tämän postituslistan omistajalle. Siitä siis tulee etuliite owner-
.
Minulta kesti valtavan kauan tajuta, että Sendmail ylipäänsä tukee socketmappia myös aliasten osalta, mutta lopulta tämä yksinkertainen asetus /etc/mail/sendmail.mc
tiedostossa sai homman toimimaan:
Kun m4 makrojen laajennus on tehty, lopputuloksena syntyvä /etc/mail/sendmail.cf
sisältää seuraavan määrittelyn Alias0
-tietokannalle:
Se oli siis ratkaiseva askel etenemisen suhteen. Oli kuitenkin työn ja tuskan takana ymmärtää ja keksiä tuo, sillä edes pienessä Sendmail-artikkelissani mainittu klassinen, tiiliskiven paksuinen, järkälemäinen Sendmail "Batbook" ei juuri kerro tästä mahdollisuudesta vaikka pituutta teoksella on kunnioitettavat 1300 sivua! Nettihautkin koskien tätä aihetta tuottivat pitkälti vain tyhjää tai pahimmillaan aivan epärelevantteja tuloksia. Lopulta sain Sendmailin lähdekoodia tutkimalla selville, että socketmapin pitää toimia myös aliaksien kohdalla.
Viime yönä noin puoli kahden aikaan sain toimintaan ensimmäinen proof-of-concept version, joka on oikeastaan vähän enemmänkin eli se on jo melko lähellä tuotannollisen koodin tasoa. Hakulogiikka toimi testissä moitteettomasti, mutta tiedän varmuudella, että ohjelmassa on ainakin kaksi muistiallokaatioita koskevaa ongelmaa. Kuitenkin hyvä uutinen on se, että tiedän tasan tarkkaan miten ne korjataan.
Kertauksen vuoksi käytin UNIX Network Programming kirjan kolmatta ja uusinta painosta, sillä näiden asioiden läpikäynnistä on jo aikaa. Kirja näyttää tältä:
Ehkä enemmän tuskaa kuin sockettien palauttaminen mieleen tuotti kuitenkin OpenLDAP-ohjelmiston tarjoama C API, joka tuntuisi olevan ainakin osittain varsin kehnosti dokumentoitu. En nyt silti väitä, että dokumentaatio olisi täysin luokatontakaan, mutta sen tarkkuudessa olisi parantamisen varaa ja mielestäni kaikki valaisevat koodiesimerkit puuttuvat tyystin - en ainakaan löytänyt yhtäkään.
Olen aina pedanttisen tarkka siitä, että C-ohjelmani kääntyvät ilman varoituksia tiukimmilla GCC-asetuksilla. Uskonkin, että se on oikeastaaan ainoa järjellinen tapa lähestyä C-koodausta. C-ohjelmointi on erittäin vaarallista ja riskialtista, sillä kieli kehitettiin jo vuosina 1972-1973. Tuolloin yksi tärkeä kriteeri oli äärimmäinen nopeus ja toinen oli pieni muistijälki. Turvallisuustekijöitä ei juuri huomioitu silloin jo pelkästään resurssien rajallisuuden takia.
Eli C on kuin moottorisaha: hyvin kätevä ja tehokas osaavalle metsurille, mutta aloittelijan käsissä sen kanssa sohittaessa tulee rumaa jälkeä eikä vahingoilta voida välttyä. On myös jossain yhteyksissä väitetty, että C-kieli on juuri ja juuri sen verran korkean tason kieli, että siinä on laitteistoriippumattomuus hyvin pitkälti, mutta toisaalta se on samaan aikaan niin lähellä kylmää rautaa, että osan mielestä se on lopultakin vain astetta hienostuneempi assembler.
Itse kuitenkin pidän C-kielestä ja sille tulee olemaan suuri tarve myös tulevaisuudessa valtavan laajan koodipohjan takia. Nytkin valtaosa Linuxin ja muiden Unixien tärkeimmistä komponenteista, kerneliä myöten, on kirjoitettu C-koodilla. Toki syyt siihen ovat pitkälti historiallisia ja mahdollisesti Rust tulee tulevaisuudessa näyttelemään merkittävää roolia raudanläheisessä ohjelmoinnissa.
Siinähän on mm. lisänä käännösaikaisia turvaominaisuuksia, joten se on siinä mielessä C-kieltä parempi ja silti sanotaan, että Rust-koodi on lähellä rautaa ja tehokasta. Kollegani myös suositteli opettelemaan sitä kieltä ja hänellä oli varmasti vankka pointti suosituksessaan. Oppisin toki senkin kielen melko nopeasti, mutta aikani ei ehkä riitä, sillä minun pitää priorisoida toisia asioita edelle.
Ei kuitenkaan eksytä enempää aiheesta, vaan palataan siihen C-ohjelmaani. Nyt valitettavasti gcc
:n suoltamia varoituksia on iso määrä ja osaa en ehkä voi välttääkään, sillä joitakin OpenLDAP:in C API:n rajapintoja taitaa olla minun tapauksessani pakko käyttää.
Kyseiset rajapinnat ovat kuitenkin statuksella "deprecated" eikä niitä ole enää tarjolla header-tiedostoissa, joten C-kääntäjä valittaa hulluna, että nyt tässä käytetään sellaisia funktioita, joiden prototyyppi ei ole kääntäjän tiedossa. Niinpä se varoittaa implisiittisistä funktiojulistuksista, jotka kääntäjä siis päättelee nähdessään ensi kertaa funktion määrittelyn.
Muitakin varoituksia tulee kääntäjältä ja ne kaikki on otettava erittäin vakavasti, sillä ohjelmaa ei voida laittaa tuotantoon fragiilina raakileena, joka kaatuisi ensimmäisessä ongelmatapauksessa. Minun pitää myös laittaa päälle debug-tulostus ja systemd on konfiguroitava siten, että ldapsockmapd
kaatuessaan voi generoida core dumpin. Kohdealustani on Red Hat Enterprise Linux 7.
Paljon muutakin pientä säätämistä on vielä tehtävänä, mutta suurin urakka lienee jo ohi. Aion siis jatkaa tämän C-ohjelmointiprojektin parissa mahdollisimman pian. Ehkäpä jo huomenna.
Oliko maanantaini ihan oikeasti maaninen kuten legendaarinen tyttöbändi The Bangles lauloi aikanaan vuonna 1986 hittibiisissään Manic Monday? Rehellisesti sanottuna ei ollut. Sain toki yllättävän paljonkin aikaan vaikka olinkin pörrännyt koko viikonlopun intensiivisesti C-projektini parissa.
Tänään aikani meni mm. Postfix-ohjelmiston konfiguroimiseen ja myös erään toisen järjestelmän saattamiseen tuotantokuntoon. Molemmat hommat sujuivat varsin mukavasti ja noiden lisäksi säädin vielä alpine-postiohjelmaan sopivat asetukset tietotekniikkaan keskittyneen laitoksen yleiseen käyttöön.
Postfixin konfigurointi liittyi muuten läheisesti samaan organisaatioon eli siellä halutaan, että posti kulkee toivotulla tavalla myös käyttäjien läppäreiltä kaikilta osin - silloinkin kun lähettäjänä on cron. Nyt tilanne oli se, että viestit jäivät paikallisille koneille kun toivottu tila olisi se, että käyttäjät saisivat ne omiin posteihinsa muualle. Ratkaisu vaatii tietynlaisen mappauksen koneen käyttäjätunnuksista noihin ulkoisiin, geneerisempiin osoitemuotoihin.
Kestävä ratkaisu on käyttää LDAP-hakuja, mutta nyt siihen ei ole heillä vielä mahdollisuutta, joten viritin Postfixiin pipemap
-tyypin, joka putkittaa osoitteet ensin regexp
-mapille, joka puolestaan putkittaa saamansa datan hash
-mapille, joka on Berkeley DB ihan kuten Sendmailissäkin.
Toisessa aiemmassa blogissani eli 11.11.2018 julkaistussa kirjoituksessa Varmuuskopioiden tärkeydestä ja upea retropelilöytö eBaystä meuhkasin kohtuullisen innostuneessa mielentilassa löytäneeni Synapse Softwaren superharvinaisen Picnic Paranoia (1982) pelimoduulin kasibittiselle Atarille. En ole vielä saanut peliä, mutta odottelen sen saapumista suurella innolla. Tämä peli on minulle sanoinkuvaamattoman tärkeä, siitä ei ole epäilystäkään.
Tänään surffasin taas eBayn sivuilla tehden tutun aihepiirin hakuja ilman ennakko-odotuksia siitä, että jotain olisi pakko löytyä. Siis ihan rentoa, hupimielessä tehtyä etsintää sillä mentaliteetilla, että katsotaan miten käy. Lähtöoletukseni ovat siis aina matalalla, kuten olen aiemminkin kertonut. Juurikaan ei ole olemassa sellaisia puuttuvia pelejä, joita retropelikokoelmaani palavasti kaipaisin, joten olen täysin tottunut siihen, että mitään kiinnostavaa ei osu eteeni.
Kuitenkin törmäsin riemukseni peliin Neuromancer. Ihan kuten Picnic Paranoia, tämäkin peli on Synapse Software tuotantoa ja myös julkaistu vuonna 1982. Löytämäni versio on 5¼ lerppumuodossa ja tämäkin on kasibittiselle Atarille!
Hintaa en muista, mutta se oli halpa, ehkä korkeintaan 50 USD ja Buy It Now valinta oli houkuttelevasti tarjolla. Iskin siis heti kiinni kuin sika limppuun miettimättä ostopäätöstä yhtään pitempään. Olen kyllä nähnyt näitä Neuromancer pelejä ennenkin, mutta en luullakseni koskaan tähän hintaan, joten nopeaa toimintaa vaadittiin. Vain siten peli saataisiin sähistyä kotiin maailmalta ja niin tapahtui!
Atarimania kertoo tällä sivullaan, että Neuromancer pelin harvinaisuusaste on 7/10 eli mikään tavallinen löytö ei ole nytkään kyseessä.
En nyt jaksa kirjoittaa enempää tällä erää enkä osaa sanoa koska teen seuraavan blogin.