-ENOTTY (Posts about Techblog)

Tak się powinno robić samochody

Tomasz Torcz — Mon, 25 Jan 2016 07:00:00 GMT

W weekend w końcu znalazłem trochę czasu na obejrzenie DEF CON 23 - Marc Rogers and Kevin Mahaffey - How to Hack a Tesla Model S. Potwierdziło się to, co czytałem wcześniej. Tesla naprawdę porządnie robi samochody.

Security IT mają zrobione bardzo dobrze zarówno wewnętrznie — izolowane podsieci CAN i infotainment z „firewallem” w postaci modułu gateway, szyfrowanie prawie wszędzie, użycie SSH do komunikacji między komponentami — ale również zewnętrznie: OpenVPN z dokładnym sprawdzaniem certyfikatów (keyUsage) itp. W przypadku „zabicia” elektroniki przez atakującego, samochodem nadal można kierować i działają hamulce.

Co prawda używają starego Ubuntu i było kilka drobnych niedoróbek, ale plusem Tesla Motors jest też sprawny system patchowania. I ekipa ludzi, którzy biorą IT Security poważnie. Poważniej, niż niektóre biznesy z którymi współpracowałem.

Prezentacja warto obejrzeć, sam chętnie bym zobaczył wycieczkę po serwerowni Tesla Motors i posłuchał więcej: jak zarządzają certyfikatami dla każdego samochodu, jaką mają infrastrukturę sieciową, jak przechowują i obrabiają telemetrię itp.

Archived comments:

sprae 2016-01-28 01:47:44

Dziękuję, też zobaczę.

Failure modes of incorrect Type= in systemd units

Tomasz Torcz — Wed, 08 Oct 2014 10:29:00 GMT

Proper supervision of daemons requires knowledge which cannot be inferred automatically. Some aspects of service behaviour have to be described by administrator. Widely used upstart system manager has 3 type-like job properties: expect daemon, fork and stop. Their description starts with a warning:

This stanza is extremely important: read this section carefully!

The warning is no less true with systemd's Type=.

Wrong type specification impacts service monitoring, failure detection and dependencies handling. There are six service types in systemd. Three basic ones (simple, forking, oneshot) and three more sophisticated (dbus, idle, notify).

Failure to set proper type may not bite you immediately. Service may run for minute or two and then get killed mysteriously. Services depending on wrongly specified one won't be started, even if it appears to run fine; but systemd won't consider the service ready and will not start dependent units.

Type highlights

simple - default type; daemon has to stay in foreground. Ready: as soon as the binary is executed (which may be too soon, service may not be ready to serve requests yet).
forking - daemon must fork. Ready: after first process exits. If PIDFile= is defined, readiness is delayed until PID is written to the pidfile.
oneshot - suitable for running scripts; systemd waits until process finishes. Ready: when main process exits.
dbus - for D-Bus services. Ready: when specified BusName= is acquired.
idle - like “simple” , but with delayed execution.
notify - most flexible and robust type; by defining simple communication protocol between daemon and systemd, precise information about state can be provided. Requires simple patching, for scripts you can use systemd-notify helper. Ready: when service says so.

Basic type determination

Suitable type can be guessed correctly in 75% cases by just running the daemon binary. If it stays in foreground, connected to the terminal, the type is “simple”. If it forks into the background, the type is “forking” (suprisingly!)

 # /usr/sbin/daemon
Copyright 2014 Foo Baz Bar Corp.
Serving Requests…

→ Type=simple

# /usr/sbin/otherdaemon
#

→ Type=forking

If you need to run a program/script which does its jobs and exits (does not stay running), use oneshot. Please note: if you can choose how the daemon behaves, it generally better to go with "forking". This makes systemd declare "ready" after daemon is actually able to accept connections.

Failure modes

Most of the failures shown below happen after TimeoutStartSec=. By default it’s set to 90 seconds, so lets stick with this value.

		simple	forking	oneshot	notify
		Incorrectly selected Type=
Correct type	simple	✓	killed after 90 s¹	stays in “activating” state forever²	killed after 90 s³
	forking	killed almost immediately⁴	✓	stays in “activating” state forever	killed after 90 s
	oneshot	becomes “failed” after executing⁵	killed after 90 s	✓	killed after 90 s
	notify	probably works fine	killed after 90 s	stays in “activating” state forever	✓

Notes:

systemd expects process to fork and parent to exit. It waits until timeout.
it never gets to the “ready” state, so no units depending on it will start; start timeout is ignored for “oneshot” units.
systemd will wait for ready notification. Until timeout.
”main” process exits
daemons should not exit, but “oneshot” units should

I hope that explains why sometimes systemd kills your service after a minute. Of course you should read man systemd.service, it contains much more details.

Partyzanckie utrzymywanie usługi w działaniu (z systemd)

Tomasz Torcz — Thu, 27 Mar 2014 11:46:00 GMT

Używam socket activation w systemd do odpalania demona FTPD. Plus jest taki, że jak na dłoni widzę wszystkie sesje i mogę je wybiórczo ubijać. Chociaż raczej nie ma potrzeby, bo użycie zasobów jest skutecznie limitowane mechanizmami z systemd.

$ systemctl | grep vsftp
  vsftpd@406-109.107.25.117:21-93.154.247.87:43126.service            loaded active running   vsftpd instance service for /vsftpd@406.service (93.154.247.87:43126)
  vsftpd.socket                                                       loaded active listening vsftpd incoming socket


$ systemctl status vsftpd@406-109.107.25.117:21-93.154.247.87:43126.service
● vsftpd@406-109.107.25.117:21-93.154.247.87:43126.service - vsftpd instance service for /vsftpd@406.service (93.154.247.87:43126)
   Active: active (running) since Thu 2014-03-27 11:40:13 CET; 1min 9s ago
   CGroup: /system.slice/system-vsftpd.slice/vsftpd@406-109.107.25.117:21-93.154.247.87:43126.service
           ├─11643 vsftpd: ::ffff:93.154.247.87: connected
           └─11645 vsftpd: ::ffff:93.154.247.87/ftp: RETR pidora-18-r1c.img

Jest też niestety minus — jeśli demon vsftpd kilkukrotnie zakończy działanie błędem, to w końcu systemd wyłączy nasłuchujące gniazdko.

Przydałaby się więc automatyka włączająca je z powrotem. W pierwszym odruchu zrobiłem parę jednostek, które używają curl do sprawdzenia stanu usługi:

$ cat ftp-check.timer
[Timer]
OnCalendar=hourly

[Install]
WantedBy=vsftpd.socket

$ cat ftp-check.service
[Unit]
OnFailure=vsftpd.socket

[Service]
ExecStart=/usr/bin/curl --silent --noproxy localhost ftp://localhost:21 -o /dev/null

Jak to działa? Jednostka timer:

aktywowana jest co godzinę
polecenie enable spowoduje, że zaczyna działać razem z vsftpd.socket
ponieważ nie ma explicité podanego co jest włączane przez timer, to aktywowana jest usługa o takiej samej nazwie: ftp-check.timer->ftp-check.service

Działanie "usługi sprawdzającej" również zawiera się w kilku punktach:

start usługi powoduje próbę połączenia curlem do FTP
po zakończeniu curla sprawdzany jest jego kod wyjścia:
- jeśli połączenie przebiegło pomyślnie, ftp-check.service po prostu się kończy
- jeśli curl nie mógł się połączyć, to kod wyjścia wskazuje na błąd; usługa przechodzi w stan failed; ponieważ zdeklarowano OnFailure=, błąd powoduje, że systemd aktywuje wskazaną jednostkę. Powoduje to ponowne wprowadzenie gniazdka vsftpd w stan nasłuchujący — powrót do normalnego działania

