udev & D-Bus & HAL helyett DeviceKit helyett udisks+UPower - 1. rész: D-Bus

 ( nice | 2012. március 2., péntek - 16:58 )

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.

Akit ezzel nem sikerült eltántorítanom, az viszont nyugodtan továbbolvashatja. Arról van ugyanis szó, hogy a címben szereplő téma már régóta érdekelt, de nem volt időm foglalkozni vele. Az utóbbi egy-két hétben azonban rászántam magam, és nem kevés alvásmegvonás árán sikerült megértenem, miről is van itt nagyba' (nem kicsibe, nagyba') szó. Egy rövid sorozat keretében megpróbálom tömören kifejteni. A sorozat minden részét úgy javaslom elolvasni, hogy először fussuk át a szöveget a hivatkozások megnyitása nélkül, és ha ez alapján sikerült nagyjából megérteni, miről van szó, és eldönteni, hogy érdemes-e többet foglalkozni a témával, csak akkor menjünk végig a hivatkozásokon, amelyekből - reményeim szerint - alaposan megismerhetjük a bejegyzés tárgyát.

A D-Bus és kapcsolódó technológiáinak tanulmányozása közben először is szomorúan szembesültem vele, hogy már nincs is HAL, hanem DeviceKit van helyette. Mire megbékéltem volna az elkeserítő ténnyel, kiderült, hogy DeviceKit sincs már, hanem udisks és UPower van helyette. A legnagyobb sokk azonban akkor ért, amikor megtudtam, hogy az udev démon immár nem hoz létre eszközfájlokat, sőt át sem nevezheti azokat. Legutóbb pedig az sokkolt, hogy az udisks és az UPower mellett tovább bővült a HAL-t kiváltó szoftverek köre.

Rántsuk hát le a leplet a tényekről. Legyen szó először a rendszer gerincéről, a D-Bus interprocessz-kommunikációs eszközről:

A sorozat részei: 1 2 3 4

1. D-Bus

Sokan hallottak már a D-Bus-ról, de valószínűleg kevesen tudják, mi is az pontosan. Nem csoda, hiszen általában feltűnés nélkül teszi a dolgát. Mivel minden modern Linux disztribúcióban jelen van, sőt mára már a Linux, és más UNIX jellegű, sőt nem UNIX rendszerek (különösen a desktopon futó változatok) egyik legalapvetőbb technológiája, és az ismerete a rendszergazdák számára - ha más hasznát nem is látjuk ;-) - lehetővé tesz néhány olyan rendkívül hasznos trükköt, amire nem is gondolnánk, az alkalmazásfejlesztők számára pedig egyszerűen KÖTELEZŐ az ismerete, úgy gondoltam, vázlatosan közzéteszem azt, amit sikerült megtudnom róla. Miért ilyen fontos a D-Bus? Mit csinál? D-Bus alapú technológiát teszik lehetővé többek között azt, hogy közönséges felhasználóként a kedvenc asztali környezetünkbe bejelentkezve olyan feladatokat hajtsunk végre, amiket a kernel csak a root felasználónak engedne meg. Felmountolunk egy USB meghajtót? NetworkManagerrel konfiguráljuk a WiFi-t, a 3G internetet vagy bármilyen más hálózati csatolót, és kapcsolódunk egy hálózathoz? Figyelmeztetést kapunk a rendszertől, hogy új szoftverfrissítések érkeztek, majd telepítjük ezeket? Hibernáljuk, felfüggesztjük a gépet? A legtöbb esetben ma már D-Bus alapú technológiát használunk ilyen esetben. A D-Bus lehetővé teszi, hogy egymástól függetlenül, jellemzően más UID alatt indított szoftverösszetevők szabványos és biztonságos módon igénybe vegyék egymás szolgáltatásait. Ha majd lesz (vagy már van?) a Linuxhoz professzionális desktop tűzfal vagy vírusirtó megoldás, a dolgok jelenlegi állasa szerint annak is D-Bus technológiát kell használnia! A D-Bus technológia legfontosabb ihletője a KDE DCOP rendszere volt, és mára a D-Bus leváltotta a DCOP-ot, csakúgy, mint a Gnome Bonobo technológiáját.

