Udev, D-Bus, systemd: megölik a BSD-ket?

Fórumok

Sziasztok!

Írtam egy blogbejegyzés-sorozatot a címben szereplő technológiákról. A sorozat részei:

http://hup.hu/node/112319
http://hup.hu/node/113796
http://hup.hu/node/114595
http://hup.hu/node/114629

A végkövetkeztetésem az, hogy nagyon hasznos, bár távolról sem tökéletes rendszerek ezek, de minél erősebben integrálódnak az asztali környezetekkel (pl. Gnome/KDE), annál inkább ellehetetlenítik a NEM Linux kernel alapú UNIX változatokat a desktop piacon, mert:

szerk: a korábbi hordozható megoldások (HAL/ConsoleKit) helyett bevezetett új Linux-only rendszerek (UPower/udisks/systemd) lehetetlenné teszik a system D-Bus példány érdemleges használatát a *BSD és *Solaris rendszereken, ezáltal a grafikus felhasználói felület és a hardver interakciója gyakorlatilag ellehetetlenül. El tudom képzelni, hogy vannak kulcsfontosságú szabad szoftver projektek, amelyek elsődlegesen BDS-n dolgoznak, úgyhogy a freedesktop.org-osok fafejűsége akár meg is bosszulhatja magát....

Hozzászólások

1. A cikksorozatod rendkívül részletes; annyira, hogy végig sem bírtam olvasni -- egyszerűen az említett cuccok annyira idegesítenek (a szerzőik hozzáállásával együtt), hogy nem bírtam sok agykapacitást fordítani rá.

2. A nem Linux kernelre alapozó, UNIX-jellegű rendszerek szerintem eddig se nagyon törekedtek a tökéletes desktop élményre -- egyszerűen nem ez volt a célközönség. (Inb4 OS X...) Az, hogy a systemd nem fut el FreeBSD-n, és hogy a Debian (egyebek mellett) emiatt nem akarja default-tá tenni, nem nagy probléma szerintem. A nagy probléma az, hogy ezek a cuccok rengeteg mást rántanak magukkal, és egyre nehezebb megszabadulni tőlük, akkor is, ha egyébként a hátad közepébe nem kívánod az ún. "desktop"-ot.

Példa: nekem semmi szükségem nem volt a dbus-ra. Sohasem. Jó pár kiadás óta azonban Debian-on nem tudsz X session-t létesíteni (pl. IceWM-est sem) anélkül, hogy elindulna a session-szintű dbus. Minek? Azért, hogy az Iceweasel fel tudjon dobni egy dobozt, hogy az összes letöltés befejeződött?

Másik példa: a céges laptop-omon RHEL-6.2 Workstation fut. Természetesen legyalultam róla minden szolgáltatást, amire nincs szükségem. Eközben természetesen volt olyan, amiről csak gondoltam, hogy nem kell nekem, valójában kellett. "hald" nélkül például el sem indul a gdm!

3. Régóta követem azt a szépen bontakozó flamewar-t, ami a Google+-on, blogokban, az lwn-en, levlistákon folyik. Nagyon jól kihozza, hogy mekkora szakadék van a GNU/Linux felhasználók két tábora között. Az egyik tábornak a kényelmes desktop kell (a "Linux Desktop éve"), a másiknak pedig hatékonyság, reszelhetőség, választási lehetőség kell, és hogy ne akarjon náluk okosabb lenni a rendszer. Ez például egy jó cikk, ez meg egy jó hozzászólás.

(A két tábor egyébként gyakran egyazon családon belül megjelenik.)

Nekem nem azzal van bajom, hogy az előbbi tábor igényeivel is elkezdett valaki célirányosan foglalkozni (... freedesktop.org), hanem hogy ez gyakran az utóbbi tábor kárára történik. (A Fedora számomra tökéletesen használhatatlan rendszernek bizonyult az F15-tel kezdődően.) Érthető, hogy egy ponton túl ugyanabban a disztróban nem lehet mindkét tábort 100%-osan kiszolgálni. Csak akkor már maradjon dedikált disztró (rendes, akár fizetett támogatással!) egyiknek is, másiknak is.

Akkor van nagy baj, amikor már nem tudsz futtatni egy GUI alkalmazást ötszáz járulékos daemon meg

~/.[^.]*

könyvtár nélkül. (Én ebből kifolyólag évek óta már meg sem próbálok KDE-s cuccokat futtatni. Az IceWM szerencsére rendelkezik valami minimális Gnome támogatással, így azok a cuccok egyelőre használhatók.)