Rozwiązanie działa, jednak z opóźnieniem. Zastanowiwszy się nad tym, wpadłem na prostsze rozwiązanie:

$ cat vsftpd@.service
[Unit]
Description=vsftpd instance service for %c
OnFailure=vsftpd.socket
[...]

W ten sposób padający vsftpd sam od razu podnosi gniazdo.

A tak w ogóle to yum install icinga.

Trimming legacy fat with systemd

Tomasz Torcz — Wed, 17 Jul 2013 19:42:00 GMT

Recently, Michael Stapelberg prepared a detailed listing of systemd's component sizes. It clearly shows how much space is really required, and how much space can be saved by giving up various optional components of systemd. It's a nice document. On the other hand, how much we can save by dropping legacy shell utilities?

Let's take some hypothetical system not designed to be accessed interactively by sysadmin. You may call it embedded, you may call it minimal cloud image or just specialised spin/just-enough-OS. We are going to remove all the tools which duplicate functionality already provided by systemd.

Directive	Obsoleted utility	Utility size in bytes
WorkingDirectory	/usr/bin/cd	26 bytes - shell builtin
RootDirectory	/usr/sbin/chroot	37 112
User, Group, SupplementaryGroups	/usr/bin/su	32 032 suid!
Nice	/usr/bin/nice	35 776
IOSchedulingClass, *Priority	/usr/bin/ionice	22 928
CPUSchedulingPolicy, *Priority	/usr/bin/chrt	27 968
CPUAffinity	/usr/bin/taskset	31 464
UMask	/usr/bin/umask	29 shell builtin
Limit*	ulimit	shell builtin
Capability*	/usr/sbin/setcap	14 024
InaccessibleDirectories	/usr/bin/unshare	14 992
RuntimeWatchdogSec	/usr/sbin/watchdog	88 752
Listen*	/usr/sbin/xinetd	178 872
OnCalendar	/usr/sbin/crond /usr/sbin/atd /usr/bin/at	66 016 28 648 53 812 suid!

Above binaries are needed because they’re doing something plain shell scripts can’t do – syscalls. Growing number of Linux API can be manipulated by means of echo, mkdir and ln, but there always will be need for some syscalls.

By removing legacy utilites, we save total of (magical) 640 kilobytes. Not much. Probably not worth the hassle. What else can we remove? /usr/sbin/hostname (20 304 bytes)? start-stop-daemon? vcsonsole setup, quotacheck, sysctl, cryptsetup, syslog, acpid?

Sizes were collected on Fedora 20 amd64 system.

Archived comments:

Stanisław 'dozzie' Klekot 2013-07-17 23:32:33

Erm.
/usr/bin/cd -- What is this? I've never seen such binary (probably because it's impossible to expose chdir() as an external command).
/usr/bin/umask -- The same. What is it?
/usr/bin/su, which is rarely located in /usr/bin, is pretty much required anyway for any system that is not horribly crippled (mainly for interactive use; I do not consider it a tool to use in scripts).

syslog virtually cannot be removed from system. systemd's journald is not (and doesn't seem to be going to be) a sensible solution for general-purpose logging and it focuses on collecting logs on a single host. Unattended or embedded system should be able to log to some remote destination.

And all the rest of your breakdown, it's actually useless. You try to measure size of executables for purposely-built system, but you take references from a desktop OS. You haven't even scratched surface of special purpose systems (BusyBox anyone?).

zdz 2013-07-18 08:38:04

% cat /usr/bin/umask
#!/bin/sh
builtin umask "$@"

And other builtins in similar manner.
For busybox, I'm not sure if it provides ”enough Linux” to run systemd.

Stanisław 'dozzie' Klekot 2013-07-18 10:10:25

Okay, and how do you expect that to affect *parent* process you issued the command in? Because bash and zsh don't take the shortcut of trying to execute the script in the same process.

shasta 2013-07-18 20:48:45

dozzie, you say that syslog cannot be removed? Well, apparently Lennart sees things differently ;-)
http://thread.gmane.org/gmane.linux.redhat.fedora.devel.announce/1117/

Stanisław 'dozzie' Klekot 2013-07-18 21:05:19

Of course he sees things that way. He is the creator of journald. But hey! Suddenly there is still a need for syslog!

Journald can't operate sensibly in installations intended for no interactive sessions. There just has to be remote logging possibility, and that journald doesn't provide.

Journald is pretty much only good for desktop cases. It will do for Fedora, as I don't know of anybody using it on servers anyway, but it's way too crippled logging solution to replace syslog altogether.

You may read a bit of Rainer Gerhards' articles about journald, shasta. He's the author of rsyslog, so he is biased the other way (but very little, I think) -- this should straighten your view on logging.

shasta 2013-07-18 23:04:43

Why do you think my view on logging needs straightening? :-) I didn't say I agree with Lennart.

I am a big fan of syslog-ng, plus - as a long time Slackware user I don't see journald/systemd crawling into my bed anytime soon. Honestly, I'm just a spectator for this whole systemd drama, watching it from a safe distance. ;-)

And as for work, well, I will always have to deal with some sort of crap anyway, so whether this is Solaris 8 or systemd - doesn't make much of a difference to me ;-)

Więc, często tak sobie benchmarkujesz?

Tomasz Torcz — Mon, 15 Apr 2013 13:14:00 GMT

Do tematu wspomagania wolnego dysku mechanicznego szybkim SSD wracam trzy lata później. Celem jest sprawdzenie jak sobie radzi i ile daje dostępne w jądrze linuksa dm-cache.

Co potrzeba?

dysk wolny — udział bierze dysk 5400 RPM 160GB
dysk na cache, czyli partycja 5GiB na Samsung SSD 830
dysk na metadane — partycja 32MiB na powyższym SSD

Pokusiłem się o test real-life. Na wolnym dysku znajdują się obrazy maszyn wirtualnych. W czasie testu w jednej z nich robiona był aktualizacja dwóch pakietów — kernel oraz fedup — oraz usunięcie trzeciego preupgrade. Po aktualizacji cofnięcie tranzakcji. Pomiar wykonany 5 krotnie, skrajne wyniki odrzucone, pozostałe uśrednione. Następnie włączenie cachu na SSD i powtórzenie procedury.

Środowisko:

host: Fedora 18 Spherical Cow z jądrem 3.9.0-0.rc6.git0.1.fc19.x86_64
gość: Fedora 20 Rawhide

Instalacja:

 fedup     noarch      0.7.3-2.fc20               rawhide     67 k
     replacing  preupgrade.noarch 1.1.11-3.fc19
 kernel    x86_64      3.9.0-0.rc6.git0.1.fc20    rawhide     27 M

Pomiar:

% time yum history redo 558 -y
% time yum history undo 558 -y

Decyzje i konfiguracja

Rozdzielenie urządzenia dla metadanych i właściwego cache ma na celu zwiększenie elastyczności rozwiązania. O ile dobór wielkości cache jest prosty (im więcej tym lepiej), to jak z nośnikiem metadanych? Do tego służy następująca reguła:

4MiB + (16bytes * nr_blocks)

A wielkość bloku? To już zależy od charakterystyki obciążenia. Ja przyjąłem “na oko” blok wielkości 64KiB. Przy urządzeniu cache wielkości 5GiB, otrzymujemy porywające zapotrzebowanie 5,25 MiB.

Mamy więc już prawie wszystko: urządzenie do przyspieszenia (sdb), partycję na cache (sda5), partycję na metadane (sda6) i wielkość bloku (64KiB czyli 128 sektorów po 512 bajtów). Potrzebujemy tylko wielkości urządzenia sdb w sektorach:

% blockdev --getsz /dev/sdb 
312581808

Możemy więc utworzyć, zamountować cache i przejść do pomiarów:

% dmsetup create fusiondrive --table '0 312581808 cache /dev/sda6 /dev/sda5 /dev/sdb 128 1 writeback default 0'

% mount /dev/mapper/fusiondrive /var/lib/libvirt/images -o subvol=var_lib_libvirt_images

Wyniki i intepretacja

Zero. Żadnej zauważalnej różnicy. O ile jeszcze procent trafień przy zapisie oscylował w okolicach 4%, to przy odczycie średnia wyszła 0,12%. Czasy sys i user zbliżone - okolice 40s i 50s dla instalacji, w granicach 2,5s dla deinstalacji. Czas real - duży rozrzut, do 83s do ponad 330s. Całkowicie bezużytecznie, nawet nie ma co wykresów robić.

Winny 1 - time yum

Instalacja jądra wydawała się dobrym pomysłem do momentu spojrzenia na wykresy zajętości zasobów przez maszynę wirtualną. Gros czasu obciążenie 100% CPU przy minimalnym użyciu dysku. Powodem było tworzenie obrazu initramfs, a użycie CPU wynika z tworzeni i kompresji pliku cpio. Przydatność do testowania wejścia/wyjścia — żadna. Dodatkowo, yum większość czasu spędzał śpiąc i czekając na procesy potomne wykonujące prawdziwą pracę, w tym czasie nie był mu naliczany czas.

Winny 2 - system plików btrfs

Zarówno dysk sdb, na którym znajduje się obraz maszyny wirtualnej, jak i sama maszyna skonfigurowane są z btrfs. Jest to system plików typu copy-on-write, co oznacza, że dane nigdy nie są nadpisywane. Zapis polega na odczycie danych, zapisaniu zmodyfikowanej kopii gdzieś indziej i uaktualnieniu wskaźników na dysku. Odniesienia do oryginalnej kopii danych znikają (o ile nie ma snapshotów).

Cache działający na poziomie bloków danych nie ma pojęcia, że wrzuca do pamięci podręcznej bloki, do których system plików już nie będzie wracał. Taka już jego uroda, ma ten problem dm-cache, ma go bcache, będzie miał każdy inny. btrfs nie nadaje sie do akceleracji w ten sposób. Dopiero wbudowanie mechanizmów cache SSD w sam btrfs da jakieś sensowne wyniki. Może nawet porównywalne z osiągami ZFS.

W skrócie: benchmarkować to trzeba umieć, panoczku.

Archived comments:

DeHa 2013-04-15 15:19:11

Czyli eksperyment dowiódł, że btrfs jest faktycznie CoW. ;)

zdz 2013-04-15 15:29:57

Mooooo!

LCF 2013-04-15 16:00:35

Huh,

A nie prościej wszystko przemigrować na SSD, zamiast jakieś wynalazki z cachami ?

zdz 2013-04-15 17:00:45

Oczywiście, że łatwiej i za parę lat ekonomicznie to będzie uzasadnione. Na dzień dzisiejszy rozwiązania pamięci hierarchicznej sprzedają się dobrze.

tap 2013-11-25 14:43:31

Zrobiłem teścik bcache - taki organoleptyczny.

Bcache na 2x 120GB SSD (samsung pro i kingston jakiś szybki) w raid1 na linuxowym md + 4x 1TB Segate w raidz1 i na tym zfs.

Bez ssd-ków trzy chodzące równolegle tary powodowały zawał systemu. Load szedł w kosmos, próba zrobienia zfs list kosztowała czasem nawet kilkanaście sekund.

Z bcache 10 chodzących równolegle tarów, load na poziomie 2-3 (8 fizycznych rdzeni HT, więc znikomy), system reponsywny, nadal możliwe było dowalenie jakiejś jeszcze operacji dyskowej. Co ciekawe, 10 tarów wykonało się szybciej (182s) niż 3 tary (270s).

bcache fkoz jako write-back - dlatego na MD, dlatego na dwóch różnych SSD.

zdz 2013-12-18 13:35:31

Przecież ZFS ma natywną obsługę cache na SSD, dlaczego przez bcache?

Pożegnanie z em1

Tomasz Torcz — Wed, 09 Jan 2013 08:08:00 GMT

Przyzwyczaili się już do em1 i podobne w miejsce eth0? Jeśli nie, to dobrze, bo wygląda na to, że znowu się zmieni.

Kay Sievers zaimplementował w udev nowe polityki nazewnictwa, znacznie rozszerzające ofertę biosdevname. Admin ma do wyboru kilka sposobów określania nazwy sieciowej wraz z możliwością wyłączenia tego w cholerę.

Wbudowane sieciówki ethernetowe już nie będą emX, a enoX. Dokładane mogą mieć nazwę zależną od "hotplug id" slotu (ensX) bądź od id gniazda PCIe (enpXsY). Oczywiście urządzenia wielofunkcyjne nazwy mają odpowiednio dłuższe, jak enpXsYfZ.

Dla hardcorowców pozostają nazwy z osadzonym adresem MAC - wwx028037ec0200 (tutaj ww jest przedrostkiem urządzenia WWAN; jak łatwo się domyślić, en w poprzednich przykładach oznacza Ethernet).

Szerszy opis na wiki oraz w kodzie źródłowym.

Linux automatic user ACL management

Tomasz Torcz — Wed, 23 May 2012 17:22:00 GMT

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:

[a movie!]

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.

systemd: Jolu, pokaż Panom cel

Tomasz Torcz — Thu, 08 Mar 2012 10:16:00 GMT

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.

Haczyki przy upgrade do 64 bitów

Tomasz Torcz — Thu, 09 Feb 2012 09:29:00 GMT

Dekadę po wprowadzeniu architektury AMD64 przerobiłem w końcu ostatnią z moich maszyn na dystrybucję 64-bitową. Sprzęt był capable od dawna, ale jego wymiana odbyła się metodą transplantacji dysków ze starego komputera i nie było kiedy zmienić softu.

Procedura jest prosta. Instalujemy kernel 64 bitowy, uruchamiany z niego system z 32-bitowym userlandem i reinstalujemy wszystkie pakiety po kolei w wersjach x86_64. Userland 32 na jądrze 64 działa sprawnie nawet na x86, ale trzeba mieć na uwadze trzy drobiazgi:

Automount ma rozbieżne wielkości strukturki danych między 32 a 64 bity. Owocuje to zawieszeniem w czasie uruchamiania systemu 32 bit na jądrze 64 bit. Pamiętać należy o wyłączeniu automountów przed takim bootem.

RRD nie lubi baz stworzonych na innej architekturze. Tu warto zrobić rrdtool dump do xml na 32 bitach, a po upgradzie rrdtool restore.

PostgreSQL też nie lubi plików baz danych utworzonych na innej architekturze. Podobnie jak z RRD, najpierw pg_dumpall, a po upgradzie initdb i psql -f dump.sql.

Inny soft na razie problemów nie wykazuje. Zapomnienie o zrzutach może zawocować drapaniem się w głowę podczas poszukiwania jakieś jeszcze działającej 32 bitowej instalacji, żeby dokonać ich post factum. Ale na szczęście wystarcza pendrive USB z zainstalowaną 32 bitową instalacją i katalogi baz danych wyeksportowane przez NFS.

Archived comments:

Remigiusz 'lRem' Modrzejewski 2012-02-09 14:56:56

Tak właściwie, to po co to zrobiłeś?

Stanisław 'dozzie' Klekot 2012-02-09 16:27:24