A D-Bus FAQ szerint D-Bus egy interprocessz-kommunikációs protokoll, és annak referenciamegvalósítása. Ezen referenciamegvalósítás egyik összetevője, a libdbus könyvtár a D-Bus szabványnak megfelelő kommunikáció megvalósítását segíti. Egy másik összetevő, a dbus-daemon a D-Bus üzenetek routolásáért, szórásáért felelős. A dbus-daemon nélkül is folytathat egymással két partner D-Bus kommunikációt, de nem jellemző ez az elrendezés. A D-Bus protokoll gyakorlatilag komponens alapú szolgáltatások megvalósítására és azok felhasználására szolgál. A D-Bus kommunikáció bármely résztvevője lehet egyszerre "szerver" (aki a szoftverkomponenseket/objektumokat rendelkezésre bocsátja) és "kliens" (aki a rendelkezésre bocsátott szolgáltatásokat igénybe veszi) is, de nem igazán jellemző mindkét szerep ugyanazon ügyfél általi egyidejű betöltése.

A D-Bus rendszer szerverként funkcionáló ügyfelei ún. objektumokat bocsátanak a kliens szerepet betöltő partnerek részére. Ezen objektumok viselkedése nagyban hasonlít az objektumorientált programozás tárgyköréből megismert objektumokéra. Bár az objektumok működése C++ fogalmakkal is jól leírható, de rendelkeznek néhány olyan tulajdonsággal, ami inkább a modernebb objektumorientált nyelvekhez (pl. C#) teszi őket hasonlatossá: Az objektumok futásidőben felkutathatóak, szerkezetük lekérdezhető (ez az ún. introspection), stb. Az a tény azonban, hogy az objektumokat nem az őket felhasználó kliens programok hozzák létre, illetve törlik (ld. constructor/destructor), hanem kizárólag a szerver típusú ügyfelek, sőt, nem is a kliensek állapotterében (memóriájában) léteznek, hanem a szerverekében, a már említett komponens alapú rendszerekkel rokonítja őket, nem pedig valamely konkrét programozási nyelvvel. Az D-Bus rendszer által biztosított - az objektumok elérésére szolgáló - stabil ABI és a többféle programnyelvhez (sőt, parancssori eszközökön keresztül még shell szkriptekhez is) rendelkezésre álló API tovább növeli ezt a hasonlóságot.

A D-Bus szerver jellegű ügyfelei fájlrendszer szerű hierarchiában ajánlják ki az objektumaikat, amit az objektumok neve (a D-Bus nevezéktanában path vagy object path) is tükröz: Az objektumnevek az abszolút UNIX elérési útvonalakhoz hasonlóan a "/" karakterrel kezdődnek, és az objektumhierarchia szintjeit szintén a "/" karakter határolja. Példaként említeném meg, hogy a D-Bus démonhoz csatlakozó programok láthatják, hogy maga a dbus-daemon is megjelenik objektumszolgáltatóként, és a D-Bus kommunikáció többi részvevője számára rendelkezésre bocsát többek között egy "/org/freedesktop/DBus" nevű objektumot.

Amint azt a mindenképpen elolvasásra ajánlott D-Bus tutorial kifejti, az alacsony szinten működő libdbus könyvtár csak a D-Bus kommunikációs protokolljának megvalósítására szolgál, az objektumok magasabb szintű kezelésével nem foglalkozik, ezért a D-Bus rendszer szolgáltatásait igénybe vevő alkalmazások más, magasabb szintű könyvtárakat, illetve objektumokat használnak, mint pl. a GObject vagy a QObject. Ezek a magas szintű natív nyelvi objektumok tipikus esetben proxiként viselkedve teszik elérhetővé a D-Bus objektumokat, teljesen elrejtve a kommunikáció részleteit. A D-Bus tehát kétarcú rendszer: a saját fejlesztői, a disztibútorok és rendszergazdák irányában leginkább interprocessz-kommunkációs eszközként mutatja magát, a rá épülő szoftverek fejlesztő viszont komponens alapú szoftverfejlesztői eszközként gondolhatnak rá.

Minden D-Bus objektum tetszőleges számú osztályba tartozhat. A D-Bus nevezéktanában az osztályok neve interface. Azt, hogy egy objektum egy adott osztály tagja, D-Bus nyelven úgy mondjuk, hogy az objektum szolgáltatást biztosít az adott interfészen keresztül. Az interfészek révén az objektumok tagfüggvényekkel (a D-Bus nevezéktanában method, azaz metódus) és adattagokkal (property vagy attribute) is rendelkeznek. Az adattagok elérésére a D-Bus ABI nem biztosít közvetlen hozzáférést, de létezik egy szabványos interfész, amelynek tagfüggvényei lehetővé teszik, hogy lekérdezzük, illetve módosítsuk az adott objektum összes többi interfészének adattagjait.

A D-Bus interfésznevek fordított DNS domainnevekhez hasonló szerkezetűek. Nem kezdődhetnek "." karakterrel, de legalább egy "." karakternek lennie kell bennük. A fenti példában említett "/org/freedesktop/DBus" objektum pl. a következő interfészeket valósítja meg (C++ elnevezéssel élve a következő osztályokba tartozik): "org.freedesktop.DBus" és "org.freedesktop.DBus.Introspectable". Az két interfésznév hierarchikus kapcsolat vagy öröklés benyomását kelti, holott technikailag egymástól teljesen függetlenek. A D-Bus szabványban semmilyen kapcsolat nincs az interfészek (osztályok) között, legfeljebb a magasabb szintű függvénykönyvtárakban jelenik meg ilyesmi.

A D-Bus objektumok interfészei tagokból (member) állnak. A tagok lehetnek metódusok, szignálok vagy adattagok (property). A metódusok és a szignálok argumentumokkal is rendelkeznek (ezek a metódusok esetében a függyvényparaméterek, illetve visszatérési értékek szerepét töltik be). A property-k, amint korábben már említettem nem kezelhetőek közvetlenül D-Bus üzeneteken keresztül, csak közvetetten, egy kifejezetten ezt a célt szolgáló interfész (org.freedesktop.DBus.Properties) metódusainak segítségével. Amennyiben egy objektum valamely osztályának property típusú tagja (azaz adattagja) is van, akkor ennek az objektumnak az "org.freedesktop.DBus.Properties" interfészt is biztosítania kell, ellenkező esetben hozzáférhetetlenek maradnak az adattagok. Az interfészek tagjainak nevei kizárólag a "[A-Z][a-z][0-9]_" karakterekből állhatnak, vagyis az objektumnevektől és az interfésznevektől eltérően nem tartalmazhatnak "/" vagy "." karaktereket, amelyek hierarchikus elnevezéseket tennének lehetővé. A member-nevek tehát egytagúak.

Amint már említettem, a D-Bus egy IPC, azaz interprocessz-kommunikációs eszköz. A D-Bus ABI tulajdonképpen egy Unix Domain Socketekre épülő kommunikációs protokollt definiál. A D-Bus kommunikáció négyféle üzenetből áll: metódus hívás (method_call), metódus visszatérés (method_return), hiba (error), szignál (signal). A method_call és method_return üzenetek a magaszintű programkönyvtárakban jellemzően függvényhívásként, majd a függvény visszatéréseként jelennek meg, az error típusú üzenetek pedig kivételeket generálnak. A szignál üzenetek broadcast jelleggel terjednek, és arra szolgálnak, hogy a szerver jellegű D-Bus ügyfelek eseményekről tájékoztassák a klienseket.

A kötelezően elolvasandó D-Bus specifikáció egyebek mellett részletesen tárgyalja a D-Bus üzenetformátumát. Ebből megtudhatjuk, hogy a D-Bus üzenetek/adatcsomagok fejlécből és törzsből állnak, és sokféle egyszerű és összetett adattípus átvitelére képesek. A fejléc adatmezői többnyire vezérlési és címzési feladatokat látnak el, az üzenettörzs adatmezői pedig a metódushívások és visszatérések, valamint a hibaüzenetek és szignálok argumentumait hordozzák. A D-Bus üzenetekben a C nyelvbeli printf formátumsztringekhez hasonló "type signature"-ök segítségével történik az adatmezők típusainak és értékeinek kódolása. A D-Bus adattípusai közül mindenképpen említésre méltó a "variant" típus, amelynek használata az adott adattípus meghatározásának futási időig történő késleltetését teszi lehetővé, ezáltal segítve a minden egyes híváskor más és más paraméterekkel vagy visszatérési értékekkel rendelkező metódusok vagy szignálok megvalósítását.

Amint fentebb már kifejtettem, az interfésznevek a path-nevekhez hasonlóan többtagúak, az interfészek tagjainak nevei viszont egytagúak. Az interfész és member-nevek a D-Bus üzenetekben ugyan külön adatmezőben utaznak, de számos D-Bus eszköz (pl. később bemutatásra kerülő dbus-send parancssori eszköz) lehetővé teszi az összevonásukat. Ez azt jelenti, hogy pl. az "org.freedesktop.DBus" interfész "ListNames" metódusára az egyszerűség (és az objektumorientált programozásból eredő megszokás miatt) "org.freedesktop.DBus.ListNames" néven hivatkozhatunk. Ez a ListNames metódus egyébként arra szolgál, hogy az adott dbus-daemon példány minden aktív ügyfelét kilistázza.

A D-Bus szabvány definiál néhány szabványos interfészt, amelyeket a legtöbb D-Bus kompatibilis alkalmazás meg is valósít, ezzel megkönnyítve a D-Buson keresztül elérhető objektumok és szolgáltatásaik feltérképezését, kezelését. A szabványos interfészek közé tartozik a feljebb már említett "org.freedesktop.DBus.Properties", amely az objektumok adattagjainak kezelésére szolgál. Nagy jelentősége van az "org.freedesktop.DBus.Introspectable" interfésznek, amely az "Introspect" metódusa string típusú visszatérési értékében XML formátumú leírást ad az adott objektum szerkezetéről, beleértve az objektum interfészeit, az interfészek metódusait, adattagjait (properties) és szignáljait, valamint az objektum gyermekeinek nevét, amelyek az objektumhierarchiában közvetlenül alatta állnak. Ezeknek (és a többi itt nem említett) szabványos interfésznek a részletes leírása megtalálható a D-Bus specifikációjában.

A dbus-daemon saját objektumai és azoknak interfészei (elsősorban a már említett "org.freedesktop.DBus.ListNames" metódusra gondolok itt), valamint a D-Bus ügyfelek saját objektumainak szabványos interfészei (feltéve, hogy tényleg szabványosan vannak megvalósítva!) lehetővé teszik többek között azt, hogy grafikus D-Bus-szolgáltatás feltérképező- és kezelő alkalmazások készüljenek, mint pl. a kdbus vagy a DBusExplorer.

Amint tehát már utaltam rá, a D-Bus kommunikáció Unix Domain Socketeken keresztül történik (ezért mindig egy hoszton belül zajlik, hálózaton keresztül nem lehet átvinni). Miután a D-Bus ügyfél rákapcsolódott a dbus-daemon socketjére, először egy SASL autentikációs folyamaton kell végigmennie. Az autentikáció típusa az általam megfigyelt rendszereken "EXTERNAL" volt (legalábbis a rendszer-dbus esetében), amiről a D-Bus specifikáció autentikációról szóló részének elolvasása után azt gondoltam, hogy a kliens sendmsg vagy hasonló out-of-band módszer segítségével aktívan autentikál. Néhány strace lefuttatása után azonban rájöttem, hogy bár az autentikáció magától értetődően out-of-band módon történik, de a kliensnek nem kell közreműködnie, hanem a dbus-daemon a Linux kernel segítségével saját maga nyomozza ki a kliens kilétét (vagyis UNIX user ID-ját), mégpedig a getsockopt rendszerhívás SO_PEERCRED opcióját segítségül hívva.

A dbus-daemon a sikeres autentikáció után (pontosabban a org.freedesktop.DBus.Hello metódushívásra válaszként) minden hozzá kapcsolódó ügyfélnek kioszt egy automatikusan generált, egyedi címet, ez az ún. "bus name". Az egyedi neveket - még ha az ügyfél lecsatlakozásával fel is szabadulnak - nem osztja ki többé a dbus-daemon. Az egyedi azonosítón kívül minden ügyfél tetszőleges számú nem egyedi vagy jól ismert (well-known) nevet is igényelhet magának. A nem egyedi címek igénylése, karbantartása az - egyébként az "org.freedesktop.DBus" jól ismert címen keresztül elérhető - dbus-daemon /org/freedesktop/DBus objektumának org.freedesktop.DBus interfészébe tartozó metódusok (pl. RequestName, ReleaseName) segítségével történik. Az egyedi és nem egyedi busznevek/címek egyaránt sztring formátumúak. Az egyedi nevek mindig ":" karakterrel kezdődnek, és általában pontokkal elválasztott számokból állnak (pl. ":1.50", ":1.102", ":1.84", stb.). A nem egyedi nevek esetében a címhamisítás elkerülése végett tilos a ":" karakterrel történő kezdés. A jól ismert nevek formátuma jellemzően megegyezik az interfésznevekével, azaz fordított DNS domain alakúak, mint pl.: "org.freedesktop.NetworkManager", "org.freedesktop.ModemManager", "org.freedesktop.Hal"(ami ugyebár időközben elavult, és a legmodernebb disztibúciókban nincs is jelen :-), stb. Észrevehetjük, hogy az egyedi- és jól ismert azonosítók hasonlóképpen viszonyulnak egymáshoz, mint az automatikusan kiosztott IP-címek a DNS nevekhez.

A dbus-daemon legfontosabb feladata a D-Bus üzenetek/adatcsomagok route-olása. Az útválasztás két fejlécmező, a forrás- (sender) és célcím (destination) segítségével történik. Ezekbe a mezőkbe magától értetődően a csomag feladójának, illetve címzettjének egyedi vagy valamelyik nem egyedi (jól ismert) címe kerül. A forráscímet a dbus-daemon tölti ki, így megbízhatónak tekinthető, ezért az esetleges válaszüzenetet küldő ügyfélnek nem kell tartania attól, hogy csomageltérítés történik. Minden D-Bus üzenet rendelkezik sorozatszámmal is, a válaszüzenetek pedig egy külön fejlécmezőben tartalmazzák annak az üzenetnek a sorozatszámát, amire válaszolnak. Ez a mechanizmus ugyancsak az kommunikáció integritásának megőrzésére szolgál. A kitöltött célcím-mezőt tartalmazó csomagok unicast forgalomirányításban részesülnek, a célcím nélküli csomagokat pedig (a szignálok túlnyomó többsége ilyen) broadcast jelleggel mindenkinek kikézbesíti a dbus-daemon.

A dbus-daemon forgalomirányításában csak unicast és broadcast továbbítási forma létezik, tehát nincs irányított multicast. Ennek ellenére a dbus-daemon nem kézbesíti ki feltétel nélkül mindenkinek a broadcast csomagokat. A D-Bus-ra csatlakozó ügyfeleknek szűrési feltételeket kell a kapcsolatukhoz hozzárendelni ahhoz, hogy fogadhassák a nem kifejezetten nekik címzett (többnyire broadcast) adatcsomagokat. A szűrőfeltételek hozzáadására, törlésére a dbus-daemon által kiajánlott /org/freedesktop/DBus objektum org.freedesktop.DBus interfészének AddMatch és RemoveMatch tagfüggvényei szolgálnak. A D-Bus rendszer finomfelbontású szűrői sokrétű képességekkel rendelkeznek a beérkező broadcast üzenetek körének szűkítése tekintetében, azonban ezen felül alkalmasak arra is, hogy megkérjék a dbus-daemont más címzettnek szóló unicast adatcsomagok kikézbesítésére, azaz a D-Bus forgalom lehallgatására. A lehallgatásra szolgáló szűrők (vagy forgalomirányíto szabályok, ha úgy tetszik) mindössze annyiban különböznek a broadcast forgalom megrostálására szolgáló közönséges szürőfeltételektől, hogy az "eavesdrop" nevő flag nem false, hanem true értéket vesz fel bennük.

Az, hogy a dbus-daemon-nal egy eavesdrop flag-et tartalmazó szűrőfeltételt rendeltetünk a D-Bus kapcsolatunkhoz, még nem jelenti azt, hogy a lehallgatni kívánt forgalmat ténylegesen ki fogja tükrözni felénk a démon. Ahhoz, hogy a lehallgatás sikeres legyen, a dbus-daemon konfigurációjában engedélyezni kell az adott csomagok kívánt irányban történő kikézbesítését. A D-Bus konfigurációja ezen a finomfelbontású tűzfal jellegű szűrőfeladaton kívül további biztonsági beállításokat is tartalmaz, pl. korlátozza az egyes ügyfelek által igényelhető és birtokolható nem egyedei azonosítók (bus name) körét, stb. Lehetőség van továbbá arra is, hogy bizonyos azonosítók (jellemzően jól ismert nevek) részére küldött üzenetek aktiválják azt az - esetleg még nem futó - ügyfelet, akihez az azonosító tartozik. Az ilyen inetd jellegűen aktivált ügyfeleket szolgáltatásnak (service) hívjuk a D-Bus nevezéktanban, és működésüket részletesen tárgyalja az imént hivatkozott man oldal.

Egy rendszeren egyidőben tetszőleges számú dbus-daemon példány futhat párhuzamosan. Bármilyen szoftvercsomagnak lehetősége van rá, hogy saját D-Bus példányt indítson testreszabott konfigurációval, hogy ezzel segítse a saját összetevői közötti kommunikációt, kizárva belőle az illetékteleneket. Általában két jól ismert D-Bus példány van jelen egy tipikus Linux rendszerben. A legfontosabb a rendszer "system" dbus-daemon. Ez teszi lehetővé a bevezetőben említett modern desktop technológiák működését, mint pl. a NetworkManager, vagyis ezt közvetít az asztali környezet és a rendszerszolgáltatások között. Események érkeznek rajta keresztül az asztali környezet számára a rendszer- és hardverváltozásokról, mint pl. az akkumulátor töltöttségének változása, a tápkábel kihúzása és bedugása, új WiFi SSID-k megjelenése, térerőváltozások, új USB meghajtó csatlakozása, stb., majd - ha a házirendek (ld. PolicyKit és ConsoleKit/systemd-logind a későbbiekben) lehetővé teszik - a rendszerszolgáltatások végrehajtják a felhasználótól a D-Bus-on keresztül érkező utasításokat. A rendszer D-Bus mellett a nehézsúlyú asztali környezetek (pl. Gnome, KDE) is indítanak egy-egy dbus-daemon példányt minden munkamenethez (ez az ún. "session" bus), amelyen keresztül az asztali környezet jól integrált összetevői kommunikálnak egymással.

Minden D-Bus példány egy Unix Domain Socketen keresztül hallgatózik, itt fogadja az ügyfelek csatlakozását. A rendszer D-Bus socketje a fájlrendszerben van, és általában a "/var/run/dbus/system_bus_socket" elérési úton található (újabban "/run/dbus/system_bus_socket"). A session D-Bus-ok általában absztrakt címzésű Unix Domain Socketen hallgatóznak. A jól ismert D-Bus példányokról, és a hozzájuk tartozó Unix Domain Socketek felkutatásának módjáról bővebben a D-Bus specifikáció "Well-known Message Bus Instances" fejezetében olvashatunk.

A D-Bus rendszernek kér fontos parancssori eszközét szeretném még röviden bemutatni. Az egyik a dbus-monitor, a másik a dbus-send.

A dbus-monitor segítségével tcpdump-szerűen hallgathatjuk le egy adott D-Bus példány forgalmát. A dbus-monitor természetesen "eavesdrop" flag-gel ellátott szűrőfeltételeket használ, tehát a működéséhez szükség lehet a dbus-daemon konfigurációjának módosítására, hogy ténylegesen jogunk legyen hallgatózni. Ennek érdekében a rendszer D-Bus megfigyelésének elősegítése érdekében hozzunk létre pl. egy /etc/dbus-1/system.d/eavesdrop.conf fájl pl. az alábbi tartalommal:


<!DOCTYPE busconfig PUBLIC
"-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<policy context="default">
<allow send_destination="*" eavesdrop="true"/>
</policy>
<policy user="root">
<allow eavesdrop="true"/>
</policy>
</busconfig>

Ezzel a beállítással mindenfajta üzenetet sikerült lehallgatnom, kivéve a method_return típusúakat, de ezzel másnak is problémája akadt, egy programhibából kifolyólag, amit egyes vélemények szerint kijavítottak, más vélemények szerint nem. A dbus-monitor parancs meghívása pl. az alábbi módon történik:

A rendszer D-Bus példány org.freedesktop.PolicyKit1 címen kapcsolatokat fogadó ügyfelének részére küldött metódushívások lehallgatása:
dbus-monitor --system --monitor "type='method_call',destination='org.freedesktop.PolicyKit1'"

A rendszer D-Bus példányon áthaladó összes metódushívás lehallgatása:
dbus-monitor --system --monitor "type='method_call'"

A dbus-send parancs segítségével mi magunk küldhetünk üzenetet tetszőleges D-Bus plédányon keresztül. Néhány egyszerű példa a dbus-send használatára:

A rendszer (system) D-Bus példány ügyfeleinek kilistázása:
dbus-send --system --dest=org.freedesktop.DBus --print-reply --type=method_call /org/freedesktop/DBus org.freedesktop.DBus.ListNames

A rendszer D-Bus org.freedesktop.NetworkManager címen kapcsolatokat fogadó ügyfele (a NetworkManagernek) gyökérobjektumának (jelen esetben /org/freedesktop/NetworkManager) megvizsgálása
dbus-send --system --dest=org.freedesktop.NetworkManager --print-reply --type=method_call /org/freedesktop/NetworkManager org.freedesktop.DBus.Introspectable.Introspect

Hibernálás:
dbus-send --system --dest=org.freedesktop.UPower --print-reply --type=method_call /org/freedesktop/UPower org.freedesktop.UPower.Hibernate

A munkamenet- (session) D-Bus példány ügyfeleinek kilistázása:
dbus-send --session --dest=org.freedesktop.DBus --print-reply --type=method_call /org/freedesktop/DBus org.freedesktop.DBus.ListNames

KDE képernyővédő lezárása:
dbus-send --session --dest=org.kde.screensaver --print-reply --type=method_call /ScreenSaver org.freedesktop.ScreenSaver.Lock

Kmix mester hangerő beállítása 75%-ra (hardver- és hangrendszerfüggő):
dbus-send --session --dest=org.kde.kmix --print-reply --type=method_call /Mixers/0/alsa_output_pci_0000_00_1b_0_analog_stereo org.freedesktop.DBus.Properties.Set string:org.kde.KMix.Control string:volume variant:int32:75

Szerk: Többen is túlságosan bonyolultnak találták a D-Bus rendszert. Erről annyit mindenképpen el kell mondani, hogy a dbus-monitor és dbus-send programok leginkább csak diagnosztikai célokat szolgálnak. A D-Bus éles használata nem parancssorból, hanem bináris programokból történik, megfelelő programkönyvtár-támogatással, tehát valószínűleg nem átlagon felüli módon bonyolult programozási feladat (erről írhatna valaki más). A rendszergazdák, felhasználók feladata szerintem többnyire a rendszer megértésére (ebben kívántam segíteni ezzel a sorozattal), és a második részben bemutatott pklocalauthority jogosultságkezelő rendszer konfigurálására korlátozódik, ami pedig szintén nem túl bonyolult.

A sorozat részei: 1 2 3 4

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Bizony, a közérdekű tájékoztatásra szükség van, mert sokan nem követik ezeket.

Esetleg kitérhetsz a BSD-kre is, ott van a átportolt HAL, meg a devd, de nincs udev, pedig egyes alkalmazások, mint a Thunar fájlkezelő (vagyis a thunar-volman) csak udev backenddel rendelkeznek.

A devd az udev-hez hasonló képességekkel rendelkezik, és korábban jelent meg.

A HAL általánosságban deprecated lett a Linuxos alkalmazásokkal, nekem még 2 éve sikerült megszabadulnom tőle.

subscribe
on topic: "BSD.kre" helyett FreeBSD, legalábbis a devd tudtommal csak ott létezik, ellenben DragonFlayBSD-ben van valami udev újraírás. (NetBSD-t és OpenBSD-t nem tudom, hol tartanak ezzel az agyrémmel.)

Hat, errol a VMware Workstation/Player nem tud. Hal nelkul olyan szep csendben meghal, hogy ihaj. Egy darab sort sohajt ki, teljesen ertelmezhetetlen szoveggel. Rakd fel a hal-t, es boldog vagy. Ennyi a VMware Workstation/Player titka.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A visszajelzések alapján ez látszik az egyetlen alkalmazásnak amihez még HAL kell (meg 64 bites processzor és hardveres virtualizáció).

Vannak rá megfogalmazott igények, hogy ne kelljen és láthatóan sok a felháborodott felhasználó.

A VirtualBox mellett ugyanakkor a VMware Workstation-t nem sokan használják.

> A VirtualBox mellett ugyanakkor a VMware Workstation-t nem sokan használják.

Valóban. Hanem a VMware Player-t. (Amúgy de, sokan használják a WS-t is.)

subscribe

+1

+1

+1

+1

+1

+1

+1

+1

+1
------------------
My Open-Source Android "Projects"

+1

A $topic-ban említett technológia váltogatást én sem tudom már követni. Pedig nem most kezdtem. Lehet, hogy kiöregedtem? Vagy holnap megveszem az első iMac-em? Na jó, azt még nem. Maradok a "must compile kernel" status-ban...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

"A D-Bus objektumok interfészei tagokból (member)"
"datcsomagok fejlécből és törzsből állnak, valamint sokféle egyszerű és összetett adattípus átvitelére képesek."
"(ezért mindig egy adott gépen belül zajlik, hálózaton keresztül nem lehet átvinni)"
Vagy magyar, vagy angol terminológia, de ötletszerüen ne használd az ún. fonetikus átirati terminológiát, mert bár helyes, mégsem mutat szépen egy tudományos igényességü cikkben.

"de a kliensnek nem kell közreműködnie"

Illetve, ne mondd folyton azt, hogy "Amint azt már korábban kifejtettem", "Ahogy arra már utaltam", stb. mert ez egyrészt nem egy akadémiai elöadás, és föleg nem olyan hosszú, hogy az olvasó elveszítse a fonalat, másrészt meg nem aranyhalak hallgatják, ennyit azért még meg lehet jegyezni a jegyzet várható (felolvasási) idötartamán belül.

Böségesen elég pl:
"Az interfésznevek a path-nevekhez hasonlóan többtagúak, az interfészek tagjainak nevei viszont egytagúak."
Kész, aki tudja, tudja, aki meg most kapcsolódott be, az meg most már tudja, mi a téma...

Egyébként eddig jó, és igényes cikk, hasonló szellemben folytasd.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Köszi, párat kijavítottam. Az az igazság, hogy menet közben elment a kedvem az írástól, de mivel már belekezdtem, megpróbálom mégiscsak befejezni. Tudományos igényűnek nevezni erős túlzás. Inkább csak egy használható kiindulópontot akarok adni a D-Bus technológia megismeréséhez, mert a fontosságához képest nem elég ismert.

Kb. kész.

Kicsit még bővítettem rajta, de most már (remélem) tényleg kész. Észrevételek?

Jó lesz kiindulási alapnak ha valamit nem értek. Köszönöm. :-)

