Zahy blogja

Retikülimportban megérkezett. Nekem élőben is tetszik.

No comment. A legszebb, hogy aki nem nyújt TCP-szolgáltatást nem-megbízható klienseknek, az nincs veszélyben. Most elgondolkodtam, a gyakorlatban ez lehet egy NFSv2-t használó NFS-szever, egy NTP-szerver, és csak megbízható slave-ekkel rendelkező DNS-szerver. Juhé.

Így jár aki figyelmetlen. Gondoltam megfrissítem az asztali gépet a múlt héten megjelent BETA1-re, és épp bőszen megy az update, amikor is sikerül belefutnom a hírbe, hogy tegnap megjelent a 10.2-BETA2. Hát istenem, idő van, tej van ... - szóval kétlépcsős update következik. (Egy VM-ben a múlt héten már frissítettem egyet, azzal nem volt gond - mondjuk agyonra nem terheltem/teszteltem; majd most.)

Azannya :-)

Nem tudom mi van ezekkel, kurvulnak elfele. Egy hónapja nem jött új SA. OK, EN - azaz Errata Notice - az volt pár, sőt rendszerfrissítés is, de SA már ezer éve nem jött. Ráadásul a mostani nem is érint, ugyanis BIND-hiba, ami alapból csak azokat érinti, akik 8.x vagy 9.x verziót használnak, hiszen már csak azokban van gyárilag BIND. Csinos kis remote DOS. Részletek a linken.

Nagy nehezen sikerült találnom egy erre a célra beáldozható kártyát, így futottam egy rövid tesztkört fenti párosítással. Mivel az RPi2 újabb, mint a legutolsó stabil FreeBSD kiadás, logikusan nincs hivatalosan tölthető RELEASE.iso (illetve img) - és igaz ugyan, hogy elvben kompatibilis a régiekkel, de pont a boothoz kell pár apró változás. A lényeg, egy június 18-i, 11-CURRENT verzióval indultam.

A tapasztalatok kissé felemásak.

A képernyő bal szélén kb 4-6-8 karakternyi infó nem lászik, így néhány infó leolvasása legalábbis nem triviális (mindez egy fullHD-TV-t használva kijelzőn, ugyanez a párosítás a Raspbiannal ilyen problémát nem mutat).

Egyelőre hivatalos SA-t nem láttam a dologról, mindenesetere a tegnap esti rutinfrissítés nem várt eredményt hozott, lett egy új kernel és egy ufs.ko modul a gépen, valamint a verziószám is 10.1-RELEASE-p10-re változott -p9-ről. A csomagoknál pedig Perl verzióléptetés történt, így megint több kupac csomag verziószáma lépett előre. Mondjuk megint volt egy SAT-solver hiba a pkgNG-ben, most a LibreOffice-szal nem tudott mit kezdeni, de - miután egy pkg fetch-csel meggyőződtem róla, hogy van letölthető verzió, egy pkg remove hu-libreoffice után már lefutott a frissítés, és a visszatelepítés is gond nélkül működött. Szóval mit a régi viccben a határőr jelentésében: "egy fő ki, egy fő be, az ország létszáma változatlan".

Nem azt mondom, hogy irgalmatlan mélységekbe megy bele, de azért hasznos olvasmány:
http://freebsdfoundation.blogspot.hu/2015/03/freebsd-from-trenches-usin…

https://www.freebsd.org/news/status/report-2015-01-2015-03.html

A RaspberryPi klaszter. Mondjuk arra nem találtam még magyarázatot, hogy a "mert megtehetjük" válaszon kívül vajon mire is lehet használni. Persze valószínűleg ez is olyan, mint a Minix - oktatásra akár jó is lehet - ehhez persze elsősorban a kódot kellene megnézni.

Rekordot döntöttünk, utolsó bejegyzésem január 28-án volt, azóta majdnem 4 teljes hét eltelt. Szóval akkor egy saját: IGMP-DoS, kernel panic távolról, minden FreeBSD verzió érintett. Valamint egy örökölt: BIND-DoS, de ez 10-es ágat nem érinti (mert ugye abban kidobták az alaprendszerből a BIND-ot).
(És ha már itt tartunk, ha lassan is, de a Samba-portok is frissültek.)

