Osoby instalujące Fedorę 15 i późniejsze może zaskoczyć drobna zmiana w nazewnictwie interfejsów sieciowych. Zamiast niemal losowo przyznawanych ethX, nazwa będzie zgadzała się z położeniem karty sieciowej w komputerze i opisem producenta. Mianowicie:

• karty wbudowane w płytę główną: emX, czyli em1, em2 itd.
• karty dołożone: pciX#Y lub pciX#Y_Z (X – numer slotu, Y– numer portu na karcie, Z – numer funkcji) , co daje przykładowe pci3#1 lub pci2#2_15. Druga wersja wyróżnia funkcje wirtualne w ramach SRV-IO.

Przyznawanie nazw dotyczy oczywiście tylko kart pojawiających się w systemie po raz pierwszy. Raz nazwana, karta zawsze dostanie tę samą etykietkę na podstawie adresu MAC i 70-persistent-net.rules. Aktualizacja:. Nazwy nadawane są przy każdym uruchomieniu. Zamiana karty w slocie PCI na inną spowoduje, że nowy interfejs przejmie nazwę starego. Nie zmienią się nazwy w systemach aktualizowanych i tam, gdzie administrator wymusił przypisania w 70-persistent-net.rules. Dane o położeniu fizycznym brane są z ACPI, DMI i tablicy przerwań PCI.

Etykiety na obudowie w końcu będą zgodne z rzeczywistością

Inne uniksowate zazwyczaj nazywają karty sieciowe na podstawie modelu urządzenia i obsługującego go sterownika. Ja od lat staram się nazywać interfejsy od ich funkcji/providera: lan, nsm, storagenet, tpsa, netia, kabel, eter itp. Znacząco ułatwia to np. pisanie reguł filtra pakietów. Wieki temu musiałem łatać iptrafa, który upierał się na działaniu tylko z interfejsami o nazwach ethX. Dzisiaj spokojnie można zakładać, że tak popsutych programów już nie ma. Nazwy interfejsów sieciowych można w Linuksie zmieniać od lat!

Więcej na stronie Features/ConsistentNetworkDeviceNaming.

Update: Pożegnanie z em1.

---

Archived comments:

Wildente 2010-12-21 13:29:23

Jednym słowem Dupa Blada. Będzie to samo co z USB. Wpięty pendrajw nie wiadomo gdzie się pojawi, bo nazwę bierze z nazwy dysku. Pod Windows wiadomo, że dostanie literkę kolejną i można pewne rzeczy zautomatyzować. eth0 było eth0 i można było porady z internetu wklejać albo skrypty sobie pisać automatyzujące. A tu kolejne zamieszanie....

No ale nie od dzisiaj wiadomo, że linuksy prześcignęły windowsa w zakresie automagiczności i nieprzewidywalności.

zdz 2010-12-21 13:36:38

Polemizowałbym. Będzie wiadomo gdzie się pojawi: wpinasz w slot PCI numer 2, to masz pci2#port. W tej chwili przypisanie karty↔ethX potrafi zmienić się co każdy reboot (w zależności jak akurat pójdzie enumeracja).

Wildente 2010-12-21 13:43:57

Już tak miałam, że kartę podmieniałam w locie, a system nadal działał po restarcie. A akurat losowej zmiany nie zauważyłam, ale ja używam Debiana, może Fedora szalała.

zdz 2010-12-21 13:51:26

To nie kwestia dystrybucji, tylko zachowanie jądra. Więcej info http://lwn.net/Articles/325131/ i http://lkml.org/lkml/2006/9/29/268 .

W Debianie zmiana karty też powinna skutkować nazwaniem jej eth1 bądź kolejna. Przynajmniej widzę w Debianie /lib/udev/rules.d/75-persistent-net-generator.rules

Wildente 2010-12-21 13:53:21

Może... Od wielu lat nic nie zmieniałam :D Więc w sumie może po pojawieniu się udeva tak się narobiło.

Margor 2010-12-21 14:05:10

Mi tam najbardziej podoba się podejście stosowane przez FreeBSD tzn. nazwa interfejsu przepisana jest do sterownika. Ale chyba od niedawna się to po części zmienia tzn. od FreeBSD 8 dla WLAN tworzony jest jeden interfejs wirtualny wlan0 (wczęsniej np. ath0). Nie leży mi to, ale może ma to jakiś słuszny cel, na szczęście dla ethernetu pozostało po staremu.

A pomysł nadawania własnych nazw w zależności od przeznaczenia bardzo mi się podoba. Od razu wiadomo do czego służy i nie trzeba się zastanawiać.

rozie 2010-12-21 20:16:49

IMHO bez sensu zmiana. Przepięcie karty ze zintegrowanej na PCI będzie się teraz wiązało z koniecznością zmiany skryptów, jeśli któreś korzystają z karty. A dowolne przypisywanie numeru ethX do adresu MAC od dawna jest możliwe (przynajmniej w Debianie, ale nie sądzę by był wyjątkiem).

BTW co z kartami na USB i bezprzewodowymi?

zdz 2010-12-23 19:57:43

rozie: moja karta wifi nie podlega zmianom nazwy, na USB nic nie mam do sprawdzenie, ale sądzę, że również nie będzie zmiany (bo nie ma slotu PCI).

zdz 2010-12-24 20:40:51

rozie: btw, zobacz tutaj: http://dżogstaff.pipebreaker.pl/2010.12.21-netlabels2.jpg . 8 portów sieciowych. Powodzenia w zgadywaniu, który jest który bez opisanego mechanizmu. Z biosdevname wszystko jest jasne: em1, em2, em3, em4, pci5#0, pci5#1, pci6#0, pci6#1.

AlchemyX 2010-12-27 09:48:57

@Wildente: No ale pendrive możesz odnaleźć po nazwie modelu lub uuid, więc automatyzacja nadal jest możliwa

Wildente 2010-12-28 22:33:36

Chyba nie rozumiem. Wkładam pendrajwa, a on zamiast się po ludzku zamontować jako znany z góry dysk F: :D montuje się każdy pendrajw gdzie indziej. Pewnie da się to jakoś automatyzować, ale trzeba pewnie mocno złożony skrypt pisać, co wykryje jakieś pojawienia się nośnika.

Wildente 2010-12-28 22:35:54

A jeszcze dodam -- te UUIDy dla dysków też porażka. Skopiowałam kiedyś konfigurację Burga na 20 stacji roboczych identycznych i się miałam z pyszna, bo mi uciekło, że UUIDy są zmienne.. /dev/sda2 to /dev/sda2, dobrze że przynajmniej nie usunęli tego z systemu i po odpaleniu z lajwów udało się wrzucić poprawne konfigi z /dev/sda2

zdz 2010-12-30 12:04:13