Nie wiem jakie były faktyczne powody, ale jednym bardzo dobrym jest możliwość pozbycia się ostatniego hosta x86. Dla administratora to na przykład brak konieczności przygotowywania pakietów na jedną więcej architekturę.

zdz 2012-02-09 17:16:34

lrem: jak dozzie pisze, odstawało od reszty. I ma 8GB RAM, niedlugo moze 16, uzywanie PAE smierdzi troche.
Z dziwnych rzeczy, po upgradzie zaczela dzialac wetknieta kiedys karta TV na chipie bttv - pewnie wczesniej cos z przestrzenia adresowa nieteges było.

rozie 2012-02-09 18:43:50

Jeśli dobrze kojarzę skorzytsałeś z bardzo niezalecanej metody upgrade'u systemu (BTW jakie distro?). W sumie jakie zalety w stosunku do odpalenie z live i przywrócenie systemu z backupu?

zdz 2012-02-10 09:05:50

rozie: z zupelnie niezalecanej, chyba żadne distro nie wspiera zmiany architektury. Fedora na pewnie nie :).
Zalety takie, że ciągłość pracy (czyt. dostępu do internetu i rozrywki, w trakcie oglądałem film na rzeczonym komputerze).
Przywracanie z backupu wiąże się też z instalowaniem od nowa wszystkiego, co się przez prawie 3 lata (od http://enotty.pipebreaker.pl/2009/06/16/goodbye-foresight/) zbierało, a czego nie ma w domyślnej instalce. A dumpy np. RRD i tak trzeba by było zrobić (bo backupują się u mnie binarne bazy).
W skrócie: oszczędność czasu.

zdz 2012-02-19 19:00:10

Tak za 64 bitami jeszcze:
nasty FPU state corruption issue that happened only when the wireless stack used the AES-NI instructions from softirqs on 32-bit x86.

Moral of the story: don't use 32-bit kernels on modern CPU's that could do so much better.
z https://plus.google.com/109995262342451767357/posts/KGijJrUZQ7j

Pamiętam jakiś czas temu było też priviledge escalation, które działało na 32 bitach, a na 64 - z uwagi na organizację pamięci - nie działało.

W którą stronę ewoluuje konfigurowanie Linuksa...

Tomasz Torcz — Mon, 16 Jan 2012 20:41:00 GMT

Ostatnio przemigrowałem z tgt na nowy, lepszy, wbudowany w jądro LIO. Chodzi o cel SCSI. Po robocie odsunąłem się od monitorów, spojrzałem na stary config, spojrzałem na nowy i naszła mnie refleksja.

Czy przejście z takiego sposobu konfigurowania:

vendor_id UTC FS Support
product_id Linux iSCSI

# Set the driver. If not specified, defaults to "iscsi".

default-driver iscsi

<target iqn.2010-08.com.fs.utc:dvdtmp>
        backing-store /dev/mapper/sabretoothvg-iscsi.dvdtmp
</target>

<target iqn.2010-08.com.utc.fs:winxppp45client-stor1>
        backing-store /dev/sabretoothvg/iscsi.winxppp45client-stor1
</target>

<target iqn.2011-02.com.utc.fs:esxi.local-space0>
        backing-store /dev/sabretoothvg/iscsi.esxi.local-space0
</target>

<target iqn.2011-02.com.utc.fs:fcoe.test0>
       backing-store /dev/mapper/sabretoothvg-fcoe.test0
       allow-in-use yes
</target>

na taki (uwaga, ściana tekstu):

#### Parameters for TCM subsystem plugin storage object reference
python /usr/lib/python2.6/site-packages/rtsadmin/tcm_node.py --establishdev iblock_0/iblock0 /dev/sabretoothvg/fcoe.test0
python /usr/lib/python2.6/site-packages/rtsadmin/tcm_node.py --setunitserialwithmd iblock_0/iblock0 72ad13f0-c8d2-4d96-bffe-30f9cfc46f2f
#### Parameters for TCM subsystem plugin storage object reference
python /usr/lib/python2.6/site-packages/rtsadmin/tcm_node.py --establishdev iblock_1/gilbertus.swap /dev/sabretoothvg/iscsi.gilbertus.swap
python /usr/lib/python2.6/site-packages/rtsadmin/tcm_node.py --setunitserialwithmd iblock_1/gilbertus.swap 7e05140f-6536-4813-a1a0-d9fdc3b7bca8
#### Parameters for TCM subsystem plugin storage object reference
python /usr/lib/python2.6/site-packages/rtsadmin/tcm_node.py --establishdev iblock_3/esxi.local-space0 /dev/sabretoothvg/iscsi.esxi.local-space0
python /usr/lib/python2.6/site-packages/rtsadmin/tcm_node.py --setunitserialwithmd iblock_3/esxi.local-space0 5bcaffac-6da0-42b0-ad07-fe130609674
#### iSCSI Target Ports
mkdir -p /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/lun/lun_0
ln -s /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/lun/lun_0/../../../../../../target/core/iblock_0/iblock0 /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/lun/lun_0/6efd3cb027
lio_node --aluasecmd iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd 1 0
mkdir -p /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/lun/lun_1
ln -s /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/lun/lun_1/../../../../../../target/core/iblock_4/winxppp45client-stor1 /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/lun/lun_1/1d6312ea35
lio_node --aluasecmd iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd 1 1
#### iSCSI Initiator ACLs for iSCSI Target Portal Group
mkdir -p /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/acls/iqn.1994-05.com.fedora:5f21153a55f
echo 16 > /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/acls/iqn.1994-05.com.fedora:5f21153a55f/cmdsn_depth
mkdir /sys/kernel/config/target/fc
#### fc Target Ports
mkdir -p /sys/kernel/config/target/fc/20:00:00:23:ae:b2:f4:3b/tpgt_1/lun/lun_0
ln -s /sys/kernel/config/target/fc/20:00:00:23:ae:b2:f4:3b/tpgt_1/lun/lun_0/../../../../../../target/core/iblock_0/iblock0 /sys/kernel/config/target/fc/20:00:00:23:ae:b2:f4:3b/tpgt_1/lun/lun_0/b522dc7322

to naprawdę jakiś postęp? Powyżej to drobny fragment, całość ,,nowości'' ma prawie pół tysiąca linii i postać skryptu, który odtwarza ustawienia przez wykonanie wszystkich katalogów i dowiązań symbolicznych.

Do LIO dostępny jest targetcli, będący tak naprawdę kolorową nakładką na mkdir, ln i touch. Ja rozumiem, że wszystko jest plikiem, ale naprawdę zajęło mi pół godziny wpadnięcie na intuicyjny sposób określenia IP, na który jądro ma słuchać. (Tym sposobem jest utworzenie katalogu, dokładniej mkdir -p /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/np/192.168.6.9:3260).

Plik konfiguracyjny jest dla mnie czymś solidnym. Skrypt zastępujący go setkami poleceniem powłoki sprawia wrażenie sznurka i taśmy klejącej.

UPDATE: Ktoś jednak stwierdził, że lepsze będzie trzymanie konfiguracji w JSON. No cóż, ma szansę sprawdzić się lepiej niż skrypt shellowy.

Archived comments:

DIVI 2012-01-17 06:04:11

Panie, a ile wojny było o ten target.

Deweloper konkurencyjnej implementacji gdy go nie wybrano strzelił potwornego focha i jest teraz wojna idelologiczna.

Argumentacja opiekuna podsystemu storage też była mało merytoryczna i bardziej się operała o to że ten "wygrany" jest gorszy ale ma bardziej uległych i skorych do ustępstw developerów.

To wszystko jest jeszcze pikuś, ale ten config to już jest parodia.

Nie podobie mnie się.

DIVI 2012-01-17 06:07:13

To tak apropos: http://lwn.net/Articles/424004/

l00natyk 2012-01-17 14:48:04

Mam wrazenie ze w niedalekiej przyszlosci ktos napisze skrypt ktory pobiera dane ze starego konfigu i bedzie tak samo tylko ze inaczej.

yZZuF 2012-01-20 09:48:57

Wygląda jakby się ktoś puścił poręczy.

systemd: stadko zamieniających Uniksa demonów

Tomasz Torcz — Thu, 04 Aug 2011 13:54:00 GMT

Czytając o systemd można czasem przeoczyć większą wizję. Celem nie jest jedynie napisanie kolejnego zastępcy inita. To tylko element całości, którą jest zdefiniowanie (również poprzez stworzenie) platformy Linuksowej. Ostatecznie będzie można powiedzieć, że ,,w Linuksie''

jest ustawiona nazwa hosta
listę zalogowanych użytkowników uzyskujemy przez systemd-loginctl list-sessions
startujemy usługi na żądanie tworząc definicje .socket
usługi potrzebujące haseł korzystają ze zdefiniowanej metody pytania
unikalny identyfikator systemu można odczytać z /etc/machine-id
itp.

I to zawsze. Dostawca oprogramowania nie będzie musiał tworzyć zawiłych skryptów sprawdzających czy używamy xinetd, inetd czy jeszcze czegoś innego. Osuszanie bagienka różnic między dystrybucjami powinno ułatwić dostarczanie oprogramowania firmom trzecim.

Aby osiągnać ten cel, systemd dostarczany jest wraz z garścią pomocniczych programików pojedynczego zastosowania. Część ujednolica czynności wykonywane we wszystkich dystrybucjach, część implementuje nowe mechanizmy mające stać się API Linuksa. Najprostsze (ograniczające się do pojedyńczych syscalli) wbudowane są w samą binarkę systemd.

Do czego zacząć się przyzwyczajać?

hostname1 — dostępna przez D-Bus usługa zarządzająca krótką oraz opisową nazwą komputera; konfigurowana w /etc/hostname
systemd-localed — dostępne przez D-Bus ustawianie języka systemu; konfigurowane w /etc/locale.conf
systemd-timedated — D-Bus; ustawianie czasu, daty, strefy czasowej; konfiguracja w /etc/adjtime, /etc/timezone, /etc/locatime
systemd-vconsole-setup — ustawienie układu klawiatury i fontu na konsoli tekstowej; konfiguracja w /etc/vconsole.conf
systemd-binfmt — konfiguracja jak traktować różne pliki wykonywalne; katalog z konfiguracją: /etc/bindfmt.d
systemd-tmpfiles — tworzenie plików, katalogów i gniazd przy starcie systemu; również kasowanie starych, nie używanych plików; konfiguracja z /usr/lib/tmpfiles.d i /etc/tmpfiles.d
systemd-sysctl — ustawienie zmiennych jądra; konfiguracje z katalogów {/usr/lib,/etc,/run}/sysctl.d i pliku /etc/sysctl.conf
systemd-modules-load — ładowanie modułów jądra; pliki konfiguracyjne w /etc/modules-load.d
systemd-kmsg-syslogd — minimalny demon zapamiętujący informacje przed uruchomieniem właściwego syslogd
systemd-random-seed — inicjacja puli entropii generatora pseudolosowego; również zapisanie stanu przy wyłączaniu komputera

Wydzielenie tych drobiazgów ze skryptow startowych umożliwia:

ujednolicenie zachowania wszystkich dystrybucji Linuksa
ujednolicenie sposobów np. zmiany nazwy komputera na wszystkich dystrybucjach
uruchamianie powyższych czynności jednocześnie
uruchamianie w razie potrzeby w trakcie działania komputera (np. pojawienie się nowego pliku w /etc/binfmt.d)

Ważnym nowością jest systemd-loginctl i skojarzony /etc/systemd/systemd-logind.conf zarządzajacy sesjami użytkownika. Odpowiada m. in. za automatycznie uruchamianie getty na konsolach, na które przełącza się użytkownik. Login manager daje informacje o zalogowanych użytkownikach, aktywnych sesjach i także pilnuje sprzątania procesów po użytkownikach wylogowanych. Poleceniem systemd-loginctl enable-linger można zażyczyć sobie uruchamiania sesji dla zwykłych użytkowników przy starcie systemu.

systemd-logind zarządza również wszystkimi zestawami klawiatura+mysz+monitor+inne urządzenia, ułatwiając pracę wielu użytkowników jednocześnie. Jest to efekt zapowiadanego pozbycia się ConsoleKit.

Archived comments:

abc 2011-08-04 17:10:38

... tylko czemu ten systemd nie działa w chroocie (cały system, a nie tylko usługa) ani w vserverowym gueście? :-/

Remigiusz 'lRem' Modrzejewski 2011-08-04 17:16:06

Nie działa w gueście? No to pozamiatane...

m 2011-08-04 17:23:05

I dlaczego wymaga dbusa?

zdz 2011-08-04 17:43:49

abc: jak nie działa? Ma problem z zamountowaniem katalogów czy coś innego? Jak używasz "systemd-nspawn" jako helpera chrootowego to też jest problem?

m: bo wymaga IPC. Można było użyć czegoś znanego, przetestowanego i zdebugowanego (D-Bus) albo wymyślać koło samemu.

abc 2011-08-04 18:39:07

zdz: w gueście vservera nie masz uprawnien do montowania czegokolwiek w najczęstrzym przypadku. chroot jest dużo mniej interesujący więc go pomińmy.

d33tah 2011-08-05 10:37:36

http://xkcd.com/927/

systemd: modyfikacja jednostek

Tomasz Torcz — Mon, 20 Jun 2011 13:27:00 GMT

W życiu zachodzi czasem potrzeba modyfikacji skryptów startowych (jednostek systemd). Co jeśli mamy jakiś niepełnosprawny program i chcemy opóźnić jego uruchomienie, a nie możemy tego wyrazić poprawnymi zależnościami?

Systemowe (dostarczane przez dystrybucję) skrypty startowe znajdują się w /lib/systemd/system. Administrator nie powinienen ich ruszać, za to może przesłonić skrypt systemowy swoim, umieszczając go w /etc/systemd/system. Skrypt z /lib wygląda następująco:

[Unit]
Description=uses CDP / LLDP frames to inform switches about connected hosts
Requires=network.target

[Service]
EnvironmentFile=/etc/sysconfig/ladvd
ExecStart=/usr/sbin/ladvd -f $LADVD_OPTIONS
PIDFile=/var/run/ladvd.pid
StandardOutput=syslog

[Install]
WantedBy=multi-user.target

Przepisywanie całości jest niezdrowe, dużo roboty i możliwe rozjechanie gdy aktualizacja zmieni systemową jednostkę. W takich sytucjach najlepiej posłużyć się dyrektywą .include:

.include /lib/systemd/system/ladvd.service

[Service]
ExecStartPre=/bin/sleep 20s

[Install]
WantedBy=multi-user.target

Pierwsza linijka zaciąga całą treść oryginalnej jednostki. Sekcja [Service] wprowadza interesującą nas zmianę. Końcowka jest potrzebna do korzystania z systemctl enable/disable.

Inny przykład: dodanie zależności, wpływa na kolejność startu. Tworzymy /etc/systemd/system/radvd.service z zawartością:

.include /lib/systemd/system/radvd.service

[Unit]
After=aiccu.service

3.0 zalicza czy psuje

Tomasz Torcz — Tue, 07 Jun 2011 08:40:00 GMT

Wraz ze zmianą numeracji jądra pojawiło się kilka problemów z programami spodziewających się numeracji x.y.z. Brak trzeciego numerka odczuły jak dotąd:

lvm2 — efektem jest problem z bootowaniem, naprawiony już w najnowszej wersji
mdadm też krztusi się z dwucyfrowym numerkiem
distributed.net client nie startuje, wysypuje się na inicjalizacji timerów
aktualizacji wymagały module-init-tools w Fedorze

3.0 udostępnia też katalog /sys/fs/selinux. Biblioteki SELinuksa korzystają z niego w pierwszej kolejności przed /selinux. Zmiana punktu mountowania zaskoczyła systemd, co kończy się pętlą komunikatów loading policy przy uruchomieniu. Poprawka już jest, w międzyczasie zbootować można dodając selinux=0 do linii poleceń jądra.

A czy Twój kod radzi sobie z nowym numerkiem? I w ogóle po co mu ta informacja, powinien sprawdzać obecność wymaganych ficzerów, a nie numer wersji.

Archived comments:

gentooGangsta 2011-06-07 11:56:56

jaki programista taki koT ;]

