Zahy blogja

É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ó.

No comment: https://www.raspberrypi.org/blog/the-little-computer-that-could/

Részletek: http://www.freebsd.org/releases/10.3R/announce.html - meg majd nyilván Trey is ír valamit :-)

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ó.

Mai SA-ink:

sshd - xauthon keresztüli támadási lehetőség minden támogatott architektúrán és OS-verzión
sysarch - csak AMD64-es architektúrán local DoS.

Ez a hét is jól kezdődik.

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.

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

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.)

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.)

Rápillantottam a levelezésemre, és (eddig) 5^H 67 db SA esett be.

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????

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.

Isten bizony így írja ki. Aranyos.

No mit nem talál az ember. Cikksorozat arról, hogy mi módon lehet a FreeBSD ARM-kódját egy addig nem támogatott lapon használhatóvá varázsolni. Jól jöhet még. (OK, most még nem hosszú cikksorozat, de remélem hamarosan megjön a folytatása.)

Első rész, UBoot
Második rész, DTS

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 ;-)

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.

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):

Kb egy hete kerestem, mert rémlett, hogy mostanában aktuális. Megérkezett.

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.)

9.3-as, és 10.1-es Amd64-es rendszereket érintő local root. Szép.
Meg a szokásos, mindenkinek fájó ssh-bug.

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ő.

10.x-et érinti a bsdpatch-ben levő hiba.
Minden verziót érint, de csak ha 16-nál több VNET-et használ a rendszer: remote DOS.
8-as és 9-es verziók esetén BIND DOS.
És szintén minden verziót érintenek az SSH-ban levő hibák.

Az április-júniusi időszak leírása: olvasható itt. (És mit ad isten szerepel benne ez a sor: Michael Dexter showed Windows Server 2012 running inside bhyve. Van remény :-) )