Pendrive montuje sie jako z góry znany dysk /media/<label>. Jak system plikow nie ma etykiety, to jako /media/<uuid>.
W drugiej sytuacji, skoro popelniles blad uzywajac UUIDow, zawsze mogles skorzystac z LABEL= do wskazania aetykiety. A sda2 nie zawsze trafia jako sda2. W niektorych komputerach wystarczy, zeby w trakcie bootowania byl wetkniety pendrive i juz enumeracja sie zmienia.

Wildente 2011-01-01 17:12:44

A skąd niby mam wiedzieć jaką etykietę ma podłączany dysk? W przupadku UUIDów to już w ogóle porażka, jak pisałam, przy np. klonowaniu konfiguracji na identycznie w miarę maszyny

zdz 2011-01-02 11:39:06

No chyba wiesz co podłączasz? Jak nie, to po wetknięciu masz polecenia "findmnt", "blkid" i inne. Pytając analogicznie, skąd możesz wiedzieć jakie /dev/sdX dostanie napęd?

Wildente 2011-01-02 13:47:34

A skąd mam wiedzieć, co podłączam? Włączam pendrajwa do windowsa i mam zawsze jako ten sam dysk, nie ważne który z miliona pendrajwów. Podłączam do Linuksa i mam na milion sposobów. A co do /dev/sda2, to wiem, bo dyski zawsze są tak samo, przynajmniej u mnie. Nie zaobserwowałam zmian.

No pewnie można jakoś sobie oprogramować te zmiany, ale zauważam po prostu fakt, że to tylko utrudnienie. I że jak kiedyś nie było UUIDów, to było wygodnie, bo było /dev/hda... Później było /dev/sda ale zasada pozostała. A teraz są UUIDy i przenaszalność mi szlag trafia.

W zeszłym miesiącu popełniłem nietypowy wpis po angielsku. Opisałem problem z którym spotykałem się od zeszłego roku. Googlanie za komunikatem błędu dawało mi dokładnie 0 trafień i takąż liczbę odpowiedzi. Znalazłszy rozwiązanie postanowiłem zostawić w sieci wskazówkę dla innych osób w mojej sytuacji.

Dwa dni później z kodu NetworkManagera w całości wyleciał fragment odpowiadający za ten komunikat. Zastąpiony został sensownym difoltem – za brakującą wartość GATEWAY0= przyjmowane jest 0.0.0.0.

Jest to świetna ilustracja znanej zasady, że jeśli długo czekamy na przyjazd autobusu, to najlepiej zapalić papierosa. Bo wtedy autobus pojawi się od razu i nadpalony narkotyk trzeba będzie wyrzucić. Chociaż w świetle ostatniego zakazu, może to spowodować pojawienie się nie autobusu, a Straży Miejskiej lub Policji.

---

Archived comments:

amused 2010-12-11 20:15:47

właśnie powoli przygotowywałem się psychicznie ;) i szykowałem do odpalenia papierosa kilka dobrych m od przystanku, kiedy nadjechały właściwie służby i wlepiły mandat (500!) osobie palącej jeszcze dalej, to tak do tematu - poczułem się jakbym wygrał życie.

zdz 2010-12-11 21:50:57

Good for you! :)

W technice zabserowować można często kuriozalny trend. Lepsze technicznie rozwiązania tłamszone są przez gorsze. Zazwyczaj tańsze. A następnie te gorsze otrzymują narośla mające je upodobnić do wypartych lepszych.

Ostatnie lata dały nam Ethernet 10+Gbps i usilne próby włożenia w niego wszystkich konkurencyjnych rozwiązań. I dopchnięcia kijkiem, żeby pasowały. Weźmy taki InfiniBand. Fajny interconnect, duża przepustowość i co najważniejsze małe opóźnienia. Bajery osiągnięte dzięki RDMA – możliwości pisania bezpośrednio do pamięci zdalnej maszyny, bez angażowania CPU. Udało się to wpasować w Ethernet, pod nazwą iWARP. A w jądrze 2.6.37 mamy całą warstwę IB-over-Ethernet.

IB pozwala też na dostęp do pamięci masowej. Odpowiada za to skrót SRP (SCSI RDMA Protocol). Rozwiązanie mało popularne, do SANów używało się raczej Fibre Channel. Który też nie oparł się przemeblowaniu – FC-over-Ethernet ustandaryzowano w 2009, po dwóch latach pracy.

Może coś prostszego do dostępu do dysków? Coś jak ATA? ATA-over-Ethernet jest z nami od lat sześciu. I co z tego, że Ethernet jest jaki jest? Ramki mogą się zagubić albo dotrzeć w innej kolejności. Dlatego AoE nie obsługuje barier I/O. Bo się nie da. Problem rozwiązano inaczej, dostępem synchronicznym. Zalety NCQ/TCQ? Tu se ne da.

Ethernet jest prosty. Tu pakiety giną. Tu można oszukiwać w wyborze slotu CSMA/CD. Tu można pisać świetne opowiadania science fiction i wydawać je jako pracy dyplomowe z niezawodny Ethernet w tytule.

(a patrzyłeś, czy twój model ADSL nie wymaga PPP-over-Ethernet?)

Gwarancje dostarczenia i sprawiedliwego dostępu do medium można szukać w grobowcach dających spoczynek Token Ringowi i lokalnemu FDDI. Ethernet wybiwszy konkurencję okazał się oczywiście za słaby do jej zastąpienia. Tak więc teraz doklejamy brakujące kawałki. Grupa pudrująca i szminkująca zajmująca się Data Center Bridging (Data Center Ethernet bądź Convergence Enhanced Ethernet) poza użyciem ulubionego słówka jednego z wykładowców ETI PG (konwergencja!) tworzy specyfikacje z zakresu:

• priorytetyzowania ruchu
• przesyłu informacji o zapchaniu łącza, co ma krytyczne znaczenie w unikaniu strat pakietów
• zarządzaniem i wykrywaniem topologii oraz urządzeń w sieci

Pięknie również wygląda skrócony opis Metro Ethernetu na Wikipedii. Najwięcej miejsca zajmuje opis dlaczego właściwie ethernet się nie nadaje i przez jakie kłody trzeba skakać, żeby go wdrożyć na skalę MAN.

Jak można odnieść wrażenie, Ethernet skrzywdził mi kota i staram się go tępić. Nic bardziej mylnego. Okablowanie strukturalne w mieszkaniu mamy zrobione na skrętce pod kątem rodziny IEEE 802.3:

Bo Ethernet najtańszy i najuniwersalniejszy jest, i basta! Lingua franca sieci. I głośniki za kanapą nie potrzebują kabli na podłodze, skoro są w ścianie. Ale niekoniecznie w implementacji Audio-over-Ethernet…

---

Archived comments:

DeHa 2010-12-08 20:41:19

O Audio-over-Ethernet (konkretnie Ethersound) prowadziłem seminarkę rok temu. W niedzielę skończyłem seminarkę o zarządzaniu w Ethernecie oraz dlaczego go nie ma (w tym First-Mile i drobinki Metro, o DCB się obiłem w poszukiwaniu materiałów).

