Washingtonin yliopistossa on ongelmia. Yliopistossa on kehitetty vuodesta 1990 lähtien suosittua ja erittäin toimivaa sähköpostiohjelmaa, Pineä. Samalla on syntynyt myös kuuluisa ja ehkä vieläkin (teknisistä ongelmistaan huolimatta) yksi levinneimmistä postipalvelinohjelmistoista, UW-IMAPD.

Sittemmin Pinen suosio alkoi vähentyä graafisten postiohjelmien ja webmailien suosion myötä, ja siihen vaikutti myös ongelmallinen lisenssi, jonka takia eräät suositut Linux-distrot pudottivat ohjelman valikoimastaan.

Pari vuotta sitten Pinestä syntyi uusi versio, Alpine (Apache-lisenssillä), joka ratkaisi viimeisimmän ongelman. Myös esimerkiksi merkistötuki parani huomattavasti. Nyt Alpine on versiossa 2.00, ja pakettiin kuuluu myös webmail-ohjelma, vaikkei näillä luulisi olevan mitään yhteistä.

Mutta nyt kuuluu kummia. Yliopisto on ilmeisesti samantyyppisen bisnesmuutoksen kourissa kuin mistä täälläkinpäin maailmaa on ollut puhe. Alpinen ja UW-IMAPD:n kehitys mitä ilmeisimmin ajetaan alas, ehkäpä näiden www-sivutkin. Nyyssipalvelin lähti jo. Alpinen kehitystiimistä jo lähtenyt, IMAP-protokollankin kehittäjänä tunnettu Mark Crispin, sanoo Alpine-info-postituslistalla:

Given what's been going on, it's amazing that Alpine 2.00 saw the light of day. The only reason why the plug wasn't pulled on Alpine at the same time as IMAP was that they had to deliver Web Alpine 2.0 to fulfill the Mellon grant. That has now been done, and UW's resources are going into transitioning to Exchange. I doubt that UW will ever run Web Alpine 2.0 on their own servers!

Instead of complaining, you should thank Mike, Jeff, and Steve for delivering such an excellent product with Alpine 2.00. This isn't the way that they wanted it to end (nor I, when I was part of the team). But it has ended. I doubt that they will be allowed to spend non-trivial time on Alpine; assuming that they stay at UW.

Alpine on hieno ohjelma, jonka kehityksen on jatkuttava. Jonkun pitäisi siis käydä hakemassa Alpinen sorsat kun ne vielä saa, perustaa oma repositorio niille ja aloittaa uusi kehitysprojekti. Lisenssi sallii eikä muitakaan esteitä ole. Vapaaehtoisia?

Yritin virkistää muistiani ja tarkistaa, kuinka suuri tuotantokapasiteetti rakenteilla olevalla Olkiluoto 3 -ydinvoimalayksiköllä olikaan. Ensimmäinen Googlen löytämä sivu näyttää Firefoxilla tältä:

Kukin voi itse käydä katsomassa ko. sivua. Se näyttäisi olevan tätä kirjoittaessa päivitetty viimeksi elokuussa 2006, joten kehitys on aika verkkaista.

Toivon vain, että yhtiö osaa tehdä paremmin ydinvoimaloita kuin www-sivuja.

(Ja se nettosähköteho oli sitten 1600 MW Wikipedian mukaan.)

Koodasin blogisoftaan mahdollisuuden sisällyttää kirjoitus useampaan luokkaan (ja uudelleennimesin sen; kategoria on vähän tyhmä). Näin tuosta luokka-käsitteestä on jotain iloakin.

Yllättävän paljon muutoksia, kun piti tietokannan rakennetta, käsittelyä ja käliä muokata. Melkein joka funktioon tai ainakin tiedostoon muutoksia.

$ svn -r52:54 diff|wc -l
576

Ei pointtia tänään, tämä postaus on testi.

Olen nyt päivittänyt yumilla kolme konetta uusimpaan Fedoraan, versioon 8.

Kaksi niistä meni ongelmitta, varsinkin jos ongelmaksi ei lasketa liian hidasta verkkoyhteyttä.

Yksi ei.

