-ENOTTY

Szef kuchni poleca: Beefy Miracle t-shirts BO2015 O mnie Słoneczna Morena Social

AF_DBUS is coming (20 czerwca 2012, 13:07:29)

Looks like Collabora's efforts to bring D-Bus into the kernel are getting close to release. It's not a revolution, but it is really nice to have.

From my perspective, the D-Bus daemon has three main tasks:

  • deciding where messages should be delivered (routing)
  • actually delivering messages
  • starting delivery sources on-demand

Third point is already intercepted by systemd and upstart (BusName= and start on dbus-activation), so we are left with message delivery and routing.

D-Bus messages have source and destination, sometimes multiple destinations. Just like TCP/IP packets, which sometimes have multicast destinations. For TCP/IP, we already have world-class delivery stack in Linux. And we have clear separation between mechanism — kernel TCP/IP stack using routing table to forward packet — and policy — routing deamons like quagga or bird. Routing daemons manipulate routing table in kernel, but are not needed to actually move the packets.

That's how I see D-Bus—in—kernel. The kernel moves the message. D-Bus daemon should only modify kernel routing table putting “deny” and “allow” where appropriate. D-Bus daemon will no longer deliver messages, leaving message juggling to kernel. This separation will fix long-standing problems with D-Bus deamon early start and restarts. Message passing will be available all the time, D-Bus routing daemon won't need to run uninterruptably. Or at all.

Just like basic networking works right now without routing daemons.

5 komentarzy | Trackback

Thunderbolt na płytach głównych to Thunderbolt na Windows? (18 czerwca 2012, 14:24:19)

Prawie półtorej dekady braku większej styczności z platformą MS Windows spowodowało, że zupełnie nie kojarzy mi się ona z komputerami określanymi jako PC. Opowieści o wyglądzie Windows 7 czy 8 mają dla mnie posmak wizyty w zoo. Owszem, gdzieśtam żyją antylopy i żyrafy, ale codziennie życie wygląda zupełnie inaczej.

Analogicznie z obsługą hardware. A kiedyś przecież prezentacja obsługi USB przez Windows była równoznaczna z prezentacją możliwości samego USB! Śledziło się newsy o zmianach czynionych przez Microsoft i oglądało obrazki z wersji testowych z odczuciem zerkania w przyszłość.

Zarysowanie się w społecznej świadomości Mac OS X i rozszerzenie rynków, na którym Microsoft nie dominuje (tablety, komórki, urządzenie wbudowane)... zanika zależność sprzętu od konkretnego systemu operacyjnego. Nowe technologie nie pojawiają się dopiero wtedy, gdy Windows ma do nich sterowniki.

Obecnie dziwnie mi się odbiera szum typu w 2012 Thunderbolt będzie szeroko obsługiwany. No jak, przecież obsługa TB była już rok temu, teraz pora zająć się ciekawszymi, nowszymi rzeczami (np. 802.11ac). Thunderbolt w Linuksie po prostu działa, nie ma nad czym się zastanawiać. Podobnie jak z USB3.0. Nota bene, cztery lata po wprowadzeniu standardu, obecny Windows nadal nie obsługuje go sam z siebie.

3 komentarze | Trackback

Terenowym lub służbowym (15 czerwca 2012, 21:16:11)

Taka mała nowelizacja prawa mi się zamarzyła:

Samochody zarejestrowane na firmę powinny być oznaczone logotypem i nazwą firmy która je posiada lub leasinguje, umieszczonym w widocznym miejscu, o wymiarach co najmniej 25x15cm.

8 komentarzy | Trackback

Linux automatic user ACL management (23 maja 2012, 19:22:44)

You may have not noticed, because it just works in Linux. Every time user logs in, Access Control Lists on a few important devices nodes are set for him. And every time his session becomes inactive, ACL are revoked. It looks like this:

# getfacl /dev/video0
getfacl: Removing leading '/' from absolute path names
# file: dev/video0
# owner: root
# group: video
user::rw-
user:zdzichu:rw-
group::rw-
mask::rw-
other::---

Works like this:


Audio device access for user “zdzichu” is only granted when this user has an active session. If no one is logged in, or user “tomek” has an active session, then “zdzichu” access is revoked.

And works internally like this...

Which devices are affected?

In theory, the devices belonging to the seat used by user. In addition to peripherals, access to a few subsystems is granted. Best practice is to classify your device — some classes have the privilege of being ACL-managed. The logic lies in 70-uaccess.rules in udev configuration. Devices of the following classes are made accessible: ID_GPHOTO2, ID_HPLIP, ID_CDROM, ID_FFADO, ID_SMARTCARD_READER, ID_PDA, ID_REMOTE_CONTROL, ID_INPUT_JOYSTICK, ID_MEDIA_PLAYER. Names are self-explanatory.

