nice's blog

Ezt a "Tesla gömböt" vettük a kisebbik fiamnak: https://www.youtube.com/watch?v=NCeBF6-qTQk. Amit eddig meg tudtam róla állapítani, az az, hogy belülről kifelé haladva egy elektródából, egy azt körülvevő kis üveggömbből, egy adag nemesgázból (főleg neon) és egy külső üvegburokból áll. Az elektróda kicsit úgy viselkedik, mint egy fél kondenzátor, amelynek a külvilág a másik fele. Az elektródát egy kb. 30-40kHz-es váltóáram hol pozitív, hol negatív töltéssel ruházza fel. A töltés elég nagy ahhoz, hogy az elektróda közvetlen(?) környezetében több ezer voltos potenciálkülönbséget hozzon létre. A frekvencia alapján ugyan nem ionizáló sugárzást bocsát ki a szerkezet, de amint látszik, a nagy feszültség mégis ionizálja a gömbbe zárt nemesgázt. Először nem értettem, hogy ha a gáz atomjai kívülről nézve nem rendelkeznek elektromos töltéssel, akkor hogy hat rájuk az elektromos mező? Nos, a helyzet az, hogy mindennapi természetes körülmények között is lépten-nyomon történnek ionizációs események, pl. a kozmikus háttérsugárzás miatt, szóval a gömbben levő gázban is előfordulnak szabad elektronok és pozitív ionok. Ezeket már nagy sebességre tudja gyorsítani az elektromos mező, és további semleges atomoknak ütközve ionizálják azokat, így beindul az elektronlavina nevű láncreakció. A kérdésem az, hogy vajon nem indíthat-e be az emberi testen belül is hasonló ionizációs folyamatot ez a plazmagömb, és ha igen, az nem rákkeltő-e? Úgy tudom az ilyen plazmalámpák akár 1,2m-ről is az EU által meghatározott egészségügyi határértéknél erősebb nem ionizáló elektromágneses sugárzást bocsátanak ki (figyelemre méltó, hogy egyáltalán meg van határozva ilyen egészségügyi határérték), és képesek kitéríteni egy Geiger-Müller számláló mutatóját. A gömböt megérintve az érezhető melegedést okoz a kézben. Mit gondoltok, mennyire lehet veszélyes?

A munkahelyemen van néhány TechSon TC-DVR LN4016, illetve TechSon TC-DVR LN4008 típusú biztonsági kamerarendszer. Ezek úgy működnek, hogy nyolc vagy tizenhat analóg videokamera jelét fogadják koaxkábeleken keresztül, és beépített HDD-re mentik a videót. Jellemzően csak akkor rögzítik a filmet, ha azon valami mozgás látható. Beállítható, hogy a mozgás kezdete előtt hány másodperccel induljon a felvétel, és hogy utána mennyivel érjen véget.

Az volt a feladatom, hogy azon kamerák képeiről, amelyek a központi egységgel közös helyiségben vannak, készüljön távoli mentés is. A mentés nyilván csak akkor jó, ha a kamerából jövő képet a lehető legkisebb késleltetéssel kiírjuk a távoli HDD-re. Maga az eszköz nem kezel semmilyen távoli tárhelyet, és a forgalmazó nem tudott olyan szoftverről, ami a kamerák képének valós időben történő lementését lehetővé tenné, és én sem találtam ilyet. Azóta megtudtam, hogy Androidra létezik ilyen, de akkor már késő volt, meg amúgy sem biztos, hogy megfelelő lenne.

Az úgy kezdődött, hogy a feleségem kapott karácsonyra pár DVD-t, lejátszónk pedig nincs, de mégis inkább szerettük volna tévén megnézni, mint gépen. Nemrég kaptam egy 64GB-os pendrive-ot, és megörültem neki, hogy a finnyás tévénk hajlandó volt beolvasni. Nincs semmiféle torrent accountom, így gondoltam, mi lenne, ha életemben először olyan formátumra hoznék pár DVD-t (köztük a feleségem új filmjeit), amit az ilyen tekintetben is válogatós tévénk le tudna játszani?

