Beep: hangjelzés Linux boot folyamat végén

És hét pap vigyen hét, kosszarvból készült kürtöt a láda előtt. A hetedik napon pedig hétszer kerüljétek meg a várost, a papok pedig fújják meg a kürtöket.
És ha majd belefújnak a kosszarvba, mihelyt meghalljátok a kürt szavát, az egész nép harsány kiáltásban törjön ki, és magától leszakad a város kőfala, és fölmegy arra a nép, mindenki az előtte levő helyen.

Ószövetség, Józsué könyve, 6. fejezet.
Jerikó bevétele

Az routerem egy Mikrotik gyártmányú termék, és ezen van egy nagyon hasznos funkció: hangjelzéssel jelzi a bekapcsolás vagy újraindulás után a sikeres indulást, amikortól már evárható a szolgáltatásinak helyes működése. Ez nagyon hasznos funkció olyan headless gépeken, amik a közvetlen környezetemben működnek. Ilyen az itthoni router mellett az itthoni NAS is. Mivel épp belakom az új gépet, amit erre a fealdatra raktam össze, és most még viszonylag gyakran újra is indítom emiatt, így megcsináltam ezt a funkciót a NAS-ra is.

A NAS-on Fedora 31 fut, így a leírás arra vonatkozik, de minimális módosításokkal nyilván más systemd alapú Linux disztribúciókon is használható.

Beep-beep!

Először is a gépen szükséges egy hardwares hangkimenet. Én a PC Speakert választottam a feladatra, mert más hangforrást nem akarok a gépre kötni.

Linux alatt legegyszerűbben a beep programmal lehet PC Speakert tütülésre bírni. Ezt a legtöbb disztribúció szállítja. Fedora alatt a telepítése mindössze annyi, hogy:

dnf install -y beep

Ezután a beep parancsot kiadva… nem hallunk hangokat. Be kell tölteni a PC Speaker kernel modulját: modprobe pcspkr. Ekkor kis szerencsével már hangokat ad a beep, de sudo alól nem szeret hangot adni. Én inkább root felhasználóval belépve kipróbáltam, és működött a nyavajás: idegesítő sípolást hallatott!

Arra jutottam, hogy a tanácsával ellentétben nem az evdev eszközök jogait fogom beállítani udev varázslattal, mivel úgyis csak bootnál akarom bizgetni, és azt majd a megteszem rootként. Nálam finnyásabbaknak jó szórakozást kívánok az udev bűvöléshez!

