En ny dag og naturligvis enda et patetisk forsøk på nytale fra justisministeren. Pluss en interessant invitt.
[Another .no politics post, I'll be back with international-style geekery soonish]
Les gjerne Knut Storbergets magnum opus Vi styrker personvernet nå, og husk på å lagre det, slik at det bevares for ettertiden.
Når vi pålegger operatører som Telenor, Netcom og andre å lagre trafikkdata, så styrker dette personvernet, sies det.
Trafikkdata handler i praksis om hvem du snakker med. For de av oss som går rundt med mobiltelefon hele tiden, vil trafikkdataene også vise hvor vi har oppholdt oss på et gitt tidspunkt. Vanligvis ikke med samme nøyaktighet som GPS-sporingen i mobiltelefonen, men nøyaktig nok til at posisjonsdata fra telenettet allerede har vært brukt som bevis i straffesaker.
I dag logger og lagrer teleoperatører og internett-tilbydere de dataene som er interessante for faktureringsformål eller som gir saklig grunnlag for teknisk drift, vedlikehold og planlegging. Og i alle sammenhenger jeg er involvert, så kaller vi dette for nettopp overvåking. Datamaskiner er nemlig uhyre godt egnet til å ta unna arbeid som mennesker ville blitt anstrengt av å utføre. Og i sammenhenger som å sørge for at kunder blir fakturert for rett mengde trafikk, se utvikling over tid i for eksempel overført volum, teknisk diagnosearbeid på utstyr (for eksempel for å se hvordan det oppfører seg under stor last) og planlegging av endringer er slik overvåking faktisk både nødvendig og nyttig.
Men når fakturaene er betalt og analysene sluttført, er det ingen saklig grunn til å beholde dataene, og de blir slettet. Summer i regnskap og samleverdier for teknisk tilstand er alt vi trenger. Rådata overlates ikke til uvedkommende.
Men justisministeren liker altså ikke at vi kaller dette for overvåking, og jeg er glad vi får denne invitten til å være behjelpelige med å finne et mer presist uttrykk. Mitt forslag er, i all beskjedenhet:
brev- og besøkskontroll for hele folket
Dette er betydelig mer presist enn det noe ulne "overvåking", og vi oppnår samtidig å ta livet av forestillingen om at "Internett" er noe som eksisterer separat fra samfunnet. Det har nemlig aldri vært slik at datamaskiner og kommunikasjonen mellom datamaskinbrukere var noe som eksisterte utenfor samfunnet eller utenfor lovene vi må forholde oss til. I Norge har en helt dominerende del av befolkningen nettopp Internett som hovedkanal for kontakt med slekt, venner, kolleger og de fleste samfunnsfunksjoner.
Når alle våre trafikkdata blir registert og sammenholdt, blir vi i praksis utsatt for en grad av kontroll som ikke skiller seg vesentlig fra det vi ilegger vareteksfanger -- altså personer som holdes i forvaring på grunn av klar mistanke om straffbare forhold -- som skjerpende tiltak når det er fare for bevisforspillelse under etterforskning.
Jeg vil oppfordre justisministeren og andre debattanter til å ta fatt i dette terminologiskiftet. Først når vi diskuterer datalagringsdirektivet som innføring av elektronisk brev- og besøkskontroll har vi tatt steget over i en edruelig debatt med virkelighetsbasert terminologi.
Så får vi heller komme tilbake til de klart uttrykte ambisjonene om å lagre innholdet i kommunikasjonen senere, om historien faktisk gjentar seg som en tragedie.
Oppdatering 1: Petter Reinholdtsen minte meg på et interessant datapunkt: I Danmark, der EUs datalagringsdirektiv allerede er innbakt i lovverket, blir det lagret gjennomsnittlig mer enn åtti tusen dataelementer per danske per år som følge av datalagringsdirektivet. En opplysende artikkel finnes i norske Digi.no: Lagrer 82 000 DLD-poster per danske i år. Vel verd å lese for interesserte.
Wednesday, December 29, 2010
Thursday, December 23, 2010
Du er en forbryter eller et virus, så Arbeiderpartiet vil overvåke alle, hele tiden
Er du ikke forbryter, kommer du til å bli det. Og vi vet at du kommer til å begå overgrep mot barn, mener Arbeiderpartiet.
[This post is in Norwegian only. I'll be back with the regular more-or-less-ordinary geekery for my international friends later.]
Hovedoppslaget på NRK1 Dagsrevyen 23. desember 2010 dreide seg i følge annonseringen om 'manglende tiltak mot spredning av overgrepsbilder på Internett'.
Metoden de henviser til, er om vi tolker innslaget rett, å bruke samme metoder som man bruker i antivirus-systemer til å identifisere og stoppe overgrepsbilder. Som politisk propaganda for totalovervåking og som reklame for Norman Antivirus fungerte dette reklameinnslaget kanskje bra, men det er verd å påpeke en del åpenbare tekniske og samfunnsmessige svakheter.
Den teknologien som blir omtalt i innslaget, går enkelt sagt ut på å generere en 'signatur' for hvert virus. Dette gjør man typisk ved å utføre en serie beregninger på innholdet og dermed få en slags avansert tverrsum. Denne tverrsummen eller signaturen kan sin tur med stor grad av sikkerhet (men aldri absolutt) kan brukes til å identifisere nye forekomster av de samme dataene. Dersom en ny datamengde eller fil som blir utsatt for beregningene gir samme resultat som en tidligere kjent fil, så er det med overveiende sannynlighet snakk om identiske data, eller samme fil.
Dette er teknikken som antivirusprodukter har brukt i mer enn 20 år, og et typisk antivirusprodukt i dag gjør stadige oppslag mot lister på flere hundre tusen signaturer.
Så langt alt vel, dette er kjent teknologi. Det reportasjen nokså beleilig unnlot å nevne, er at signatur-teknikken fungerer bare når det er tale om identiske data. Virusfirmaer som Norman vet smertelig vel at det trengs bare en triviell endring, for eksempel å endre et enkelt tegn i en del av viruset som ikke har direkte innvirkning på hvordan det kjører, så slipper det nå 'muterte' viruset forbi filtreringen, siden innholdet skiller seg fra det som allerede er kjent.
Resultatet er velkjent: Jo flere påfunn de slemme kommer med og jo flere nye varianter som dukker opp, jo flere signaturer må vi sjekke mot. Et typisk antivirus-sysmem (Clam Antivirus) har til sammen i sine databaser vel 1,25 millioner signaturer.
Om man bruker den samme tilnærmingen på bilder, vil det være tilstrekkelig å justere fargepalett eller gjøre en enkel beskjæring slik at formen på bildeflaten endres, så vil bildet passere. For video vil helt ubetydelige redigeringer som å fjerne eller flytte rundt på noen utvalgte øyeblikk i en sekvens være tilstrekkelig. Og siden den nødvendige manipuleringen av et bilde er betydelig enklere å gjøre enn programmeringsgrepene som må til for å gjøre endringer i et virus, må vi anta at antallet signaturer vil vokse betydelig fortere enn det tilsvarende antallet signaturer for skadelig programvare.
Så lenge dette dreier seg om filer man finner under beslag hos mistenkte, er antakelig dette likevel et håndterlig problem. Filer med ukjent innhold kan man sjekke manuelt.
Noe mer interessant blir det når Inger-Marie Sunde argumenterer for at "politiet og internetttilbyderne med loven i hånden kan filtrere folks datatrafikk". I klartekst betyr dette at Inger-Marie Sunde endelig sier offentlig og i klartekst det vi lenge har ant hun mente, nemlig at totalovervåking av oss alle, med fullstendig innholdsfiltrering av all datatrafikk er både ønskelig og nødvendig. I innslaget brukte hun til overmål formuleringer som at 'staten har plikt til' kontrollere innholdet i internett-trafikk.
Det bør heller ikke være noen stor overraskelse at vår justisminister Storberget avslutningsvis så ut til å omfavne dette påståtte behovet for innholdsfiltrering av all kommunikasjon i befolkningen som argument for sin aktuelle hjertesak: innføring av datalagringsdirektivet.
Så om det noen gang har vært grunn til å tvile på det, er det nå helt klart:
At det også kan oppleves som plagsomt for et parti som regner seg som statsbærende å ikke ha fullt innsyn i hva opposisjonen holder på med, kan vi levende tenke oss. For de av oss som har blitt satt under overvåking kun med bakgrunn i politiske standpunkter2) er det blitt stadig mer interessant å vite om det fortsatt finnes politikere som har et snev av demokratisk sinnelag. Arbeiderpartiet er med dette varig diskvalifisert.
Noter:
1) Tatt fra tekstutgaven av innslaget, http://www.nrk.no/nyheter/norge/1.7438572
2) Første halvår 1985 var jeg som nyvalgt tillitsmann for sivilarbeiderne i mitt fylke litt overrasket over at det som regel tok flere sekunder med spolelyder før summetonen dukket opp når jeg skulle ringe. Og til de som kom med de litt pussige sidekommentarene: vi hørte dere.
[This post is in Norwegian only. I'll be back with the regular more-or-less-ordinary geekery for my international friends later.]
Hovedoppslaget på NRK1 Dagsrevyen 23. desember 2010 dreide seg i følge annonseringen om 'manglende tiltak mot spredning av overgrepsbilder på Internett'.
"Både politiet og internettselskapene kjenner til metoden for å begrense flyten av overgrepsbilder på nett. Men de tar den ikke i bruk."1)
Metoden de henviser til, er om vi tolker innslaget rett, å bruke samme metoder som man bruker i antivirus-systemer til å identifisere og stoppe overgrepsbilder. Som politisk propaganda for totalovervåking og som reklame for Norman Antivirus fungerte dette reklameinnslaget kanskje bra, men det er verd å påpeke en del åpenbare tekniske og samfunnsmessige svakheter.
Den teknologien som blir omtalt i innslaget, går enkelt sagt ut på å generere en 'signatur' for hvert virus. Dette gjør man typisk ved å utføre en serie beregninger på innholdet og dermed få en slags avansert tverrsum. Denne tverrsummen eller signaturen kan sin tur med stor grad av sikkerhet (men aldri absolutt) kan brukes til å identifisere nye forekomster av de samme dataene. Dersom en ny datamengde eller fil som blir utsatt for beregningene gir samme resultat som en tidligere kjent fil, så er det med overveiende sannynlighet snakk om identiske data, eller samme fil.
Dette er teknikken som antivirusprodukter har brukt i mer enn 20 år, og et typisk antivirusprodukt i dag gjør stadige oppslag mot lister på flere hundre tusen signaturer.
Så langt alt vel, dette er kjent teknologi. Det reportasjen nokså beleilig unnlot å nevne, er at signatur-teknikken fungerer bare når det er tale om identiske data. Virusfirmaer som Norman vet smertelig vel at det trengs bare en triviell endring, for eksempel å endre et enkelt tegn i en del av viruset som ikke har direkte innvirkning på hvordan det kjører, så slipper det nå 'muterte' viruset forbi filtreringen, siden innholdet skiller seg fra det som allerede er kjent.
Resultatet er velkjent: Jo flere påfunn de slemme kommer med og jo flere nye varianter som dukker opp, jo flere signaturer må vi sjekke mot. Et typisk antivirus-sysmem (Clam Antivirus) har til sammen i sine databaser vel 1,25 millioner signaturer.
Om man bruker den samme tilnærmingen på bilder, vil det være tilstrekkelig å justere fargepalett eller gjøre en enkel beskjæring slik at formen på bildeflaten endres, så vil bildet passere. For video vil helt ubetydelige redigeringer som å fjerne eller flytte rundt på noen utvalgte øyeblikk i en sekvens være tilstrekkelig. Og siden den nødvendige manipuleringen av et bilde er betydelig enklere å gjøre enn programmeringsgrepene som må til for å gjøre endringer i et virus, må vi anta at antallet signaturer vil vokse betydelig fortere enn det tilsvarende antallet signaturer for skadelig programvare.
Så lenge dette dreier seg om filer man finner under beslag hos mistenkte, er antakelig dette likevel et håndterlig problem. Filer med ukjent innhold kan man sjekke manuelt.
Noe mer interessant blir det når Inger-Marie Sunde argumenterer for at "politiet og internetttilbyderne med loven i hånden kan filtrere folks datatrafikk". I klartekst betyr dette at Inger-Marie Sunde endelig sier offentlig og i klartekst det vi lenge har ant hun mente, nemlig at totalovervåking av oss alle, med fullstendig innholdsfiltrering av all datatrafikk er både ønskelig og nødvendig. I innslaget brukte hun til overmål formuleringer som at 'staten har plikt til' kontrollere innholdet i internett-trafikk.
Det bør heller ikke være noen stor overraskelse at vår justisminister Storberget avslutningsvis så ut til å omfavne dette påståtte behovet for innholdsfiltrering av all kommunikasjon i befolkningen som argument for sin aktuelle hjertesak: innføring av datalagringsdirektivet.
Så om det noen gang har vært grunn til å tvile på det, er det nå helt klart:
Arbeiderpartiet mener du er forbryter eller kommer til å bli det.
Derfor skal du overvåkes, hele tiden.
At det også kan oppleves som plagsomt for et parti som regner seg som statsbærende å ikke ha fullt innsyn i hva opposisjonen holder på med, kan vi levende tenke oss. For de av oss som har blitt satt under overvåking kun med bakgrunn i politiske standpunkter2) er det blitt stadig mer interessant å vite om det fortsatt finnes politikere som har et snev av demokratisk sinnelag. Arbeiderpartiet er med dette varig diskvalifisert.
Noter:
1) Tatt fra tekstutgaven av innslaget, http://www.nrk.no/nyheter/norge/1.7438572
2) Første halvår 1985 var jeg som nyvalgt tillitsmann for sivilarbeiderne i mitt fylke litt overrasket over at det som regel tok flere sekunder med spolelyder før summetonen dukket opp når jeg skulle ringe. Og til de som kom med de litt pussige sidekommentarene: vi hørte dere.
Tuesday, November 9, 2010
The Book of PF, 2nd ed: It's Here!
Yes, it's that time of the year again -- we missed both Halloween and the OpenBSD 4.8 release, but hot on the heels of both, here it is:
The Book of PF, 2nd Edition is here, a box of author's copies turned up here just after lunchtime, and were taken well care of by Nora and Birthe.
This means, of course, that those of you who preordered will be receiving your copies shortly (mod the usual factors eloquently described by Michael Lucas here, the printer in my case is in Louiseville, Quebec), those who have reason to expect copies from my hoard here can rest assured that I'm taking them to the post office right after this. There's an illegible scrawl on some early pages, sorry 'bout that.
Better bookstores online and elsewhere will have it, or you could make it part of a bundle by ordering from the OpenBSD orders page. You will be going there for your six monthly fix anyway, won't you?
Upcoming events: The plans are not fixed yet, but you should expect me to turn up at BSD-themed events over the next few months. Look for announcements here, tweeted, or via the usual mailing lists.
NOTE: This article refers to the now outdated second edition, which has been superseded by The Book of PF, 3rd Edition, which covers changes up to and including OpenBSD 5.6. For the purpose of learning network technology in general and PF in particular, the significantly updated third edition is a better choice than the second edition. Also see the October 25, 2015 post about the arrival of my third edition author copies.
Sunday, October 24, 2010
If It Runs OpenBSD, It Has To Be Important
If we are starting to see targeted attacks on OpenBSD systems, the world has become more interesting.
A lazy Sunday turned a tad more interesting when Dragos Rui, a person usually involved in high-quality security work (or somebody with access to his twitter account) tweeted this:
There have been no further updates as of this writing, and without access to the actual files in question, we can not offer any real meat on the actual payload, so any preliminary conclusions will be uncertain at best. But it is possible to come up with a threat assessment based on general knowledge of what it would take for a boot sector based OpenBSD exploit to make it into the wild.
OpenBSD is used in a wide range of environments (see the OpenBSD at work page for some examples, the list is by no means exhaustive), and since it is commonly perceived to be one of the most secure general-purpose operating systems available, it should be no surprise to find OpenBSD systems in mission critical roles.
So the motive for trying to forge a way in, past a system that is generally considered trustworthy, is obvious. If you hit the right targets, the potential payoff could be huge.
Then it becomes interesting to consider how you would go about to compromise a system running OpenBSD. If we leave aside social engineering such as bribing the sysadmin or stealing the passwords database for the moment, the traditional, and obvious, way to compromise a system is to find an exploitable, unpatched bug and use that to take control of the system.
The OpenBSD source tree is available to the world (in fact, OpenBSD was the first project to make its CVS repository available via anonymous read-only CVS), but writable only by small group of developers. The developers tend to concentrate on the in-development -current, but they do produce a small number of patches to the released version that become available via the patches page. If you want to study the OpenBSD development process more closely, there are a number of good articles and presentationas available via this page, but the important message is that insisting on code correctness and continuous code audits have yielded quite solid results. Exploiting any bugs you would be lucky enough to find in OpenBSD is harder than elsewhere.
But apart from patches to -stable, OpenBSD users usually do not update their systems by recompiling source. Neither do we usually run automatic system upgrades via an upgrade service. For packages, $ sudo pkg_add -u (assuming your PKG_PATH is set to something sensible) provides binary upgrades. For base system upgrades (the only time the boot sector code is likely to be updated), we tend to run the installer in upgrade mode and point it to a set of known good file sets. If the installer finds that a file set does not match the expected SHA256 checksum, it will warn you in no uncertain terms. The same messages will turn up if you, like me, tend to install snapshots on at least some systems as they become available, but sometimes forget to copy the correct bsd.rd into the right place.
The lesson here is that to taint an OpenBSD system, your most likely way in would be to replace a full set of installation files on your likely target's usual mirror, complete with checksums that makes the installer report your modified file sets as genuine. This has two obvious implications: one, you should never install anything on a mission critical system unless you find identical files on several different mirrors, and you should make sure that checksums from one mirror match the files on another. Watching the errata page for the release you are running is a good idea, too, of course.
This gives the proper context to the suspected exploit Dragos reported. The suspect still has some interesting properties. The boot sector code is very small and any changes would be relatively easy to spot once the system is running, but the code there runs early in the boot process and is there mainly to fetch other code that makes sure the system boots. The only useful modification here for an attacker would be to modify the boot loader code to load something that replaces the OpenBSD kernel and performs actions whatever the attacker wants.
The result of modifying the early stage boot code would more than likely be a trashed system unable to boot, but an appropriately skilled attacker who managed to insert code in the right places might be able to pass off a subtly modified system as a genuine one and keep it running for long enough to matter. That's why it will be very interesting to hear whatever real information becomes available about this suspected OpenBSD-targeting attempt.
If we are starting to see attack attempts specifically targeting OpenBSD systems, it could be an indication that at least some criminals have achieved a level of skill, or at least reached a new level of ambition. I have a strong feeling that the OpenBSD developers' efforts have paid off and creating a workable exploit will be very hard, but in the meantime, now is not the time to be slacking, even if all your critical system run OpenBSD. But you have a head start.
If you are curious about the status of the The Book of PF, second edition, preorders have started, and a PDF version is available right away. Physical copies will start shipping as soon as they exist, likely around November 10th. (Update 2015-03-05: For fresh reading material on PF, you're better of with the newer Book of PF, third edition, which became available in late 2014.)
A lazy Sunday turned a tad more interesting when Dragos Rui, a person usually involved in high-quality security work (or somebody with access to his twitter account) tweeted this:
Analysis of recently deleted data on compromised server has turned up an OpenBSD boot sector trojan worm? Volunteer deconstuctors?
There have been no further updates as of this writing, and without access to the actual files in question, we can not offer any real meat on the actual payload, so any preliminary conclusions will be uncertain at best. But it is possible to come up with a threat assessment based on general knowledge of what it would take for a boot sector based OpenBSD exploit to make it into the wild.
OpenBSD is used in a wide range of environments (see the OpenBSD at work page for some examples, the list is by no means exhaustive), and since it is commonly perceived to be one of the most secure general-purpose operating systems available, it should be no surprise to find OpenBSD systems in mission critical roles.
So the motive for trying to forge a way in, past a system that is generally considered trustworthy, is obvious. If you hit the right targets, the potential payoff could be huge.
Then it becomes interesting to consider how you would go about to compromise a system running OpenBSD. If we leave aside social engineering such as bribing the sysadmin or stealing the passwords database for the moment, the traditional, and obvious, way to compromise a system is to find an exploitable, unpatched bug and use that to take control of the system.
The OpenBSD source tree is available to the world (in fact, OpenBSD was the first project to make its CVS repository available via anonymous read-only CVS), but writable only by small group of developers. The developers tend to concentrate on the in-development -current, but they do produce a small number of patches to the released version that become available via the patches page. If you want to study the OpenBSD development process more closely, there are a number of good articles and presentationas available via this page, but the important message is that insisting on code correctness and continuous code audits have yielded quite solid results. Exploiting any bugs you would be lucky enough to find in OpenBSD is harder than elsewhere.
But apart from patches to -stable, OpenBSD users usually do not update their systems by recompiling source. Neither do we usually run automatic system upgrades via an upgrade service. For packages, $ sudo pkg_add -u (assuming your PKG_PATH is set to something sensible) provides binary upgrades. For base system upgrades (the only time the boot sector code is likely to be updated), we tend to run the installer in upgrade mode and point it to a set of known good file sets. If the installer finds that a file set does not match the expected SHA256 checksum, it will warn you in no uncertain terms. The same messages will turn up if you, like me, tend to install snapshots on at least some systems as they become available, but sometimes forget to copy the correct bsd.rd into the right place.
The lesson here is that to taint an OpenBSD system, your most likely way in would be to replace a full set of installation files on your likely target's usual mirror, complete with checksums that makes the installer report your modified file sets as genuine. This has two obvious implications: one, you should never install anything on a mission critical system unless you find identical files on several different mirrors, and you should make sure that checksums from one mirror match the files on another. Watching the errata page for the release you are running is a good idea, too, of course.
This gives the proper context to the suspected exploit Dragos reported. The suspect still has some interesting properties. The boot sector code is very small and any changes would be relatively easy to spot once the system is running, but the code there runs early in the boot process and is there mainly to fetch other code that makes sure the system boots. The only useful modification here for an attacker would be to modify the boot loader code to load something that replaces the OpenBSD kernel and performs actions whatever the attacker wants.
The result of modifying the early stage boot code would more than likely be a trashed system unable to boot, but an appropriately skilled attacker who managed to insert code in the right places might be able to pass off a subtly modified system as a genuine one and keep it running for long enough to matter. That's why it will be very interesting to hear whatever real information becomes available about this suspected OpenBSD-targeting attempt.
If we are starting to see attack attempts specifically targeting OpenBSD systems, it could be an indication that at least some criminals have achieved a level of skill, or at least reached a new level of ambition. I have a strong feeling that the OpenBSD developers' efforts have paid off and creating a workable exploit will be very hard, but in the meantime, now is not the time to be slacking, even if all your critical system run OpenBSD. But you have a head start.
If you are curious about the status of the The Book of PF, second edition, preorders have started, and a PDF version is available right away. Physical copies will start shipping as soon as they exist, likely around November 10th. (Update 2015-03-05: For fresh reading material on PF, you're better of with the newer Book of PF, third edition, which became available in late 2014.)
Sunday, October 10, 2010
EuroBSDCon 2010: The Finest Software Tool Is Alive And Well
From mainframe replacements to firewall appliances, the BSD family of systems is a toolbox flexible enough to baffle insiders and newbies alike. EuroBSDCon 2010 was good fun.
I arrived in Karlsruhe on Thursday night, and ran into Erwin Lansing, Mark Linimon and a few other FreeBSD devsummit attendees at the perfect moment to tag along to dinner at a sort-of-greek place. Forgettable food, but fortunately the dark beer was quite drinkable and the various FreeBSDers made for good company.
Then up relatively early on the Friday. My own path through the conference started with the by now fairly familiar PF tutorial, which as you may be aware, is a close relative of The Book of PF, really soon now out in its second edition. Off the top of my head I'm not sure how many times I've given some version of the PF tutorial, but BSD-DK members will find that this edition of the slides borrows heavily from the somewhat swifter paced introduction they saw in Copenhagen this August.
Among my seven attendees were several who had hoped to be able to catch early copies of The Book of PF, second edition, which I had strongly hinted in the tutorial description would be available by now.
That did not happen, unfortunately, but it's getting very close -- last week entering final-really-final corrections to the index and the laid out book itself took up a good part of my non-office time, and the last word from my contact at No Starch was that the complete and final PDF would land in my inbox for final approval before going to the printers. Amazon.com now lists a likely delivery date of November 15th, which I for one think is a rather realistic guesstimate.
The tutorial went roughly as expected, unfortunately without live demos (demo equipment has a tendency to break badly during air transport or soon afterwards just in time muck up your presentation), and produced just enough good questions that it's likely useful to keep up the effort to maintain the tutorial. Slides are available from roughly where you would expect them.
After the session I ran into Thordur Bjornson (thib@) in the bar-cum-waiting area downstairs at the hotel, waiting for various other OpenBSD developers to arrive. This year's conference had a pleasantly larger than usual number of OpenBSD topics on the program, with some rather interesting talks scheduled for the first day. After a few beers we had reached critical mass with the arrival of among others Theo (deraadt@), Henning Brauer (henning@) and Felix Kronlage (fkr@) we found food and beer at a conveniently local eatery. Then back to the hotel bar for (slightly better) beer and mingling with arriving conference attendees and organizers.
The conference proper started on the Saturday with a "Software tools" themed keynote by Poul-Henning Kamp. PHK is always witty and fun to listen to, and he took us through a number of fresh perspectives on how, even though the world has changed dramatically in several ways and the BSDs still manage to kick ass, we need to keep up the effort to stay relevant.
FreeBSD jails have been a major attraction for quite a while, and I took in the two back to back jails talks by Bjoern A. Zeeb and james Britton. Both talks were fun refreshers on jails, with each presenting a preview of what may turn up in FreeBSD 9 jails code, plus of course tidbits like Bjoern's anectdote about setting up a million jails on the same physical server.
I was intending to attend thib@ and oga@'s OpenBSD on large memory systems talk, but was unfortunately diverted into a meeting that lead to me becoming slightly more involved in future EuroBSDCons. More details on that at a later time, the meeting ran for long enough that the next talk I did catch was reyk@'s iked(8) talk.
If you're on OpenBSD 4.8 or newer, man iked will give you the full story. If you're not that fortunate, it's nice to know that OpenBSD 4.8 gives you a new key exchange daemon for IPsec, up to date with the latest versions of all relevant protocols and able to handle all the nasty little details for IPsec communication with operating systems this column would rather not mention. A good talk about a very useful program, and during the questions part, Theo de Raadt pulled out OpenBSD 4.8 CD sets for attendees who had not already preordered to buy. It's almost a month until the official release date, but the CDs do exist and are likely on their way to early preorderers.
Henning's talk about the state of the OpenBSD networking code was good fun and to the point as always. No shocking new revelations for those who have followed the subject closely like yours truly, but do look out for this talk's slides when it hits the openbsd.org papers section along with the other EuroBSDCon 2010 presentations, hopefully soon.
The social event was conveniently placed in the hotel restaurant and bar area, where something called "Phönix Disco" had set up their equipment, including earth mover size speakers and a mirror ball hanging from the ceiling. Inbetween the dining noises and music, techie talk (at my table, OpenBSD internals, with a helping of ACPI insanities) could be heard. At some point they turned on their laser strobes, which made me queasy enough that I retired to my room soon enough to be in reasonable shape for the early Sunday morning sessions.
The 09:15 sessions on the Sunday offered a choice between Dru Lavigne's BSD Certification talk (highly recommended for your next event if you haven't taken it in already, she not only writes well, she's a brilliant presenter as well), and "Hacking NanoBSD for fun and profit" by Patrick Hausen, who has twisted the NanoBSD setup (originally intended for tiny machines) to serve as a basis for maintaining a hosting environment consisting mainly of regular-sized and capable servers. I'm already quite familiar with the bsdcertification.org efforts (and I recommend getting involved if you aren't already), so I decided to try Patrick's talk which turned out to be very enjoyable and presented some good ideas that could very well be carried over to other BSDs.
One other interesting talk that morning was Hans-Martin Rasch's "From Mainframe to FreeBSD", chronicling the gradual and successful migration by a subscriptions and mass mailings company from their legacy mainframe based system to an all-FreeBSD setup, of course shedding costs in the pretty serious range along the way.
The next time slots had a "Quo vadis ZFS" talk by Martin Matuska, that fortunately contained not the usual "see how great ZFS is" but rather focused on the challenges involved in using ZFS code, technical and legal as things stand today. The FreeBSD project seems to have concluded that the way ZFS is included in their code base does not pose legal problems in itself, but there could be other submarine issues. Apparently the NetApp vs Sun patent suit had ended with one patent invalidated and a settlement whose terms were not disclosed plus the remaining two patents under reexamination. Two unresolved patent issues would be enough to scare me off, but then again the ZFS feature set is perhaps too tempting to not take a few risks for.
Next up were espie@'s back to back talks about the *amazing* work he's been doing with OpenBSD packages. Before lunch, "the long road to pkg_add -u ... and beyond" which took us through the background and the design choices and evolution that took us to the point where upgrading your packages with pkg_add -u can be reliably expected to work. All I can say is that it was an excellent presentation about top-notch work that has made the life of OpenBSD users everywhere a lot better. The after lunch part, "efficient distributed package builds in OpenBSD" took us to the slightly more esoteric part of the world that contains the magic that makes sure the binary packages you expect to have at the other end of your pkg_add command actually exist. Another very enlightening talk, and this set of talks was certainly my favorite at this conference.
For further information on the topics mentioned in this column, the EuroBSDCon web site is the natural place to start. The OpenBSD developers' presentations will appear in the papers section of the OpenBSD web site, while my slides, as usual are available from the NUUG site.
Update 2015-04-02: This article refers to the second edition of The Book of PF. The third edition of that title (linked in the previous sentence) became available, with significant updates, in late 2014 and is overall a better resource for learning about networking and PF on all PF-capable systems.
I arrived in Karlsruhe on Thursday night, and ran into Erwin Lansing, Mark Linimon and a few other FreeBSD devsummit attendees at the perfect moment to tag along to dinner at a sort-of-greek place. Forgettable food, but fortunately the dark beer was quite drinkable and the various FreeBSDers made for good company.
Then up relatively early on the Friday. My own path through the conference started with the by now fairly familiar PF tutorial, which as you may be aware, is a close relative of The Book of PF, really soon now out in its second edition. Off the top of my head I'm not sure how many times I've given some version of the PF tutorial, but BSD-DK members will find that this edition of the slides borrows heavily from the somewhat swifter paced introduction they saw in Copenhagen this August.
Among my seven attendees were several who had hoped to be able to catch early copies of The Book of PF, second edition, which I had strongly hinted in the tutorial description would be available by now.
That did not happen, unfortunately, but it's getting very close -- last week entering final-really-final corrections to the index and the laid out book itself took up a good part of my non-office time, and the last word from my contact at No Starch was that the complete and final PDF would land in my inbox for final approval before going to the printers. Amazon.com now lists a likely delivery date of November 15th, which I for one think is a rather realistic guesstimate.
The tutorial went roughly as expected, unfortunately without live demos (demo equipment has a tendency to break badly during air transport or soon afterwards just in time muck up your presentation), and produced just enough good questions that it's likely useful to keep up the effort to maintain the tutorial. Slides are available from roughly where you would expect them.
After the session I ran into Thordur Bjornson (thib@) in the bar-cum-waiting area downstairs at the hotel, waiting for various other OpenBSD developers to arrive. This year's conference had a pleasantly larger than usual number of OpenBSD topics on the program, with some rather interesting talks scheduled for the first day. After a few beers we had reached critical mass with the arrival of among others Theo (deraadt@), Henning Brauer (henning@) and Felix Kronlage (fkr@) we found food and beer at a conveniently local eatery. Then back to the hotel bar for (slightly better) beer and mingling with arriving conference attendees and organizers.
The conference proper started on the Saturday with a "Software tools" themed keynote by Poul-Henning Kamp. PHK is always witty and fun to listen to, and he took us through a number of fresh perspectives on how, even though the world has changed dramatically in several ways and the BSDs still manage to kick ass, we need to keep up the effort to stay relevant.
FreeBSD jails have been a major attraction for quite a while, and I took in the two back to back jails talks by Bjoern A. Zeeb and james Britton. Both talks were fun refreshers on jails, with each presenting a preview of what may turn up in FreeBSD 9 jails code, plus of course tidbits like Bjoern's anectdote about setting up a million jails on the same physical server.
I was intending to attend thib@ and oga@'s OpenBSD on large memory systems talk, but was unfortunately diverted into a meeting that lead to me becoming slightly more involved in future EuroBSDCons. More details on that at a later time, the meeting ran for long enough that the next talk I did catch was reyk@'s iked(8) talk.
If you're on OpenBSD 4.8 or newer, man iked will give you the full story. If you're not that fortunate, it's nice to know that OpenBSD 4.8 gives you a new key exchange daemon for IPsec, up to date with the latest versions of all relevant protocols and able to handle all the nasty little details for IPsec communication with operating systems this column would rather not mention. A good talk about a very useful program, and during the questions part, Theo de Raadt pulled out OpenBSD 4.8 CD sets for attendees who had not already preordered to buy. It's almost a month until the official release date, but the CDs do exist and are likely on their way to early preorderers.
Henning's talk about the state of the OpenBSD networking code was good fun and to the point as always. No shocking new revelations for those who have followed the subject closely like yours truly, but do look out for this talk's slides when it hits the openbsd.org papers section along with the other EuroBSDCon 2010 presentations, hopefully soon.
The social event was conveniently placed in the hotel restaurant and bar area, where something called "Phönix Disco" had set up their equipment, including earth mover size speakers and a mirror ball hanging from the ceiling. Inbetween the dining noises and music, techie talk (at my table, OpenBSD internals, with a helping of ACPI insanities) could be heard. At some point they turned on their laser strobes, which made me queasy enough that I retired to my room soon enough to be in reasonable shape for the early Sunday morning sessions.
The 09:15 sessions on the Sunday offered a choice between Dru Lavigne's BSD Certification talk (highly recommended for your next event if you haven't taken it in already, she not only writes well, she's a brilliant presenter as well), and "Hacking NanoBSD for fun and profit" by Patrick Hausen, who has twisted the NanoBSD setup (originally intended for tiny machines) to serve as a basis for maintaining a hosting environment consisting mainly of regular-sized and capable servers. I'm already quite familiar with the bsdcertification.org efforts (and I recommend getting involved if you aren't already), so I decided to try Patrick's talk which turned out to be very enjoyable and presented some good ideas that could very well be carried over to other BSDs.
One other interesting talk that morning was Hans-Martin Rasch's "From Mainframe to FreeBSD", chronicling the gradual and successful migration by a subscriptions and mass mailings company from their legacy mainframe based system to an all-FreeBSD setup, of course shedding costs in the pretty serious range along the way.
The next time slots had a "Quo vadis ZFS" talk by Martin Matuska, that fortunately contained not the usual "see how great ZFS is" but rather focused on the challenges involved in using ZFS code, technical and legal as things stand today. The FreeBSD project seems to have concluded that the way ZFS is included in their code base does not pose legal problems in itself, but there could be other submarine issues. Apparently the NetApp vs Sun patent suit had ended with one patent invalidated and a settlement whose terms were not disclosed plus the remaining two patents under reexamination. Two unresolved patent issues would be enough to scare me off, but then again the ZFS feature set is perhaps too tempting to not take a few risks for.
Next up were espie@'s back to back talks about the *amazing* work he's been doing with OpenBSD packages. Before lunch, "the long road to pkg_add -u ... and beyond" which took us through the background and the design choices and evolution that took us to the point where upgrading your packages with pkg_add -u can be reliably expected to work. All I can say is that it was an excellent presentation about top-notch work that has made the life of OpenBSD users everywhere a lot better. The after lunch part, "efficient distributed package builds in OpenBSD" took us to the slightly more esoteric part of the world that contains the magic that makes sure the binary packages you expect to have at the other end of your pkg_add command actually exist. Another very enlightening talk, and this set of talks was certainly my favorite at this conference.
For further information on the topics mentioned in this column, the EuroBSDCon web site is the natural place to start. The OpenBSD developers' presentations will appear in the papers section of the OpenBSD web site, while my slides, as usual are available from the NUUG site.
Update 2015-04-02: This article refers to the second edition of The Book of PF. The third edition of that title (linked in the previous sentence) became available, with significant updates, in late 2014 and is overall a better resource for learning about networking and PF on all PF-capable systems.
Sunday, January 3, 2010
The Goodness of Men and Machinery
If you keep them to their promises, what will corporations and individuals do? Plus, the general goodness of OpenBSD and its installer.
Happy new year, everyone!
As I write this, 2010 is still quite new, and I'm writing this on a new laptop, running, of course, OpenBSD. I've been mostly quite happy with the ThinkPad R60 that has served me since late 2006, but a while back the fan started giving off ugly noises and the organization nominally in charge of doing Lenovo repairs in my area seemed quite uninterested in actually doing repairs on the unit.
So after the usual browsing of web shops I ended up going for a simpler ThinkPad, the SL500 model. From the looks of it, the machine would be a tad faster and support more physical memory than the one I had already, and most likely the newer Intel processor would support running in true 64-bit (amd64) mode.
Click the buttons, whip out the credit card and away we go. Of course, the next day the repair shop turned called in to say that they could in fact get that fan repair done after all. So now I had a once-more-silent and oldish but working machine and a new one on the way.
The new one would come with Microsoft Windows XP preinstalled, Vista Business recovery media and an option to upgrade to Windows 7. I certainly did not want any of those. I make my living in free software consulting, with a bit of promoting and training thrown in and could credibly be denoted part of the competition. Microsoft's End User License Agreement in most of its incarnations (there are several) promises a full refund if you find their licensing terms unacceptable.
So with a minimal delay I fired off an email (sorry, Norwegian only) to what I thought was the right addresses at the retailer, saying essentially that I would want to arrange for the return of the software, in accordance with Microsoft's standard contract terms.
After all, we had heard of successes such as MacSlow in Germany and Poul-Henning Kamp's (of FreeBSD fame) slow but steady progress, also involving Lenovo hardware.
I expected that the response would be either that they have a process set up to make a symbolic refund, or they would refuse, saying that the software and the hardware are inseparable parts of the product, no matter what the clickwrap screen says.
Their actual response was mostly the latter, but with the twist that 'we do not get refunds for this from the manufacturer'. Distinctly odd, if you ask me, but I suppose we will find out more once people with actual decision making power are back after the holidays.
So no other alternative than start establishing the facts of the matter, that is, wait for the package to turn up and see what the clickwrap screen actually says.
Windows Refund Norway: The Fact Finding Mission
The package arrived this Saturday, and after the outer wrapping came off, sure enough there was a warning on the outside of the box:
That was pretty much as expected, so I continued unpacking.
Plugging in and turning on gave me this screen:
That eventually segued into
('please wait while Windows is preparing for startup') and proceeded through a few more largely information-free screenfuls up to the the point where you choose your location.
That choice likely serves several purposes. It's useful for choosing user interface languages as well as the legal terms for using the software or not, so I proceeded.
Finally, the Microsoft End User Agreement, Norwegian version, started to appear, in a miniature text box that needed several scrolling motions to reveal much of anything:
It would take only a minimal dose of negativity to suspect that these screens were in fact designed to make the user just click agreement without ever reading the full text. But taken together, these screenfuls gave me all the information I needed.
Microsoft promises a refund if you find their license terms unacceptable, but farms out the responsibility for the refund to the manufacturer, not the retailer.
So I had been barking up the wrong tree after all. Fortunately, in the meantime my friends at NUUG offered some good advice on how to proceed, and I will likely be offering updates on "Windows Refund, Norwegian version" as the tale progresses.
The promise of a refund has clearly been made. I suspect that with a sufficiently staffed legal team, playing a symbolic blame game over who should honor that promise is enough of a deterrent to the average end user, if they do not just go away after the initial rejection.
The fact-finding mission complete, it was time to try installing OpenBSD. If you are not at all interested in OpenBSD, you can scroll to the end of the article for more on the Windows refund and legalities part.
The Further Adventures of the OpenBSD Installer
The OpenBSD installer has a somewhat ugly reputation, as witnessed by this recent article over at TechRepublic. In all fairness, some years back one of the developers was quoted as saying about the installer, "it was never released, it just kind of escaped".
But things have change since then, to the point that I was wondering just which version of OpenBSD Mr. Wallen had tried to get running on his hardware, nevermind that he seems totally unaware of the automatization features you can exploit by simply adding hostnameVv.tgz or siteVv.tgz (Vv being Major.minor version numbers) file sets to your install media.
The following sequence shows you what it really looks like, with my most sincere apologies for my near-total lack of photography skills.
Booting from the CD image from the latest amd64 snapshot, my first screenful was
This proceeds through what we 'greybacks' recognize as kernel messages that scroll of the screen rather rapidly (dmesg output of the installed system is available here), ending with a menu of possible actions:
Choosing (I)nstall produces an encouraging message and a prompt to choose your preferred keyboard layout:
Next up, you get to choose a hostname
followed by a prompt which network interfaces you want to configure.
This is where I hit my first and only snag. I had tried to do the install with only wireless networking available, and for reasons known only to Intel, they have not allowed the OpenBSD project redistribution rights to the firmware files that turn the Intel WiFi Link 5100 circuitry into a working wireless networking component.
Here's what it looks like when a manufacturer chooses not to play nice with free software:
Fortunately, the OpenBSD man page for the iwn driver shows you just how to fetch and install the firware via the OpenBSD package tools. Other manufacturers have granted the OpenBSD project redistribution rights to similar firmware files needed by their products, with the result that you can perform a network install of OpenBSD directly from a typical bsd.rd over a Ralink wireless network card (using the ral driver), but not over most of the wireless network cards from Intel and some other manufacturers.
I was in fact prepared that this exact thing would happen, and it was time to move up to the attic where the wired Ethernets live. (Our house is an 18th century wooden building, and my sweetheart wanted no more holes drilled, certainly not to accommodate Ethernet cabling for her and others to trip over).
Restarting the install with a wired Ethernet got me through the entire sequence so far inside one screenful.
Once I told the installer I was done with network configuration, it naturally used all the configuration information my DHCP server had supplied:
You can go in with manual network configuration if you want, but in my case that was not needed.
Next up, your root account will need a password, you choose to run or not run some basic services such as sshd and ntpd, and you can choose to add a regular user too.
Notice the second part of the dialogue here, where the installer notices that I added a regular user and offers to disable root logins over ssh, adding the regular user to the wheel group so it's easier to add the regular user to sudoers.
The installer does not edit sudoers for you, but it's the little things like these that warms the hearts of greybacks like me.
And naturally, the installer correctly guesses my time zone but offers me a prompt to change it if the guess was not the correct one.
Network setup done, the installer presents the choice of disks available and asks you to specify which device will contain the root file system. In this case my new laptop had only one usable disk, so I proceeded directly to the dreaded partitioning part.
The first part here shows the disk partitioning before the OpenBSD installer touched it, with an option to either use the whole disk or edit the Master Boot Record (MBR). I did not plan to run several operating systems on this machine, at least not natively, so I opted for using the whole disk for OpenBSD instead.
That lead to the second part, where the installer suggests a disk partitioning scheme based on typical use, with the utterly sane choice of leaving the largest part (the k partition in this case) for user files as the /home partition.
You can edit the setup or choose your own entirely, the main point here is that the defaults are sane and unless you know a good reason to choose differently, the default choice is the safe and comfortable choice.
The installer goes on to create and mount file systems,
and the informed reader will recognize that the default mount options make a lot of sense, too.
With file systems mounted, the actual installation can proceed once you have indicated where you want to fetch the file sets from. Here I chose the http install method, and the installer made a reasonable guess at what was my closest mirror. I chose ftp.eu.openbsd.org (based in Sweden) instead, and chose not to exclude any file sets.
The next part is when you can go fetch your cup of coffee, get some other refreshment or simply a breath of fresh air. Even on a very good link, the transfers will take a few minutes.
When you get back, the installer prompts for further install sets, and if you do not have any to offer, it will finish up the install, choose the right kernel for your hardware and offer some advice for how to proceed from here on.
That is, enter reboot, let the system boot, log in as your new user or root if you did not create a user as prompted, read the (almost) personalized message from Theo de Raadt, and go on using the system as you please. Actually, you can skip reading the message if you like, but the time is likely well spent with the tips (or reminders if you like) it contains.
Here is a photograph of the disk utilization of my newly installed OpenBSD laptop a few moments after I had started transferring my files over. Notice the /home file system is not quite empty, since I almost forgot to try to document the pristine state of the system, but I am reasonably sure this picture was taken before I added any packages.
So please, Mr. Lenovo, may I have that Windows money refunded?
As the numbers add up, there is no space for your precious proprietary software on my system, and I would gladly offer to send those restore CDs and the license label back.
It was indeed Microsoft that made that promise on your behalf, but then you must have been aware of these legal issues.
I am not about to abuse your trust or your software. However I do like the hardware that I have bought, am sure we will come to a reasonable agreement.
Now back to the tech. After installing a few packages, my desktop looks roughly like this,
and disk utilization is
peter@deeperthought:~$ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/sd0a 1005M 49.8M 905M 5% /
/dev/sd0k 263G 44.5G 205G 18% /home
/dev/sd0d 3.9G 40.0K 3.7G 0% /tmp
/dev/sd0f 2.0G 1.3G 542M 72% /usr
/dev/sd0g 1005M 178M 776M 19% /usr/X11R6
/dev/sd0h 5.9G 2.1G 3.5G 38% /usr/local
/dev/sd0j 2.0G 2.0K 1.9G 0% /usr/obj
/dev/sd0i 2.0G 732M 1.2G 38% /usr/src
/dev/sd0e 9.8G 51.5M 9.2G 1% /var
Yes, there's probably a lot of old data there I don'really need. But then, the time it takes to identify and remove old cruft is hard to come by.
Good night and good luck.
Raw size versions of the illustrations are available here, other updates after the footer.
If you found this article useful, enjoyable or irritating, please drop me a line. Material related to this article is available free via links from my web space. Some additional material will be made available for reasonable research purposes. If you want more extensive assistance, please contact me (via email or other means) to make arrangements.
Other updates: The password guessing Hail Mary Cloud is still with us, and I occasionally update the data referenced in that article. As to the antics of the various spammers, they haven't changed much either. They're still fun to watch from time to time, though.
As should be fairly obvious from the above, this article was produced using only free software: OpenBSD and various software available through the OpenBSD packages system.
Happy new year, everyone!
As I write this, 2010 is still quite new, and I'm writing this on a new laptop, running, of course, OpenBSD. I've been mostly quite happy with the ThinkPad R60 that has served me since late 2006, but a while back the fan started giving off ugly noises and the organization nominally in charge of doing Lenovo repairs in my area seemed quite uninterested in actually doing repairs on the unit.
So after the usual browsing of web shops I ended up going for a simpler ThinkPad, the SL500 model. From the looks of it, the machine would be a tad faster and support more physical memory than the one I had already, and most likely the newer Intel processor would support running in true 64-bit (amd64) mode.
Click the buttons, whip out the credit card and away we go. Of course, the next day the repair shop turned called in to say that they could in fact get that fan repair done after all. So now I had a once-more-silent and oldish but working machine and a new one on the way.
The new one would come with Microsoft Windows XP preinstalled, Vista Business recovery media and an option to upgrade to Windows 7. I certainly did not want any of those. I make my living in free software consulting, with a bit of promoting and training thrown in and could credibly be denoted part of the competition. Microsoft's End User License Agreement in most of its incarnations (there are several) promises a full refund if you find their licensing terms unacceptable.
So with a minimal delay I fired off an email (sorry, Norwegian only) to what I thought was the right addresses at the retailer, saying essentially that I would want to arrange for the return of the software, in accordance with Microsoft's standard contract terms.
After all, we had heard of successes such as MacSlow in Germany and Poul-Henning Kamp's (of FreeBSD fame) slow but steady progress, also involving Lenovo hardware.
I expected that the response would be either that they have a process set up to make a symbolic refund, or they would refuse, saying that the software and the hardware are inseparable parts of the product, no matter what the clickwrap screen says.
Their actual response was mostly the latter, but with the twist that 'we do not get refunds for this from the manufacturer'. Distinctly odd, if you ask me, but I suppose we will find out more once people with actual decision making power are back after the holidays.
So no other alternative than start establishing the facts of the matter, that is, wait for the package to turn up and see what the clickwrap screen actually says.
Windows Refund Norway: The Fact Finding Mission
The package arrived this Saturday, and after the outer wrapping came off, sure enough there was a warning on the outside of the box:
That was pretty much as expected, so I continued unpacking.
Plugging in and turning on gave me this screen:
That eventually segued into
('please wait while Windows is preparing for startup') and proceeded through a few more largely information-free screenfuls up to the the point where you choose your location.
That choice likely serves several purposes. It's useful for choosing user interface languages as well as the legal terms for using the software or not, so I proceeded.
Finally, the Microsoft End User Agreement, Norwegian version, started to appear, in a miniature text box that needed several scrolling motions to reveal much of anything:
It would take only a minimal dose of negativity to suspect that these screens were in fact designed to make the user just click agreement without ever reading the full text. But taken together, these screenfuls gave me all the information I needed.
Microsoft promises a refund if you find their license terms unacceptable, but farms out the responsibility for the refund to the manufacturer, not the retailer.
So I had been barking up the wrong tree after all. Fortunately, in the meantime my friends at NUUG offered some good advice on how to proceed, and I will likely be offering updates on "Windows Refund, Norwegian version" as the tale progresses.
The promise of a refund has clearly been made. I suspect that with a sufficiently staffed legal team, playing a symbolic blame game over who should honor that promise is enough of a deterrent to the average end user, if they do not just go away after the initial rejection.
The fact-finding mission complete, it was time to try installing OpenBSD. If you are not at all interested in OpenBSD, you can scroll to the end of the article for more on the Windows refund and legalities part.
The Further Adventures of the OpenBSD Installer
The OpenBSD installer has a somewhat ugly reputation, as witnessed by this recent article over at TechRepublic. In all fairness, some years back one of the developers was quoted as saying about the installer, "it was never released, it just kind of escaped".
But things have change since then, to the point that I was wondering just which version of OpenBSD Mr. Wallen had tried to get running on his hardware, nevermind that he seems totally unaware of the automatization features you can exploit by simply adding hostnameVv.tgz or siteVv.tgz (Vv being Major.minor version numbers) file sets to your install media.
The following sequence shows you what it really looks like, with my most sincere apologies for my near-total lack of photography skills.
Booting from the CD image from the latest amd64 snapshot, my first screenful was
This proceeds through what we 'greybacks' recognize as kernel messages that scroll of the screen rather rapidly (dmesg output of the installed system is available here), ending with a menu of possible actions:
Choosing (I)nstall produces an encouraging message and a prompt to choose your preferred keyboard layout:
Next up, you get to choose a hostname
followed by a prompt which network interfaces you want to configure.
This is where I hit my first and only snag. I had tried to do the install with only wireless networking available, and for reasons known only to Intel, they have not allowed the OpenBSD project redistribution rights to the firmware files that turn the Intel WiFi Link 5100 circuitry into a working wireless networking component.
Here's what it looks like when a manufacturer chooses not to play nice with free software:
Fortunately, the OpenBSD man page for the iwn driver shows you just how to fetch and install the firware via the OpenBSD package tools. Other manufacturers have granted the OpenBSD project redistribution rights to similar firmware files needed by their products, with the result that you can perform a network install of OpenBSD directly from a typical bsd.rd over a Ralink wireless network card (using the ral driver), but not over most of the wireless network cards from Intel and some other manufacturers.
I was in fact prepared that this exact thing would happen, and it was time to move up to the attic where the wired Ethernets live. (Our house is an 18th century wooden building, and my sweetheart wanted no more holes drilled, certainly not to accommodate Ethernet cabling for her and others to trip over).
Restarting the install with a wired Ethernet got me through the entire sequence so far inside one screenful.
Once I told the installer I was done with network configuration, it naturally used all the configuration information my DHCP server had supplied:
You can go in with manual network configuration if you want, but in my case that was not needed.Next up, your root account will need a password, you choose to run or not run some basic services such as sshd and ntpd, and you can choose to add a regular user too.
Notice the second part of the dialogue here, where the installer notices that I added a regular user and offers to disable root logins over ssh, adding the regular user to the wheel group so it's easier to add the regular user to sudoers.
The installer does not edit sudoers for you, but it's the little things like these that warms the hearts of greybacks like me.
And naturally, the installer correctly guesses my time zone but offers me a prompt to change it if the guess was not the correct one.
Network setup done, the installer presents the choice of disks available and asks you to specify which device will contain the root file system. In this case my new laptop had only one usable disk, so I proceeded directly to the dreaded partitioning part.
The first part here shows the disk partitioning before the OpenBSD installer touched it, with an option to either use the whole disk or edit the Master Boot Record (MBR). I did not plan to run several operating systems on this machine, at least not natively, so I opted for using the whole disk for OpenBSD instead.
That lead to the second part, where the installer suggests a disk partitioning scheme based on typical use, with the utterly sane choice of leaving the largest part (the k partition in this case) for user files as the /home partition.
You can edit the setup or choose your own entirely, the main point here is that the defaults are sane and unless you know a good reason to choose differently, the default choice is the safe and comfortable choice.
The installer goes on to create and mount file systems,
and the informed reader will recognize that the default mount options make a lot of sense, too.
With file systems mounted, the actual installation can proceed once you have indicated where you want to fetch the file sets from. Here I chose the http install method, and the installer made a reasonable guess at what was my closest mirror. I chose ftp.eu.openbsd.org (based in Sweden) instead, and chose not to exclude any file sets.
The next part is when you can go fetch your cup of coffee, get some other refreshment or simply a breath of fresh air. Even on a very good link, the transfers will take a few minutes.
When you get back, the installer prompts for further install sets, and if you do not have any to offer, it will finish up the install, choose the right kernel for your hardware and offer some advice for how to proceed from here on.
That is, enter reboot, let the system boot, log in as your new user or root if you did not create a user as prompted, read the (almost) personalized message from Theo de Raadt, and go on using the system as you please. Actually, you can skip reading the message if you like, but the time is likely well spent with the tips (or reminders if you like) it contains.
Here is a photograph of the disk utilization of my newly installed OpenBSD laptop a few moments after I had started transferring my files over. Notice the /home file system is not quite empty, since I almost forgot to try to document the pristine state of the system, but I am reasonably sure this picture was taken before I added any packages.
So please, Mr. Lenovo, may I have that Windows money refunded?
As the numbers add up, there is no space for your precious proprietary software on my system, and I would gladly offer to send those restore CDs and the license label back.
It was indeed Microsoft that made that promise on your behalf, but then you must have been aware of these legal issues.
I am not about to abuse your trust or your software. However I do like the hardware that I have bought, am sure we will come to a reasonable agreement.
It's all about honesty in your business life.
Now back to the tech. After installing a few packages, my desktop looks roughly like this,
and disk utilization is
peter@deeperthought:~$ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/sd0a 1005M 49.8M 905M 5% /
/dev/sd0k 263G 44.5G 205G 18% /home
/dev/sd0d 3.9G 40.0K 3.7G 0% /tmp
/dev/sd0f 2.0G 1.3G 542M 72% /usr
/dev/sd0g 1005M 178M 776M 19% /usr/X11R6
/dev/sd0h 5.9G 2.1G 3.5G 38% /usr/local
/dev/sd0j 2.0G 2.0K 1.9G 0% /usr/obj
/dev/sd0i 2.0G 732M 1.2G 38% /usr/src
/dev/sd0e 9.8G 51.5M 9.2G 1% /var
Yes, there's probably a lot of old data there I don'really need. But then, the time it takes to identify and remove old cruft is hard to come by.
Good night and good luck.
Raw size versions of the illustrations are available here, other updates after the footer.
If you found this article useful, enjoyable or irritating, please drop me a line. Material related to this article is available free via links from my web space. Some additional material will be made available for reasonable research purposes. If you want more extensive assistance, please contact me (via email or other means) to make arrangements.
Other updates: The password guessing Hail Mary Cloud is still with us, and I occasionally update the data referenced in that article. As to the antics of the various spammers, they haven't changed much either. They're still fun to watch from time to time, though.
As should be fairly obvious from the above, this article was produced using only free software: OpenBSD and various software available through the OpenBSD packages system.
Subscribe to:
Posts (Atom)
Posts