Pár hónapja ismerkedtem meg az ffmpeg-gel, amikor azt a feladatot kaptam, hogy a semmiféle ezirányú szoftver- és hardvertámogatással nem rendelkező analóg kamerákra épülő biztonsági rendszerünk néhány steamjét távoli meghajtóra mentsem. A kizárólag IE alatt működő ActiveX alapú kamerakliensek kommunikációjának wireshark-os elemzése után ffmpeg-ből, ffplay-ből,tcpdump-ból és bbe-ből összegányoltam egy olyan kis shell scriptet, ami képes a kameraképek megjelenítésére és folyamatos rögzítésére. Ezen tapasztalatok nyomán úgy gondoltam, hogy ha az ffmpeg nem lesz képes kiripelni a DVD-ket, akkor semmi. Egy kis guglizás után az alábbi módszerhez folyamodtam:

http://mywiki.wooledge.org/BashFAQ/031

Szóval minden úgy kezdődött, hogy kaptam egy feladatot:

http://hup.hu/node/137107

Háromféle digitális aláírás került a látókörömbe: OpenPGP, S/MIME és DKIM.

Ezek közül csak az első kettő minősül end-to-end digitális aláírásnak, vagyis csak erre a kettőre igaz, hogy az aláírást a levél feladójának számítógépe, az aláírás ellenőrzését pedig a címzett számítógépe végzi. A DKIM esetében a titkos kulcs a feladó tartomány kimenő levélszerverein van (azokon, amelyekre a tartomány SPF rekordjai mutatnak), itt történik az aláírás is. Az aláírás ellenőrzését a címzett tartomány leveleit fogadó szerverek (amelyekre a tartomány MX rekordjai mutatnak) végzik. Éppen ezért a DKIM nem end-to-end aláírás, már csak azért sem, mert nem felhasználónként, hanem tartományonként van egy-egy külön titkos-nyilvános kulcspár. A titkos kulcsot természetesen nem adja ki az SMTP szerver, a nyilvános kulcsot viszont egy TXT típusú DNS bejegyzésben teszi közzé a tartomány adminisztrátora. A levelet befogadó SMTP szerver egy Authentication-Results nevű mail headert hoz létre, amiben feltünteti, hogy milyen eredménnyel járt a levél DKIM aláírásának (és egyéb authentikációs jellemzők) ellenőrzése. A küldő szerver a DKIM aláírásí művelet paramétereit, és magát az aláírást a DKIM-Signature nevű mail headerben helyezi el. A DKIM nem csak abban különbözik a másik két digitális aláírási szabványtól, hogy nem biztosít end-to-end védelmet, hanem abban is, hogy nem a levél törzsében, hanem a fejlécében található, és nem csak a levél törzsét, hanem néhány fejlécmezőt (pl. from, to, subject, date, message-id, user-agent, stb.) is aláír. Ez alapján azt is gondolhatnánk, hogy nagyobb biztonságot, ad, de egyrészt nem tudja lekezelni a levél törzsének semmilyen változását, ami a levél befogadása után történik, másrészt nem találtam olyan levelezőklienst, amely képes lenne a DKIM aláírás ellenőrzésére. Csak a levél forrásának manuális ellenőrzésére (pl. az Authentication-Results mező átnézésére) hagyatkozhatunk. Ha azonban ezt kiegészítjük azzal, hogy a Google levelezőrendszere semmilyen módon nem teszi lehetővé, hogy a levél feladója meghamisítsa a saját email címét, akkor már egy viszonylag elfogadható biztonsági megoldást kapunk.

