Zahy blogja

FreeBSD 10.3-p2 - OpenSSL SA

Hogy szalad az idő, eltelt megint 1-2 év a legutolsó hibajegy óta (nem) - most megint az OpenSSL-ben van gond (*). Részletek itt.
Az már csak hab a tortán, hogy hasonlóan az előző hibajegyhez, most sem működik hibátlanul a freebsd-update fetch install, most a következővel örvendezteti meg az emberek egy részét:
[code]
# freebsd-version
10.3-RELEASE-p1
# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 10.3-RELEASE from update6.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

FreeBSD 10.3-p1

No ma kijött egy jó kis NTP-bugreport. Alig 9 CVE azonosítót sorolnak fel a szokatlanul hosszú SA-ban. És ami külön öröm, eddig 4 gépből (2 VM-ben, 2 fizikai vas; 2 i386-os, 2 Amd64-es) 4 gépen nem megy a freebsd-update. A hibaüzenet:


The update metadata is correctly signed, but
failed an integrity check.
Cowardly refusing to proceed any further.

Hiba jelezve, többen megerősítették, (néhányan nem publikusba, csak nekem, nem is értem) egyelőre össz annyi a "hivatalos" válasz, hogy nyomozzák. (Ami külön vicces, az erről szóló levelet a saját címemre is iszonyat későn kaptam meg, de a levlistán még most sem látom.)

Ujjgyakorlat: Üres sor ellenőrzése kizárólag shell belső parancsokkal

Én napi feladataimhoz még ma is gyakran közönséges shell scriptet használok. Ilyenkor rendszeresen szükséges ellenőrizni, hogy valamilyen szöveges adatban van-e üres sor. Erre egy egyszerű grep pont megfelelő. Rákeresünk az adatban az üres sort jelentő regexp-re ( ^$ ), és a státusz kód jelzi.

Természetesen ezzel is van baj: létezik még a világban olyan rendszer, amelyiknél a grep nem ismeri a -q opciót, így ha hordozható kódot kell írni, akkor a triviális megoldást bonyolítani kell, és nem a grep-pel, hanem a shell-lel kell eldobatni az esetlegesen megjelenő fölösleges kimenetet. Azaz nem így:


if echo "$VAR" | grep -q '^$' ; then
# van üres sor

hanem így:


if echo "$VAR" | grep '^$' > /dev/null ; then
# van üres sor

A napokban viszont az egyik megoldandó probléma kapcsán elégedetlen voltam a kapott teljesítménnyel, így felmerült bennem, hogy ha a tízezres nagyságrendű fölösleges processz létrehozása helyett (merthogy egy ekkora számban lefutó ciklusban történt mindez) a shell belső parancsaival csinálnám az üres sor ellenőrzését, nyilván gyorsabb lenne a dolog. Viszonylag hamar beugrott, hogy melyek azok a shell konstrukciók, amelyek alkalmasak lehetnek, de valahogy nem nagyon sikerült a működő megvalósítást megtalálni. (Mindezt nehezítette az, hogy mint általában ilyen agymenésekkor mindig, a feladatot úgy szerettem volna megoldani, hogy ne használjak ki valami olyasmit, amit kizárólag a bash ismer - nálam az alap, hogy lehetőség szerint a kereskedelmi UNIX-okban kicsit sűrűbben előforduló Korn-shellben is működő módszert találjak.) Tegnap éjszaka aztán kigyököltem a megoldásokat. A könnyű tesztelés és olvashatóság érdekében shell-függvényt csináltam. Annak neve lehet valami értelmes, kódja lehet a francban a valódi futáshoz képest (tehát nem zavarja az olvashatóságot) - sőt az autoloading function nevű játékkal totál el is lehet rejteni :-) ; szóval az úgy jó.

FreeBSD-10.3-RELEASE

Hivalatos bejegyzést még nem láttam, de összesen 4 gépet megfrissítettem (i386 és Amd64-es is volt közte). Nekem ezt tojta a nyuszi locsolás helyett ;-) Egyelőre annyit látok, hogy megy. AZtán amikor megjelenik a bejelentés is, akkor majd megtudom, hogy ez most nekem miért jó.

Motorola G2 + Marshmallow