Gyárilag kaptam zseblámpát (ami eddig nem volt), meg olvasható színezetű billentyűzetet. Cserébe elvették a gyors ki/be kapcsoló ikonjaimat. Ez nagyjából egál. Holnaptól akkuteszt (bár az eredeti, 3 nap 16 órát nehéz lesz verni - neki magának se nagyon sikerült megközelítenie se.) Moto G2

Ha valakit esetleg érdekel, ma este 6-tól a Mandragóra kávézóban ülünk le egyet fecsegni a BSD Egyesület színeiben.

Találtam egy programot a neten, és legnagyobb meglepetésre ezt mondta a FreeBSD-s file parancs :

ABC: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.26, BuildID[sha1] XYZ, not stripped

(A fájl nevét és a checksum-ot direkt szedtem ki.) Számomra az a meglepő, hogy eddig nem találkoztam ilyennel (vagy legalábbis nem vettem észre) hogy egy binárisba beleplántálják a checksum-ját - illetve egy valamilyen checksum-ot. (Határozottan jobb ötlet, mint extended attribútumban tartani, bár gyanítom ezt könnyebb módosítani.) No most ha ráengedem az sha1 nevű programot, akkor (természetesen) mást számol ki. Jelenleg túrom a netet hogy milyen eszközökkel lehet ezt olvasni/írni/ellenőrizni. Egyelőre két RedHat-es oldalt találtam a témában, de eléggé szószátyárak. Annyit már látok, hogy vannak valamilyen eu-readelf meg eu-unstrip parancsok, amik ehhez kötődnek(*). Érdekes, de valószínűleg nem túl jól keresek, mert gugli nem igazán ad értékelhető találatot. A szoftvert a FreeBSD Linux-emulációjával akartam egy kicsit tesztelgetni de sajnos az jelenleg 2.6.18-as kernelt emulál, ez a dög meg ugye ennél újabb kernelt igényel - ezt induláskor egy morózus hibaüzenettel jelzi is :-( . A fenti RedHat-es parancsok neve alapján rápróbáltam a readelf-re, és gyakorlatilag egy perc alatt meglett az egyik infó:

$ readelf -x .note.gnu.build-id ABC

és az első 16 bájt után ott a keresett infó. No most akkor még azt kellene kideríteni, hogy pontosan mely szekciókat számítja bele, és hogy vajon mivel lehetne felülírni, csak mert writeelf-et nem találtam. Marad a binris peccselés (bpatch, vagy bvi) :-)

Megint eltelt vagy két hét, megint új FreeBSD SA-k jöttek. Ezúttal van lokálisan kihasználható memóriaszivárgás/korrupció az SCTP-ben, illetve távolról DOS-olható (kernel pánik) - szintén SCTP-beli hiba. Mind a kettő 8-astól 10-es ágig bezárólag minden támogatott verzióban létező hiba.
Lassan ott tartunk, hogy ha nem jön ki két-három hiba egy 2 hetes intervallumban, akkor kezdhetünk aggódni, mert nem végzik a "munkájukat" a fejlesztők.

FreeBSD SA. Eddig egy esett be, OpenSSL témakörében, ha jól számolom 8 CVE-numbert soroltak fel a leírásban. A frissítés a szokásos freebsd-update fetch install módon történik, reboot, vagy legalábbis az ntpd és a sendmail újraindítása erősen javasolt. Legalábbis ezek az alaprendszerben meglevő, SSL-lel fordított binárisok - ha jól láttam a listát. Nyilván aki az alaprendszerbeli OpenSSL-t használva SSL-t fordít egy alkalmazásba és statikus binárist állít elő, akkor ha az szerver, akkor újrafordítás és újraindítás szükséges. (Nem szervernél ebből elég csak a fordítás.)

Egy eredetileg docx-ben levő anyag LO-val lett kicsit módosítva (igen, tudom, ez már 3 hiba egymás után). Mentés után egy MSO-val próbáltuk nyomtatni de szerencsére még időben észrevettük, hogy valami nagyon nem OK. Jött az ODT-be mentés, majd előbb az MSO-ban, majd egy wines LO-ban történő megnyitás. Mind a kettőben érthetetlen módosulás látszott. Végül a mentés-másként DOC-ba hozta meg az eredményt, ezt már legalább a másik gépen levő LO képes volt szinte ugyanolyan kinézetűen kinyomtatni, mint ami az eredeti állapot volt.
Haverom megfogalmazása:

No ilyet eddig még nem pipáltam. Hét végén volt egy frissítés a gépen, erre ma csörög a telefon, mi az isten van a gépen, nem lehet nyomtatni - csak fehér ablak látszik, miután rá lett klattyantva a nyomtató-ikonra. No hazajövet nézem mi van, hát a normálisan futtatott (és néhány egyéb random) alkalmazásban minden szép és jó (néztem VBox-ot, Gimp-et, Evince-t, O/A-t, FF-et, pár XFCE-s alkalmazást - mind jó). Ellenben a LibreOffice menüben minden szöveg hiányzik. Ha lenyitom a menüt, és pl. billentyűzettel elkezdek jobbra-balra "rohanni", akkor időnként látszik, hogy van ot tszöveg. Sőt! Csináltam képernyőképet - és azon minden látszik. Ellenben a képernyőn nem látszik. (Anno karakteres terminálon volt un. invisible attributum - "tput invis" segítségével lehetett bekapcsolni - de grafikus felületen még nem találkoztam ilyennel.)
fc-cache -c -v nem segít. ~/.config törlése nem segít. Egyelőre még keresem a megoldást, de ez azért elég furcsa.

Nos megérkezett a napok óta susogott NTPD-vuln-nal kapcsolatos bejelentés. Akik klasszikus ISC-féle ntpd-t használnak, azoknak remote-root, meg amit akartok.
Öröm az ürümben, hogy az előző, unbound-SA kapcsán emlegetett hiba nem létezik (legalábbis az első 64-bites gépen végrehajtott frissítés szerint). Azaz a hibajavításhoz szükséges (ezen a gépen éppen) 18 db javítófájl mellé valóban villámgyorsan letöltött még 461 másikat (a lib32-t technikailag), ellenben nem akarta a frászt hozni a derék jóhiszemű rendszergazdára, és nem emlegeti a / törlését. Ráadásul sikerült is újraindulnia, szóval van itt karácsonyi áhitat, meg öröm, boldogság. (Közben a második Amd64-es gépen is lezajlott fájdalommentesen, lassan időszerű tesztelni 32-bites gépeken is.)

unbound DOS Mivel az unbound a 10-es verzióban jelent meg, természetesen csak 10-es ágban érdekes.

11 év 1 nap

Micsoda balfékség lehetett az oka, hogy 13-án regisztráltam (akkor már vagy 2 évnyi olvasgatás után)?

Beesett kettő. Vagy több.
Az első a leírás szerint csak a 10.1-et érinti (???), a második már nem ennyire válogatós. (És milyen szép, hogy a nem túl régi linuxos strings hibához hasonlóan ez is egy olyan programban: file, aminek azért első ránézésre nem kéne túl bonyolultnak lennie. Hát ez van.)
Javítás: közben jött egy bind hiba is. (De ez legalább csak a 8-as és 9-es ágnak rossz.)

Kb 2-3 hete frissült végre a FreeBSD ports-ban (és persze a bináris csomagok között is) a GNOME, és lett GNOME3. Naccerű - már annak, aki azt akarna használni. Nekem egyelőre azt jelentette, hogy az elmúlt 2 héten ömlöttek az ebből adódó csomagjavítások - és persze az újratelepítendó csomagok. (És várhatóan még van 2-3 hétig ez megszűnni nem nagyon fog, max elhalkulni.) A múlt heti frissítés se volt kevés, de a mai az minden várakozásomat alulmúlta. Egyrészt a csomagok darabszámát, másrészt sikertelenségét tekintve.