A hétvégén ellátogattam az Árok Party nevű rendezvényre. Nem a saját ötletem volt, egy munkatársam találta ki, hogy elmenjünk rá, sőt azt is, hogy ezt csak úgy érdemes megtennünk, ha indulunk egy pályamunkával valamilyen compo kategóriában. Mivel kb. 20 évvel ezelőtt írtam pár zenét C64-re, kézenfekvő választásnak tűnt, hogy frissítsem fel az ilyen irányú képességeimet. Ez nehezebben ment, mint gondoltam: Úgy éreztem, szinte mindenre emlékszem, de rá kellett jönnöm, hogy az amúgy sem túl hosszú előző korszakom során felszedett tárgyi tudás nagy része megkopott. SID chip dokumentációk olvasgatásával kezdtem, aztán a korábbi korszakomban is használt Music Assembler feltérképezésével folytattam, amit szegényes help és nem létező dokumentáció nehezített meg. Beletelt bár napba, mire megértettem, hogyan kell használni. Külön nehézség volt a CCS64 emulátor billentyűzetének tökéletes belövése, és a Music Assemblerrel készített zene RUN paranccsal indítható programfájllá alakításának elsajátítása is, mivel ilyet korábban sohasem csináltam. Akár meg is könnyíthette volna a dolgomat, hogy három hetes szabadságon voltam, de a feleségem dolgozott közben, ezért én vigyáztam a három gyerekre, és csak éjszakánként tudtam készülni a partyra. Mire az említett technikai ismereteket sikerült összeszednem, már csak pár napom maradt arra, hogy közel húsz év teljes kihagyás után a semmiből összedobjak valami értékelhető zenét. Újabb alvásmegvonási menetek során sikerrel jártam, és elmondhatom, hogy nem vallottam szégyent, hiszen sikerült dobogóra állnom a SID zene kategóriában! Igaz, ami igaz, némiképp csökkenti a megszerzett bronzérem értékét, hogy mindössze hárman indultunk a versenyen. Más szóval nincs mit szépíteni, tökutolsó lettem. Nade majd jövőre!

Bizony, az OpenJDK alapú IcedTea Java implementációval nem fut rendesen az abevjava, ezért letöltöttem az Oracle JDK (jdk-7u4-linux-x64.rpm) csomagját innen: http://www.oracle.com/technetwork/java/javase/downloads/index.html

Találtam egy érdekes doksit a telepítésről itt: http://www.freetechie.com/blog/installing-oracle-sun-java-1-7u1-opensus…

A doksi elolvasása után úgy döntöttem, megpróbálom egy kicsit mélyebben megérteni az update-alternatives rendszer működését. Az alternatives rendszer célja, hogy kezelje azt a szituációt, amikor egy adott feladat ellátására két vagy több különböző programcsomag van telepítve a gépre. Tipikusan ilyen helyzet az, amikor két java csomagunk van: A $PATH változó által lefedett területen található java virtuális gép (/usr/bin/java) nem bináris, csak symlink, amely a /etc/alternatives/java elérési útra mutat. A /etc/alternatives könyvtár az alternatives rendszer lelke. Ha belenézünk, láthatjuk, hogy csak symlinkek találhatók benne. Ezek a symlinkek mutatnak a kiszemelt szoftververzió által biztosított célfájlra, más szóval megválaszthatjuk, hogy az /etc/alternatives/java symlink a két telepített java bináris melyikére mutasson. Az alternatives rendszer kétszintű symlinkláncolata lehetővé teszi hát, hogy az elérési útban levő symlinket végig érintetlenül hagyjuk, amíg van programcsomag, ami ellátja az adott funkciót, és csak a /etc/alternatives könyvtáron belüli symlinkeket kell manipulálnunk, vagyis az alternatives rendszer műveletei a /etc könyvtárra korlátozódnak, ami tiszta, jól átlátható helyzetet teremt.

A sorozat részei: 1 2 3 4

A sorozat befejező része rövidebb lesz, mint a többi: Az Udev és D-Bus rendszereknél fennállt az a probléma, hogy nem találtam hozzájuk átfogó, jól érthető doksit, sőt néhány részlet nincs is ledokumentálva. Magamnak kellett összeszednem, sőt részben kinyomoznom az információmorzsákat, ezért fogtam bele a sorozat megírásába. A systemd feladatköre hagyományos UNIX ismeretek birtokában sokkal inkább megfoghatónak és jobban körülhatároltnak tűnik, mint a régi UNIX-okon ismeretlen - és rendkívül szerteágazó - funkciót betöltő Udev/D-Bus rendszeré, és mivel a fejlesztése viszonylag korai fázisban van és még eléggé centralizált, létezik hozzá néhány olyan minden vonatkozását lefedő dokumentáció, amelyeket némi UNIX, Linux-kernel és Udev/D-Bus ismeret birtokában átolvasva eléggé pontos képet kapunk arról, hogy mi is a systemd. A systemd megismeréséhez jól kiindulópont a szerzőjének, Lennart Poetteringnek a youtube-on megtekinthető "systemd, beyond init" című előadása, és "Rethinking PID 1" című tanulmánya. Ezekből megtudhatunk eleget ahhoz, hogy értelmezni tudjuk a dokumentációt, és a man oldalak segítségével bele is foghatunk a systemd menedzselésébe.