Mieszkając w Bydgoszczy miałem modem Sagema, który używał albo PPP-over-ATM albo PPP-over-Ethernet -- pewności nie mam.

O tym, że FibreChannel po Ethernecie zrobili to wiedziałem (też seminarka o tym była u nas) i w sumie nieszczególnie mnie to dziwiło, bo FC to raczej egzotyka dla bogatych zawsze była z mojego punktu widzenia (ciekawostka: u nas w firmie jakieś dwa lata temu kupiono maszynkę z FC i leży smutna, bo nie ma budżetu na dyski do tego...). O InfiniBand niewiele wiem i że go zethernetyzowali także nie wiedziałem.

A z innych ciekawostek: u mnie w domu muzyka również płynie po Ethernecie z NASa, ale na trochę wyższym poziomie UPnP.

One size fits all.

zdz 2012-01-13 14:58:54

BTW https://picasaweb.google.com/117922758877367179365/HomeStructuralWiring

The dreaded message ifcfg-rh: error: Missing or invalid IP4 gateway address '0' perplexed me last time when I let NetworkManager bring up ethernet interfaces. Everything worked fine before, but with NM one of the network cards wasn't been configured. I've read ifcfg-ep0 hundred times, checked /etc/sysconfig/network, /etc/default-routes, other interfaces configuration but still cannot find this gateway address of ‘0’.

Then I've found it: I had per device routes configured in /etc/sysconfig/network-scripts/route-ep0. I had it slightly wrong, with ADDRESS0= and NETMASK=0 provided but GATEWAY0 missing. So, if you encounter such message, check if you per device-route config file contain GATEWAYx= or GATEWAYDEVx=0.

After correcting this issue NM was able to bring up interfaces just like /etc/init.d/network.

Re-enabling NetworkManager was prompted by systemd migration of my home server. Traditional network.service has some annoying bugs when systemd is used. NM – has not.

Also, I've converted few services to native units. For now: maradns, aiccu, spamassassin. Seldom used mounts like /boot benefit from dead-easy automount setup. I was able to trim my system's boot time by minute and half. Now it only takes 3½ minutes to start. One full minute is spent in BIOS and harddrives enumeration, there's not way to make it faster. But rest of boot still can be optimized. I'm going to analyze bootchart made during next boot (maybe in few weeks time). Before systemd, my server needed almost 5 and a half minute to boot to GDM screen.

Wiadomość późna, aczkolwiek ciekawa: dzisiaj w Gdańsku będzie można podyskutować z kreacjonistami. Dyskusja Epoka lodowcowa a potop Noego odbędzie się o 18°° w klubie Infinium.

Organizatorem jest Biblijne Towarzystwo Kreacjonistyczne. Postaram się podać informację z wyprzedzeniem, gdy w Trójmieście będą spotykać się przeciwnicy jaszczurów piekła, wśród nich Tomasz Lis aka Ptaah.

---

Archived comments:

Zal 2010-10-20 12:51:35

"Niebędziemy cipowani" - they made my day :D

tdudkowski 2010-10-20 13:56:11

Znowu Gdansk, choc tym razem to tylko klub studencki w akademiku.
Na szczescie w Toruniu stworzeni z brudu zostali powstrzymani - http://www.racjonalista.pl/forum.php/s,369381

zdz 2010-10-20 15:17:44

W Infinium czasem występują kabarety.

O firmie Segway głośno zrobiło się blisko dekadę temu. Za sprawą skutera wynalezionego przez Deana Kamena, który miał zrobić rewolucję i zmienić sposób budowania miast. Wyszło jak zwykle, pierwsze miejsce na liście 50 najgorszych wynalazków i wypadnięcie z publicznej świadomości.

Żeby jeszcze raz znaleźć się na czołówkach gazet, firma wymyśliła sprytny manewr. Z klifu zrzucony został obecny (teraz już były) właściciel Segway Inc. Pozbywając się najmniej produktywnego^* elementu (managementu), firma spowodowała, że znowu o niej mówią. Przynajmniej przez chwilę:

Skrajnie odmienną taktyką wykazuje się Oracle, po zakupieniu Sun Microsystems na początku tego roku. Z firmy znikają ludzie, którzy to wszystko stworzyli. Oracle straciło już ojca Javy – Goslinga. Odeszli odpowiedzialni za DTrace (Cantrell, Leventhal) i ZFS (Bonwick). Nie ma osób związanych z XML (Bray & Phipps; ten drugi miał stanowisko Chief Open Source Officer). Odszedł nawet Jens Axboe, zajmujący się podsystemem blokowym w Linuksie. Lista znikających jest długa i ciągle się powiększa, a o Oracle wcale nie słychać więcej. Pora wyrzucić wierchuszkę?

* jak w tym dowcipie o ludożercach:
Firma informatyczna zatrudniła 4 kanibali.
— Ok chlopaki jako informatycy będziecie zarabiać kupę forsy, możecie jeść w naszej kantynie, ale kolegów macie zostawić w spokoju. Ok?
— OK.
Po czterech tygodniach chłopaki lądują u prezesa na dywaniku…
— Chłopaki pracujecie super, jesteśmy bardzo zadowoleni, ale jest jeden problem. Brakuje nam sprzątaczki. Zniknęła bez śladu! Nie zjadł jej ktoś z was przypadkiem?
Kanibale:- My? Ależ skąd Sprzątaczka? Nic nie wiemy!
— OK. OK.
Chlopcy wyszli z gabinetu…
Szef kanibali:
— Chłopaki! Teraz szczerze! Kto zjadł sprzataczkę‽
Zgłasza się cichy, mały kolo:
— Ja szefie zjadłem…
Na to szef:
— Imbecylu! Pracujemy tu 4 tygodnie, zarabiamy kupę forsy, jemy sobie spokojnie szefów projektów, szefów wdrożeń, szefów supportu, tak żeby nikt się nie zorientował a Ty, idioto, musiałeś zjeść sprzątaczkę…?

---

Archived comments:

Szymon 2010-09-30 20:08:04

btw, kto dziś pamięta o DEC ? Sun pewnie też zniknie w niepamięci, taka kolej rzeczy...

a_patch 2010-10-01 17:34:45

I ATI już nie ma...

Na studiach miałem nieodparte wrażenie, że wykładowcy mówią tylko o technologiach dawno już umarłych. Słuchaliśmy o sieciach 100VG-AnyLAN, Token Ring, ALOHA, a nikt nawet nie zająknął się o InfiniBand, Myrinet czy Fiber Channel. Czasem przedmiot z „Następnej Generacji” w nazwie mówił o rozwiązaniach dawno zarzuconych.

Zdziwiłem się więc widząc w tym tygodniu tytuł Nadchodzi energooszczędny Ethernet. Nadchodzi? Przecież już 3 lata temu słuchałem prelecji mojego promotora, dr Krzysztofa Nowickiego, dotyczącej właśnie energooszczędnego Ethernetu. Było to w Łodzi, na konferencji SIS 2007. A tu mainstreamowe media dopiero przymierzają się do tematu.