In future, this classification will let administator decide which classes are granted to local user.

Some subsystems are treated specially, access is allowed without further classification. Those subsystems are: sound, video4linux, dvb, drm.

We need to go deeper

Classification from previous paragraph is really an abstraction layer. The ACL granting is handled at the lowest level in file /usr/lib/udev/rules.d/73-seat-late.rules by this line:

TAG=="uaccess", ENV{MAJOR}!="", RUN+="/usr/lib/systemd/systemd-uaccess $env{DEVNAME} $env{ID_SEAT}"

The systemd-uaccess helper is run for each device with uaccess tag (tagging itself happens in 70-uaccess.rules). On my system, there are a few devices affected:

# udevadm info --export-db | grep -cE "TAG.*uaccess"
9

Example: USB-to-RS232 converter

There is no proper class for this gizmo. We can either invent one and send the patch to upstream, or short-circuit logic by tagging device directly. For simplicity, let’s take the second route, keeping in mind it’s discouraged :)

After plugging in our device, use udevadm info to see what udev knows about it and what makes it special. It may be a serial number, specific values of vendor id or product id, type, model or any other property. For my device, I will differentiate on model. Create a simple rule:

# cat /etc/udev/rules.d/92-usbserial-for-user.rules 
SUBSYSTEM=="tty", ENV{ID_MODEL}=="USB_Serial_Converter", TAG+="uaccess"
From now on, every time this converter is plugged in, an active user will gain access to /dev/ttyUSB0 thanks to ACLs.

This leaves us with important question:

Who is an active user?

This information is managed by logind. CLI interaction is provided by loginctl:

# loginctl 
   SESSION        UID USER             SEAT            
        36        502 tomek            seat0           
         2        500 zdzichu          seat0    

# loginctl show-session -p Active 36
Active=no

# loginctl show-session -p Active 2
Active=yes

Thus, ACLs for currently active user “zdzichu” are applied. Start of new session is signalled by pam_systemd module, which should be included in PAM stack. logind by itself watches for active VT console. In other implementations, like for example kmscon, explicit calls on console switch are needed. Calls to logind, of course.

(This section probably needs to be expanded)

Daemons

What to do if you have daemon requiring access to device nodes? Should it start its own session and keep it active? The answer is no. Daemons should be added to the appropriate group. For example, CCTV daemon should be in group video, which has access to /dev/video*.

Group ownership of device nodes is of course managed by udev:

# grep video /usr/lib/udev/rules.d/*
/usr/lib/udev/rules.d/50-udev-default.rules:# video4linux
/usr/lib/udev/rules.d/50-udev-default.rules:SUBSYSTEM=="video4linux", GROUP="video"

Yes, that’s an UNIX way.

By the way, you don’t want users permanently added to groups like audio or video. Such user would be able to ssh into the machine while you are using it and spy on you using webcam, microphone etc. Access to such critical peripherals should only be granted for active user.

What could possibly go wrong?

Everything. There’s a lot of moving parts. Hopefully, most of them are very simple. And with this document, you’ll know what parts to check.

One quite complicated aspect is finding the link between current graphical session and Xorg socket in /tmp. This could go wrong, and will go wrong if you have per-user /tmp dirs¹. In this case current user will have no sound, no accelerated GUI etc.

Standard installations require pam_systemd to be included in PAM stack. pam_systemd(8) man page contains example snippet.

¹ — this could be fixed by looking for X socket in abstract namespace first. Nobody needed it done, yet.

Look into the past

Information here applies to the last couple of Fedora releases.

Some time ago, ACL modifications were done by udev working with ConsoleKit database. The rules were different. Devices had to be TAGed with TAG+="udev-acl" or variables like ENV{ACL_MANAGE}="1" were used. This no longer applies.

3 komentarze | Trackback

Rok czytania na rzecz Wspólnoty (20 maja 2012, 20:41:59)