Várom már egy ideje, hogy az 5.0.2 után végre ide is elérjen az 5.1. Nem tette. Aztán legnagyobb meglepetésemre péntek este hazafele menet bedobott egy frissítési figyelmeztetést, amelynek leírásában szerepelt a Marshmellow szócska. Így aztán mikor hazaértem, bekapcsoltam a wifit, rádugtam a töltőre és elindítottam. Maga a frissítés gyorsan lefutott, de az alkalmazások optimalizációjával jócskán elszöszmötölt. Mindenesetre amikor végzett, akkor már 6-os Android indult. OK, nem annyira friss, mint Trey telóján, mert csak 2016. január 1-i a security level, de ezzel együtt is pozitívumnak tekintem; állítólag pl. a Samu S5-je, ami dupla ennyi pénz (mostani áron több is mint 2x annyi), a mai napig nem kapta meg - pedig az ugye egy felsőkategóriás telefon volt a megjelenésekor, ez pedig már akkor is éppen csak a belépőszint fölötti. (Az persze érdekel, hogy befutnak-e az egyéb biztonsági javítások.) Mindenesetre annyit láttam, hogy azok a hibák amikkel én eddig találkoztam, egy kivételtől eltekintve megszűntek. (Ami maradt: változatlanul időnként feldobja a hibaablakot az Exchange services elhalálozásáról.) Valamint nagyon szépen bővült a Motorola-logó, amit bootkor rak ki. Ezt mondjuk túl sűrűn nem nézi az ember :-) Már csak az van hátra a belakásból, hogy szépen elkezdjem a szoftverek - szerintem - fölösleges jogosultságait megnyirbálni.

A várva várt SA-k

Hét végén hasraütésszerűen futtattam egy freebsd-update -et, és némi meglepetésemre jöttek javítások. Mostanra a biztonsági figyelmeztetők is megérkeztek hozzá:

OpenSSL és BIND

FreeBSD 10.3-BETA3

Megjelent. Igazság szerint a kiadási naptárban már tegnap látszott 26-i dátummal, ezért én este meg is frissítettem a netbookot, de a hivatalos kiadási megjegyzésre egy kicsit várni kellett. A frissítés zökkenőmentes és viszonylag fürge volt, igaz, egyelőre nem teszteltem mélyebben a rendszert. Érdekes, hogy a módosítások listájában összesen egyetlen javítás kapcsán emlegettek PVS-Studio segítségével felfedett hibát. (Ami nen zárja ki, hogy többnél az legyen az ok.)

RPi2 és a hardveresen gyorsított VideoCore

A tegnapi délután/este során megejtettem a szükséges frissítést. Ez eltartott egy jó darabig, ráadásul van egy halom olyan csomagom, ami számomra értelmezhetetlen, hogy minek van fenn gyárilag. Miután megállapítottam, hogy a grafikus raspi-configban nem találom a GPU-gyorsítás bekapcsolását (nincs kizárva, hogy ott van, de én tényleg nem láttam), maradt a karakteres verzió és némi teszteknek vetettem alá az új, hardveres gyorsításos RPi2-t. A GPU-nak már a korábbiakban 128MB memóriát adtam, mert különben a 1080-as filmeket nem vitte az omxplayer. (Ezt amúgy nem is teszteltem, hisz eléggé egyértelműen le van írva, hogy jelenleg a 3D-gyorsítás és a grafikus rásegítéses filmnézés jelenleg egymást kizáró opciók.)

RPi2 és HW-es GLX-gyorsítás

Most épp az az ötletem támadt, hogy az RPi2-n megnézem azokat a bugyuta játékokat, amiket a Raspbian biztosít. Nyilván már megint én nem találok valami triviálisat, de hogy a csomagban fent levő Emilia Pinball-t még 640x480-ban se lehessen élvezhetően lejátszani, az szerintem nagyon gáz. Először mindenféle GLX-hibákra panaszkodott, aztán némi telepítgetés után az már nem jött elő, de a szoftveres rendering és az adott játékhoz használt SDL együttese gyakorlatilag élvezhetetlenné tette a dolgot.Az ellőtt golyó kb 3x jelent meg a képernyőn, de annak se nagyon látszott a hatása, hogy mozgattam az asztalt, vagy akár az "ütőket". Grrr. Kutattam, de csak mindenféle olyan leírásokat találtam, hogy kézzel lehet fordítani kernelt, meg X-szervert, meg meg meg. Hogy lesz ebből játékgép????

BHyve + Slackware64 [megoldva]

A korábbi tesztek ( 1. és 2. ) után megint elővettem a netbookot és a bhyve-ot. Miután az első menetben a 7-es CentOS majd a következő körben a 14.04-es Ubuntu és a 8-as Debian is működőképes állapotba került, tényleg a Slackware-t vettem elő. (Mert csak, bár a Slackware-es csomagkezelős sorozat is segített egy kicsit.)