Tak, na WETI są też wykładowcy nadążający, a wręcz wyprzedzający obecny poziom techniki. I nie bojący się zajmować np. WiMAXem.

---

Archived comments:

Tap 2010-09-19 18:47:39

Element testowej instalacji WiMAX stał u mnie na oknie ;D

Szymon 2010-09-19 18:58:31

nadchodzi. głosowania chyba jeszcze nie było ?

DeHa 2010-09-20 20:48:22

W tym wypadku to chyba akurat wyjątek od reguły. Owszem na przedmiocie z KN (o wdzięcznej nazwie "Sieci Ethernetowe") kazano nam nie mówić o żadnych technologiach "starych". A "stare" to takie wprowadzone przed 2007. Najciekawsze były rozwiązania będące niedawno zgłoszone lub te, które miały stać się standardami w przeciągu kilku najbliższych lat.

Oprócz tego mieliśmy też o Fibre Channel i pamiętam wzmianki o InfiniBandzie (acz samą seminarkę, jeśli miała miejsce przegapiłem).

Dużo też było o sieciach dostępowych opartych na Ethernecie, zarządzaniu w Ethernecie i Ethernecie w telekomunikacyjnych sieciach szkieletowych.

Mam wrażenie, że (niektórzy) ludzie z tej katedry interesują się tym, co wykładają, a co za tym idzie starają się być na czasie.

Nadal chcesz przyspieszyć serwer dzięki SSD? Budżet nie pozwala na zakup dającego 1,5 miliona IOPS Kaminario K2. Pewnie nie starcza nawet na najmniejszą konfigurację K2 (300 kIOPS, 1TB, $200k), ani na małego RamSan-440.

Pozostaje dopingować (a najlepiej zasponsorować) Bena Chocieja z IBM, który pracuje nad infrastrukturą do śledzenia temperatury danych. Im gorętsze — częściej używane — tym bardziej nadają się do przeniesienia na szybszą pamięć masową. Czyli na dyski 10k, 15k RPM, short-stroked, SSD czy wysokowydajne wolumeny RAID10 na macierzy.

Łatki Bena na początek współdziałają z btrfs. Pojawiły się głosy za umieszczeniem funkcjonalności na poziomie VFS, co daje możliwość korzystanie z niej innym systemom plików. Koncepcja jak najbardziej słuszna.

W stosunku do rozwiązań cache'ujących, pojemność szybkiej pamięci masowej wchodzi w skład dostępnej przestrzeni dyskowej w puli. Stąd już tylko krótki krok do niezłej implementacji hierarchicznego składowania w Linuksie. I do zastąpienia DMAPI, niedawno usuniętego z XFS w jądrze.

---

Archived comments:

sprae 2010-08-29 16:40:24

Czy dzisiaj się nie stosuje już do takich krytycznych rzeczy zwykłego ramdysku?

zdz 2010-08-29 17:02:19

sprae stosuje się, ale cenowo/pojemnościowo się nie opłaca. Do serwera włożysz jakiś terabajt RAMu (do Sun Fire x4800) ale zapłacisz za to masakrycznie dużo (KVR1333D3D4R9S/8G za 1300 pln, potrzebujesz 128 takich). Po to są rozwiązania HSM, na jednym końcu page cache jądra, potem SSD, dyski, a na końcu taśmy.

zdz 2010-08-29 17:10:08

W sumie inaczej: jeden poziom cacheowania danych już mamy - tak jak mówisz, w pamięci RAM. Problemem są dwa:1) że jądro widzi tylko pamięć RAM i system dyskowy, bez niczego pośredniego; 2) dane są duplikowane w RAM i na dysku, więc tracimy na pojemności.
Po zauważeniu, że dyski nie są jednolite - różnią się prędkością - łatki Bena pozwalają te różnice wykorzystać.
Ręczne zakładanie ramdysków i kopiowanie częściej używanych danych to prowizorka. Tym powinno się zajmować jądro.

sprae 2010-08-29 21:21:45

Tak spytałem, bo ostatnio głośno o facebookowym przejściu na ARM. I gdy o tym dyskutowaliśmy to wyszło nam, że na ARM można co najwyżej zrobić komputery obsługujące aplikacje (te ich kompilowane PHPy itp). Z resztą oni też są znani z tego, że trzymają statyczne dane w ramie.
Co do reszty infrastruktury o której piszesz we wpisie wydaje się fajna, o ile będzie stabilna i przewidywalna. Inaczej dalej będzie jak to nazywasz "prowizorka" (dla mnie to normalne elementy infrastruktury).

Research In Motion to firma będąca producentem telefonów marki Blackberry i właścicielem systemu QNX. Blackberry nie są u nas popularne, za to po drugiej stronie oceanu zajmują pierwsze miejsce (ponad 40%) na „rynku smartfonów”, przed Apple (24%) i Windows Mobile z Androidami (po 13%).

Blackberry są tak kochane m.in. dlatego, że są postrzegane jako bezpieczne. RIM na swoich kolorowych stronach pisze Data remains encrypted in transit and is never decrypted outside of the corporate firewall.

Nie spodobało się to kilku krajom arabskim, które na początku tego miesiąca zgodnie oznajmiły, że noszą się z zamiarem zakazania używania BB na swoim terenie. Bez kozery oznajmując, że z powodu nieumiejętności podsłuchiwania.

RIM został postawiony przed wagą, gdzie na jednej szalce leżała kasa od 700 tys. abonentów, z drugiej strony — reputacja i opinia bezpiecznej platformy. Wybór kanadyjczyków? BlackBerry maker tests three Saudi servers.

Zagranie z wizerunkowego punktu widzenia bardzo złe. Ale jakiego PR oczekiwać po firmie, która portal z ofertami pracy nazwała rim.jobs? RIM assures its customers that it is committed to continue delivering highly secure and innovative products that satisfy the needs of both customers and governments. Zwłaszcza governments. A jak nie potrafią podsłuchiwać mając serwery u siebie, to RIM wyciągnie pomocną dłoń, na której poda klucze szyfrujące.

Często słyszy się argument: jeśli nie ma się nic na sumieniu, to nie ma co ukrywać. Dedykuję go organizacjom wojskowym, których dokumenty bywają na WikiLeaks.

---

Archived comments:

DeHa 2010-08-22 22:08:18

"All your base are belong to us", chciałoby się rzec. Apple prawdopodobnie powiedziałby w takiej sytuacji, że to dla dobra klientów i zapewnienia wysokiej jakości świadczonych usług w wielu krajach świata...

h. 2010-08-27 00:28:57

