Öregecske laptopom nem cserélném fiatalabbra, úgyhogy arra jutottam, hogy gondjait másként próbálom orvosolni. Egy ütött-kopott ThinkPad X200-as szegényke, 4GB memóriával, 120GBos kis SSD-vel, puttonyos utángyártott akkupakkal.

Windows 10-el használom egy ideje, mérsékelt elégedettséggel:

• nincsenek hivatalos driverek, az ujjlenyomatolvasó DELL driverrel működik.
• az Intel 5300-as sorozatú WiFi kártya drivere szintén trükközéssel került fel. Sleep után nem mindig tud csatlakozni az AP-khez, bár a scan működik. Ekkor le kell tiltani a device managerben, ismét engedélyezni, és már működik is! AZ RF-Kill kapcsolóval letiltás, engedélyezés nem segít ezen.
• a Spectre javítások óta érezhetően lassú lett.
• a TrackPoint mozgásának dinamikája más, mint amit Linux, NetBSD alatt tapasztaltam korábban, és valahogy kényelmetlen. Középső gombos görgetés is kényelmetlenebb, nem működik UWP alapú “modern windows” alkalmazásokban. A Synaptics driver minősége egyszerűen rosszabb, mint amit *NIX-on tapasztaltam.

Melegedés

A gép mostanában ráadásul nagyon hamar felmelegedett, és elkezdett leszabályozni… Ki kellett hát tisztítani!

A szerelés végére egy csavar elveszett, de a következő hétvégi porszívózáskor meglett, és a helyére is került!

Lehúztam a rolót a Windowsnak

A Windows élmény már nem az, amire szükségem van. Most munkahelyen is Windows környezetben fejlesztek, és azzal együtt kezd ez már sok lenni. Power Userként nagyon sok minden fáj, hiába a mostanában felgyorsult fejlődés a Windows 10-ben. Death by a thousand papercuts.

Vegyük például a terminál környékét: sok az újdonság, de ezzel együtt is még mindig több év múlva reális, hogy a 25 évvel ezelőtti XTerm funkcionalitását elérje a konzol… A PowerShell egy pedig külön pokol. Azok közül a dolgok való, amit nem azért gyűlölök, mert rossz (sajnos az), hanem mert akár lehetett volna jó, is, és az elszalasztott lehetőség miatt sokkal jobban fáj minden hibája. A .Net Core/C#/F# környékén is ezt érzem, minden bejelentés az előrelépésről valami visszalépést is tartalmaz, hiába a még több (sokszor felesleges, marginális) feature.

Eljött hát a Windows letakarításának az ideje is!

No de mi legyen a Windows helyett? Korábban használtam már NetBSD-vel ThinkPad-et, és egészen tűrhető élmény volt, előtte Gentooval pedig unalmasan tökéletes volt (nem 😀). Egy kellően alusisakos ismerős javasolta az OpenBSD kipróbálását, ráadásul több egybehangzó vélemény szerint ThinkPaden kulcsrakész élményt ad, úgyhogy neki is vágtam!

Csupán ki kell dd-zni egy filet egy pendrivera… ami Windows alatt beépített eszközökkel nem annyira megvalósítható. Máris ott vagyunk a fájó apró dolgoknál. Egy gyors közvélemény-kutatás után telepítettem a Balena Etcher-t a telepítő kiírására.

Alusisakot fel!

Nekiálltam hát az OpenBSD épp aktuális 6.4-es verziójának telepítésének. Mi kell ehhez?

• ThinkPad X200
• Ethernet kábel
• Pendrive
• internet
• alufólia
• host név

Letöltöttem az OpenBSD 6.4 telepítőjét, kiírtam és bebootoltam róla.

A telepítő elég intuitív, a NetBSD élményre hasonlón fapados, érthető volt. A dokumentáció hasonlóan jó minőségű és részletes volt. A gépnek stílszerűen a tinfoil nevet választottam, a partícionálást alapértelmezetten hagytam. A seteket a netről húztam le, ssh-t, X-et kértem, majd újraindítottam.