Tapasztalatok.

1. Noha az előzőeket mind 4 procis virtualizációval játszottam végig, ez a Slackware-nél nem ment. Stabilan és megbízhatóan elpanic-olt már az ISO-ról történő boot közben. Viszont ha 1 processzort kapott, akkor ezt az akadályt némileg könnyebben vette.

FreeBSD Bluetooth audio

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203745

Örömmel jelentem, hogy a totál noname kínai BT-s "fülesem" a fenti pecsben található leírás szerint szépen összepárzott a laptop beépített BT-vevőjével, és az ott leírt módon a virtual_oss nevű "izé" segítségével most hallgatom rajta a harmadik zenedarabot. Tekintve hogy ezen a gépen épp se wav, se mp3 fájel nincs, ellenben van MP4Audio, ezért nem a pédában szereplő play/sox segítségével, hanem az mplayerrel (és mpv-vel), de azt hiszem ez a legkevésbé érdekes a dologban. Ha így haladunk, lassan mégis csak eljöve a FreeBSD desktop éve ;-)

Linux, USB-SATA, SSD. Rossz vicc.

Van egy USB-SATA átalakítóm. Szépen működik. Tegnap egy pár percre kölcsönkért SSD-t rádugtam a laptopomra vele, de a gép semmilyen módon nem akarta az igazat. dmesg szerint a rendszer észrevette, hogy van ott valami periféria, meg is mondta, h scsi7, scsi8, stb eszköz, de már sd* eszköz nem lett belőle, már /dev alatt, meg /sys alatt semmi nyoma nem volt, lsblk nem látta, stb. Nem értettem, mert úgy rémlett, a saját SSD-met ezen a gépen ugyanígy már használtam. No ma behoztam azt a diszket, és ugyanúgy viselkedett. Majd némi szenvedés után az a furcsa helyzet állt elő, hogy ha elindítottam a VirtualBoxban egy VM-et, akkor annak a virtuális gépnek oda tudtam adni az USB eszközt (és mellesleg mind egy VM-ben futó Ubuntu, mind VM-beli FreeBSD ugyanúgy hibásan látta az eszközt, így a VM-ben sem lehetett csatolni). Majd ezek után a meglepetés: abban a pillanatban, hogy a VBox-ban elengedtem az USB-s eszközt, a hostban immár megjelent a diszk. Az, ami előtte nem volt látható. Vajon mi a franc maradhat ki a diszk gépre dugása során, amit a VBox valahogy kierőszakol, és vajon hogy tudnám VBox nélkül kierőszakolni ugyanazt én? Hm.

btrfs resize error

A hét végén nézegettem egy kicsit a btrfs-t. Azt értem, hogy nagyméretű diszkrendszerekhez jó, de örültem volna, ha valahol megtalálom, hogy mi a francért nem működik az átméretezés úgy, ahogy én szeretném. A felállás. Csináltam egy 192MB-os virtuális diszket (OK, eredetileg 32 illetve 64 MB-ossal kezdtem, én ugyanis a tesztjeimhez ilyen kis apró vackokat használok):

BHyve megint

Korábban már játszadoztam vele. Ma hajnalban úgy döntöttem újra megpróbálom az Ubuntut életrelehelni. A gép közben frissült FreeBSD 10.2-p5-re, ráadásul 14.04.3-s imidzset is töltöttem az előzőleg használt 2-s helyére (nyilván most is szervert, és most is 64 biteset). Tudom, hogy a kutyát se érdekli, de örömmel vettem tudomásul, hogy valamelyik lépésnek köszönhetően nem halt bele a fájlrendszer létrehozásba. Sőt. Feltelepült. Valamint bebootolni is sikerült. Most nem küzdöttem a hálózattal, majd a legközelebbi alkalommal azt is megnézem jobban. Mindenesetre ez is megy. (Változatlanul várom a tippeket a VGA-nélküli, csak soros porttal működő Windows verzióhoz.)

2 új SA

bsdpatch (10.x) és routed (9.x és 10.x). Külön aranyos, hogy a patch kapcsán leírják, hogy ahol nem nem használnak peccset, az a rendszer nincs veszélyben. Javítás: peccseljük meg a rendszert. A routed-es hiba kicsit kellemetlenebb, de ma már asszem a routed használata kevéssé jellemző.