moher 2011-06-07 12:20:10

Samo sprawdzenie obecności ficzera nie zawsze wystarczy, przykładem mogą być dwie wersje jajka z danym ficzerem i bonusowym bugiem, który trzeba obejść w jednej z nich. Nie zawsze sprawdzanie wszystkich możliwych bugów w danym ficzerze jest optymalne.

trasz 2011-06-22 22:18:48

Ciekawe, kiedy developerzy Linuksa wynajdą getosreldate(), które pozwala unikać tego typu problemów.

zdz 2011-06-23 18:44:45

trasz: kosztem innych problemow? x.y.z.bignum zazwyczaj wydawane jest sporo po x.y.z+1.

/run Forest, /run

Tomasz Torcz — Wed, 30 Mar 2011 16:36:00 GMT

Linuksowi administratorzy w nadchodzących wydaniach swoich ulubionych dystrybucji natkną się na nowy wpis w katalogu głównym. Będzie to /run.

Katalog /run jest dostępny zaraz po zamountowaniu głównego /, przed pojawieniem się /var, który może być na osobnym wolumenie. Zawiera rzeczy odnoszące się do aktualnie działających program‎ów i usług (nie przechowuje wpisów przy reboocie). Są to:

pliki blokad (/run/lock, dostępne również jako /var/lock)
różne pliki uruchomieniowe, dotąd w /var/run
zbiór rzeczy do tej pory ukrywanych w .katalogach w /dev:
- dane udev z /dev/.udev
- informacje przekazane przez programy z initramfs, działające przed zamountowaniem /, dotąd w /dev/.initramfs
- informacje z systemach plików z /dev/.mount/utab (wszystko to, co nie jest zawarte w /proc/self/mounts)
- pliki kontrolne w /dev/.systemd
- pliki tymczasowe z /dev/.mdadm
pamięć podręczną z /etc/lvm2/cache