Első bootnál letöltötte a WiFi kártya firmwarejét, ami jogi okokból nem kerülhetett bele a telepítőkészletbe, majd a telepítésnél bekapcsolt xenodm (1) login manager üdvözölt. Azon belépve egy gyönyörű TWM ablakkezelővel találkoztam, és nekikezdhettem a gép testreszabásának.

sudo helyett

Első lépés a sudo, pontosabban nyílt helyettesítőjének, a doas (1)-nek beállítása. Én a /etc/doas.conf-ba a következőt írtam:

permit setenv { -ENV PS1=$DOAS_PS1 SSH_AUTH_SOCK } :wheel
permit persist keepenv kodfodrasz
permit nopass kodfodrasz cmd shutdown
permit nopass keepenv root as root

és persze hozzáadtam magam a wheel csoporthoz is:

usermod -G wheel kodfodrasz

Logout, login után már működött is!

Hálózati beállítások

Windows alatt a rendszer kezeli a hálózati eszközök közötti váltást: ha például ethernetet dugunk be, a wifi helyett azon fog zajlani a forgalom. Linux alatt a NetworkManager kezeli ezt. Mik a lehetőségek OpenBSD alatt? Úgy tudom, hogy az OpenBSD egyik erőssége a hálózat, lássuk a szerverek világán kívül mennyire igaz ez?

A dokumentáció erre a helyzetre egy konkrét megoldást javasol, melyet én is alkalmaztam:

A gépben az ethernet vezérlőt az em (4), a wifit az iwn (4) driver hajtja. Elérhető még a trunk (4) virutális hálózati eszköz driver, mely link aggregációt tesz lehetővé különféle stratégiák, valamint a CARP protokol segítségével. A failover stratégia segítségével összefogható több különböző prioritású link egy virtuális eszközzé. IP címet a virtuális eszközre kérünk, nem az egyes interfészekre (ez a fő különbség a Windows és Linux/Network Manager megoldásokhoz képest).

A vezérlők beállítása az egyes interfészekhez tartozó hostname.if (5) fileok segítségével történik.

A wifi vezérlőt a /etc/hostname.iwn0 fileban állíthattam be a kedvenc access pointjaim auto-joinra!

join kedvenc_ap wpakey titkos_kulcs
join masik_ap wpakey ez_is_titkos_kulcs
up powersave

Az ethernet interfészt egyszerűen csak engedélyezni kell (/etc/hostname.em0):

up

A varázslat pedig az aggregáció beállításaiba, az /etc/hostname.trunk0-ba kerül:

trunkproto failover trunkport em0
trunkport iwn0
dhcp

Ez az aggregált linkhez fő prioritással az em0 eszközt állítja be, amiről failover van iwn0-ra, ha az em0-n nincs link. Amennyiben talált linket a trönkölt eszköz, akkor DHCP segítségével kap IP címet.

Újraindítás, vagy a következő parancsok futtatása után a beállítások érvényre jutnak:

doas pkill dhclient
doas ifconfig em0 down
doas ifconfig iwn0 down
doas ifconfig trunk0 destroy
doas sh /etc/netstart

Működik a hálózat, ahogy elvárható!

Harmadik féltől származó programok telepítése

Az OpenBSD a harmadik féltől származó programokat a Ports nevű alprojekjén keresztül teszi elérhetővé. Ez a NetBSD pkgsrc-hez hasonlóan egy make alapú receptekből álló build és csomagoló rendszer.

A Ports azonban NetBSD pkgsrc-vel ellentétben nem próbál sem OS platformok, sem OS verziók közt hordozható lenni. Így, mivel egy Ports kiadás egy OpenBSD kiadáshoz kapcsolódik a portok karbantartása, támogatása, és egyáltalán a Makefile-ok sokkal tisztábbak, csak a hardware platformok közötti, illetve az OpenBSD-n működésre bíráshoz szükséges patchek és komplexitás található meg bennük.

Egy OpenBSD verzió kiadásához tartozik a Ports egy kiadása, amihez publikálják a lefordított csomagokat bináris formában is. A csomagoknak a pkgsrc-ben megszokott módon lehetnek különböző build beállítású változatai (flavours). Ezekből és kombinációikból is készül bináris, emiatt a Portsban én kevés csomagnál kevés flavourt láttam.