(Ma már nem ez a hivatalos írásmód, én valami perverzióból mégis BHyve-nak írom.)
Ha már egyszer van egy AMD C-60-as procival szerelt netbookom, gondoltam kipróbálom a BHyve-ot. (A NAS-on kívül ez az egyetlen olyan gépem, amelyik alkalmas a futtatására.) Ráadásul a 10.2-s FreeBSD-ben végre hivatalosan is támogatott az AMD-féle AMD-V, így összesen annyi dolgom volt, hogy 10.1-ről felfrissítsem (jelenleg még 10.2-BETA2-n fut, de valószínűleg a nap végére megkapja az RC1-et is).
Azt kezdetnek el lehet mondani, hogy ha az ember nem használ semmi előtét programot, akkor a BHyve használata iszonyat macerás, ezer paramétert kell állítani, ráadásul kell egy loader amivel elindítjuk a VM-et, aztán valami másik amivel futtatjuk azt, és végül egy harmadik, amivel leállítjuk. Van ugyan egy vmrun.sh nevű script a rendszerben a példák között, de abban például a nem-FreeBSD-s VM-ek futtatása nincs támogatva. (FreeBSD-hez a gyárilag rendelkezésre álló bhyveload kell az 1. ponthoz, minden más OS-hez egy grub2-bhyve nevű csomagot kell telepíteni, de ezt a loadert egyelőre nem kezeli a script - mondjuk nem lenne kifejezetten bonyolult belehekkelni.) Én meg pont nem FreeBSD-t akartam benne megnézni, hanem mást. Megjegyzendő, hogy a Handbook kifejezetten részletesen és szájbarágósan leírja ezeket a lépéseket.
Ha jól vettem ki a dolgokat a doksikból, jelenleg 64-bites OS-ekkel lehet értelmesen kisérletezni, így én egy Ubuntu szerver LTS-t és egy CentOS7-t választottam magamnak. Nehezítő tényező, hogy jelenleg a BHyve semmiféle grafikus kártya emulációjára/szimulációjára/virtualizációjára nem képes (sőt ha jól olvastam a közeljövőben nem is várható), a VM-ben - ha megfelelően paramétereztük fel -, a klasszikus COM1/COM2 érhető el, azaz csak soros konzollal működő OS-ek jöhetnek szóba. Mondjuk ez azt is jelzi, hogy szerver virtualizációra van igazából kihegyezve. Hálózatként a host oldaláról egy tun interfészt javasolt használni, amit aztán pl. a host valós interfészével összebridzselve lehet működő hálózatot csiholni.
No a lényeg, megcsináltam a VM diszkjéhez egy 8 GB-os img-t, eldöntöttm, hogy a 4 GB memóriából 1 legyen elég a VM-nek, és elindítottam az Ubuntu telepítőjét. Egész tűrhetően működött, a leírást követve minden szépen ment egészen odáig, míg a mgpartícionált diszkre az általam kiválasztott LVM-struktúra megépítése után el nem kezdett FS-t csinálni - ebbe egy gyönyörű linuxos hibával belehalt - több oldalnyi stack-dump. Újra és újra kipróbálva (más-és más telepítési lehetőségeket kipróbálva - úgy is mint OEM install, nem OEM install), stabilan és megbízhatóan ugyanott szállt szét. Ubuntut félretettem, jött a CentOS. Annak a bootja egy hangyányival macerásabb (nekem kell a grub-ból kiválasztanom a kernel és initrd imidzseket), a telepítés elindul, a diszket ugyanúgy LVM-esítve, a szükséges (nyilván minimalista) csomagkészletet kiválasztva, a rendszer szépen feltelepül. Ugyan nyekereg útközben, hogy a hálózat szerinte off-ban van, de ennek ellenére amikor a kész rendszert indítottam, szépen működött. Kapott DHCP-n címet, és annyira ment, hogy az első körben megejtett yum update - ami pedig lehúzott egy vagon frissítést -, minden további nélkül lefutott.
Miután volt sikerélmény, újra nekiugrottam az Ubuntunak - pont ugyanazzal az eredménnyel. OK, ugorjunk, letöltöttem egy Debian 8.1-es telepítőt, ahhoz is elkészítettem az "infrastruktúrát" és hajrá. És mondhat akárki akármit, az Ubuntu csak egy felpimpelt Debian - pont ugyanott, pont ugyanúgy halt meg. Ezt akkor egyelőre félreteszem, elképzelhető, hogy valami Slackware-t még kipróbálok, esetleg LVM nélküli módban az Ubuntut. Az a legfurcsább, hogy találtam egy eléggé durva cucost a nete, amiben pont ugyanígy FreeBSD, meg BHyve és Ubuntu LTS játszik, a leglényegesebb különbség, hogy ő ZFS fölötti ZVOL-t használ VM-diszknek, nem pedig fájl.img-t. A cikk egyébként a HardenedBSD-s Shawn Webb leírása arról, hogy egy, a FreeBSD által nem támogatott Wifit hogyan használ: mivel Linuxhoz van driver, ezért FreeBSD alatt van egy BHyve VM-ben egy Ubuntu, az megkapja az egész kártyát szőröstül-bőröstül (hogy ezt hogy kell, én doksiban még nem láttam máshol leírva, csak hivatkoznak a lehetőségre), és a VM-ben NAT-ol egyet a FreeBSD-nek - így máris lehet a host-ról is Wifizni. Perverz.
Még egy apróság. A kezdetben a netbookot kábeleztem. Aztán megunván a kényelmetlen drótkígyót, áttértem Wifire - ez meg azért volt kényelmetlen, mert a bridge konfigot is módosítani kellett - ezért aztán gondoltam egy merészet, és az ezer éve leírt módon a wifit és az ethernetet összekapcsoltam egy lagg interfésszé, és még egyszer utoljára módosítottam a konfigon. És az már látszik, hogy valahol valami nem kerek, mert az a tény, hogy az eth+wlan -> lagg interfészt egy bridge-be fogom a tun-nal, egyelőre nem végigtesztelt módon ugyan, de néha azt eredményezte, hogy beállt a hálózat, és bit se ki, se be. Majd még próbálkozom vele, hátha csak az interfészek felkonfigurálási sorrendje kavar, de mivel ha leáll a BHyve-os VM, akkor megjavul, lehetnek itt rejtettebb hibák.
(Egyszer ki akarok benne próbálni valamilyen Windows-t is, bár erre vonatkozó kérdésemre azóta se kaptam választ a lusta haveromtól, hogy vajon van-e olyan win szerver verzió, amelyik tényleg el tud működni soros konzollal, és mi az és honnan lehet pl. teszthez legálisan hozzájutni, mert venni aztán nem fogok, de ehhez lopni kissé gáz.)

Épp be akartam írni, hogy és meg is jött az első csúszás, de gondoltam előtte azért ránzek az oldalra. (Az a helyzet, hogy majdnem éjfélig vártam, mert frissíteni akartam az egyik gépemet. Tudom, másik időzóna.) A lényeg:
https://lists.freebsd.org/pipermail/freebsd-stable/2015-July/082903.html