Nie wiem, dlaczego Cie to dziwi? :) PS: Podobnie zrobili rowniez dla Indii - obiecali dostarczac informacje "na zadanie". Dodatkowo warto nadmienic iz sluzby uzywajace BB, maja jego specjalna wersje oraz wlasne serwery BES. Sporo korporacji rowniez posiada swoje serwery BES, takze warto nadmienic iz zagrozeni sa standardowi uzytkownicy.

Dotychczas w cyklu epopei nerdowskiej^* ukazały się:

1. Wstęp
2. Usługi
3. Cele i migawki
4. Gniazdka
5. Timery
6. Ścieżki
7. Punkty (auto)mountowania
8. Urządzenia i swap
9. Zależności
10. Kontrola startu
11. Użyteczne drobiazgi
12. Spis treści
13. Addendum:
    • Modyfikacja jednostek
    • Stadko zamieniających Uniksa demonów
    • Jolu, pokaż Panom cel

I nawet brak dobrego tłumaczenia dla określenia crash course nie przeszkodził.

Kotek:

^* dzięki, Doom :)

---

Archived comments:

Caladan 2010-08-13 14:23:07

Kicia!

Rebel 2010-08-13 17:52:06

krzyż! i to podwójny ! ;p

Szymon 2010-08-13 21:20:08

kotek :3

obiecuję sobie to wszystko niedługo przeczytać, zgaduje że odwaliłeś kawał dobrej roboty...

Paweł Ciupak 2010-08-14 01:39:03

Trawka!

Michał &quot;Wolvverine&quot; Panasiewicz 2012-06-29 03:21:51

CGroups - Zarządzanie zasobami w Linux - rlimit (ulimit) do lamusa?

Stara metoda limitowania:
rlimit - pam_limits, limits.conf, /proc/[pid]/limits
część programów jej nie respektuje, niejasna konfiguracja, limity nieprzestrzegane przez programy.

Aktualna:

CGroups - Mechanizm do hierarchicz[...]

RTFM: sd_notify

Na początku należy mieć świadomość, że aktywacji jednostek nie podlegają tylko usługi, a wszystkie możliwe typy. Można więc stworzyć gniazdko, z którym połączenie zaktywuje inne gniazdo. Albo licznik czasu wyzwalany pojawieniem się pliku w katalogu. Efektem nawiązania połączenia może być zamontowanie urządzenia. I to wszystko wyrażone naturalnie zmienną konfiguracyjną Unit=.

Przy konfigurowaniu jednostek działających w podobny sposób można skorzystać z dyrektywy .include. Usługi mogą korzystać z instancji generowanych dodaniem znaku @ do nazwy.

Pisząc skrypty działające jako usługi warto je wzbogacić wywołaniami polecenia systemd-notify przekazującymi konkretniejsze informacji o stanie działania. Dla demonów w C do poznania jest strona manuala funkcji sd_notify(). Pełniejszy status może wyglądać następująco:

# systemctl status avahi-daemon.service
…
      Status: "Server startup complete. Host name is dhartha.local. Local service cookie is 3239089184."

Wpisanie zależności jako OnFailure= pozwala zaregować na błędy przy uruchamianiu/restartowaniu usługi. Efektem może być np. aktywowanie zadania wysyłającego do administratora maila/SMSa, że kluczowa usługa przestała działać.

Aktywacja usług na żądanie może trwać długo. Zawsze możemy taką długostartującą usługę przypisać do .wants/ któregoś z celi aktywowanych przy bootowaniu. Wtedy uruchomienie usługi nastąpi przy starcie systemu.

Zdarza się czasami popsuć system w sposób uniemożliwiający prawidłowy start. Niechcący można chociażby wyłączyć getty dające logowanie na konsolach i nie wystartować sieci z ssh. Uruchomienie awaryjne systemu realizujemy przez linię poleceń jądra, w ktorej przekazujemy nazwę jednostki do aktywowania zamiast default.target. Przykładowo systemd.unit=emergency.target. Jest o tyle lepsze od podania single lub init=/bin/bash, że po naprawieniu możemy przejść do normalnego uruchomienia systemu: systemctl default.

W czasie pracy można przejść do awaryjnej linii poleceń domyślnie konfigurowaną usługą kbrequest, startowaną skrótem klawiaturowym Alt+↑.

Poprzednio: Kontrola startu; Następnie: Spis treści.

---

Archived comments:

DeHa 2010-08-12 21:02:44

Wszystko, co tu przeczytałem wygląda bardzo na czasie i fajnie. Widać, że ktoś to przemyślał.

Co z tego, natomiast, że mamy piękne wnętrzności skoro z zewnątrz dalej jesteśmy pryszczaci?

Paweł Ciupak 2010-08-12 23:53:06

> Wszystko, co tu przeczytałem wygląda bardzo na czasie i fajnie.

O Iphone też mówią, że wygląda bardzo na czasie.

RTFM: systemctl, systemd.unit

Do śmieci: chkconfig

W SysV zarządzanie usługami polega na ogarnięciu stada symlinków z /etc/rcX.d/, odpowiadających runlevelom. W systemd start usług w większości wynika z zależności, czasem jednak trzeba dodać coś swojego. Albo wskazać, że naszserver.target oznacza uruchomienie Tomcata.

Zarządzanie takimi explicit zależnościami również realizuje się przez łącza symboliczne. Przy analizie każdej jednostki sprawdzana jest zawartość katalogu o takiej samej nazwie z doklejonym .wants (np. touchme.service.wants/). Jednostki, do których symlinki znajdują się wewnątrz traktowane są jakby były wyszczególnione słowem kluczowym Wants= w definicji touchme.service.

W drugą stronę: jednostki mogą zasugerować, że są potrzebne do czegoś, np. przez WantedBy=multi-user.target. W takim przypadku systemctl enable <UNIT> doda symlinki w katalogach .wants/ wyszczególnionych jednostek. Analogicznie disable łącza usunie.

chkconfig SERVICE [on|off] przechodzi w systemctl [enable|disable] UNIT

Do dyspozycji jest też słówko Also=, które rządzi włączaniem usług stowarzyszonym. Jednym ruchem można aktywować usługę, jej gniazdko, timery itp.

Poprzednio: Zależności; Następnie: Użyteczne drobiazgi.

---

Archived comments:

DeHa 2010-08-12 09:49:49

Podoba mi się ta epopeja nerdowska. Planujesz wypuścić tyle odcinków, co Klan? ;P

A z innych: podoba mi się tempo prac. Systemd stał się używalny i funkcjonalny w krótszym czasie, niż upstart zaczął robić "cokolwiek".

zdz 2010-08-12 13:36:32

Moda na sukces to wzór! A tak na poważnie to dzisiaj spiszę ostatnie skrawki myśli i to chyba koniec eksperymentu z taką formą blogowania.

Co do tempa prac, to faktycznie jest niezłe. Pierwszy commit w listopadzie zeszłego roku, a tej chwili już praktycznie niczego nie brakuje, został ,,polishing''. A dla porówniania o upstart od lat słyszę:
"As Upstart matures, it is intended that its role will expand to the duties currently handled by cron, anacron and atd, and possibly (but much less likely) inetd." (wiki).
Gdzieś tam kiedyś. A tutaj systemd.timer, systemd.socket...