Ezt nem kétlem, azonban amikor én ezt két alkalommal próbára is tettem (több év távlatában), az alaprendszert sem sikerült felhúzni fordítási hiba miatt. Nekem stabilitás kell. Egyszer bereszelem úgy, hogy jó legyen, onnantól évekig csak biztonsági frissítéseket akarok. Új feature-ök pl. egyáltalán nem kellenek.

A gentoo rolling release alapú, tehát nem választhatod azt az opciót hogy stabil rendszer mellé évekig csak biztonsági frissítéseket kapj, mert az upstream felől érkező összes új ficsőrt és frissítést megkapod, ha használod bármilyen formában a csomagok frissítését. Tehát ha sikerül is felrakni, nem azt kaptad volna amit akartál. :) Én erre a scenario -ra debian -t vagy ubuntu lts -t szoktam javasolni, esetleg RHEL - származékot (centos, scientific).

--
http://neurogadget.com/

Nem vagyok hozzáértő, de úgy látom, ezek a technológiák igenis jók, bár az igaz, hogy a D-Bus biztonsági modellje talán nem eléggé finom felbontású, a systemd előnyei pedig még nagyrészt kihasználatlanok (meg persze a systemd még el sem készült). Persze, ezek az újítások önmagukban még nem elegendőek ahhoz, hogy eljöjjön a Linux desktop éve, de nélkülük viszont egészen biztosan nem jön el.

Más kérdés, hogy a korábbi hordozható megoldások (HAL/ConsoleKit) helyett bevezetett új Linux-only rendszerek (UPower/udisks/systemd) lehetetlenné teszik a rendszer D-Bus érdemleges használatát a *BSD és *Solaris rendszereken, ezáltal a grafikus felhasználói felület és a hardver interakciója gyakorlatilag ellehetetlenül. A session D-Bus, gondolom ezután is megy majd azokon a rendszereken is, dehát az nem vigasztal senkit.

Amúgy nem az asztali környezeteket kell foltozgatni, mert nem azokkal van a baj, hanem azzal, hogy kihaltak a D-Bushoz való kernelfüggetlen hardverabsztrakciós rétegek, és már csak linux-specifikusak vannak helyettük. Nélkülük is működhetnek persze a grafikus asztali környezetek, de akkor nem tudják követni az akku töltöttségi szintjét (sőt, nem is látják, ven-e akku), nem veszik észre, ha bedugjuk vagy kihúzzuk a tápkábelt vagy egy pendrive-ot, nem tudják felmountolni a külső meghajtókat, stb.

Egyébként lehet, hogy neked van igazad, és mégsem a D-Bus alapú hardverabsztrakciós technológiákat, hanem a grafikus környezeteket kell portolni. Sőt, mi van, ha nincsenek is annyira a D-Bushoz kötve, mint gondoltam? Én végül is csak a D-Bust viszsgáltam, nem az asztali környezeteket.

A KDE 4 mintha kifejezetten támogatná, hogy portolva legyen: http://solid.kde.org
A FreeBSD-sek meg mintha neki is ugrottak volna: http://wiki.freebsd.org/KDE4

Lehet, hogy a KDE4 lesz a BSD-k megmentője? ;-)

Es ehhez jon hozza, hogy a kwin4 sokkal jobban is mukodik, mint az osszes tobbi window manager barmilyen compositing megoldassal (talan a compiz meg versenykepes vele, de a ccsm bonyolultsaga elrontja azt is). Barmit probaltam vegul mindig a kwin-nel kellett maradnom, barmennyire is nem szeretem azt a sok hatterfolyamatot, amit a KDE4 alapbeallitaskent elindit (ha meg kikapcsolom akkor meg folyton sir).

atyaég, ez nem kis meló lehetett...

Végkövetkeztetéseddel egyetértek. Meg lacossal is. (Lásd ugye az XFCE-4.8-ban megjelent *BSD támogatás elvesztése.) És igen, kifejezetten hátrányos, hogy a használható Linux-desktopot ennyire elbonyolított eszközökkel próbálják előállítani, és ennek köszönhetően ennyire sok szar válik a rendszerek kikerülhetetlen részévé.

Hát igen. Szerény véleményem szerint az üzleti érdekek mellett erősen befolyásolja a mai szoftverfejlesztés irányát a kihasználatlan hardverteljesítmény. Csúcshardvereket lehet potom pénzért venni, viszont a mai szoftvertechnológiák semmivel sem tűnnek innovatívabbnak, mint mondjuk 10-20 évvel ezelőtt, az akkori viszonyokat alapul véve.
Optimalizálatlan kód csúcshardvereken, plusz 1000 felesleges szolgáltatás.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