Kezdetben azt hittem, a systemd csak a System V init szkriptek indítását és leállítását vezérlő /etc/init.d/rc szkriptet hivatott leváltani, de kiderült, az egész 1-es PID, azaz a /sbin/init teljes funkcionalitását átveszi, sőt a fejlesztői a jövőben nem csak a rendszer munkamenetét, hanem felhasználói session-öket is kivánnak vezérelni vele, azaz a gnome-session, kdeinit és hasonló démon processzek kiváltását is tervbe vették. Ez utóbbi lépés eredményeképpen a systemd-ből a dbus-daemonhoz hasonlóan több példány futna: egy rendszerpéldány, és felhasználói munkamenetenként egy-egy további session-példány.

A sorozat részei: 1 2 3 4

Az udev rendszer alapvető feladata a UNIX eszközfájlok kezelése. (Ld. A Linux fájlok hét típusa.) A korai Linux-disztribúcióknál az eszközfájlok létrehozása nem automatizált mechanizmussal történt, hanem általában legkésőbb a telepítés során, egyrészt a telepítőkészletről történő átmásolással, részben hardverdetektálás eredményeképpen. Ezeken a rendszereken az eszközfájlok a mai, memóriabeli fájlrendszeres megoldásokkal ellentétben még közönséges merevlemezen levő fájlrendszeren tárolódtak, így a rendszergazdák által kézileg létrehozott eszközfájlokat is beleértve mind túlélték a rendszer újraindítását.

A sorozat részei: 1 2 3 4

A D-Buson keresztül elérhető fontosabb szolgáltatások

A rendszeren futó különböző D-Bus példányok (pl. session D-Bus) elsődleges feladata, hogy keretet biztosítson különböző szoftverkomponensek együttműködéséhez. A rendszer D-Busról emellett azonban elmondható, hogy - mivel privilegizált és felhasználói szoftverkomponensek között közvetít, ezáltal bizonyos SETUID programfájlok kiváltására és a legkevesebb privilégium elvének megközelítésére alkalmas - a modern UNIX rendszerek biztonsági modelljének fontos építőkövévé kezd válni. A rendszer D-Bushoz csatlakozó, és azon jól ismert (well known) nevek alatt szolgáltatásokat biztosító démonokat ebben a blogbejegyzésben szolgáltató ágensnek nevezem. A szolgáltató ágensek a felhasználó - általában rendszergazdai jog híján közvetlenül el nem végezhető - utasításait hajtják végre, valamint multicast szórással az általuk felügyelt alrendszerek - többnyire végső soron a kernelből érkező - eseményeit is továbbítják a felhasználói felület vagy más érdeklődő szoftverkomponens felé. A rendszer D-Busunkon jelen levő szolgáltató ágensek (és jól ismert névvel nem rendelkező egyéb ügyfelek) listáját megkaphatjuk a következő parancs kiadásával:
dbus-send --system --dest=org.freedesktop.DBus --print-reply --type=method_call /org/freedesktop/DBus org.freedesktop.DBus.ListNames

Kedves testvéreim!

Rohanó világunkban immáron sajnos a UNIX is eltávolodott az évszázados, biztonságot adó szokásoktól, hagyományoktól. A szülők és testvérek tisztelete, az egyszerűség nem érték többé. Új hóbortok ütik fel a fejüket, mint például a címben is szereplő hivalkodó, minden földi jóval kecsegtető gonosz bálvány. Pedig régen minden jobb volt! Szabaduljunk meg hát az evilági kötelékektől, és fordítsunk hátat a megannyi életet tönkretevő káros szenvedélyeknek, mint a modern Linux desktop. Hányjunk fittyet a D-Busra és a többi kísértőre.