RTFM: systemd.unit

Ważna sprawa, jednak najnudniejsza. Większość zależności nie musi być podawana. Nie trzeba przykładowo podawać, że usługa wymaga MySQL. Jeśli program połączy się z /var/lib/mysql/mysql.sock, MySQL zostanie automatycznie wystartowany.

Zależności explicite między jednostkami mogą być typu słabego (co jest zalecane). WantedBy= i Wants= pozwala definiować w obie strony, co jest potrzebne i czemu jest potrzebna jednostka. Problem w aktywowaniu jednostek chcianych nie powoduje problemu z aktywacją jednostki rozpatrywanej.

Mocne zależności to requires. Tutaj brak spełnienia zależności uniemożliwia aktywację jednostki. Podobnie oznaczenie jednostek jako konfliktujących będzie powodować ich wzajemne wyłączanie przy starcie drugiej.

Słabe zależności mogą być przez systemd zignorowane, jeśli powodują konflikty. Mocne nie. Obydwa typy nie określają kolejności, wszystkie wymagane jednostki są startowane jednocześnie z główną. W celu wymuszenia kolejności można stosować Before= i After=.

Poprzednio: Urządzenia i swap; Następnie: Kontrola startu.

RTFM: systemd.device, systemd.swap

Do śmieci: swapon

Dzięki informacjom pobieranym z udev swoje odpowiednik wśród jednostek mają urządzenia. Wszystkie, które w regułkach udev otagowane są znacznikem systemd mają automatycznie tworzoną jednostkę. W Fedorze dotyczy to urządzeń blokowych, sieciowych i kilku specjalnych typów.

Skojarzenie z urządzeniem zmiennej SYSTEMD_WANTS pozwala na automatyczne wystartowanie programów umożliwiających korzystanie ze sprzętu. Przykłady z /lib/udev/rules.d/99-systemd.rules:

SUBSYSTEM=="bluetooth", TAG="systemd", ENV{SYSTEMD_WANTS}="bluetooth.target"
SUBSYSTEM=="printer", TAG="systemd", ENV{SYSTEMD_WANTS}="printer.target"
ENV{ID_SMARTCARD_READER}=="*?", TAG="systemd", ENV{SYSTEMD_WANTS}="smartcard.target"

Bardzo prostą jednostką jest odzwierciedlenie swapu. Wymaga tylko podania urządzenie i opcjonalnie priorytetu. Interpretowane są linijki definiujące swap z /etc/fstab.

Poprzednio: Punkty (auto)mountowania; Następnie: Zależności

---

Archived comments:

LCF 2010-08-09 18:45:15

A co jeżeli chcemy zrobić flush swap-a, na zasadzie swapoff device && swapon device ?

zdz 2010-08-09 19:17:45

Tak jak każdą jednostkę:

# swapon -s
Filename Type Size Used Priority
/dev/dm-1 partition 983036 176 -1

# systemctl restart dev-dm\x1d1.swap

RTFM: systemd.mount, systemd.automount

Do śmieci: fstab, mount ;)

Punkty mountowania po części są tworzone automatycznie (dla systemówych katalogów typu /sys/, /proc/, /selinux/ itd.), a po części z interpretacji pliku /etc/fstab. W tym drugim przypadku możemy zarządać montowania przy starcie systemu wpisując odpowiedni ciąg komentarza.

Zauważylem pewną niekonsekwencję przy zapamiętywaniu urządzenia do montowania. Przy podaniu UUIDu czasem systemd operuje na odnośniku do /dev/disk/by-[id,uuid]/, a czasem na urządzeniu:

 # grep /boot /etc/fstab 
UUID=6e958881-903e-4211-a686-4ca8083eaaac /boot                   ext4    defaults        1 2

# systemctl show -p What boot.mount
What=/dev/vda1

Przykład odmontowania:

# findmnt /boot
TARGET SOURCE    FSTYPE OPTIONS
/boot  /dev/vda1 ext4   rw,relatime,barrier=1,data=orde

# systemctl stop boot.mount
# findmnt /boot
# 

Przy definiowaniu punktu montowania można od razu podać uprawnienia, jakie mają być nadane katalogowi. Każdy punkt mountowania może być aktywowany dopiero w momencie dostępu. Używany jest autofs, a punkty automatycznego mountowania definiuje się w plikach z rozszerzeniem .automount.

W domyślnej konfiguracji pod nadzorem systemd jest kilkanaście systemów plików:

# findmnt
TARGET                         SOURCE                         FSTYPE      OPTIONS
/                              /dev/mapper/vg_dhartha-lv_root ext4        rw,relatime,barrier=1,data=orde
├─/proc                        /proc                          proc        rw,relatime
│ ├─/proc/sys/fs/binfmt_misc   systemd-1                      autofs      rw,relatime,fd=19,pgrp=1,timeout=300,minproto=5,maxproto=5,dir
│ │ └─/proc/sys/fs/binfmt_misc none                           binfmt_misc rw,relatime
│ └─/proc/bus/usb              /proc/bus/usb                  usbfs       rw,relatime
├─/sys                         /sys                           sysfs       rw,relatime
│ ├─/sys/kernel/debug          systemd-1                      autofs      rw,relatime,fd=17,pgrp=1,timeout=300,minproto=5,maxproto=5,dir
│ │ └─/sys/kernel/debug        debugfs                        debugfs     rw,relatime
│ └─/sys/kernel/security       systemd-1                      autofs      rw,relatime,fd=18,pgrp=1,timeout=300,minproto=5,maxproto=5,dir
├─/dev                         udev                           devtmpfs    rw,relatime,size=171468k,nr_inodes=42867,mode=
│ ├─/dev/pts                   devpts                         devpts      rw,relatime,gid=5,mode=620,ptmxmode=
│ ├─/dev/shm                   tmpfs                          tmpfs       rw,relatime
│ ├─/dev/hugepages             systemd-1                      autofs      rw,relatime,fd=15,pgrp=1,timeout=300,minproto=5,maxproto=5,dir
│ │ └─/dev/hugepages           hugetlbfs                      hugetlbfs   rw,relatime
│ └─/dev/mqueue                systemd-1                      autofs      rw,relatime,fd=16,pgrp=1,timeout=300,minproto=5,maxproto=5,dir
├─/cgroup                      tmpfs                          tmpfs       rw,nosuid,nodev,noexec,relatime,mode=
│ ├─/cgroup/systemd            cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgro
│ ├─/cgroup/cpuset             cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,cpu
│ ├─/cgroup/ns                 cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime
│ ├─/cgroup/cpu                cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime
│ ├─/cgroup/cpuacct            cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,cpua
│ ├─/cgroup/memory             cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,mem
│ ├─/cgroup/devices            cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,devi
│ ├─/cgroup/freezer            cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,free
│ ├─/cgroup/net_cls            cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,net_
│ └─/cgroup/blkio              cgroup                         cgroup      rw,nosuid,nodev,noexec,relatime,bl
└─/boot                        /dev/vda1                      ext4        rw,relatime,barrier=1,data=orde