+1 Sajnos, mint világunkban annyi területen, az oprendszer-fejlesztés is egyéni szubjektív indíttatások kérdése, pedig a hatékony, - a felhasználás szempontjait is figyelve, - a világot átívelő, jobban szervezett, kooperatív módon folyó fejlesztési munka sokat segítene nekünk felhasználóknak is. A jelenleg folyó, a humánerőforrás idejének felesleges pazarlása pedig személyes kárt is okoz a fejlesztőknek, felhasználóknak, világgazdaságnak egyaránt, legyenek bármennyire motiváltak is a jelenlegi "sokféleség" fejlesztésében, használatában. Ha az általános hasznosság felől közelítjük a kérdést, egy ember által használt, hovatovább az életben maradásához nélkülözhetetlen munkaeszközről van szó.., sok-sok egyeztetésre, szabványosításra lenne szükség. A végén busásan megtérülne mindannyiunknak.

De végül is ez a systemd + társai (meg még pl. a Pulseaudio, szóval Lennart Poettering munkássága) felfogható egyfajta szabványosításként. Amúgy, gondolom a fent leírt rendszerek már erősen eltérnek attól az állapottól, amit leírtam, és sajnos már el is felejtettem :-(

Jó sok energiádba kerülhetett, mire összefoglaltad nekünk. Úgyhogy nagy köszönet.

Üdv:
Dw.

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

És az udev tényleg nem csinál már /dev nodeokat, nagyon jók ezek a cikkek a régi megkopott tudást egy kicsit feltuningolni!
Hogy nem lesz BSD-kre...hát, talán azért megoldható a portolás, bár a systemd-t kétlem, hogy akarják egyáltalán portolni, viszont a HAL helyett (ami amúgy is egy szörnyszülött) az uxxx-eket nem hiszem, hogy lehetetlen vállalkozás lenne.

Én inkább azt gondolnám, hogy a systemd-t kellene megpróbálni portolni, mert egyrészt eléggé nagy királyság (lesz, ha teljesen kész lesz), másrészt nem a funkcionalitása Linux-specifikus, csak a működése. Az udev család azonban szinte teljes egészében értelmezhetetlen a Linux kernel nélkül. A D-Bus még hordozható lenne, de a rajta keresztül elérhető értelmes szolgáltatások többségéhez systemd és udev cuccok kellenek.

Lecci ne portoljak a systemd-t. Konstans szopofaktor. Halalosan gyulolom, amikor elinditok valamit, aztan csak annyi van, hogy szolt a systemd-nek. Es most akkor elindult, vagy mi a rak van? Kit erdekel, hogy kinek szolt? Elindult, vagy nem indult, ez a kerdes. Es sokszor nem indul el, es info semmi arrol, hogy miert. Ha esetleg stacktrace-t dobott az app, melyen el van nyelve.

Szoval, ne, ne portoljak, inkabb egy kest valaki a projekt szivebe. Megveszem a kest, komolyan. Csak dobjuk mar.
--

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

Őőőőő, tényleg, ezt kihagytam a 4. részből. Valószínűleg pótolni fogom valamennyire. Na, szóval példának okáért, ha mondjuk egy SuSE rendszeren kiadod a /etc/init.d/nscd restart parancsot, akkor ugye azt látod, hogy redirecting to systemctl. Na, most ezt az átirányítást nem a systemd vagy valami haverja csinálja, hanem az aaa_base csomagban levő /etc/rc.status szkriptet módosították úgy, hogy méltóztasson átirányítani. Ezt a szkriptfájlt ugyanis minden System V init szkript include-olja, és ha ennek egy megfelelő függvénye azt érzékeli, hogy hagyományos init helyett systemd vezérli a rendszert, akkor meghívja magára a /bin/systemctl $1 "${_rc_base}.service" parancsot. A megoldás kulcsa tehát a systemctl parancsban keresendő. Ezt kellene egy kicsit bőbeszédűbbé tenni. Csakhogy úgy tűnik, sajnos nem lehet. Sőt kipróbáltam, még a systemctl parancs visszatérési értéke sem utal rá, hogy sikerült e végrehajtani a kért műveletet :-(

Ez viszont nagy fekete pont!

imho sajat absztrakciokat kellene letrehozni es nem a linuxos felevente kidobott bloat apik utan kullogni

--
NetBSD - Simplicity is prerequisite for reliability

"El tudom képzelni, hogy vannak kulcsfontosságú szabad szoftver projektek, amelyek elsődlegesen BDS-n dolgoznak"

Például?
Amúgy komolyan azt gondolod, hogy egy projekt csak azért pusztul majd el, mert nem tudnak a termék fejlesztéséhez használt BSD-re gnómot telepíteni a kóderek, akik *emiatt* nem tudnak dolgozni? Az ilyen projekt szerintem meg is érdemli :).

Nagyjából meg tudom érteni a Red Hat álláspontját ebben a kérdésben: rettenet erőforrást tolnak a Linux-alapú fejlesztésbe (kernel+plumbing+desktop egyaránt), ennek megfelelően pörögnek is a projektek rendesen. Most azért lassítsanak, mert a "konkurencia" fejlesztőinek nincs energiája kifejleszteni/Linux-kompatibilissé módosítani az új eszközök más kernelekhez való implementációit, a saját fejlesztők meg nem akarják karbantartani azt a saját kódbázison belül?
Asszem ezt hívják úgy, hogy verseny - és ebben tőzsdei cégként *nagyon* jóknak kell lenniük. A konkurencia jövőjéért való aggódás nem gondolom, hogy belefér ebbe.

___
Arany János: Grammatika versben

Ha nem hetente váltogatnák az absztrakciós rétegeket, kicsit könnyebb lenne. Speciel amikor a Microsoft teszi ugyanezt az egyes Windows verziók között, akkor sok Linux-emberke tud habzó szájjal hörögni. De mindegy, ez elég parttalan vita. Ha neked tetszik, örülj neki. Csak fogadd el, hogy van olyan, akinek viszont nem.

> Amúgy komolyan azt gondolod, hogy egy projekt csak azért pusztul majd el,
> mert nem tudnak a termék fejlesztéséhez használt BSD-re gnómot telepíteni
> a kóderek, akik *emiatt* nem tudnak dolgozni? Az ilyen projekt szerintem meg is érdemli :).