Térjünk vissza a kernel modulhoz! Automatikusan be kellene tölteni a gép induláskor. A modern systemd világban ezt a /etc/modules-load.d/*.conf fileokban felsorolt modulokra a sysetmd meg is csinálja nekünk!

echo pcspkr > /etc/modules-load.d/pcspkr.conf

Ha pedig systemd, akkor nyilván egy service kell a program iduláskori futtatására is. Mire is van szükségem? Egy egyszer futó servicere, ami a modulok betöltése, és az ssh indulása után, a multiuser mód előtt fut, egyszer, és nem indul újra kilépése után. Ezt a /etc/systemd/system/beep-after-boot.service file a következők írásával érhetjük el:

# Systemd unit file /etc/systemd/system/beep-after-boot.service
[Unit]
Description=Beep after boot is complete
After=sshd.service systemd-modules-load.service

[Service]
User=root
Group=root
# 100ms 2kHz beep, 100 ms silence (hack: 1Hz beep), 100ms 1kHz beep.
ExecStart=/usr/bin/beep -f 2000 -l 100 -n -f 1 -l 100 -n -f 1000 -l 100
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Ezután már csak a boot folyamathoz kell adni az új szolgáltatást:

systemctl enable beep-after-boot.service

Újraindítás után a gép vidáman csippant kettőt amikor lehet ssh-zni rá! 📯🎉

A tmux és az ssh újracsatlakozás után is működő SSH Agent-forwarding

Egy borítóképnek nem feltétlen kell köze legyen a témához

Újabban ismét többet használok Unixokat, most leggyakrabban Linuxot. Elengedhetetlen társam ebben a tmux terminál multiplexer. Gyakran használom bonyolultabb munkamenetek átlátásához, illetve arra, hogy hosszan futó feladatok egy hálózati problémát is túléljenek.

Amikor megbízható gépekhez csatlakozom, akkor az SSH Agent Forwardingot is használom, mert hasznos, és kényelmes funckió. Persze tisztában kell lenni a biztonsági kockázataival, és azt figyelembe véve szabad csak használni.

Amikor azonban egy új ssh kapcsolattal csatlakozunk egy géphez, és a tmux munkamenethez ismét csatlakozunk, azt vehetjük észre, hogy már nem működik az SSH Agent Forwarding. Ez azért van, mert az új kapcsolat új agent socketet csinált, amin keresztül a távoli ssh a helyi ssh agenttel tud kommunikálni, és a környezetben a korábbi socket elérése található.

Az interneten szétnézve találni erre megoldásokat, amik legtöbbször egy fix helyre symlinkelik a legutolsónak csatlakozó kapcsolat ssh socketjét. Én ezek alapján egy hasonló, de kicsit a saját szájam ízéhez igazított megoldást választottam.

A tmux frissítse a tárolt környezeti változót újrakapcsolódáskor

A tmux támogatja, hogy a környezeti változóit frissítse egy már futó session-nek, így az újonan nyíló ablakokban induló új shellek már az aktuális értéket kapják.

Ehhez csupán a következőt kell a ~/.tmux.conf fileba írni:

set-option -g update-environment "SSH_AUTH_SOCK \
                                  SSH_CONNECTION"

Ezzel azonban a korábban nyitott shellekből nem fog még működni az agent forwarding, ami kissé kellemetlen.

Futó shellek környezeti változóinak frissítése

Mivel most linuxon tevékenykedek, ezért meg se próbálok úgy tenni, mintha érdekelne a POSIX-kompatiblitás. Inkább valami életszerűbbet, egy Bash shellhez való megoldást mutatok.

A ~/.bashrc fileban a következő függvényt kell létrehozni:

function refresh-env-vars()
{
    if [ -n "$TMUX" ];
    then
        while read env_line;
        do
                eval "$env_line";
        done < <(tmux show-environment -s)
    fi
}

A tmux show-environment -s parancs Bourne shell parancsok formájában soronként kiírja az általa kezelt környezeti változókat, amiket a set-environment, és a korábban látott update-environment parancsaival lehet manipulálni. Ezeket a sorokat az eval segítségével a shell kontextusában lefuttatva frissültek is a megfelelő változók.

💡 Fontos a fent látható Process substitution formátumban kikérni a tmux-tól a parancsokat, mert amennyiben a szokásos parancs | while read ciklus formát használnánk, úgy a while már egy subshellben futna, így a változók értékadásai nem lennének hatással a környezetünkre!

Ezek után egy már futó környezetben csupán a refresh-env-vars parancsot kell hívni, és már működik is az agent forwarding!

Hosszú idő után nem a felhőben, hanem ismét a valódi vasak világában találkoztam régi ismerősömmel, a Linuxxal. Eljött az idő a rendkívül koros Intel Atom alapú házi szerverem ráncfelvarrására, és AMD Ryzen alapokra helyezésére. A régi idők emlékére először a Fedora Linux segítségével próbálom meg feléleszteni a gépet.

Titkosítsunk! Mit és miért?

Ha az ember valódi hardverre telepít, nem a felhőben virtualizálva dolgozik, akkor olyan problémákat kell megoldjon maga, amiket a felhőben már megoldottak a háttérben dolgozó szorgos kezek, és adottságként állnak rendelkezésre. Ilyen a bizalmas adatok hardware selejtezés utáni szivárgásának megakadályozása. Akinek kellett már félig haldokló lemezek szeméttel felülírásával vacakolnia mielőtt selejtezhette volna őket, már biztos elgondolkozott azon, hogy mi lenne ennek a hatékony megoldása. Van aki úthengerre, lángszóróra, vagy kalapácsra szavaz, de mint minden hardveres problémát, természetesen ezt is akad aki szoftver segítségével akarja megoldani: a lemez titkosításával.

Jó pár éve már, hogy olvastam az Apple iPhone telefonokban alkalmazott gyors törlési megoldásában: mivel a teljes háttértárat felülírni soká tartana, ezért a teljes háttértár titkosítva van, csak a kulcs van egy biztonságos tárhelyen tárolva, és a (távoli) törlési kérelem esetén csak a kulcsot kell eltávolítani, így a sok titkosított adat máris hozzáférhetetlen. Ezt a megoldást elég kiterjedten alkalmazzák azóta.

Egy példa: a / filerendszer nem titkosított, így a /etc alatt egy olyan program bizalmas információt (pl. tanúsítványokat) tárol, ami elkerült a rendszergazda figyelmét, aki az általa telepített szolgáltatok általa ismert bizalmas adatait gondosan titkosított tárhelyre helyezte. Ha a teljes lemezt titkosítjuk, akkor minimalizáljuk annak az esélyét, hogy véletlen adatot szivárogtassunk.

Hogy oldjuk fel?

Ha titkosítva van a rendszer, hogyan oldjuk fel a titkosítást a használathoz? Alapesetben egy jelszó a kulcs, amit a telepítés során lehet megadni. A rendszer betöltés korai szakaszában szükséges ezt megadni az initrd scriptek egyike, hogy a root filerendszert fel tudja oldani. Alapesetben egy jelszó-prompt jelenik meg, ahol be kell gépelni a jelszót, hogy a betöltés folytatódni tudjon. Ez egy notebookon megfelelő felhasználói élmény, de egy szerveren nem jó, ha interaktív tevékenység szükséges a konzolon az indítás során.

Több megoldás kínálkozik, a legegyszerűbb, amit alapjáraton is támogat a rendszer, ha egy boot során rendelkezésre álló külső eszközön (pendrive) tárolt kulccsal is feloldható a rendszer.

Az ellen nem véd!

Fontos tudni, hogy mi a fenyegetési modellünk:

  • Ha a géphez fizikailag hozzáfér egy támadó, akkor a beledugott pendrivehoz is hozzáfér. Így el tudja indítani a gépet, és a lemezt fel tudja oldani. Azonban, ha fizikailag hozzáfért a géphez, akkor a gép már amúgy sem megbízható többé, más módokon is tudná kompromittálni, és megszerezni a szükséges kulcsokat.
  • Ha mindig be van dugva a pendrive, akkor egy megfelelően magas jogokat szerző távoli támadó fel tudja csatolni, és meg tudja szerezni a kulcsot. Ekkor azonban már amúgy is teljes hozzáférése van a géphez, és ekkorra már bármilyen bizalmas adatot meg tudott szerezni.

Mi ellen véd akkor? Ahogy már fent is írtam: Ha a lemezt selejtezzük, többé nem kell aggódni azon, hogy adatot szivárogtatunk róla, mert külön van tárolva a feloldáshoz szükséges titkosítási kulcs.

Lehetséges bonyolultabb, de szűkebb támadási felületet nyújtó nem-interaktív feloldási sémák megalkotása is, például hálózatról letöltött kulcs, amivel pl. betörő ellen védhető a gépen tárolt adat, mert a kulcsforrás feletti ellenőrzés továbbra is megmarad, míg a pendriveot magával tudja vinni a betörő. Ezek azonban számottevő extra erőfeszítést igényelnek.

Sok a rizsa! hogy kell megcsinálni?

Valóban bő lére eresztettem, de a megoldás egyszerűségéhez képest sok macerával járt, mivel sajnos az internetes keresések találatai alapján indultam neki a megoldás keresésének. Így sok elavult, még több gányolt, és számtalan haszontalan tanácsot láttam, sokat ki is próbáltam, de végül tiszta lapról kezdve a dokumentációból dolgozva sikerült megtalálni a következő egyszerű receptet:

Rendszer telepítése

ℹ Az alábbiakat a Fedora 31 verzión végeztem el.

A rendszer telepítése során lehetőség van a titkosítás konfigurálására, ahol a kezdeti jelszót meg kell adni. Így minden partíció, és a swap egyaránt egy LVM PV-be kerül, ami egy titkosított blokkeszközön kerül tárolásra. A titkosítást LUKS segítségével végzi a rendszer.

A telepítés után a rendszer első indításánál a jelszóval kell feloldani a lemezt, hogy a gép betöltsön, és be lehessen jelentkezni.

Jelentkezzünk be rendszergazdaként, majd készítsük el a pendriveot a kulccsal. A lemezt a címkéje alapján fogjuk azonosítani. Lehetséges lenne UUID alapú azonosítás is, ám akkor a drive meghibásodása esetén új filerendszer után több konfiguráció frissítés is szükséges lenne.

mkfs.ext4 -L key-disk /dev/sda1
mount -t ext4 /dev/disk/by-label/key-disk /mnt/
dd if=/dev/urandom of=/mnt/the.key bs=1024 count=4
chown root:root /mnt/the.key
chmod 600 /mnt/the.key

Azonosítsuk a LUKS által használt blokkeszközt:

blkid

Látható a kimenetben, hogy egyetlen crypto_LUKS eszköz szerepel, és a /dev/mapper alatt egy virtuális blokkeszköz van ennek titkosítatlan képével, mely neve luks-<UUID> formát követi. Ebből megállapítható, hogy a titkosított rendszerpartíció a /dev/nvme0n1p2.

/dev/nvme0n1p1: UUID="ad346a3f-115e-4859-912a-ab12d2ec9b7a" TYPE="xfs" PARTUUID="fc06552d-01"
/dev/nvme0n1p2: UUID="e5a1edd8-1e92-4daa-bcf8-3ab26e677e32" TYPE="crypto_LUKS" PARTUUID="fc06552d-02"
/dev/sda1: LABEL="key-disk" UUID="15c0603d-a582-4303-bc10-331a639c2b4b" TYPE="ext4" PARTUUID="dd814dd5-01"
/dev/mapper/luks-e5a1edd8-1e92-4daa-bcf8-3ab26e677e32: UUID="d0prxL-fYml-QPiL-9zBr-624P-w9Kf-3KLTfM" TYPE="LVM2_member"
/dev/mapper/fedora-root: UUID="f58639e1-7369-4244-8751-9f5b0d1ecfc3" TYPE="xfs"
/dev/mapper/fedora-swap: UUID="d6ce8801-e3bd-4dbd-9cf9-3c741dd7c9e4" TYPE="swap"

A partíció LUKS kulcstartójához adjuk hozzá a korábban elkészített kulcsfilet.

cryptsetup -v luksAddKey /dev/nvme0n1p2 /mnt/the.key luks

Ekkor már a kulcsfile képes lenne feloldani a kötetet, de az initrd scriptek futása során kellene ezt automatikusan megtenni. Itt kezdett az internetes források sokasága használhatatlanná válni. Egyes források boot parancssori opciókat javasolnak, de ezek (rd.luks.key, rd.luks.uuid) sajnos nem működtek. Mások kézműves scriptek initrd-be plántálásával dolgoznak, amik szintén nem az igaziak.

A megoldás azonban nagyon egyszerű: a LUKS konfigurációja az /etc/crypttab fileban található. Ezt a filet megfelelően kitöltve, és az initrd-ben frissítve a lefutó scriptek képesek a szükséges filerendszer mountolást, és lemez feloldást elvégezni.

A telepítő által generált file 3. oszlopa, mely a titkosítási jelszót tartalmazza, none értékű, ami az interaktív belépésre kényszeríti az ez alapján dolgozó initrd scripteket. Az alábbi módosításokkal azonban megadhatjuk, hogy a keyfile mely lemezen található, milyen néven, és amennyiben ez nem áll rendelkezésre 30 másodpercen belül, úgy az interaktív belépésre váltson vissza a rendszer.

# /etc/crypttab

#
# this was the original contents:
#
#luks-e5a1edd8-1e92-4daa-bcf8-3ab26e677e32 UUID=e5a1edd8-1e92-4daa-bcf8-3ab26e677e32 none discard

# 
# use file key from the root of the block device identified by its label key-disk, 
# if not found in 30 seconds fall back to interactive password authentication,
# propagate SATA TRIM discard commands
#
luks-e5a1edd8-1e92-4daa-bcf8-3ab26e677e32 UUID=e5a1edd8-1e92-4daa-bcf8-3ab26e677e32 the.key:LABEL=key-disk discard,keyfile-timeout=30

A változtatás érvényre juttatásához frissíteni kell az initrd filet, mert a crypttab abba be van csomagolva. Mivel már létezik a célfile, ezért szükséges a --force kapcsoló.

drakut --force

Frissítések során a telepített újabb kernelekhez automatikusan elkészülnek majd a megfelelő initrd imagek.

Ezen egyszerű megoldás megtalálását kissé megnehezítette, hogy a crypttab manpage a file:blockdevice formátum létezését nem igazán hangsúlyozta, csak egy példában lehetett kiszúrni. Nekem ez csak a sokadik kört futva tűnt fel.

Kész is vagyunk!

Ezzel el is készültünk, nincs más tennivaló, mint újraindítani a rendszert, és a élvezni a munka gyümölcsét!

… az üveghegyeken innen, de a bejelentésén sok évvel túl, hosszas hallgatáson is túl, ahol az inkumbens kartell az úr, a magyar mobilelefon piacon a legkisebb fiú a DIGI lett a negyedik önálló mobiltelefon szolgáltató!

Ezzel a negyedik önálló mobilszolgáltatóvá vált, és remélhetőleg tartva magát agresszív árképzéséhez és tapasztalataim szerint jó minőségű szolgáltatásához végre némi versenyt hoz a legalábbis oligopol, de már-már kartell gyanús hazai mobilpiaci viszonyok közé.

Szolgáltatása egyelőre még nem ad akkora lefedetséget mint versenytársai, és még csak nyilvános tesztüzemben működik. A béta-tesztelésben minden DIGI előfizető (műholdas vagy kábeles TV vagy internet) részt vehet: az év végig ingyen kaphat legfeljebb 5 SIM kártyát előfizetése mellé, mellyel hálózaton belül ingyen, azon kívülre pedig nagyon kedvező árképzéssel telefonálhat, SMS-ezhet. Roaming nincs (még). További részleteket a DIGI oldalán, vagy például a HWSW oldalán lehet olvasni erről.

Eljött az ideje, hogy én is beszálljak az internetbe! Felkerestem egy DIGI pontot, és kértem SIM kártáyát. Röviden: kipróbáltam, működik!

VoLTE támogatás

Miért érdekes a VoLTE? Mert hazánkban a DIGI az első olyan szolgáltató, aki elsősorban 4G alapú szolgáltatást célozza meg, és egyből utoléri már a piacon levő társait a VoLTE (Voice over LTE) telefonhívás támogatásával, sőt, a Vodafone-t meg is előzi ezzel! Mivel még nem teljesen kiforrott a szolgáltás (handset oldaról se), ezért egyelőre a DIGI 2G hálózatot is üzemeltet. A tisztán 4G alapú szolgáltatás egyik fő gátja a VoLTE támogatás felemássága: hiába támogatja a DIGI hálózata, hiába támogatja az előfizető készüléke, ez nem elég, hogy a funkció működhessen. Mivel még nem zajlott le a legtöbb készülék hitelesítése, tesztelése a hálózattal, ezért a készülékek gyártói nem engedélyezték még a funkciót ezen a hálózaton. Globálisan nagyon kevés hálózat-készülék párossal van csak engedélyezve a VoLTE egyelőre. Felmerülhet a kérdés, hogy miért is? Egyszerű a válasz: a 2G és 3G alapú szolgáltatás már kiforrott és működik. A legtöbb szolgáltató és előfizető így azon keresztül tudja a hanghívásokat bonyolítani a törvényileg megkövetelt paraméterekkel. Olyan ez kicsit, mint az IPv6: bár a VoLTE szolgáltatást is úgy tervezték, hogy mindenben megfelejen mind a piaci, mind a törvényi elvárásoknak, de mivel van már bevált előd, nem kapkodják el a tesztelését, minősítését.

Így történhetett, hogy a telefonom bár képes VoLTE hívásokra, de én nem találtam ezt sehol sem a menüben. Mit tehet ilyenkor az ember? Keres egyet az interneten! Egyből a középiskolás éveimet idéző mágikus számsorra akadtam egy Xiaomi fórumon.

*#*#86583#*#*

De mi is ez a számsor? *#*#VOLTE#*#*! Ez egy szervíz-kód, ami egy nem széles körben publikált beállítást tesz lehetővé a telefonon. A szervíz kódokat a tárcsázóban kell beütni aktiválásukhoz. Ez a kód engedélyzei a Xiaomi whitelisten nem szereplő szolgáltatók számára is a VoLTE funkciót.

Beírva a kódot egy VoLTE carrier check disabled felugró értesítést kaptam, és megjelent a HD felirat a menüsor tetején. Miért HD? A VoLTE marketingjében HD hanghívásnak is brandelik ezt a funkciót, mivel jobb tömörítési algoritmusokat használ mint elődei. Valódi előnye azonban nem ez, hanem az, hogy csomag kapcsolt, nem pedig (virtuális) áramkör-kapcsolt, így kisebb sávszélesség igényű, és az erőforrások jobb kihasználását teszi lehetővé, mint elődjei.

VoWiFi

Bár a VoLTE szolgáltatásban egyből dobogós a DIGI, de van, amiben egyenesen első! Ez pedig a VoWiFi azaz Voice over WiFi támogatás. Ez épp az, amit a neve sugall: ahol van WiFi-n elérhető internet, ott a hálózathoz azon át is tud csatlakozni a telefon. Ez ott jöhet jól, ahol rossz a lefedettség, de van vezetékes internet. A technológia természetesen akár hívás közben is észrevétlen váltást tesz lehetővé a WiFi hálózatról a mobilhálózatra. Ez nem ingyen VoIP hívás, mint pl. a Skype, hanem rendes telefonhívás, csak az átviteli közeg más.

Ezt azonban nem támogatja a telefonom (Xiaomi Mi A1). Akinek viszont modernebb Xiaomi készüléke van, az a következő szervízkóddal tudja a szolgáltató ellenőrzést letiltani:

*#*#869434#*#*

A szervízkód amúgy a *#*#VOWIFI#*#* telefonon bebillentyűzve.

Tapasztaltaim

A VoLTE engedélyezése után a hívások néhány próba alapján gyorsan felépültek, de a HD hangot nem volt módom kipróbálni, mivel az ellenoldalon nem volt VoLTE képes telefon. Óbudán a térerő kielégítő beltérben is, kültéren jó. A mobilnet nem ment először, de a szükséges beállításokat elvégezve működik. Nem egy villám, de még YouTubeozni is lehet rajta. Nagyjából pariban van (még…) a mostanra érzésem szerint lelassult (telítődő kapacitású) Telenor Hipernet szolgáltatással.

Kis kávézacc-jóslás

Meglátjuk, hogy sikerül-e a DIGI-nek jövőre további frekvenciákat szerezni az esedékes frekvencia-aukción. Ez létfontosságú számára mind a vidéki lefedettség fokozásához, mind a nagyvárosi sávszélesség növeléséhez. Amennyiben sikeresen tereli az előfizetőit a VoLTE és VoWiFi felé, plldául csak minimális 2G kapacitás fenntartásával, úgy a hatékonyabb technológiáknak köszönhetően versenyképessé válhat a konkurenciánál a szűkösebb kapacitásai ellenére is.

Előfizetői oldalról nézve ugyanakkor várhatóan az árazópisztoly nem lesz annyira agresszív a tesztüzem után, ha nem lesz elég frekvencia. A sok elégedetlen ügyfél szerzése és hosszú időre elidegenítése nem lehet cél, márpedig elegendő kapacitás nélkül az előfizetőkben csak az “olcsó húsnak híg a leve” benyomást tudná kelteni. Ezt elkerülendő mérsékelt árelőnyt kínálva egy jövedelmezőbb, és fokozatosan fejlődő üzletet építhet ki. Szerintem, de ez csak a személyes benyomásaimon alapul, a telekommunikációs szolgáltatások kereslet-árrugalmassága kicsi az általam megfigyelt felhasználási szokások alapján. Akinek kell valami megveszi, akinek kéne, de nem tudja megvenni, az az olcsóbból sem fog tudni annyit venni nominálisan. Szomorú, de ez azt jelenti, hogy az államnak sem érdeke a verseny élénkítése például a frekvencia aukció szabályozása által, mivel szerintem (ex-has) az adóbevétel csökkenést eredményezne, a szektor zsugorodásával járna. Épp ezek miatt csodát nem várok, de mindenképp a verseny enyhe élénkülésére számítok, ahogy a vezetékes internet szolgáltatások piacát is felrázta a DIGI berobbanása.

Az első nap alapján a szolgáltatás működőképes. Az zacc-jóslásom pedig érdekes lesz számomra visszanézni. Gondolom mellélövök, mert a buborékomon kívül sok más tényező van, amit én nem tudok, de a piackutatók nagyon is feltárták.

Szegény ember éjszakai módja

Fényesség vagyok: bárcsak volnék sötét éjjel!
De az a magánosságom, hogy fényesség ővez engem.
Óh, bárcsak volnék sötét és éjszakázó!
Hogy szívnám akkor - a fényesség emlőit!

– Friedrich Nietsche: Im-igyen szóla Zarathustra.

Mostanában sok weblap, alkalmazás témája sötét színű. Ez azonban néha több, mint puszta divathullám: nem csak az különféle ízlésekről szól ez, de az ergonómiáról is. Én is azok közé tartozok, akiknek este még minimális fényerőn is bántóan fényes tud lenni a világos alapon megjelenő felület vagy tartalom: számomra is kényelmi kérdés ez a funkció.

Mind az Android, mind a MacOS, mind a Windows aktuális verziói támogatják a világos és sötét témákat, esetenként a könnyű váltást is köztük, valamint az alkalmazások számára is felkínálják azt az információt, hogy azok a flhasználó számára neki tetsző felületet varázsolhassanak.

Az aktuális webes szabványok is lehetővé teszik a preferenciák érzékelését: A CSS prefers-color-scheme media-query segítségével.

Mit tehetünk azonban, ha nem támogatott az éjszakai mód, és bántóan világos tartalommal szembesülünk éjjel?

Olvasó mód

Webes tartalom esetében az olvasó mód használata segíthet, ott ugyanis csak kivonatolt tartalmat látni, de az oldal stílusa helyett egységes felületet látni minden weblapra. Az olvasó mód nappali/éjszakai stílusa viszont már kiválasztható!

Invertálhatunk // ʞunʇɐɥןáʇɹǝʌuI

Nem minden weblap tartalmát tudja kinyerni az olvasó mód, néha kifejezetten a készítők szándékából. Ezen felül (egyelőre) nem csak a webből áll a világ, és egy alkalmazásal mit lehet tenni? Invertálni a színeket!

Régen ilyenkor képernyő mentést csináltam, és invertáltam a színeit egy képszerkesztőben. Ez elég körülményes volt, minden lapozásnál meg kellett ismételni. Interaktív felületek esetében pedig egyáltalán nem jöhetett szóba.

Windows 10

A Windows 10 azonban kisegítő lehetőségei közt a korábbi verziók által a gyengénlátóknak kínált nagy kontrasztú módon és nagyobb gombokon felül immár a színtévesztők életét is próbálja megkönnyíteni, különféle színszűrőkkel. Vannak szűrők, melyek a különféle színtésvesztési módokban érintettek számára jobban megkülönböztethető árnyalatokba transzformálják a színeket, de van szürkeárnyalatos mód, és invertált mód, szőt invertált szürkeárnyalatos mód is!

Ami az egészet különösen kényelmessé teszi, hogy a Ctlr + Win + C billentyűzet kombinációval lehet ki és bekapcsolni a szűrőket, miután bekonfiguráltuk őket.

Így mutat a beállítási felület invertálva:

Windows 10 kisegítő lehetőségek beállításai invertált színekkel

OpenBSD

Most, hogy OpenBSD-t is aktívan használok, azonnal fel is merült bennem a kérdés, hogy rendben, de hogyan tudom ezt OpenBSD alatt is használni?

Az xcalib nevű eszköz segít ebben, ami a ports-ban elérhető. Az xcalib -invert -alter parancs invertálja a képernyő színeit. Az i3 konfigomba a következő sort beszúrva már élvezhettem is a Windows 10 alatt megszokott billentyűzet kombinációval elérhető szegény ember éjszakai módját:

bindsym $mod+Ctrl+C exec xcalib -invert -alter

Ezek után már nincs más teendő, mint a bloghoz is elkészíteni az éjszakai módot. Vagy így már nem is kell. 😎