Poprzednio: Ścieżki; Następnie: Urządzenia i swap.

---

Archived comments:

sprae 2010-08-08 15:19:32

Systemd jest bardzo wygodny i elastyczny, ale chyba głównym jego założeniem jest agresywne zarządzanie demonami. Zastanawiamy się czy w dzisiejszych czasach na desktopie jest to opłacalne?
Wydaje nam się, że nacisk w takich podsystemach położony jest dziś na szybkość uruchamiania i szybką wygodną pracę.
Szybkość uruchamiania oprócz zmian w samym jądrze zapewnia [s/u]readahead.
Wygodną i szybką pracę po uruchomieniu zapewnia włącznie odpowiedniej ilości usług przy uruchamianiu. Readahead zapewnia i tak ich szybkie uruchomienie na starcie.
To dość proste i praktyczne rozwiązania powodujące, że oczekiwanie na system/konkretną usługę w łącznym rozrachunku znacznie się zmniejsza.
Tu pojawia się systemd z nieco akademickim podejściem "wyłącz to czego nie potrzebujesz". Czy to nie spowoduje, że oczekiwanie na system/usługi znacznie się nie wydłuży?
Problemem rozwiązania, które nazwałem "praktycznym" jest z góry założenie o wymaganej minimalnie ilości pamięci i profilowanie ilości usług do tego rozmiaru.
Wymyśliliśmy, że ciekawym rozwiązaniem systemd byłaby możliwość autoprofilowania. Zapewnić to można przez ustawianie priorytetów usług i konfiguracje ilości zajętej pamięci. Wtedy przy uruchamianiu włączałyby się wszystkie usługi wg priorytetów, aż do osiągnięcia zajętości pamięci.
Głównym problemem może być tu współpraca z readahead (czyli najprawdopodobniej jego kolejny fork wyposażony w profile ładowania).
Teraz pytanie. Czy systemd zapewnia już funkcjonalność pozwalającą na takie zastosowania?

zdz 2010-08-08 15:48:00

StopWhenUnneeded=
Takes a boolean argument. If true this unit will be stopped when it is no longer used. Note that in order to minimize the work to be executed, systemd will not stop units by default unless they are conflicting with other units, or the user explicitly requested their shut down.

Piszesz o desktopie, a to tylko jeden z wielu profili dzisiejszego Linuksa. Zauważ, że te z najmniejszą ilością zasobów jako pierwsze przeszły w całości na upstart. Mam tu na myśli komórki - Maemo/MeeGo, WebOS to rozwiązania upstartowe, czyli z włączaniem usług na żądanie.

Osobiście nie rusza mnie zupełnie przyspieszanie startu systemu - jest to coś, co robię raz na kilka miesięcy.
Natomiast profile o jakich mówisz... Wystartowanie wszystkiego spowoduje, że rzadziej używane usługi wylądują w swapie. A nie jestem do końca przekonany, czy wyciągnięcie czegoś ze swapa będzie szybsze niż uruchomienie od zera. W końcu strony w swapie są bardzo nieciągłe.
W tej chwili nie widzę możliwości startowania usług aż do wypełnienia RAMu.

sprae 2010-08-09 03:25:50

Piszę o desktopie, gdyż uważam, że pierwsze zaadoptuje to Fedora i przez jej pryzmat ludzie będą oceniali to rozwiązanie, tak jak przez pryzmat Ubuntu rozpatrują PulseAudio (które jest obecne nawet w Maemo5)

Wypełnianie pamięci to bardzo optymalna rzecz. Mam 4 GB, a Ubuntu wypełnia mi usługami jakieś 500 MB. Gdyby zrobić takie bardziej inteligentne narzędzie wypełniające 1/4 RAMu priorytetyzowanymi usługami to byłoby bardzo elastyczne dla szerokiej gamy komputerów.

Systemy takie jak Maemo (z którym jestem bardzo związany) mają własne dużo ciekawsze usługi zarządzania aplikacjami przez Dbus pozwalające wysyłać również stany urządzenia i niedopuszczają do zamykania aplikacji, chyba że zabraknie RAMu (podobnie jak w MacOS X). Ale do tego trzeba dostosować aplikacje o odpowiednią obsługę sygnałów Dbus.

HerrLeon 2010-08-11 14:02:58

fajny ten findmt , to twoj skrypt ?

zdz 2010-08-11 15:12:05

# rpm -qf `which findmnt`
util-linux-ng-2.18-3.fc15.x86_64

RTFM: systemd.path

Do śmieci: inotify-tools

Wbudowana obsługa inotify pozwala reagować na zmiany w systemie plików. Demon drukarki może być startowany dopiero, gdy w katalogu z kolejką wydruków pojawi się zadanie. Wrzucenie pliku przez FTP może uruchamiać program, który przeskanuje go antywirusowo i przeniesie we właściwe miejsce.

Stwórzmy więc kolejną prostą usługę, która zareaguje na pojawienie się pliku jego usunięciem. Najpierw usługa (untouchme.service):

[Service]
ExecStart=/bin/rm /tmp/hey

I aktywator do niej (untouchme.path):

[Path]
PathExists=/tmp/hey

Po systemctl start untouchme.path najlepiej obserować działanie używając systemctl monitor. Konfiguracji specyficznej dla jednostki Path nie ma wiele. Poza pojawianiem się plików, także ich zmiana bądź pojawienie się plików w uprzednio pustym katalogu.

Poprzednio: Timery; Następnie: Punkty (auto)mountowania

---

Archived comments:

zdz 2010-08-07 22:22:31

Końca nie widać... do opisania zastało mi jeszcze jakieś 5-6 kwestii.

Paweł Ciupak 2010-08-08 02:35:14

Niech zgadnę, jak zacznie sie następny artykuł…

„RTFM: systemd.mount

Do śmieci: fstab"

zdz 2010-08-08 11:21:45

Dzięki, postaram się skorzystać przy pisaniu.

RTFM: systemd.timer

Do śmieci: cron (prawie)

Kolejnym udogodnieniem dostępnym w systemd (a zaplanowanym również dla upstart) jest możliwość wyzwalania czasowego jednostek. Niestety, nie jak w cronie podawanie dni i godzin, do dyspozycji jest aktywacja po upłynięciu okresu od konkretnego wydarzenia. Powtarzalność można uzyskać przez skonfigurowanie licznika do wyzwalania np. „5m” po starcie systemu i „1w” po zakończeniu działania przez jednostkę. W ten sposób jednostka będzie aktywowana co tydzień.

Wracając do przykładu, stworzenie pliku touchme.timer o zawartości:

[Timer]
OnUnitInactiveSec=30