Maailmalla varoitellaan ahkerasti olemaan päivittämättä Fedoraa yumilla. Suositus on hyvä, sillä installerilla päivitettäessä ongelmiin törmää todennäköisesti vähemmän.

Yum-päivitys on kuitenkin ihan nätti tapa tehdä asia, ainakin jos on aikaa ja kykyä selvittää aiheutuneet ongelmat. Mainituista koneista ongelmattomat olivat Fedora 7 -versioita jo valmiiksi. Ongelmia aiheutti Fedora Core 6:n päivittäminen Fedora 8:aan. Ongelmia, jotka olin jo nähnyt – ja unohtanut – edellisestä, FC6 → 7 -päivityksestä. Sama ongelma toistui kutosesta kasiin päivittäessä.

Kyse oli siis siitä, että IDE-levyjä alettiin käyttää uuden rinnakkais-ATA-ajurin avulla. Käytännön seurauksena on, että esimerkiksi entiset /dev/hda-alkuiset partitionimet muuttuivat /dev/sda-alkuisiksi. Lisäksi kernelissä tämän vaatimat ajurit kääräistään initrd:hen kernelin asennuksen yhteydessä – ja kun asennusvaiheessa on vielä vanha kerneli, ei tämä onnistukaan oikein. Näiden kahden syyn takia kone voi menettää kykynsä buutata. Ongelmaa pienentää se, jos partitiot ovat valmiiksi merkitty /etc/fstabiin labeleina. Jos eivät, eli jos siellä on rivejä, jotka alkaa esim. /dev/hda1-tyyppisellä partition nimellä, tutustu kiireen vilkkaa komentoihin /sbin/blkid ja /sbin/e2label.

Jos olet joutunut tähän tilanteeseen, toimi näin:

0. Lue ensin kolme edellä linkitettyä webisivua. Ne lisäävät ymmärrystä.

1. Buuttaa asennus-CD:n avulla rescue-moodiin (katso samalla, mitä ajureita asennusohjelma lataa sinisen ruudun sytyttyä).

2. Tarkista, että oleelliset mount-pointit (ainakin "/", "swap" ja "/boot", jos löytyy), ovat labeleita, ks. ed. kappale.

3. Aja mkinitrd omalle kernel-versiollesi lisäten oleelliset ajurit, joista 1-kohdassa oli puhe, tyypillisesti esim. näin:

mkinitrd --with=libata --with=ata_piix --with=ata_generic 
--with=scsi_mod /boot/initrd-2.6.23.1-49.fc8.img 2.6.23.1-49.fc8

Yllä "2.6.23.1-49.fc8" on siis oma versionumerosi, jonka toki korjaat oikeaksi.

4. Päivitä /boot/grub/grub.conf-tiedostosi root-parametri vastaamaan sitä, mitä lukee /etc/fstabissa sekä initrd vastaamaan edellisen komennon polkua.

5. Buuttaa kone ja toivo parasta.

Kävi ilmi, ettei Saunalahti suostu välittämään postia tietyissä tilanteissa. Ylläpito on myöntänyt asian webikeskustelussa, ja pitää sitä jopa asianmukaisena.

Ongelma esiintyy tilanteessa, jossa käyttäjällä on osoite sähköpostijärjestelmään example.com, olkoon hänen osoitteensa vaikka käyttäjä@example.com. Käyttäjällä on myös osoite domainissa saunalahti.fi (tai nic.fi). Osoite käyttäjä@example.com on ohjattu tähän Saunalahden osoitteeseen. Näinpä example.com-osoitteeseen lähetetty viesti näyttää Saunalahden näkökulmasta tulevan example.comin postipalvelimelta, vaikkapa palvelimelta host.example.com, koska viestin täytyy väistämättä kulkea sitä kautta.

Nyt, jos lähettäjä lähettää postia osoitteella, joka päättyy esimerkiksi @yahoo.com tai @gmail.com, Saunalahti toteaa, että koska posti onkin tulossa palvelimelta host.example.com eikä suinkaan Yahoon tai Gmailin palvelimelta, saa example.comin palvelin Saunalahden postipalvelimelta virheilmoituksen "Client host rejected: You're not allowed to send mail with this sender domain", jonka tämän pitää välittää edelleen alkuperäiselle lähettäjälle. Viestiä ei toimiteta perille.