A mai frissítés lehúzott majd egy gigát. Letörölt egy kupac csomagot, telepített egy tucat újat, és frissített 10 marékkal. Node mindezt oly módon, hogy eredményül nem volt FF, LO, a fél XFCE hiányzott, és egy csomó segégprogram is ment a levesbe; ilyen senkinek nem kellő marhaságok, mint Evince, gThumb, Gimp, Brasero vagy éppen az XSane; ami külön gyönyör, hogy az általam használt levelezőt is mindenestül kikukázta :-( Szerencsére szemfülesen mikor kiírta, hogy mit tenne, akkor a törlendőeket felírtam, így viszonylag fájdalommentesen vissza tudtam rakni azokat, amikről még ma is azt képzelem, hogy esetleg szükség lenne rá. Ez mindenesetre nem tetszik. (Hozzátartozik az igazsághoz, hogy a csomagfrissítés úgy indult, hogy fél ablaknyi SAT solverre vonatkozó hibaüzenettel jelezte, hogy valami azért nem OK, így némileg gyanakodva figyeltem a működését.)

A mai este ezzel telt. Nem mondhatnám, hogy teljesen tisztában vagyok vele, kezd homályosodni a dolog (gy. k. már nem teljesen sötét a dolog). Pl. a következőt egyelőre emésztenem kell:

sudo ip link add dev veth0 type veth peer name veth1
sudo ip link list
sudo ip netns add red
sudo ip netns list
sudo ip link set dev veth1 netns red
sudo ip link list
sudo ip netns exec red ip link list

Fenti parancsokkal létrehoztam a veth0+veth1 interfészeket, a red nevű namespace-t és a veth1-t betette ebbe a namespacebe (*) (ezt ugye az utolsó két parancs mutatja is, hogy immár ott a veth1 interfész a red-ben, és eltűnt a "default" NS-ből). No azt kitaláltam magamtól, hogy ha csinálok egy másik NS-t (ugye példákban ez meg blue), akkor áttehetem red-ből blue-ba az interfészt:

sudo ip netns add blue
sudo ip netns exec red ip link set dev veth1 netns blue

Ez szuper. Meg azt is mondja a net, hogy visszarakni a "default" NS-be úgy kell, hogy beteszem az 1-es NS-be (ez valahogy az init PID-jével mutat szoros kapcsolatot(???), ez majd még később lesz remélem világos) - azaz (most már ugye blue-ban van az a nyavalyás veth1):

sudo ip netns exec blue ip link set dev veth1 netns 1
sudo ip netns exec red ip link list
sudo ip netns exec blue ip link list
sudo ip link list

Ez eddig OK. Ellenben bennem megindult a vezérhangya, és úgy döntöttem, akkor most keresztbe teszek a józan észnek. Miután megállapítottam, hogy a 0-s "NS" nem jó ehhez a visszapakoláshoz, ellenben pl. a 2 vagy az 5 látszólag ugyanolyan jól visszatette az interfészt a "default" NS-be, csináltam egy "1" nevű NS-t; ez szépen látszott az NS-ek listájában a többi mellett, és természetesen alapból benne is csak a lo interfész jelent meg - ugyanúgy, mint bármelyik - ennél épelméjűbb névvel ellátott NS-ben.

sudo ip netns add 1
sudo ip netns list
sudo ip netns exec 1 ip link list

Eddig OK, és akkor elértünk a lényeghez. Ha egy interfészt beteszek valami normális nevű NS-be (pl red), majd átpakolom az 1-be, akkor az interfész hova kerül. Hova is?

sudo ip link set dev veth1 netns red
sudo ip link list
sudo ip netns exec red ip link list
sudo ip netns exec red ip link set dev veth1 netns 1
sudo ip link list
sudo ip netns exec red ip link list
sudo ip netns exec 1 ip link list

Normális esetben vissza az eredeti NS-be. De ha van ilyen hülye nevű NS, akkor természetesen ebbe az "1" nevűbe (azaz nem vissza a "default" vagy "global" néven emlegetettbe). Szóval el azért nem veszik. Eddig jó. Akkor most tekerjünk rajta még egyet:

sudo ip netns delete 1
sudo ip netns list
sudo ip netns exec 1 ip link list
sudo ip link list

Megszűnt az "1" nevű NS, és ha már arra járt, megszüntette a hozzá tartozó interfészt is (sőt, mivel a veth interfészek párban járnak, a párját is). Juhé. Persze az lehet, hogy ez mind le van írva, meg nyilván még sok más okosság is, de ugye egy újszülöttnek minden vicc új. (Közben ha jól láttam, virtuális interfészeknél ez a természetes viselkedés. Állítólag valós interfészeknél visszamászik a "global"-ba. No majd ezt még tesztelni kell.)

A hír.