A także inne pliki tworzone przez dracut, plymouth, bootchart i wszystkie programy, które do tej pory potrzebowały takiego miejsca. Użycie /dev było podyktowane obecnością tego katalogu od samego początku uruchamiania systemu. Nie do końca prawidłowe jest jednak przechywanie w /dev wpisów nie będących urządzeniami, a zwłaszcza ukrywanie ich kropką w nazwach.

Poza nadużywaniem /dev, dystrybucje do problemu podchodziły różnie. Debian daje /lib/init/rw, który z kolei narusza przestrzeń /lib dla bibliotek. Ubuntu udostępnia /var/run i /var/lock przy starcie, a przy mountowaniu właściwego /var dokonuje przypięcia (bindmount). Jest to jednak rozwiązanie podatne na wyścigi.

Wynik międzydystrybucyjnych uzgodnień ogłosił Kay Sievers, jednocześnie odpowiedzialny za wdrożenie tego rozwiązania w SUSE. Zawtórował mu Scott James Remnant, opiekun upstart i członek rady technicznej Ubuntu. Rozwiązanie wdrożyła Fedora, poddane zostało również pod dyskusję w Debianie.

Nasuwać się może pytanie, co z File Hierarchy Standard? Wersja 2.3 nie zakazuje, jednak wymaga rozwagi:

Distributions should not create new directories in the root hierarchy without extremely careful consideration of the consequences including for application portability.

Twórcy najważniejszych dystrybucji porozumieli się między sobą i stosowna poprawka do FHS została zgłoszona. Ostatecznie będziemy mieli: /var do rzeczy zmiennych, dostępnych pomiędzy restartami i /run dla tych mających sens jedynie w działającym systemie (wskazane więc użycie tmpfs). Coraz bliżej jest do umożliwienia funkcjonowania systemu z kluczowymi katalogami (/usr, /etc itp.) zamountowanymi w trybie tylko-do-odczytu.

Archived comments:

liori 2011-03-30 18:38:34

Aaa... czym to się różni od /tmp? Tym że dane w środku będą jakoś konkretnie poukładane?

zdz 2011-03-30 18:42:43

/tmp też może znajdować się na osobnej partycji lub wolumenie wymagającym zachodu (składanie RAID, logowanie iSCSI itp). /tmp nie daje gwarancji, że dane tam zapisane nie znikną pomiędzy dwoma uruchomieniami programu. W końcu /tmp może być odrębne dla każdego użytkownika (chociaż /run jest dla rzeczy systemowych, nie związanych z użytkownikiem). I tak, /run ma odrobinę bardziej sformalizowaną zawartość.

mh 2011-03-30 18:49:27

Ja bym poszedł na całość:
runfs on /run type runfs

Stanisław 'dozzie' Klekot 2011-03-31 11:52:51

> Debian daje /lib/init/rw, który z kolei narusza przestrzeń /lib dla bibliotek

Osobiście bym się tym nie przejmował. Kernelowe moduły też naruszają tę przestrzeń, podobnie jak firmware dla modułów, baza terminfo (pod Debianem) czy binarki i skrypty udeva.

Bye bye, suid

Tomasz Torcz — Fri, 31 Dec 2010 15:14:00 GMT

Wychodząc naprzeciw trendowi „jeden komputer — jeden użytkownik”, od następnej wersji Fedory będzie w systemie tylko konto root. Dzięki temu możliwe stanie się wyeliminowanie programów z suidami.

A tak na poważnie, eliminacja polega na zastąpieniu suid-rootów odpowiednimi capabilities. Program, który wymaga tylko uprawnień do zmiany czasu lub używania portów sieciowych poniżej 1024, dostanie uprawnienia tylko do tego. Do tej pory wszystkie możliwości roota były przyznawane.

Wcześniej temu wyzwaniu podołał OpenWall Linux. Przez przerobienie niektórych mechanizmów pozbyto się konieczności uruchamiania przez użytkownika programów jako root. Przykładowo, zmiana powłoki, opisu, hasła czy innych pól w bazie użytkowników /etc/passwd wymagała uprawnień do modyfikacji tego pliku, a więc superużytkownika. W OWL każdy użytkownik ma swój plik w /etc/tcb, którego jest właścicielem i którego edycja nie wymaga superusera.

W Fedorze wysiłki zmierzają do konkretnego nadawania uprawnień. W sieci można znaleźć przykłady użycia setpcap. Jest to proces dość żmudny i niekoniecznie zakończy się powodzeniem, już w tej chwili idzie dość opornie. Rozwiązanie z OWL wygląda lepiej i bardziej przypadło mi do gustu.