Nem erre gondoltam, hanem arra, hogy ha az adott projekt fejlesztői eléggé BSD szimpatizánsok, akkor mondjuk előfordulhat, hogy "véletlenül" nem lesz elég erőforrásuk arra, hogy Linuxra is portolják/optimalizálják a progit.

Én nem nevezném ezt feltétlenül Linux-only rendszernek, mások is előállhatnak saját implementációkkal. Persze komoly feladat és lehet puffogni, hogy ha a "Linuxosok" nem találják ki ezt az egész hülyeségét akkor nem is kéne, de igazából kellett. Nagyon.

A D-Bus absztrakció tulajdonképpen magában foglalja a platformfüggetlenség lehetőségét, a desktop környezetek kernelre támaszkodó kényelmi funkciói javarészt a D-Bus-t használják. Sokkal keményebb kritikát lehetne megfogalmazni, ha a desktop környezetek direktben a sysfs-t túrnák, akkor már rá lehetne sütni, hogy Linux-only.

Szerintem itt csak arról van szó, hogy kitolódik az absztrakció határvonala. Extra teher, ráadásul adott esetben más után kell kullogni - de a fejlődés megállíthatatlan. Nem hiszek az összeesküvés-elméletekben.

A puffogás annak szól, hogy ez már nem az első, és sikerült olyan absztrakciós szintet választani, ahol kb annyi az absztrakció, hogy barna vagy zöld vagy piros rendszeren fut, de mindenképpen legyen Linux. (Egyébbként magát desktop környezetet még nem láttam direktben sysfs-t túrni, de alkalmazást már nem egyet (meg procfs-t). Szóval ebbe az irányba haladunk :-) )

Talán mégsem szándékos a "BSD-gyilkosság", sőt talán nincs is szó ilyesmiről:

http://lists.freedesktop.org/archives/devkit-devel/2009-December/000644…

http://web.archiveorange.com/archive/v/7azSgZHlple9Zr6y68bY

Amúgy a *BSD-seket kérdezem: a Gnome3 és a KDE4 rendesen működik nálatok? Ha igen, milyen hardver backendet használ? Még a HAL-t, vagy van már működő udisks/upower port, vagy valami BSD-specifikus cuccot?

Csak FreeBSD-ről tudok nyilatkozni, azon a KDE4 megy, pendrive bedugását szépen érzékelte (laptop akksira nem emlékszem, fényképezőgépet nem próbáltam). A KDE-fejlesztők viszont tudtommal megtartották a HAL-backendet *is*, és FreeBSD-n azt használja. upowerd van, udisk nincs. GNOME3-ról nem tudok nyilatkozni, de mintha hivatalosan nem lenne, legalábbis most csak 2.32.1-et találok. (9.0 release notes: Gnome version 2.32.1, KDE version 4.7.3 ; kicsit később megjelent 8.3-as: KDE-4.7.4)