Niedługo minie rok od zawiązania się naszej Wspólnoty Mieszkaniowej. W tym czasie rozrywek dostarczały mi pasjonujące lektury:

  • Ustawa o Własności Lokali z 24 czerwca 1994 - kopalnia złota praw i możliwości. Jak to, możecie sprzedać moje mieszkanie za puszczanie głośnej muzyki? (art 16.)
  • Ustawa o Gospodarce Nieruchomościami - To do zarządzania budynkiem jako firma musimy mieć człowieka z licencją? really?
  • Prawo budowlane - My, deweloper, nie przekażemy wam Dziennika Budowy, bo tam jest napisane, że zapomnieliśmy wylać fundamentów (art. 3 pkt 16)
  • rozporządzenie MSWiA z dnia 7 czerwca 2010 roku w sprawie ochrony przeciwpożarowej budynków - Grilla na balkonie też nie mogę rozpalić? (§ 4. pkt 1., 5)
  • Rozporządzenie Ministra Gospodarki z dnia 04 maja 2007r. w sprawie szczegółowych warunków funkcjonowania systemu elektroenergetycznego - zakład energetyczny jest generalnie nietykalny, a za 40h braku prądu przysługuje 7,66 zł bonifikaty.
  • Ustawa o zbiorowym zaopatrzeniu w wodę - nie płacisz 2 miesiące za wodę, to Ci ją odetną.
  • Rejestr Klauzul Niedozwolonych UOKiK - Nie odpowiada wam odbiór techniczny mieszkania w niedzielę o 3 w nocy? Zapłaćcie karę!
  • Ustawa o dostępie do informacji publicznej - i co z tego, że nie jestem stroną, mam prawo wiedzieć co mi za płotem budują

Jak widać, aktów prawnych wpływających na nasze życie, nakładających obowiązki jest multum. Szokujące jest jednak, że ludzie kupujący mieszkania za kilkaset tysięcy złotych nie znają nawet tych kilku stron UoWL. Nie zdają sobie sprawy, że poza mieszkaniem kupują udział (i obowiązki) w częściach wspólnych. Że jak przepali się żarówka, to nie ma jakieś spółdzielni, która ją wymienia, tylko idzie to bezpośrednio z ich kasy. Że za odsnieżanie i sprzątanie trzeba płacić. Itd. itp.

Zdarzają się również Asy nie patrzące nawet w plany zagospodarowania przestrzennego. Potem z wielkimi oczami dowiadują się, że w ich ogródku będzie biegła dwupasmowa droga z tramwajem, planowana od 10 lat. Albo inaczej, że wygodna droga dojazdowa do bloku istnieje tylko na makiecie dewelopera, a nie w jakimkolwiek budżecie Miasta na najbliższe ćwierćwiecze.

9 komentarzy | Trackback

Zły peleng (19 maja 2012, 11:32:23)

Dzisiaj kolejny krok w prywatnej eksploracji kosmosu. Co prawda z nieprzewidzianymi problemami (SpaceX Launch aborted. 7 minutes ago), ale zawsze duże wydarzenie. Nic więc dziwnego, że transmitowane w mediach na żywo.

Gdy więc w RSSach przy porannej kawie mignęło mi zdanie Zobacz gdzie znaleźć transmisję na żywo - live i streaming w Internecie kliknąłem, żeby zobaczyć. I co? Link prowadzi do jakiego meczu piłki kopanej.

No kurde. Dzieją się naprawdę ważne rzeczy, a w mediach o niecałych dwóch tuzinach facetów pocących się na trawniku. Wciskają wszystkim tematy interesujące może kilka procent społeczeństwa, absolutnie bez wpływu na życie. A rozwój całej ludzkiej cywilizacji wspomniany gdzieś na ostatnich stronach, jeśli w ogóle.

Słusznie zauważa WO, że pomija się rekordowe tempo budowy A2 w zamian marudząc, że na jakieś tam mecze nie będzie otwarta. Who the fuck cares? Nawet jeśli skończą A2 za pół roku, to dalej będzie wzorowym przykładem budowy dróg i dalej będzie służyła społeczeństwu. A polscy “kibice” w większości i tak nie będą z niej korzystać, bo kilkanaście PLN za przejazd nie mieści się w ich budżetach. I nie są w stanie ogarnąć wyzwań pokonywanych przez rocket science.

A może nie powinienem wychowywać się na sci-fi?

Dodaj komentarz | Trackback

Chciałbym więcej LXC (07 maja 2012, 14:30:15)

Od kilku lat Linux ma w jądrze implementację kontenerów o krótkiej nazwie LXC. W przypadku wcześniejszych rozwiązach typu VServer czy OpenVZ dokumentacji było mnóstwo i wszędzie można się było natknąć na jakieś slice'y i inne hostingi. LXC zaś jest jakby zupełnie niezauważone. Mam więc takie małe RFP — niech osoby zajmujące się tym tematem robią więcej prezentacji na linuksiastych imprezach!.