Tak jak wcześniej ACL'e rozszerzyły uprawnienia plikowe rwx, tak teraz capabilities rozszerzają ideę rootowego suida. Admini, którzy do tej pory zwlekali z uzupełnieniem swojej wiedzy mają kolejną szansę na pobudkę z ręką w nocniku.

Archived comments:

Stanisław 'dozzie' Klekot 2011-01-01 18:40:01

> Admini, którzy do tej pory zwlekali z uzupełnieniem swojej wiedzy mają kolejną szansę na pobudkę z ręką w nocniku.

Znaczy tego, no. Zdajesz sobie sprawę że naprawdę niewiele usług potrafi skorzystać z POSIX 1003.1e ACLs? W żadnym wypadku nieznajomość POSIX 1003.1e ACLs nie powoduje problemów, a i znajomość stosunkowo niewiele pomaga.

Podobnie pewnie będzie z capabilities.

ickon 2011-01-01 19:49:40

poczekamy - zobaczymy, jak się przyjmie to zerknę dokładniej ...

zdz 2011-01-02 11:28:44

dozzie; prawda, niewiele aplikacji bezpośrednio korzysta. Ale jak już to robią, to ma to zazwyczaj większy impact, jak np. udev-acl rozdające uprawnienia do plików w /dev.

Problem widzę raczej w ,,starej gwardii'', która uważa, że "ls -l" wystarczy do sprawdzenia kto ma dostęp do pliku lub jakie uprawenienia ma program po uruchomieniu.

spinus 2011-01-03 18:00:00

Hm, a to nie jest tak, że ta ,,stara gwardia'' to ludzie, którzy lubią KISS? Łatwo szybko i przyjemnie, natomiast ACLe i podobne wynalazki zabierają dużo czasu na najprostsze zadania, jak np sprawdzenie listy dostępu czy inne mechanizmy? W Windowsie takie rozwiązanie istnieje od dawna i często widze jak koledzy z tych systemów klą na te mechanizmy. Ale być może to kwestia braku dobrych narzędzi do obsługi mechanizmów?

Pożegnanie z eth0

Tomasz Torcz — Tue, 21 Dec 2010 11:59:00 GMT

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.

Hot, hot data

Tomasz Torcz — Sun, 29 Aug 2010 14:36:00 GMT

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

Krótki instruktaż systemd: spis treści

Tomasz Torcz — Fri, 13 Aug 2010 11:40:00 GMT

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

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ł "Wolvverine" 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[...]

Z upstart do systemd w sobotnie popołudnie

Tomasz Torcz — Sat, 17 Jul 2010 15:54:00 GMT

Dzisiaj przystosowałem paczkę, którą zajmuję się w Fedorze (hdapsd) do współpracy z systemd. Systemd jest najnowszym podejściem do zarządzania w Linuksie procesami i usługami na poziomie systemu, operacji cyklicznych i sesji użytkownika.

Moją paczkę od początku wyposażyłem w skrypt współpracujący z upstart, czyli poprzednią próbą unowocześnienia tradycyjnego inita. Upstart jest stosowany w Ubuntu od 2006 roku, w Fedorze od wersji 9, czyli od 2008. Porzucenie upstart w F14 jest gruntowne — systemd współpracuje ze skryptami startowymi SysV, ale zupełnie ignoruje definicje zadań z upstart. Stąd konieczność modyfikacji.

Po kilku kwadransach czytania i modyfikowania wg. wskazówek Lennarta stwierdzam: podoba mi się systemd.

Program, który się zajmuje ma proste zadanie: zatrzymuje pracę dysku twardego, gdy któryś z akcelerometrów wykryje spadek komputera. Dla każdego z chronionych dysków hdapsd musi być uruchomiony osobno. Najlepiej jak najszybciej, żeby objąć dyski nadzorem jak tylko pojawią się w systemie. Do tego odrobina konfiguracji w pliku /etc/sysconfig/hdapsd.

Pierwszym elementem jest regułka wywoływana dla dysków twardych przez udev. Informuje systemd, że dla niewymiennych dysków sda i sdb przydałoby się uruchomić usługę hdapsd:

SUBSYSTEM=="block", KERNEL=="sd[ab]", ATTRS{removable}=="0", TAG="systemd", ENV{SYSTEMD_WANTS}="hdapsd@%k.service"

Podobną regułkę wykorzystywałem, gdy w Fedorze używany był Upstart 0.3. Wersja 0.6 nie potrzebowała regułki. Prawdopodobnie w systemd też będzie (a może już można?) obejść się bez dodatków do udev.

Druga sprawa to definicja usługi już w systemd. Plik /lib/systemd/system/hdapsd@.service wygląda następująco:

[Unit]
Description=%I shock protection daemon

[Service]
EnvironmentFile=/etc/sysconfig/hdapsd
StandardOutput=syslog
SyslogIdentifier=%p(%I)
Nice=-5
ExecStart=/usr/sbin/hdapsd -d %I $(HDAPSD_OPTIONS)

Jest tu przekierowanie standardowego wyjścia z programu do sysloga. Hdapsd ma przełącznik -l, dzięki któremu robi to sam, ale nie każdy program lub skrypt tak potrafi. Dzięki implementacji na poziomie inita programiści nie muszą pisać obsługi syslog samemu.

Uruchomienie z żądanym poziomem Nice to tylko szczyt góry lodowej możliwości regulacji. Moja dusza sysadmina szeroko się uśmiecha, gdy czytam stronę manuala systemd.exec, gdzie podane są wszystkie możliwe przełączniki. A jest ich multum: katalogi, capabilities, UID, GID, ustawienia OOM, parametry planisty I/O, klasy planisty CPU, przywiązania do procesorów itd. Pieczę nad nimi trzyma systemd, więc skrypty startowe mogą składać się z ustawień i nazwy binarki do uruchomienia. Do tej pory osiągnięcie takiej kontroli wiązało się z uruchamianiem wielu pomocniczych progamów (nice, ionice, echo > /proc/…, ulimit, setcap, chrt, su, taskset, …) a czasem wymagało skorzystania z odpowiednich wywołań systemowych już w programie.

Pochwała należy się za dokumentację, która rzadko w linuksanych programach jest odpowiednio obszerna. Systemd opisany jest wyczerpująco, a główny autor na IRCu i poprzez kanał mailowy wyjaśnia wątpliwości.

*** **Archived comments:** **Piotr Pyclik** _2010-07-17 18:00:27_

A może w przystępnych słowach, czym się różni systemd od upstart i z jakich względów ma zostać preferowanym rozwiązaniem w F14? Obserwuję rozwój Fedory, jednak programistą nie jestem, stąd to wszystko nie jest dla mnie zrozumiałe...

**zdz** _2010-07-17 18:08:30_

W przystępnych słowach, hm... Lennart opisał dokładnie u siebie: http://0pointer.de/blog/projects/systemd.html (w tym porównanie z systemd) , kocio pisał też kiedyś na linuxnews.pl , plan na F14 jest tu: https://fedoraproject.org/wiki/Features/systemd
Powtarzać tego wszystkiego raczej nie ma po co. IMO nie wymaga wiedzy programistycznej do zrozumienia.

**Paweł Ciupak** _2010-07-17 23:01:30_

> A może w przystępnych słowach, czym się różni systemd od upstart

Upstart to wymyślaniie koła od nowa, zaś systemd, to wymyślanie koła od nowa drugi raz.

**Stanisław 'dozzie' Klekot** _2010-07-18 23:17:02_