Szerk: e szerint van gnome3, de még a ports-ba nem került bele

Akkor talán mégsincs akkora baj. Inkább csak arról lehet szó, most egy fokkal kevésbé törekednek a hardverabsztrakciós cuccok aapvetően linux fejlesztői a hordozhatóságra, és a BSD-seknek kellene összekapni magukat.

Mondjuk az sem elhanyagolható probléma, hogy a ConsoleKit elhal és bejön helyette a Linux-only systemd. Ebben az esetben szerintem a BSD-seknek vagy forkolniuk kellene a ConsoleKit-et és beszállni a PolicyKit fejlesztésébe, hogy a ConsoleKit backend megmaradjon benne, vagy talán még jobb lenne, ha alaposan összeszedék magukat, és portolnák a systemd-t.

> a BSD-seknek kellene összekapni magukat.

ez szokott történni, csak talán az átgondolatlan fejlesztéseknek köszönhetően a kelleténél többször kell és nehezebb a Linux-fejlesztők után menni.

> talán még jobb lenne, ha alaposan összeszedék magukat, és portolnák a systemd-t.

a saját véleményem: ha a *BSD-fejlesztőknek is tetszik a systemd elve, akkor majd megteszik. De mivel elképzehető, hogy más elképzeléseik vannak a dologról, én hajlok arra, hogy azt higyjem a korábban felvázolt (maradjon meg a ConsoleKit backend) lesz az irány.

Speciel nekem általános desktop felhasználóként már az is elég lenne, ha a devd által küldött jelzéseket valami kis eszköz elkapja, esetleg üzenetablakot dob föl, de még jobb, ha ezen kívül lehetővé teszi egy művelet végrehajtását a'la Windows (interaktívan, esetleg beállíthatóan automatikusan).