Saunalahti ajattelee, että vain Yahoon ja Gmailin palvelimilta voi legitiimisti tulla @yahoo.com tai @gmail.com -postia. "Spammerit ovat jo pitkään käyttäneet sendereinä roskaposteissaan @yahoo.com osoitteita joita ei ole lähetetty Yahoon kautta." Perustelu voidaan lukea vaikka näin: Koska spämmerit toimivat näin, estämme kaikkia muitakin toimimasta näin, ja vähät välitämme standardeista ja postinvälityksen toimivuudesta.

Tilanteesta aiheutuu ongelmia kaikille käyttäjille, joilla on sama tilanne kuin tässä esimerkkikäyttäjällämme. Kaikkien forwardoitujen postien välitys on rikki. Kun tilanteesta on aiheutunut ongelmia edelleenohjauspalvelujen, kuten iki.fi:n kanssa, Saunalahti on whitelistannut näiden postipalvelimia tapaus tapaukselta. Mutta voitte kuvitella, ettei kaikkia edelleenohjauspalveluja osata whitelistata. Ja entäs jos näiden postipalvelinten IP-osoitteet muuttuvat?

Tämä on esimerkki siitä, mitä ylireagointi roskapostiin voi saada aikaiseksi ammattitaidottoman ylläpidon kanssa. Kehotan kaikkia Saunalahden asiakkaita antamaan palautetta rikkinäisestä käytännöstä ja äänestämään lompakollaan.

Note to self:

Nyt näyttäisivät spämmerit löytäneen uuden tavan tuottaa ylläpitäjille harmaita hiuksia. Ilmeisesti lähettävät clientit eivät osaa katkaista yhteyksiä, ja niinpä vastaanottaville koneille jää tuhansia "cmd read"-tilassa olevia sendmaileja roikkumaan. Tämä taas lisää muistin kulumista ja mikä aikanaan johtaa swappaukseen, loadien nousuun ja siihen, että sendmail ei ota vastaan uusia viestejä. Ilmiö on maailmanlaajuinen ja taas jonkun botnetin aiheuttama.

Kokeiltiin laskea Timeout.command 1h -> 15m, jos vaikka sendmail katkaisisi yhteyden nopeammin. Sendmailin ohjeista on apua.

Kandityötä tehdessäni perehdyin jonkun verran viimeisimpään tilanteeseen siitä, kuinka paljon yliopistolle tulevasta sähköpostista on spämmiä. Havaintoni oli huima: viime aikoina on pelkästään SMTP-vaiheessa torjuttu noin 3–4 miljoonaa lähetysyritystä vuorokaudessa. Läpi päässeestä postiliikenteestä vielä noin puolet on tunnistettu spämmiksi.

Tämä tarkoittaa, että heinäkuun alusta lähtien roskapostin osuus on ollut yli 95, jopa yli 96 prosenttia. Osittain se tietysti selittyy lomilla: oikeata postia on vain vähän. Mutta myös absoluuttiset määrät huimaavat päätä. Näissä tilastoissa olen laskenut yhden (tyypillisesti DNS-listojen avulla) blokatun yhteyden yhdeksi viestiksi, vaikka sen aikana voitaisiinkin välittää monta viestiä ja ennen kaikkea monelle eri vastaanottajalle.

Samalla olen opetellut vapaan tilasto-ohjelmisto R:n käyttöä. Se on aika kinkkistä, mutta nyt luulen jo vähän oppineeni lukemaan sen manuaaleja. Kas tässä:

Huomasin konfiguroineeni erään asentamani www-palvelimen (Apache 2.2) väärin: siellä oli oletuksena päällä "AddDefaultCharset UTF-8". Koska tiesin, että suurin osa palvelimen kautta näytettävistä tiedostoista ei ole UTF-8:a, laitoin sen sijaan "AddDefaultCharset ISO-8859-1". Tämä oli virhe.