Solaris ma swoje Zones od ośmiu lat i generalnie wzbudza zachwyt. W dużej mierze dzięki działającej i rozbudowanej otoczce w postaci zoneadm, którą łatwo się wszystkim zarządza. Możliwości jądra Linuksa już dawno przewyższają Solarisa w kwestii kontenerów, tylko konfiguracja wciąż mocno kuleje. A może jestem w błędzie i tylko mi się wydaje, że przy LXC trzeba się ostro narzeźbić?

Mówisz — masz. Michał zaczął pisać.

9 komentarzy | Trackback

Projekt 61107 (18 kwietnia 2012, 16:39:51)

Na początku miesiąca przyszła większość elementów potrzebnych do kontroli umysłów rozpoczęcia Projektu 61107 i siostrzanego Projektu 1434.

[elementy]

Brakuje jeszcze kilku ważnych szczegółów, jak np. płytki prototypowej. Nie jest to pilny problem. Projekt(y) z założenia weekendowe, więc z uwagi na rozpoczęcie sezonu wyjazdów, jakieś efekty osiągnę pewnie za pół roku :-/

4 komentarze | Trackback

systemd: Jolu, pokaż Panom cel (08 marca 2012, 11:16:38)

Jak pisałem dwa lata temu, systemd pozbywa się pojęcia runleveli, dając w zamian cele. Cel jest swego rodzaju punktem synchronizacji, w którym system zapewnia określoną funkcjonalność. Zależności między celami, tak jak między innymi jednostkami, nie są liniowe:

Otwórzmy powyższy obrazek i zastanówmy, co ja pacze?

Na początek legenda. Czarna strzałka oznacza, że wskazywany cel jest wymagany przez wskazujący (Requires=). Zielona wskazuje na kolejność, wskazywany musi się aktywować do końca, zanim systemd przejdzie do wskazywanego (After=). Czerwona oznacza konflikt (Conflicts=). Jak widać shutdown.target konfliktuje ze wszystkich, czyli aktywacja shutdownu powoduje zwinięcie wszystkich innych celi.

Jak widać w górnej-lewej części obrazka: nss-lookup.target nie wymaga network.target. Jeśli jednak z jakiegoś powodu network.target zostanie aktywowany, to nss-lookup.target wykona się po nim — zielona strzałka.

Przy systemd nie można za bardzo powiedzieć o kolejności przy starcie systemu. Tutaj wybiera się docelowy stan systemu i osiąga go poprzez przywołanie wszystkich zależności. Analizę co się dzieje łatwiej jednak prowadzić od końca.

Załóżmy więc, że system ma działać w trybie graficznym. Celem jest więc graphical.target, który z grubsza można porównać z runlevelem 2. w debianowatych. 4. w Slackware, 5. w starych redhatowych, SUSE i Archu — umożliwia logowanie użytkowników w trybie graficznym.

Jako pierwsze aktywowane zostaną wymagania sysinit.target (A special target unit covering early boot-up scripts). Ten zaciąga przestrzenie wymiany (swap.target), lokalne systemy plików (local-fs.target), w tym również szyfrowane z pytaniem o hasło, jeśli potrzeba (cryptsetup.target). Aktywacje tej trójki odbywają się równolegle. Kiedy zakończą się aktywacje i wystartowane zostaną usługi dla tego celu, sysinit.target zostaje osiągnięty.

Umożliwia to przejście do basic.target. Zadaniem tego jest dodatkowo uruchomienie wszystkich gniazd, na których słucha systemd (sockets.target). System w tym stanie może przejść do trybu ratunkowego (rescue.target) który daje powłokę odzyskiwania systemu. Przypominając: mamy zamountowane lokalne systemy plików, włączony swap i zainicjowane podstawowe mechanizmy dystrybucji. Taki runlevel 1.
Tu warto wspomnieć o trybie awaryjnym emergency.target. Jest to absolutnie minimalny stan, w którym można próbować naprawić całkowicie zepsuty system. Odpowiada niemal uruchomieniu jądra z parametrem init=/bin/sh, daje jednak możliwość kontynuacji normalnego uruchamiania po naprawie.

Stąd system może przejść również multi-user.target. Jest to podstawowy stan linuksa — działają prawie wszystkie demony, użytkownicy moga logować się na konsolach (dzięki zaciągnięciu getty.target). Pachnie jak runlevel 3. multi-user.target nie wymaga trybu ratunkowego, ale jeśli takowy był uruchomiony, to musi skończyć się wykonywać przed przejściem w m-u.target — zielona strzałka.