+1

Koszonjuk a leirast, az utolso (KMix) peldahoz masnak is kellemes hanyast!

:)))

A 2. cikk miatt néztem meg ezt is, ott megfogalmaztam én is a, hm, kételyeimet. :)

--
Java apps are nothing more than sophisticated XML-to-exception converters.

Egyszerűbben is meg lehet oldani, csak egyszerre akartam bemutatni a függvényparaméterezést, az adattagkezelést és a variant típust. És ne feledd, hogy ez egy parancssori tesztelőeszköz, ami a D-Bus protokoll alsó rétegében működik. A programozók számára rendelkezésre álló API-ban ez a konkrét példa egészen máshogy nézne ki.

Mondjuk, az igazság kedvéért hozzá kell tenni, hogy függvényparaméterezés és variant típus nélkül nincs adattagkezelés.

Sztem kéne egy link a következő rész(ek)hez a végére.

Gondoltam rá, de majd csak akkor fogom megcsinálni, ha mindegyik rész kész lesz.

Szerintem meg inkabb egyesevel rakosgasd bele, sokaknak meg ezek a felkesz cikkek is sok infot hordoznak. De ez csak tipp.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Okéfőnök, megvan.

Koszi :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Többen is túlságosan bonyolultnak találták a D-Bus rendszert. Erről annyit mindenképpen el kell mondani, hogy a dbus-monitor és dbus-send programok leginkább csak diagnosztikai célokat szolgálnak. A D-Bus éles használata nem parancssorból, hanem bináris programokból történik, megfelelő programkönyvtár-támogatással, tehát valószínűleg nem átlagon felüli módon bonyolult programozási feladat (erről írhatna valaki más). A rendszergazdák, felhasználók feladata szerintem többnyire a rendszer megértésére (ebben kívántam segíteni ezzel a sorozattal), és a második részben bemutatott pklocalauthority jogosultságkezelő rendszer konfigurálására korlátozódik, ami pedig szintén nem túl bonyolult.

+1
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/

nem ide

SATA, ha negy betu :-)
--
Blog | @hron84
Üzemeltető macik

Vagy PATA. Vagy SCSI. De szerintem SAS lesz az, pont azért, mert 3 betű.

Oh, a SASok... azok jöhetnének már... :-)
--
Blog | @hron84
Üzemeltető macik