Spowoduje aktywowanie touchme.service po upływie pół minuty od ostatniej aktywacji.

Na tę chwilę nie widzę sposobu na pełną emulację działania crona i at. Zmieni się to, gdy startowanie o konkretnej godzinie (podanej w formacie RFC2445) zostanie dopisane:

133003 <kay>  ah, i guess that can all end up in timer. it just has no date-spec parser now

Poprzednio: Gniazdka; Następnie: Ścieżki.

RTFM: systemd.socket

Do śmieci: inetd, xinetd

Przerobienie naszej usługi na sieciową? Banalnie proste (touchme.socket):

[Socket]
ListenStream=1234

Aktywacja:

 # systemctl load touchme.socket
Unit touchme.socket added.
# netstat -apn | grep 1234

# systemctl start touchme.socket
Unit touchme.socket removed.
Job 67350 added.
Job 67350 removed.
Unit touchme.socket added.
# netstat -apn | grep 1234
tcp        0      0 :::1234                     :::*                        LISTEN      1/init           

Do wyboru obsługa TCP, UDP, SOCK_SEQPACKET i plików FIFO. Od razu możliwość skonfigurowania:

• ograniczenia nasłuchu do konkretnego urządzenia sieciowego
• wielkości backlog
• ustawień podtrzymywania (keep-alive)
• maksymalnej liczby połączeń i wielkości buforów
• ustawień priorytetu, TTL i TOS
• markowania pakietów na potrzeby iptables/tc
• wybór algorytmu kontroli przepływu TCP

systemd nasłuchuje na wszystkich aktywowanych gniazdach, również tych w systemie plików. Dzięki temu może startować na żądanie nie tylko demony sieciowe, ale również te, do których dostęp realizowany jest przez gniazdka typu /tmp/.s.PGSQL czy /var/lib/mysql/mysql.sock.

Przy usługach, które tworzą nową instancję dla każdego połączenia, warto polecenie w ExecStart= poprzedzić minusem. Wtedy zniknięcie procesu z każdego powodu spowoduje usunięcie instancji. Inaczej instancje usług kończących pracę błędem będą wisiały w systemie, co teoretycznie może doprowadzić do DoSa.

Poprzednio: Cele i migawki; Następnie: Timery.

---

Archived comments:

pecet 2010-08-05 18:49:32

Link do timerów ci nie działa.

Paweł Ciupak 2010-08-05 19:00:58

> Link do timerów ci nie działa.

No bo pewnie też idzie do śmieci i jest _passe_ ;p.

zdz 2010-08-05 19:01:35

Jutro będzie działał.

RTFM: systemd.target, systemd.snapshot

Do śmieci: runlevele

Cele są stosunkowo bezmięsnym typem jednostki. Ich głównym zadaniem jest zbieranie zależności dla jednostek reprezentujących konkretny poziom funkcjonalności systemu. Przykładowo, multi-user.target pozwala na pracę wielu użytkowników — dostępne są konsole tekstowe i możliwość logowania się po sieci. graphical.target zbiera usługi potrzebne do pracy graficznej i wymaga uruchomienia graficznego zarządcy logowania.

Domyślnie, przy starciesystemd aktywuje default.target. Jest to w założeniu link symboliczny do odpowiedniego celu, np. graphical.target. W bardzo dużym przybliżeniu odpowiada staremu ustawieniu inittdefault z pliku /etc/inittab.

Cele mają zapewniać pewien zestaw funkcji i obsługi sprzętu. Przykładowo, urządzenie typu czytnik smartcard żąda aktywacji smartcard.target. Ten z kolei w zależnościach demona pcscd i inne usługi przydatne w tej sytuacji. Jednocześnie może być aktywnych kilka celi, o ile mają niewykluczające się zależności.

W każdej chwili działania systemu można zrobić migawkę aktualnie aktywnych jednostek. Powrót to tego punktu działania systemu uzyskujemy poleceniem systemctl isolate [UNIT]. Aktywowane zostaną jednostki działające w momencie zrobienia migawki, pozostałe zostaną wyłączone. Odkrycie praktycznego zastosowania tego mechanizmu czeka jeszcze na uwagę badaczy.

Poprzednio: Usługi; Następnie: Gniazdka.

---

Archived comments:

Marcy 2012-05-01 12:59:59

This is the only time I've been to your website. Thanks for explaining more details.

RTFM: systemd.service

Do śmieci: skrypty sysvinit i upstart

Podstawową jednostką w systemd są usługi. Definiowane w plikach z rozszerzeniem .service, ładowanych, tak jak inne jednostki, z katalogów /lib/systemd/system/, /etc/systemd/system/, /usr/share/systemd/system/ i /usr/local/share/systemd/system/ dla usług systemowych. Usługi definiowane w ramach sesji użytkownika znajdują się w katalogach session.

Stwórzmy najprostszą usługę. W jednym z powyższych katalogów załóżmy plik touchme.service z następującą zawartością:

[Service]
ExecStart=/bin/touch /tmp/hey

To wystarczy. Załadowanie definicji tej usługi do systemd i jej uruchomienie:

# systemctl load touchme.service
# systemctl start touchme.service

W katalogu /tmp/ powinien pojawić się pusty plik hey.

To oczywiście tylko wierzchołek góry lodowej. Podaliśmy jeden parametr usługi — program do uruchomienia. Pełną kontrolę zapewnia ponad setka innych właściwości:

# systemctl show --all touchme.service | wc -l
109

Opis wszystkich znajduje się w na stronach manuala systemd.unit, systemd.exec i systemd.service. Wśród właściwości znajdują się również informacyjne, jak np. kiedy usługa została ostatni raz uruchomiona, zatrzymana itp. Jest też mnóstwo innych skarbów.

Dla porównania, w upstart definicja usługi pozwala podać wartość nice, poprawkę braną przez Out-Of-Memory killera i czy restartować usługę automatycznie. Definicja systemd załatwia te trzy rzeczy, a także:

• piorytet planisty wejścia/wyjścia
• wszystkie dostępne ulimity
• politykę schedulera CPU (w tym czas rzeczywisty, batch i idle) oraz priorytet w jej obrębie
• wymaganą dokładność timerów wyzwalanych przez jądro
• capabilities i securebits
• nazwę usługi intepretowaną przez PAM i tcp-wrappers
• czy wydzielać prywatny katalog /tmp/
• podobnie, które katalogi mają być udostępniane tylko do odczytu, do zapisu, a które w ogóle niedostępne (niezależnie od globalnej dostępności)
• czy zająć dla tego procesu nazwę na szynie D-Bus
• zawartość środowiska dla usługi
• użytkownik, grupy, katalog chroot()

Powyższe to opcje udostępniane przez jądro Linuksa. Systemd ściśle się integrując daje wygodny dostęp i ustalanie parametrów bez konieczności wywoływania tabunu programów pomocniczych.

Poprzednio: Wstęp ; Następnie: Cele i migawki.