A csomagok telepítéshez semmit nem kell beállítani, a rendszer telepítésekor használt alapértelmezett CDN-el minden további konfiguráció nélkül egyből működik. A telepítés a pkg_add (1) paranccsal történik.

A legtöbb nekem szükséges dologról találtam csomagot, de néhány dolgot hiányoltam:

• nincs mksh, amit sokat használtam és megszerettem, többek közt a gyorsasága és ksh létére egész jó Unicode támogatása miatt.
  Ennek az oka az, hogy készítője összeveszett az OpenBSD projekttel, amit emiatt forkolt. Többször próbálta a ports-ba beküldeni, de ahogy én tudom egyik fél sem volt elég nyitott a békülésre, hogy ez végül sikerrel járhasson. Szomorú.
  Lefordítottam magamnak. Csinálok majd saját portot belőle bemelegítésnek, és esetleg megpróbálom beküldeni.
• nincs Telegram desktop kliens. A Pidgin/Purple alapút inkább elkerülöm, mivel egyszer belenéztem a kódjába, és elszörnyedtem, mennyire nem biztonságos: az első közel random megnyitott fileban potenciális buffer overflowt találtam…
  Megpróbálom majd portolni, bár amit a kliens dokumentációjában láttam az elborzasztott, nem biztos, hogy lesz elég türelmem hozzá, hogy záros határidőn belül megcsináljam.
• nincs friss gcc.
  Ennek oka az alaprendszerből a gcc friss verzióinak GPL-3 licenc inkompatibilitás miatti száműzése. Az alaprendszer emiatt régi gcc-t szállít, vagy clang fordítót. Valamiért sokáig a Portsban is elmaradozott a gcc verziók frissítése. A 6.5-ös OpenBSD/Ports kiadás azonban ismét friss, 8-as gcc-t is szállít. Enélkül a Telegram portolás eleve reménytelen.
• nincs VisualStudio Code, se semmi egyéb electron alapú manapság natív alkalmazásnak vagy desktop alkalmazásnak nevezett szörny. A VS Code azért kissé hiányzik, a VIM-nál produktívabb.
  Gyorsan beállítottam a vim-et, hogy ne a 70-es évek agyhalott defaultjaival működjön (pl. backspace csak sor elejéig töröl, balra nyíl nem lép előző sorba vissza, stb.). Hiába ismerem alapszinten, sosem szerettem meg a vim-et igazán. Most elkezdtem az emacs-et tanulni.

Frissítések

Az alaprendszer biztonsági frissítéseit a syspatch (8) paranccsal tudjuk feltenni.

Kapacitás hiány miatt a bináris portokhoz nincs frissítés a kiadás élete során, azt egy harmadik féltól, az M:Tier-től szerezhetjük be. A mindenkori stable verzióhoz ez ingyenes. A kiadások fél éves ütemezését tekintve nem tragikus ez a helyzet, de nagyobb projekteknél azért ez gördülékenyebb, valamint a biztonság fókuszáltságot kissé árnyalja.

Én ezt egyelőre nem állítottam be a kísérleteimhez. Alternatívaként magunknak fordíthatjuk a portokat, ami azonban a legtöbb esetben nem javasolt.

Filerendszerek finomhangolása

Az OpenBSD nem túl innovatív filerendszerek terén. Gyakorlatilag semmi modern filerendszert nem támogat, az FFS az innováció csúcsa. Nem ezért fogjuk szeretni. Ráadásul nekem valahogy sikerült egy pkg_add-ba belefagyással össze is korruptálnom az alapbeállítású FFS-t elsőre. Teszter kéz 👌! Ezután egy kis pkg_check (8) küzdelem után inkább tiszta telepítéssel kezdtem inkább neki.

Az /etc/fstab-ban minden ffs bejegyzéshez hozzáadtam a softdep,noatime opciókat, hogy legalább gyors(abb) legyen.