Albo też inaczej: upstart jest broken by design, bo bazuje na podaniu przez opiekuna pakietu wszystkich zależności usługi (rzecz niewykonalna, widziałem w praktyce).
systemd ma szanse działać sprawnie, bo listę zależności sporządza sam. Za usługę jest uznawane coś, co słucha na gnieździe; systemd słucha na tym gnieździe, a przy pierwszym połączeniu startuje stosowną usługę i przekazuje jej gniazdo.
Konstrukcja podobno zaczerpnięta z MacOS X.

**Marek** _2010-07-19 23:29:18_

Witam. Szukając informacji o przywracaniu ext3 do stanu spójnego po nagłej śmierci systemu natrafiłem na tę stronę. Normalnie nie zostawiłbym żadnego wpisu, ale to słońce pomagające czytać zafascynowało mnie...
Pozdro dla autora strony ;)

**zdz** _2010-08-03 07:23:02_

Piotrze: zacząłem pisać, pierwsza notka z cyklu: Krótki instruktaż systemd: wstęp

Więc chcesz użyć SSD do przyspieszenia serwera?

Tomasz Torcz — Mon, 03 May 2010 19:37:00 GMT

Twój serwer, jak każdy szanujący się, spędzą większość czasu nudząc się oczekując na zakończenie operacji wejścia/wyjścia. Jak mu pomóc?

Na zakup serwera z terabajtem RAMu Cię nie stać. A szkoda, bo obsługiwałby obsceniczną liczbę setek tysięcy IOPS. Macierz SSD też pewnie przekracza limit na kredytówce. Milion operacji wejścia/wyjścia na sekundę — fun! Developerzy linuksa już usuwają wąskie gardła przy współpracy z F5100.

No to z ciężkim sercem decydujemy się tylko na ,,przyspieszenie'' podsystemu dyskowego używając SSD. Tylko co tam wtrynić… jeśli używasz programowego RAID, możesz przejrzeć man mdadm i nauczyć się o write intent bitmap. Który to wib dobrze będzie się czuł na SSD.

Ale to wciąż mało, mało i niewiele daje. OK, spójrzmy trochę wyżej na system plików. Jeśli posadowiłeś dane na ext3/4, XFS to super. Możesz wynieść journal na zewnętrzne urządzenie. Twoja baza danych wesoło zareaguje zwiększeniem ilości możliwych zapisów na sekundę z 200÷300 (HDD) do 10 tysięcy (sprawdzić, czy SSD Intela). Jeśli masz JFS to również możesz zeksternalizować dziennik. Ale mając JFS na produkcji powinieneś bać się $DEITY.

Oczywiście niebycie pingwiniarzem zaprocentowało. Używając ZFS dostępnego w FreeBSD i Solarisie już dawno zastosowałeś dyrektywę log. Obecnie Twój ZIL podkręca licznik zużycia komórek SSD, a Ty czytasz ten wpis celem pośmiania się z przyjaciół drobiu arktycznego.

Załatwiliśmy zapisy, ale wciąż nie wszystko mieści się w buforze i odczyt czeka na odpowiednie położenie mechanicznej głowicy i talerza. Bo za złotówkę można dostać 2,3 GiB talerza w dysku. RAM jako bufor to tylko 0,008 GiB / PLN. SSD gdzieś pośrodku, ze jednego złocisza — jedna dziesiąta GB.

Odczytom pomóżmy jakąś pamięcią podręczną. ZFSowcy ponownie robią zieeeew, bo L2ARC od lat czyni im cuda z wydajnością. Podobnie podśmiewają się (wszyscy dwaj) użytkownicy DragonflyBSD. Tam swapcache załatwia brudną robotę.

Za to w linuksie dostępny jest pierdyliard rozwiązań, z których każde kuleje na inną nóżkę. I gotowe będzie za pół roku. Gimnastykować się można z FS-Cache i udawać, że wcale nie działa tylko z NFS, AFS i iso9660. Bo ma potencjał.

Potencjał ma też dm-cache. Działa na tylko sprawnie, że Facebook po drobnych przeróbkach i przemianowaniu na flashcache stosuje go produkcyjnie.

Można poczuć się jak saper i wypróbować bcache. Autor będzie wdzięczny za pomoc w ustabilizowaniu rozwiązania. Klienci za wysłanie ich danych w kosmos trochę mniej.

Obiecująco wyglądało dm-hstore. Heinz jednak zajął się innymi, bardziej pasjonującymi zabawkami i odłożył swoje dzieło na półkę. Wyraźniejszy jest cleancache, który teoretycznie może być zastosowany z SSD jako zapleczem.

Pozostaje mieć nadzieję, że Josef po zakończeniu walki z O_DIRECT zajmie się trzymania drzewa intencji btrfs na zewnętrznym urządzeniu. A potem dorobi drugi poziom cache w podobny sposób. Może za pół roku.

Archived comments:

krzyszsz 2010-05-03 22:10:07

Nie wiem czy dobrze zrozumiałem, ale chyba zrobiłeś mały błąd w zdaniu: "Bo za złotówkę można dostać 2,3 GiB talerza w dysku. RAM jako bufor to tylko 0,008 GiB / PLN. SSD gdzieś pośrodku, ze jednego złocisza — jedna dziesiątka GB". SSD ma droższy gigabajt niż gigabajt na talerzu. Nie wiem co to jest ZIL - sprawdzę w wolnej chwili. : ) Wpis jak każdy o ssd, ciekawy. : ) BTW u mnie był ostatnio wpis z dużą ilością komentarzy na ten temat.

zdz 2010-05-03 22:20:18

SSD jest droższe za GB. Za 1zł kupimy 23 razy mniej. Ceny oczywiście obrazują tylko rząd wielkości, a brałem do porównania następujące:
Seagate 2 TB 7200rpm 64MB cache SATA III Barracuda XT SATA600 [ST32000641AS] 869zł
Intel X25-M SSD 80GB (250MB/70MB) [SSDSA2MH080G2C1] 799zł
A-Data 4GB (2x2GB) 2000MHz CL9 Xtreme Series
[AX3U2000XB2G9-2X] 499zł

krzyszsz 2010-05-03 22:34:58

Ok, może się przyczepiłem niepotrzebnie. Chodziło mi o wyrażenie jakiego użyłeś: "jedna dziesiątka" potocznie oznacza liczbę 10 a nie liczbę 0.1.

zdz 2010-05-03 22:36:40

O! Literówka! Już poprawiam, dzięki.

LCF 2010-05-03 23:16:12

"10 tysięcy (sprawdzić, czy SSD Intela)." <- zrobiłeś własne testy czy tylko czytałeś w necie ? Bo mam ciut inne wrażenia jeżeli chodzi o zapisy.

mina86 2010-05-03 23:49:47

Czemu użytkownicy BSD bardziej nie lubią GNU/Linuksa niż zamkniętych systemów?

quackety 2010-05-04 01:12:47

Jest ZFS na FUSE, ale nie testowałem.

Ogólnie, *bardzo* fajny wpis.

pecet 2010-05-04 01:58:21

Czy w przypadku XFS można przenosić journal w locie z partycji z danymi na zewnętrzna i odwrotnie, czy trzeba najpierw odmontować partycję?

mt3o 2010-05-04 06:58:07

Na logikę powinno się odmontować. Zresztą, to bezpieczniej.

rozie 2010-05-05 06:59:01

@mina86: Pewnie zazdrość. *BSD niestety miejscami mocno przegrywa z Linuksami (miejscami oczywiście równie mocno wygrywa). A skoro przy BSD jesteśmy, czy Debian kFreeBSD pozwala na stosowanie ZFS? Z wszystkimi ficzerami?

ejdzej 2010-05-08 09:14:22

"Czemu użytkownicy BSD bardziej nie lubią GNU/Linuksa niż zamkniętych systemów?"

Bo zajmują tę samą niszę ekologiczną.