[A számítógép akkumulátoros töltésre váltott.
Kívánja/od energiatakarékos módba kapcsolni a gépet?
-> (FreeBSD-n powerd parancs lefut, máshol más)

[Megjelent egy új külső diszk.
Nyissam meg a fájlkezelővel?
-> általad kiválasztott fájlkezelő elindul

[Fényképezőgép jelent meg.
Elindítsm képek áttöltését?
-> gThumb --import-photos (vagy más) elindul

[Új audio CD jelent meg.
Elindítsam a CD-lejátszó alkalmazást?
-> smplayer / vlc / xcdplayer elindul

Nekem speciel ennyi bőven elég lenne, és személyes véleményem szerint ezt meg lehet csinálni OS-független módon, sőt mi több, desktop rendszer független módon is. Ha egy ilyenhez lenne OS-enként (Linuxon ez a parancs az energiatakarékos üzemmódra váltáshoz; FreeBSD-n pedig az) 3-4 default beállítás (XFCE-n Thunar, GNOME-on Nautilus, stb) - no az nekem, desktop userként bőven fedezné az igényeimet.

kb fel eve jelent meg egy sh script:

op@opn ports> make search name=automount | less
Port: automount-1.3.1
Path: /usr/ports/sysutils/automount
Info: FreeBSD's devd(8) based automount sollution
Maint: vermaden@interia.pl
B-deps:
R-deps:
WWW: https://github.com/vermaden/automount/

___
info

Korábban néztem, egyfelhasználós környezetben nem rossz, de én pl. nem találtam szabályos umount-ot benne - legalábbis ha több felhasználó is van a gépen, akkor ezt nem lehet megtenni. A sysutils/volman-hoz valahol létezik olyan peccs, ami a desktopra rak ikonokat a mount/umounthoz. (Enek előzményét - amount néven - használja pl. a PC-BSD.

Ez a Lennart Poetteringet kirúghatná már a Red Hat, még mielőtt egy újabb gonosz démont szabadít a UNIX/Linux világra

Most nem olvasom az egeszet vegig de: a csoda kiforrott szuperjo AccountsService (ami nelkul egy Ubi-s desktop gnomemmal meg sem szolal) udisksel systemdvel dbussal...meg mindig keptelen lekezeleni azt, hogy a user nem csak az /etc/passwdbol jon...

Enterprise Linux desktop eve jon, en erzem.

Érdekes:

root@ubuntu-11-10:/proc/905# dbus-send --system --dest=org.freedesktop.Accounts --print-reply --type=method_call /org/freedesktop/Accounts org.freedesktop.DBus.Introspectable.Introspect
method return sender=:1.12 -> dest=:1.69 reply_serial=2
   string "<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
  <interface name="org.freedesktop.DBus.Introspectable">
    <method name="Introspect">
      <arg name="data" direction="out" type="s"/>
    </method>
  </interface>
  <interface name="org.freedesktop.DBus.Properties">
    <method name="Get">
      <arg name="interface" direction="in" type="s"/>
      <arg name="propname" direction="in" type="s"/>
      <arg name="value" direction="out" type="v"/>
    </method>
    <method name="Set">
      <arg name="interface" direction="in" type="s"/>
      <arg name="propname" direction="in" type="s"/>
      <arg name="value" direction="in" type="v"/>
    </method>
    <method name="GetAll">
      <arg name="interface" direction="in" type="s"/>
      <arg name="props" direction="out" type="a{sv}"/>
    </method>
  </interface>
  <interface name="org.freedesktop.Accounts">
    <method name="DeleteUser">
      <arg name="id" type="x" direction="in"/>
      <arg name="removeFiles" type="b" direction="in"/>
    </method>
    <method name="CreateUser">
      <arg name="name" type="s" direction="in"/>
      <arg name="fullname" type="s" direction="in"/>
      <arg name="accountType" type="i" direction="in"/>
      <arg name="user" type="o" direction="out"/>
    </method>
    <method name="FindUserByName">
      <arg name="name" type="s" direction="in"/>
      <arg name="user" type="o" direction="out"/>
    </method>
    <method name="FindUserById">
      <arg name="id" type="x" direction="in"/>
      <arg name="user" type="o" direction="out"/>
    </method>
    <method name="ListCachedUsers">
      <arg name="users" type="ao" direction="out"/>
    </method>
    <signal name="UserDeleted">
      <arg type="o"/>
    </signal>
    <signal name="UserAdded">
      <arg type="o"/>
    </signal>
    <property name="DaemonVersion" type="s" access="read"/>
  </interface>
  <node name="User1000"/>
  <node name="User104"/>
</node>

root@ubuntu-11-10:/proc/905# ldd /usr/lib/accountsservice/accounts-daemon
        linux-gate.so.1 =>  (0x005a7000)
        libdbus-glib-1.so.2 => /usr/lib/i386-linux-gnu/libdbus-glib-1.so.2 (0x00a17000)
        libdbus-1.so.3 => /lib/i386-linux-gnu/libdbus-1.so.3 (0x004b2000)
        libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0x009ca000)
        libpolkit-gobject-1.so.0 => /usr/lib/libpolkit-gobject-1.so.0 (0x00fba000)
        libgio-2.0.so.0 => /usr/lib/i386-linux-gnu/libgio-2.0.so.0 (0x0030f000)
        libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (0x0016e000)
        libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0x001bd000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x0078a000)
        librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0x00c3d000)
        /lib/ld-linux.so.2 (0x00afa000)
        libgmodule-2.0.so.0 => /usr/lib/i386-linux-gnu/libgmodule-2.0.so.0 (0x00c12000)
        libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0x00110000)
        libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0x00aac000)
        libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0x00125000)
        libgthread-2.0.so.0 => /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 (0x00168000)
        libffi.so.6 => /usr/lib/i386-linux-gnu/libffi.so.6 (0x00761000)
        libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0x002b6000)
        libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x0013c000)

Nem hivatkozik a libpam-re, az biztos. Úgy látom, a helyi felhasználói fiókok menedzselésére való, pontosabban arra, hogy közönséges felhasználók is végezhessék ezt a feladatot GUI-n keresztül. Jól gondolom?

Na, belenéztem abba is, milyen műveleteket tud végezni a felhasználói fiókokon:


root@ubuntu-11-10:/proc/905# dbus-send --system --dest=org.freedesktop.Accounts --print-reply --type=method_call /org/freedesktop/Accounts/User1000 org.freedesktop.DBus.Introspectable.Introspect
method return sender=:1.12 -> dest=:1.72 reply_serial=2
   string "<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
  <interface name="org.freedesktop.DBus.Introspectable">
    <method name="Introspect">
      <arg name="data" direction="out" type="s"/>
    </method>
  </interface>
  <interface name="org.freedesktop.DBus.Properties">
    <method name="Get">
      <arg name="interface" direction="in" type="s"/>
      <arg name="propname" direction="in" type="s"/>
      <arg name="value" direction="out" type="v"/>
    </method>
    <method name="Set">
      <arg name="interface" direction="in" type="s"/>
      <arg name="propname" direction="in" type="s"/>
      <arg name="value" direction="in" type="v"/>
    </method>
    <method name="GetAll">
      <arg name="interface" direction="in" type="s"/>
      <arg name="props" direction="out" type="a{sv}"/>
    </method>
  </interface>
  <interface name="org.freedesktop.Accounts.User">
    <method name="SetAutomaticLogin">
      <arg name="enabled" type="b" direction="in"/>
    </method>
    <method name="SetPassword">
      <arg name="password" type="s" direction="in"/>
      <arg name="hint" type="s" direction="in"/>
    </method>
    <method name="SetPasswordMode">
      <arg name="mode" type="i" direction="in"/>
    </method>
    <method name="SetAccountType">
      <arg name="accountType" type="i" direction="in"/>
    </method>
    <method name="SetLocked">
      <arg name="locked" type="b" direction="in"/>
    </method>
    <method name="SetIconFile">
      <arg name="filename" type="s" direction="in"/>
    </method>
    <method name="SetShell">
      <arg name="shell" type="s" direction="in"/>
    </method>
    <method name="SetHomeDirectory">
      <arg name="homedir" type="s" direction="in"/>
    </method>
    <method name="SetLocation">
      <arg name="location" type="s" direction="in"/>
    </method>
    <method name="SetXSession">
      <arg name="x_session" type="s" direction="in"/>
    </method>
    <method name="SetLanguage">
      <arg name="language" type="s" direction="in"/>
    </method>
    <method name="SetEmail">
      <arg name="email" type="s" direction="in"/>
    </method>
    <method name="SetRealName">
      <arg name="name" type="s" direction="in"/>
    </method>
    <method name="SetUserName">
      <arg name="name" type="s" direction="in"/>
    </method>
    <signal name="Changed">
    </signal>
    <property name="SystemAccount" type="b" access="read"/>
    <property name="AutomaticLogin" type="b" access="read"/>
    <property name="PasswordHint" type="s" access="read"/>
    <property name="PasswordMode" type="i" access="read"/>
    <property name="Locked" type="b" access="read"/>
    <property name="IconFile" type="s" access="read"/>
    <property name="LoginFrequency" type="t" access="read"/>
    <property name="Location" type="s" access="read"/>
    <property name="XSession" type="s" access="read"/>
    <property name="Language" type="s" access="read"/>
    <property name="Email" type="s" access="read"/>
    <property name="Shell" type="s" access="read"/>
    <property name="HomeDirectory" type="s" access="read"/>
    <property name="AccountType" type="i" access="read"/>
    <property name="RealName" type="s" access="read"/>
    <property name="UserName" type="s" access="read"/>
    <property name="Uid" type="t" access="read"/>
  </interface>
</node>

Azt hiszem, ezek között azért sok olyan van, amit az NSS/PAM rendszer nem tud kezelni, úgyhogy nem lenne sok értelme azokat használni. A Linux többféle címtár- és autentikációs rendszerrel képes integrálódni, mint a Windows, de nem olyan magas szinten…

Hat igen, csak igy, mint irtam, a dolgok fele nem mukodik egy ubi-s desktopon. Egy celom lenne: egy LDAPos user Ubis Desktoppal, ugy mukodjon hibmentesen, hogy meg az LDAP nemlatasat is tulelje.Nem es nem es nem.

Indoklas bugreportban miert nem NSS/PAM: tul lassu...argh tokonlovom magam.

Na kibanyasztam ujra:

https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/873784

...es ha ezt megoldottam, akkor latszodik a user a login kepernyon. Jippije. utana mar csak arra kell ravennem ezt a csodat (meg nem tudom min keresztul), hogy az nscdvel cache-elt accountokat kezelje le, mert eddig ha nincs LDAP kapcsolat, akkor a desktop fele nem mukodik...

Egyébként ma elég sokat kísérleteztem vele, és nem hiszitek el, de a PolicyKit és a KDE viszont elég jól integrálódik a PAM-mel, konkrétan az active directory-val. Simán YaST-tal beléptettem egy openSUSE 12.1-et egy AD tartományba, és megadtam, hogy egy bizonyos AD csoport (ugyebár \ és szóköz is van a nevében!) tagjai csak rendszergazdai authentikációval függeszthetik fel a gépet, sőt a rendszergazdai fiókok közé felvettem egy AD felhasználót, hogy azzal kelljen authentikálni, és még az is működik!!! Sőt, meg tudtam változtatni az AD jelszavamat mind passwd paranccsal, mind a KDE vezérlőpultjával. Már csak az a probléma, hogy a getent és a finger parancsok nem látják az AD adatbázist (de a többi program úgy tűnik, igen). Hát mi ez, ha nem a Linux desktop éve?