Azóta amúgy semmi gikszért nem tapasztaltam, pedig egy keveset buildelgettem is, telepítgettem is. A kipróbáláshoz egy 10+ éves 160 GB-os hdd-t raktam a gépbe, akár azzal is lehetett valami. Ubuntu livecd-ről futtatott destruktív badblocks semmi hibát nem talált, de lehet hogy reallokált közben, a SMART bújásához már nem volt kedvem, inkább egyből újratelepítettem a majd egy napnyi tesztelés után.

Energia gazdálkodás

Nagyjából minden ment egyből, csak be kellet kapcsolni! Az apmd (8) szolgáltatást automatikus órajel szabályozásra, valamint 10% akkumulátor töltöttségnél hibernálásra állítottam be (a gép kb. 7% töltöttségig merülve kikapcsol).

rcctl enable apmd
rcctl set apmd flags -A -Z 10
rcctl start apmd

Hang

Korábban NetBSD alatt (5.0 és korábbi verziók) problémám volt, hogy nem lehetett egyidejűleg több hangforrásnak használnia a hangeszközt. Választhattam, hogy cmus, vagy valami más adja-e a hangot… Azóta ez ott megoldott dolog, viszont tartottam tőle, hogy OpenBSD alatt ezen a téren lemaradást fogok tapasztalni. Nagyot tévedtem!

Ez az OpenBSD alatt valójában már elég rég megoldott: a 2012-es kiadású OpenBSD 5.1 verzióban lett az alaprendszer része az sndiod (8) szolgáltatás. Ahogy azt a dokumentáció idevágó része le is írja, az sndiod (8) segítségével megoldott az egyidejűleg több forrásból érkező hangfolyamok szoftveres hangkeverése, szükség szerinti resamplingje, vagy akár hálózaton keresztüli távoli hanglejátszás is. A hangerőt mind a kevert master folyamon a mixerctl (1) parancs segítségével lehet szabályozni. Programonkénti hangerő szabályozásra én telepítettem a cmixer nevű portot, amivel ez kényelmesen elvégezhető.

Nagyjából mint a PulseAudio, de reményeim szerint Lennart Poettering közreműködésének hiányában minimalistábban, függőség spagetti mentesen.

A hangfelvétel alapesetben tiltva van magánszféra védelmére irányuló megfontolásokból.

Hotplug

Windows vagy modern Linux alatt megszokhattuk, hogy a csatlakoztatott adathordozók egyből a filerendszerbe fűzésre is kerülnek. (Olvastam ám régi magyar nyelvű UNIX könyveket is!) Hogyan lehet ezt OpenBSD alatt elérni?

Ezt elősegítendő létezik a hotplugd (8) a rendszerben!

Célszerű telepíteni hozzá a hotplug-diskmount csomagot, ami egyfelhasználós környezetben mindenféle ConsoleKit és egyéb modern linuxos komplexitás hegyek nélkül elintézi ezt.

pkg_add hotplug-diskmount

Ezután pedig elő kell készíteni a /vol könyvtárat az automatikus befűzéshez (nem tudom abbahagyni).

doas /usr/local/libexec/hotplug-diskmount init

Valamint konfigurálni kell a szolgáltatást a /etc/hotplug/attach script beállításával:

#!/bin/sh

DEVCLASS=${1}
DEVNAME=${2}
LOGIN=kodfodrasz

case ${DEVCLASS} in
2)
    /usr/local/libexec/hotplug-diskmount attach -u ${LOGIN} -m 700 ${DEVNAME}
    ;;
esac

Ezután ezt a filet végrehajthatóvá kell tenni, majd a szolgáltatást elindítani.