Z aktywnego multi-user.target już tylko krok do uruchomienia graficznego zarządcy logowania i osiągnięcia zadanego graphical.target.

Większość z tych etapów opisana jest na stronie manuala systemd.special.

Skąd brany jest cel przy starcie systemu? Zazwyczaj wskazuje go łącze symboliczne: /usr/lib/systemd/system/default.target -> graphical.target. Administrator może je przesłonić podając w linii poleceń jądra frazę systemd.unit=.

Cele są punktami, do których przypisujemy usługi do uruchomienia w obecnym stanie. Weźmy np. wiszące luzem na obrazku cele po prawej stronie. Taki bluetooth.target aktywowany jest przez pojawienie się urządzenia obsługującego BT:

/usr/lib/udev/rules.d/99-systemd.rules:SUBSYSTEM=="bluetooth", TAG+="systemd", ENV{SYSTEMD_WANTS}="bluetooth.target"

i powoduje wystartowanie odpowiedniej usługi:

/etc/systemd/system/bluetooth.target.wants/bluetooth.service.

Podobnie można np. przywiesić usługi do wystartowanie w związku z kartą dźwiękową do sound.target.

Nie należy zapominać, że start to tylko jeden z etapów życia systemu. Wdzięczny do omówienia, gdyż powoduje kaskadę aktywacji różnych celi. W normalnym użytkowaniu jest to jednak bardzo specyficzna sytuacja i nie należy się na niej skupiać w celach innych niż akademickie.

Obrazek wygenerowany grepem z systemctl dot.

Dodaj komentarz | Trackback

btrfsck: koda (22 lutego 2012, 13:37:51)

Konkludując historię wielkiego nieobecnego btrfsck… Szósty lutego 2012, Josef Bacik:

We're running close to the wire on this but it looks like Chris will have fsck out for btrfs tomorrow

I co? Oficjalnego ogłoszenia nie było, ale fama sie już rozniosła: od dwóch tygodni btrfsck jest dostępny. Mason udostępnił kod w gałęzi repozytorium o nazwie dangerdonteveruse. Użycie oczywiście używanie na własną odpowiedzialność. Bugreporty od osób, które tym narzędziem popsuły sobie system plików będą ignorowane.

11 komentarzy | Trackback

Archiwum :: 26.06.03-26.06.03 | 28.06.03-20.07.03 | 20.07.03-11.08.03 | 23.08.03-10.09.03 | 16.09.03-05.12.03 | 08.12.03-07.01.04 | 08.01.04-21.02.04 | 22.02.04-21.03.04 | 02.04.04-11.05.04 | 14.05.04-04.06.04 | 10.06.04-04.07.04 | 07.07.04-03.08.04 | 04.08.04-28.08.04 | 29.08.04-20.09.04 | 24.09.04-17.11.04 | 29.11.04-18.01.05 | 22.01.05-21.02.05 | 22.02.05-03.04.05 | 03.04.05-18.05.05 | 03.06.05-06.07.05 | 13.07.05-22.08.05 | 23.08.05-21.10.05 | 31.10.05-28.12.05 | 04.01.06-22.02.06 | 13.03.06-12.04.06 | 19.04.06-22.05.06 | 25.05.06-25.06.06 | 25.06.06-05.08.06 | 13.08.06-14.10.06 | 15.10.06-14.11.06 | 19.11.06-14.12.06 | 20.12.06-19.01.07 | 20.01.07-22.02.07 | 28.02.07-20.04.07 | 24.04.07-05.06.07 | 08.06.07-03.09.07 | 07.09.07-19.10.07 | 22.10.07-01.02.08 | 06.02.08-28.05.08 | 02.06.08-07.10.08 | 09.10.08-26.01.09 | 26.01.09-09.05.09 | 10.05.09-02.09.09 | 06.09.09-08.12.09 | 06.01.10-03.08.10 | 04.08.10-13.08.10 | 22.08.10-31.12.10 | 03.01.11-04.08.11 | 29.09.11-22.02.12 | 08.03.12-03.07.12 | 07.07.12-18.04.13 | 13.05.13-10.12.13 | 26.12.13-06.09.14 |
Dodatki :: Nagłówki RSS ATOM
Powered by Jogger. © 2002-2003 Justin Mecham oraz JabberPL Group.
Wszystkie prawa zastrzeżone. Legalność; Informacje
Technorati Profile; ikonki z Tango. Z wyłączeniem komentarzy i zaznaczonych inaczej, autorem tekstów jest zdzichu.