Egyébként még annyi kellemetlenséggel szembesültem, hogy a PolicyKit csak a felhasználók elsődleges csoportjaira tud szűrni, a kiegészítő csoportokra nem :-(

Rajöttem még egy dolgra: a PolicyKitben nem csak szövegszerkesztővel, hanem D-buson keresztül is lehet manipulálni a biztonsági beállításokat, így aztán GUI-n keresztül is lehet konfigurálni, sőt a beállítások magukat is védik! A KDE vezérlőpultjában van is hozzá modul, úgyhogy királyság. Már csak az a baj, hogy ez a GUI ugyanúgy nem látja az active directory adatbázisát, mint a getent és a finger. Remélem, ugyanaz a bug áll a hibák hátterében. Be is jelentettem. Ha kijavítanák, az nagyvezér lenne!

Nem, te értetted félre:

"Már csak az a probléma, hogy a getent és a finger parancsok nem látják az AD adatbázist "

Amúgy ez tényleg agybaj, hisz a getent-nek pont az a lényege, hogy szépen végigkövetve az nsswitch.conf -ot, előkaphass valamit parancssorból, tök mindegy milyen (lokális, távoli, unixos, windowsos) adatbázisban van.

*Gondolom* ez külön kiválasztás azt jelenti, hogy piszkálhatod külön a PAM-ot *és* az NSS-t. (Bár szerintem a kettőnek együtt van igazán értelme.)

De te is figyelmetlenül olvastál, akkor idézem a mondat folytatását is:

"nem látják az AD adatbázist (de a többi program úgy tűnik, igen)"

ha ez így igaz (nekem az "úgy tűnik" furcsa kissé), az azért agybaj. (Speciel én azt gondolom, hogy ha a PAM-ot beállítom, de az NSS-t nem, akkor senkinek nem kéne látnia az AD-t.)

Redhaton igen, piszkálhatod külön a csilivili setup tool-ban.

Lehet, hogy a többi működő program elfogadja a jelszót, aztán annyi, nem
szaroznak azzal, hogy létezik-e ilyen user. Vagy nem tudom.

Mondjuk ha egy getent passwd (így, usernév paraméter nélkül) nem adja ki az összes usert, akkor lehet, hogy csak az enumeration interface van tiltva (sok ezer usernél érdemes kikapcsolni, (winbind enum users, winbind enum groups, ha tényleg samba+winbind páros szedi őket). De ekkor egy getent passwd usernév még működik. Meg egy ls -l is mutatja a korrekt neveket.

> Melyik ez a KDE app?

Simán a "Rendszerbeállítások", és azon belül a "Globális házirendbeálítások" és a "Műveleti házirend" modulok végzik a PolicyKit konfigurálását.

> az /etc/nsswitch.conf-ot kellene első körben megnézni

Korábban évekig kézzel konfigurálgattam ezt az Active Directory tagságot, úgyhogy ismerős az nsswitch.conf. Nem felejtettem el bekattintani meg beírni semmit, és több alkalmazás esetében jól működik az nsswitch. Eddig csak a getent és a finger esetében tűnt fel, hogy nem működik. Mitha valami rossz eredményt kapnának vissza a /var/lib/samba/winbindd_privileged cuccból. Talán a samba hibája, de nem biztos.

Először is kösz a cikk sorozatot. Tényleg nagyon alapos. Szerintem a fentebb említett 2 tábor (reszelős vs kényelmes) nem nagyon fedi egymást. El tudom képzelni, hogy ketté fog szakadni ementén a linux. Tőzsdére, meg GPS-re meg kitudja még mire tuti nincs szükség a wifi nyomtató automatikus csatolására, de stabilitásra, egyszerűségre igen. Tehát lesz egy ipari linux, meg lesz egy szegényember OS X-e / Windows-a linux. Én jelenleg arra használok linux-ot, mint amire 10 éve windowst. Ismeri a videókártyámat, megy rajta a flash. Szóval játék, youtube, dvd-zés. Ilyenek. De szép lassan megszűnt mókásnak lenni. Míg egy BSD-ben szívesen túrom a dolgokat, linux forrásokba már bele sem mernék nézni. Plan9-on meg egyenesen élvezet. beírod, hogy 'src program' és már meg is nyitotta a forrást a kedvenc szerkesztődben. Átírsz valamit 'mk install; mk clean' (mocsok gyorsak a fordítók ja és nem csak x86-ra vannak) és már megy is. Vagy ha nem, vannak fasza debuggerek.

--------------------------------------
Unix isn't dead. It just smells funny.