doas chmod +x /etc/hotplug/attach`
doas rcctl enable hotplugd
doas rcctl start hotplugd

Et voilà! Már működik is:

tinfoil$ mount    
/dev/sd0a on / type ffs (local, noatime, softdep)
/dev/sd0k on /home type ffs (local, noatime, nodev, nosuid, softdep)
/dev/sd0d on /tmp type ffs (local, noatime, nodev, nosuid, softdep)
/dev/sd0f on /usr type ffs (local, noatime, nodev, softdep)
/dev/sd0g on /usr/X11R6 type ffs (local, noatime, nodev, softdep)
/dev/sd0h on /usr/local type ffs (local, noatime, nodev, wxallowed, softdep)
/dev/sd0j on /usr/obj type ffs (local, noatime, nodev, nosuid, softdep)
/dev/sd0i on /usr/src type ffs (local, noatime, nodev, nosuid, softdep)
/dev/sd0e on /var type ffs (local, noatime, nodev, nosuid, softdep)
/dev/sd1i on /vol/DT 100 G2 type msdos (local, nodev, nosuid, uid=1000, gid=0, mask=0700)
tinfoil$ ls -l /vol/
total 128
drwx------  1 kodfodrasz  wheel  16384 Jan  1  1980 DT 100 G2
tinfoil$

X11: intel driver, xsession, Unicode, TrackPoint

Bár az X11 elsőre működött de még nem felelt meg az igényeimnek. Észrevettem, hogy a locale nem Unicode barát, sem X, sem konzol vagy ssh login alatt.

Ennek megoldásához a locale beállítása szükséges, amit az alábbi sor a ~/.profile és ~\.xsession fileokba írásával tudunk mind login sell, mint X11 alatt beállítani:

export LC_CTYPE="en_US.UTF-8"

Ezután a számomra elég kényelmetlen twm ablakkezelőt cseréltem le az általam kedvelt i3-ra. Először telepíteni kellett a portot:

doas pkg_add i3 i3status

A TrackPoint *NIX alatt megszokott kényelmes középső gombos görgetés és középső gomb kattintás funkciói sem voltak tökéletesen beállítva alapból. Ezt is az X induláskor kell beállítani, és nem tudtam olyan Xorg konfig töredéket alkotni, ami működne, úgyhogy az xinput paranccsal az .xsession-ből csinálom ezt is.

Zavaró volt még a mindig induló xconsole ablak, amit akár a login manager szintjén le lehet tiltani, én azonban inkább csak kilövöm loginkor. Ehhez a megfelelő /etc/doas.conf beállítás is szükséges volt:

permit nopass :wheel cmd pkill args -G _x11 xconsole

Az .xsession fileom végül így néz ki:

export LC_CTYPE="en_US.UTF-8"

doas pkill -G _x11 xconsole

if [ -f $HOME/.Xresources ]
then
        xrdb -merge $HOME/.Xresources
fi

#export ENV=$HOME/.kshrc

xsetroot -solid "#002244"

xset b off

xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation" 1
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Button" 2
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Axes" 6 7 4 5

exec i3

Azt találtam, hogy a képernyő mintha nem az intel driverrel működne. Konkrétan az intel string nem szerepelt a logban. Az X logokból látszott is, hogy a modesetting_drv framebuffer driverrel működik:

[404222.769] (II) Loading /usr/X11R6/lib/modules/drivers/modesetting_drv.so
[404222.780] (II) Module modesetting: vendor="X.Org Foundation"
[404222.780]    compiled for 1.19.6, module version = 1.19.6
[404222.780]    Module class: X.Org Video Driver
[404222.780]    ABI class: X.Org Video Driver, version 23.0
[404222.780] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[404222.781] (**) modeset(0): claimed PCI slot 0@0:2:0
[404222.781] (II) modeset(0): using default device
[404222.781] (II) modeset(0): Creating default Display subsection in Screen section

Erre az volt a megoldás, hogy létrehoztam a /etc/X11/xorg.conf.d/intel.conf filet a következő tartalommal:

Section "Device"
  Identifier "drm"
  Driver "intel"
  Option "TearFree" "true"
EndSection

Máris ilyeneket találtam a logban:

[    25.846] (II) LoadModule: "intel"
[    25.848] (II) Loading /usr/X11R6/lib/modules/drivers/intel_drv.so
[    26.109] (II) Module intel: vendor="X.Org Foundation"
[    26.109]    compiled for 1.19.6, module version = 2.99.916
[    26.109]    Module class: X.Org Video Driver
[    26.110]    ABI class: X.Org Video Driver, version 23.0
[    26.110] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
        i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
        915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
        Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
        GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
[    26.118] (II) intel: Driver for Intel(R) HD Graphics: 2000-6000
[    26.118] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100, 6100
[    26.118] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200, 6200, P6300
[    26.143] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20151010
[    26.217] (--) intel(0): Integrated Graphics Chipset: Intel(R) GM45
[    26.217] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1
[    26.217] (II) intel(0): Creating default Display subsection in Screen section

Ezzel az X11 es környezet nagyjából megfelelően is működött, innentól már minden az ízlésem dolga.

Az X11 indítására a startx nem volt ajánlott már ekkor sem, de a 6.5-ös kiadás óta biztonsági okokból már egyáltalán nem támogatott.

RFKILL kapcsoló probléma

Ha a hálózatot fel tudtam éleszteni, lássuk, le tudom-e kapcsolni? A gép oldalán hardware kapcsoló van erre, ami sikeresen le is kapcsolja a Wifi eszközt. Visszakapcsolása után azonban nem csatlakozott ismét a hálózathoz, amíg egy ifconfig iwn0 up parancsot ki nem adtam. Régi megszokásoktól vezérelve az IRC-re vettem az irányt, ahol a Freenode #OpenBSD csatornáján azt a workaroundot javasolták, hogy az ifstated (8) segítségével próbáljam meg ezt áthidalni.

A kézikönyv olvasása után, megnéztem mit csinál, ha kapcsolgatom az RFkill kapcsolót:

tinfoil$ doas ifstated -d -vv  
running ifconfig iwn0 up
started
interface cdce0 departed
interface cdce0 arrived

Azt látni ebből, hogy van egy hálózati eszköz, a cdce0, ami jön-megy a kapcsoló állításánál, és ezt az ifstated érzékeli is! A cdce (4) egyébként USB-USB hálózati eszköz, ami szintén tiszteletben tartja ezek szerint az RFKILL kapcsolót! Még egy kis kézikönyv olvasás után a konfiguráció az /etc/ifstated.conf fileban így néz ki:

state rf_off {
    if cdce0.link.up {
        set-state rf_on
    }
}

state rf_on {
    init {
        run "ifconfig iwn0 up"
    }

    if ! cdce0.link.up {
        set-state rf_off
    }
}

Ekkor megismételve a kísérletet:

tinfoil$ doas ifstated -d -vv  
initial state: rf_off
changing state to rf_off
changing state to rf_on
running ifconfig iwn0 up
started
interface cdce0 departed
changing state to rf_off
interface cdce0 arrived
changing state to rf_on
running ifconfig iwn0 up

Jól látszik a logban, hogy az ifconfig iwn0 up parancs meghívásra került, a wifi pedig valóban csatlakozott a hálózathoz, úgyhogy a probléma áthidalásra került!

Már csak automatikusan el kell indítani a szolgáltatást, és kész is vagyunk!

rcctl enable ifstated
rcctl start ifstated

Néhány nappal később került bejelentésre az OpenBSD 6.5, aminek changelogja többek közt ezt is tartalmazza:

The iwn(4) and iwm(4) drivers will now automatically try to connect to a network if the radio kill switch is toggled to allow radio transmissions while the interface is marked UP.

Elsőre arra gondoltam, hogy az IRC-en láthatta valaki a nyomorom, és megfelelő domain tudás birtokában gyorsan javította a hibát. Valójában utánajárva kiderült, hogy a hiba ekkor már javítva volt a CURRENT ágon, kiadásra várt csupán.

Nincs más hátra, mint előre!

Eddig összességében pozitív a benyomásom, úgyhogy a nemrég elkészült OpenBSD 6.5 kiadást hamarosan telepítem, ez alkalommal a teljes lemez titkosítását is kipróbálva.

A negatívumok ledolgozásában pedig megpróbálok besegíteni majd.

Nagyobb biztonságban érzem magam, mint korábban!

Források

A fenti banner az OpenBSD project prómóanyagai közül származik.
A borítókép a Pixabayről származik.

OpenBSD 6.4
OpenBSD Frequently Asked Questions
OpenBSD Manuals

OpenBSD on a Laptop