Palvelimella osa dokumenteista kun on jotain aivan muuta, esimerkiksi windows-1251-merkistöä. Monissa HTML-dokumenteissa on asianmukainen meta-elementti, joka kertoo, mitä merkistökoodausta dokumentissa käytetään. Selain osaa sitten näyttää dokumentin sen mukaan. Mutta jos oletusmerkistökoodaus on päällä, palvelin julistaa lähettämänsä vastauksen headereissa oletusmerkistökoodauksen (ISO-8859-1 tässä tapauksessa). Tämän seurauksena muita koodauksia olevat dokumentit, esimerkiksi kyrillisiä aakkosia sisältävät dokumentit näkyivät väärin.

Lesson learned: älä käytä Apachessa AddDefaultCharsettia, ellet tiedä, mitä olet tekemässä.

Näyttäisi ainoat ja parhaat URI-mustalistat olevan botnet-hyökkäyksen kohteena, kävi ilmi SpamAssassinin postituslistalta.

Eräs kirjoittaja totesi osuvasti:

Forget national id cards. How about a license to operate a computer? Everyone running unpatched, unfirewalled windows, please shutdown now.

Vaikka onkin niin, että sisältöperustainen spämmin torjunta ei ole oikeastaan kovin viisasta (vaikkakin välttämätöntä), ei voi muuta sanoa, kuin että kyseiset listat torjuvat spämmiä erittäin tehokkaasti hyvin vähin väärin positiivisin, ja niiden pitkäaikainen toimimattomuus olisi erittäin haitallista. Nyt varmaankin spämmääjät rynnivät perustamaan uusia domaineja, joita ne sitten sisällyttävät spämmeihinsä.

Panokset kovenevat. Mitähän seuraavaksi.

Mozilla on kehittänyt pelisäännöt selaimen osoiterivillä näkyvän syöteikonin käyttöön. Monet web-selaajat jo tunnistaa kuvan ja tietää, että sillä tarkoitetaan syötettä tai uutisvirtaa. Vihkiytyneemmät tietävät, että syöte on XML-muotoinen esitys jostain sisällöstä, jonka surffaaja voi sitten näyttää haluamallaan ohjelmalla tai tavalla, jopa räätälöimällään ulkoasulla tai muiden syötteiden joukossa.

Blogeja voi siis vallan helposti lukea vierailematta juuri koskaan itse blogisivustolla. Toki kommenttien jättäminen ja seuraaminen voi olla mukavampaa, kun itse sivu on siinä selaimessa.

Itsekin seuraan blogeja, joita seurannassani on kymmeniä, varmaan jo lähemmäs sataa kuin viittäkymmentä, juuri tähän tapaan. Käytän KDE:n mukana tulevaa ohjelmaa nimeltä Akregator. Myös Thunderbird osaa ilmeisesti näyttää feedit luettavasti. Uusi Firefox 2.0 myös näyttää ne suoraan klikkaamalla. Vanhakin versio osasi näyttää ne "Live Bookmark"-nimellä.

Myös Microsoft on ilmoittanut poikkeuksellisesti omaksuvansa tämän Mozillan kehittämän ikonin käyttöönsä, eikä sooloile omiaan. MS tulee tässäkin asiassa tosin niin jälkijunassa, että sooloilu näyttäisi vain hölmöltä.

Syötteitä on kahta samankaltaista, mutta kuitenkin erilaista XML-formaattia, Atom ja RSS. Käyttäjälle näissä ei ole juuri eroa, mutta sanottakoon, että RSS on vanhempi, ennen blogien yleistymistä kehitetty formaatti, jolle ei kuitenkaan ole varsinaista standardia. Atom kehitettiin sen pohjalta, ja soveltuu tarkoitukseen paremmin, ja on lisäksi virallisempi standardi (RFC 4287). Suosikaamme sitä.

Tätä blogia voi seurata www-sivun lisäksi Atom 1.0 ja RSS 2.0 -formaateissa. Lisäksi myös kommentit on saatavana syötteenä (Atom 1.0). Linkit oikeassa laidassa.

TODO: Selvitä, voiko Atom- ja RSS-syötteisiin kytkeä XSL-tyylit vai menevätkö lukijat rikki tms.