Forum Debian Users Gang

morfik · 2015-01-15 01:25:23

Zamknęliście wątek o systemd to nie mam gdzie napisać teraz. xD

Sprawa wygląda tak -- gdzieś na necie wyczytałem coś o przesyłaniu logów przez systemd do zwykłego rsysloga. I z tego co tam pisali, to powinno działać bez problemu. Szukając info na temat tych logów, doczytałem się, że systemd ma kilka opcji logowania, z grubsza to 1) wszystko do ramu, 2) wszystko na dysk, 3) 0 logów. No i tam jeszcze jest jakiś tryb auto, który ustala gdzie logi mają iść jeśli folder z logami jest utworzony na dysku ale olać to. W każdym z tych przypadków jest możliwe przesłanie logów generowanych przez systemd do rsysloga i innych syslogów. Nawet w przypadku kompletnego wyłączenia logowania via systemd.

Pomyślałem sobie, w sumie wszyscy tak naskakiwali na te binarne logi a tu można zaciągnąć do pracy rsysloga i w ogóle nie korzystać z tego loggera systemd. Choć w sumie można by zrobić hybrydę i logi systemd zostawić w ramie, a zapisywać poszczególne pliki via rsyslog na dysk. I generalnie takie rozwiązanie by mnie nawet zadowalało i po krótkim zastanowieniu się, doinstalowałem systemd i wróciłem z tymi 4 pakietami z repo matiego do wersji z debiana. Niby nie zmieniłem jeszcze inita tylko odpalam go via parametr w extlinuxie init=/bin/systemd , a domyślnie mam dalej sysvinit.

Niestety nie zdążyłem sobie popatrzeć jak się ten hybrydlog będzie sprawował bo... szyfrowanie..... xD
Generalnie wszystko chyba działa jak należy z tym, że ja na swoim laptopie korzystam ze skryptów cryptsetupa, to ten parametr keyscript w pliku /etc/crypttab . To przy ich pomocy automatycznie otwiera mi się kilka voluminów przy starcie systemu. Niestety systemd prosi mnie z jakiegoś powodu o hasło cały czas, tak jakby kompletnie ignorował te skrypty i konfigurację w /etc/crypttab .

Szukając info trafiłem na ten bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862 -- data zgłoszenia: Date: Sat, 19 Mar 2011 02:48:01 UTC . No tak 4 lata minęły problem dalej występuje. xD To już jest drugi init, który nie potrafi poprawnie obsługiwać szyfrowanych kontenerów -- pierwszym był openrc.

No i niby pewnie bym przeszedł sobie na ten systemd bo on mi tutaj poprawia kilka błędów, których nie mogłem w żaden sposób wyeliminować na sysvinit ale znowu tylko sysvinit potrafi odszyfrować mi system. xD

Z tego przejrzałem info tu na portalu dotyczące błędów, które mają być poprawione do wydania stabilnego debiana, to nie ma wzmianki na temat tego krytycznego błędu. Da radę jakoś ich pogonić by uwzględnili tego błęda i poprawili go zanim wydadzą nowego debiana? xD

morfik · 2015-01-21 04:35:46

Nieźle idzie. xD Póki co udało mi się załatwić problem z szyfrowaniem. Co prawda, nie ma chyba fixów na to bo systemd nie ma pojęcia o tych skryptach w /etc/crypttab ale zaznaczyłem wszystkie dodatkowe kontenery w powyższym pliku jako noauto i dopisałem sobie do /etc/fstab przy odpowiednich pozycjach nofail . Na koniec w /etc/rc.local :

Kod:

cryptdisks_start xaxa
fsck.ext4 -y /dev/mapper/xaxa
mount -a

Być może później to na jakiś skrypt przerobię czy coś. Póki co działa w miarę. Tylko mi co jakiś czas na konsoli wyrzuca poniższy komunikat:

Kod:

Jan 21 04:13:20 morfikownia systemd[1]: Dependency failed for /media/xaxa. 
Jan 21 04:13:20 morfikownia systemd[1]: Dependency failed for File System Check on /dev/disk/by-uuid/990d110a-1310-4ab2-8a03-c952a408be11.

Nie wszystkie kontenery odpalam na starcie, i być może to jest wina braku zamontowanego voluminu.

Inna rzecz, którą poprawiłem sobie to tworzenie plików urządzeń. Wcześniej skrypt init rsysloga tworzył mi urządzenie, z którego czytane są logi na pulpicie via:

Kod:

LOG_DEV=/dev/logi
if [ ! -r $LOG_DEV ]; then
    mkfifo $LOG_DEV
    chmod 640 $LOG_DEV
    chown root:morfik $LOG_DEV
fi

W tej chwili nie ma co już edytować skryptów i można wrzucić regułki do /etc/tmpfiles.d/ i takie powyższe urządzonko jest tworzone za pomocą poniższej linijki:

Kod:

p /dev/logi 0640 root morfik

Bez tej powyższej konfiguracji, to urządzenie nie chciało zbytnio zachowywać się jak FIFO, i cat takiego urządzenia zwyczajnie sczytywał wszystko i kończył działanie, co mi rozbijało okienko tmuxa. xD

Udało mi się też zaimplementować w pełni funkcjonalną hybrydę logowania — logi systemd do ramu + przesłanie wszystkich komunikatów do rsysloga, a ten loguje wszystko na dysk według swojego pliku konfiguracyjnego.

Zniknęły też te syfiaste logi od:

Kod:

console-kit-daemon[4263]: GLib-CRITICAL: Source ID 142 was not found when attempting to remove it

Zwykle pojawiały się przy podłączaniu/odłączaniu zasilacza w lapku i przy logowaniu się na roota.

No i chyba ostatni ficzer póki co, to te komunikaty przy zamykaniu systemu — w końcu są. xD

Jeszcze mi sporo rzeczy zostało do przeniesienia bo kilka z nich nie działa ale myślę, że w ciągu paru dni uda mi się to ponaprawiać i za tydzień czy dwa przejdę na ten systemd.

___

Pozbyłem się przy okazji consolekit. I z tego co sobie testuje ten logind, to consolekit może się schować. xD Chyba, że nie umiałem tamtego skonfigurować. Chodzi generalnie o pozostawiane procesy po wylogowaniu się. Kiedyś nawet zakładałem wątek o ubijaniu procesów przy wylogowywaniu się ale to wtedy dotyczyło błędów Xservera. W każdym razie ten logind bez problemu ogarnia to zadanie. Wystarczy dopisać do pliku /etc/systemd/logind.conf te poniższe linijki:

Kod:

KillUserProcesses=yes
KillOnlyUsers=morfik
KillExcludeUsers=root

Z tego co wyczytałem, to wszystkie procesy tworzone podczas sesji są oznaczane i ładowane do cgroups, W momencie gdy użytkownik się wyloguje całkowicie, wszystkie te procesy są ubijane. I nie zostaje taki gnome-keyring czy gpg-agent. xD

I można sobie podejrzeć procesy sesyjne nawet:

Kod:

morfik:~$ loginctl list-sessions
   SESSION        UID USER             SEAT
         4       1000 morfik           seat0

1 sessions listed.

morfik:~$ loginctl session-status 4
4 - morfik (1000)
           Since: Wed 2015-01-21 07:19:19 CET; 11min ago
          Leader: 2626 (login)
            Seat: seat0; vc4
             TTY: /dev/tty4
         Service: login; type tty; class user
           State: active
            Unit: session-4.scope
                  ├─2626 /bin/login --
                  ├─2649 /usr/bin/gnome-keyring-daemon --daemonize --login
                  ├─2651 /bin/sh /usr/bin/startx
                  ├─2693 xinit /home/morfik/.xinitrc -- /home/morfik/.xserverrc :0 vt4 -auth /tmp/serverauth.irOmayerYk
                  ├─2694 /usr/bin/X -nolisten tcp :0 vt4 -auth /tmp/serverauth.irOmayerYk
                  ├─2700 /usr/bin/openbox --startup /usr/lib/x86_64-linux-gnu/openbox-autostart OPENBOX
                  ├─2714 dbus-launch --autolaunch=159815709bbc46c29ef786cfc497afd4 --binary-syntax --close-stderr
                  ├─2715 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
                  ├─2720 /usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd
                  ├─2737 dbus-launch --sh-syntax --exit-with-session openbox-session
                  ├─2738 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
                  ├─2750 compton --config /home/morfik/.config/compton.conf -b
                  ├─2753 gpg-agent -s --enable-ssh-support --daemon --write-env-file /home/morfik/.gpg-agent-info
                  ├─2765 /usr/bin/urxvtd -q -f -o
                  ├─2766 /usr/bin/urxvtd -q -f -o
                  ├─2769 tint2 -c /home/morfik/.config/tint2/tint2rc_up
                  ├─2770 tint2 -c /home/morfik/.config/tint2/tint2rc_down
                  ├─2771 volumeicon
                  ├─2772 xscreensaver -no-splash
                  ├─2782 sg p2p -c megasync
                  ├─2783 claws-mail
                  ├─2790 megasync
                  ├─2797 /usr/lib/x86_64-linux-gnu/gconf/gconfd-2
                  ├─2806 /usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd
                  ├─2808 /usr/lib/at-spi2-core/at-spi-bus-launcher
                  ├─2812 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
                  ├─2815 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
                  ├─2817 conky -c /home/morfik/.conky/.conkyrc_fs
                  ├─2841 conky -c /home/morfik/.conky/.conkyrc
                  ├─2848 tmux attach-session -t logi
                  ├─2853 tmux attach-session -t logi
                  ├─2857 bash -c cat /dev/logi | ccze -m ansi -p syslog -C
                  ├─2858 -bash
                  ├─2859 newsbeuter
                  ├─2860 cat /dev/logi
                  ├─2861 ccze -m ansi -p syslog -C
                  ├─3669 conky -c /home/morfik/.conky/1c/.conkyrc_1c
                  ├─3670 conky -c /home/morfik/.conky/1b1/.conkyrc_1b1_int
                  ├─3958 tmux attach-session -t tmux
                  ├─4298 su -
                  ├─4315 -su
                  ├─4404 geany /etc/systemd/logind.conf
                  ├─4485 /bin/sh -c /opt/firefox/firefox -new-instance -ProfileManager
                  ├─4486 /opt/firefox/firefox -new-instance -ProfileManager
                  ├─6173 -bash
                  ├─6626 /usr/sbin/ifplugd -i eth1 -q -f -u0 -d5 -w -I
                  ├─7532 xsel -b -i
                  ├─7888 loginctl session-status 4
                  └─7889 pager

morfik · 2015-01-21 17:31:07

Wychodzi na to, że systemd inaczej też podchodzi do aplikowania reguł dla klawiatur. Choć w sumie to dotyczy tylko tych, które mają dwa eventy. Przykładowo, moja klawiatura jest widziana przez system jako:

Kod:

# evtest
...
/dev/input/event6:      Logitech Logitech USB Keyboard
/dev/input/event13:     Logitech Logitech USB Keyboard
...

Ten event6 to zwykła klawiatura, event13 zaś to klawisze multimedialne i te bez odpowiedniego mapowania nie działają. Jeśli w takim przypadku się napisze regułki dla udeva w postaci:

Kod:

# cat /etc/udev/hwdb.d/65-keyboard-logitech.hwdb 
keyboard:usb:v046dpc30f*
 KEYBOARD_KEY_c01bc=chat
 KEYBOARD_KEY_c022d=prog3
 KEYBOARD_KEY_c022e=prog4
 KEYBOARD_KEY_90040=finance
 KEYBOARD_KEY_c0184=sport
 KEYBOARD_KEY_c0186=shop
 KEYBOARD_KEY_c0188=f14
 KEYBOARD_KEY_90049=f15
 KEYBOARD_KEY_9004a=f16
 KEYBOARD_KEY_9004b=f17
 KEYBOARD_KEY_9004c=f18

to po zaktualizowaniu bazy i podłączeniu klawiatury dostanie się taki błąd:

Kod:

Jan 21 17:00:50 morfikownia systemd-udevd[88118]: keyboard: mapping scan code 786820 (0xc0184) to key code 220 (0xdc)
Jan 21 17:00:50 morfikownia systemd-udevd[88118]: Error calling EVIOCSKEYCODE on device node '/dev/input/event6' (scan code 0xc0184, key code 220): Invalid argument

No i nie ma się czemu dziwić, bo przecie scancode-keycode mają być przepisywane na evencie13, a nie 6. Na 6 nawet takich klawiszy nie ma.

Problem tkwił w niezbyt dokładnym dopasowaniu reguły (keyboard:usb:v046dpc30f*). Szukając na sieci znalazłem poniższą linijkę:

Kod:

find /sys -name modalias -print0 | xargs -0 cat | sort -u

Jeśli przeszukamy wyjście tego polecenia pod kątem usb, otrzymamy:

Kod:

# find /sys -name modalias -print0 | xargs -0 cat | sort -u | grep usb
usb:v046DpC30Fd2300dc00dsc00dp00ic03isc00ip00in01
usb:v046DpC30Fd2300dc00dsc00dp00ic03isc01ip01in00
usb:v09DAp000Ad0015dc00dsc00dp00ic03isc01ip02in00
usb:v1D6Bp0002d0316dc09dsc00dp00ic09isc00ip00in00
usb:v2109p2811d9070dc09dsc00dp01ic09isc00ip00in00
usb:v5986p0149d0003dcEFdsc02dp01ic0Eisc01ip00in00
usb:v5986p0149d0003dcEFdsc02dp01ic0Eisc02ip00in01
usb:v8087p0020d0000dc09dsc00dp01ic09isc00ip00in00

vendor i product id tej klawiatury to 046d oraz c30f , zatem są tylko dwa wpisy, które nas interesują — akurat dwa. Można na ślepo wpisać całą linijkę do pliku bazy udeva albo też można sprawdzić ID. Ta druga opcja opiera się o wydrukowanie bazy:

Kod:

# udevadm info --export-db > plik

Zawartość przeszukujemy pod kątem urządzenia z klawiszami multimedialnymi, w tym przypadku event13:

P: /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3.4/2-1.3.4:1.1/0003:046D:C30F.0018/input/input52/event13
N: input/event13
S: input/by-id/usb-Logitech_Logitech_USB_Keyboard-event-if01
S: input/by-path/pci-0000:00:1d.0-usb-0:1.3.4:1.1-event
E: BACKSPACE=guess
E: DEVLINKS=/dev/input/by-id/usb-Logitech_Logitech_USB_Keyboard-event-if01 /dev/input/by-path/pci-0000:00:1d.0-usb-0:1.3.4:1.1-event
E: DEVNAME=/dev/input/event13
E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3.4/2-1.3.4:1.1/0003:046D:C30F.0018/input/input52/event13
E: ID_BUS=usb
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_MODEL=Logitech_USB_Keyboard
E: ID_MODEL_ENC=Logitech\x20USB\x20Keyboard
E: ID_MODEL_ID=c30f
E: ID_PATH=pci-0000:00:1d.0-usb-0:1.3.4:1.1
E: ID_PATH_TAG=pci-0000_00_1d_0-usb-0_1_3_4_1_1
E: ID_REVISION=2300
E: ID_SERIAL=Logitech_Logitech_USB_Keyboard
E: ID_TYPE=hid
E: ID_USB_DRIVER=usbhid
E: ID_USB_INTERFACES=:030101:030000:
E: ID_USB_INTERFACE_NUM=01
E: ID_VENDOR=Logitech
E: ID_VENDOR_ENC=Logitech
E: ID_VENDOR_ID=046d
E: KEYBOARD_KEY_90040=finance
E: KEYBOARD_KEY_90049=f15
E: KEYBOARD_KEY_9004a=f16
E: KEYBOARD_KEY_9004b=f17
E: KEYBOARD_KEY_9004c=f18
E: KEYBOARD_KEY_c0184=sport
E: KEYBOARD_KEY_c0186=shop
E: KEYBOARD_KEY_c0188=f14
E: KEYBOARD_KEY_c01bc=chat
E: KEYBOARD_KEY_c022d=prog3
E: KEYBOARD_KEY_c022e=prog4
E: MAJOR=13
E: MINOR=77
E: SUBSYSTEM=input
E: USEC_INITIALIZED=183789602
E: XKBLAYOUT=pl,us
E: XKBMODEL=logimel
E: XKBOPTIONS=grp:alt_shift_toggle,lv3:ralt_switch,compose:rctrl,terminate:ctrl_alt_bksp,grp_led:scroll

I jak widać wyżej ID_USB_INTERFACE_NUM=01 , zatem dopasowanie pliku bazy do tego urządzenia wyglądać będzie:

keyboard:usb:v046DpC30Fd2300dc00dsc00dp00ic03isc00ip00in01
KEYBOARD_KEY_c01bc=chat
KEYBOARD_KEY_c022d=prog3
KEYBOARD_KEY_c022e=prog4
KEYBOARD_KEY_90040=finance
KEYBOARD_KEY_c0184=sport
KEYBOARD_KEY_c0186=shop
KEYBOARD_KEY_c0188=f14
KEYBOARD_KEY_90049=f15
KEYBOARD_KEY_9004a=f16
KEYBOARD_KEY_9004b=f17
KEYBOARD_KEY_9004c=f18

I tyle.

-----
Z jakiegoś powodu też mi pulseaudio nie działał. Niby odpalał się przy wpisywaniu w konsoli

Kod:

$ pulseaudio -D

ale startować wraz z systemem to już nie chciał i przy próbie odpalenia pulse via start-pulseaudio-x11, dostawałem poniższego błęda:

Kod:

morfik:~$ /usr/bin/start-pulseaudio-x11
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

Okazuje się, że teraz systemd odpala pulse gdy jakaś aplikacja tego sobie życzy, np. odpalając vlc i potem już pulse sobie działa cały czas.

Rozwiązaniem było zakomentowanie w pliku /etc/pulse/client.conf poniższej linijki:

Kod:

autospawn = no

Nie mam pojęcia wtf ale zdaje się działać:

Kod:

morfik:~$ /usr/bin/start-pulseaudio-x11
morfik:~$ ps -aux | grep -i pulse
morfik   106170  1.6  0.5 434816 10392 ?        S<l  18:02   0:00 /usr/bin/pulseaudio --start --log-target=syslog
morfik   106181  0.0  0.2 122880  5156 ?        S    18:02   0:00 /usr/lib/pulseaudio/pulse/gconf-helper

-----
I chyba ostatnia rzecz na dziś (przynajmniej na razie) — przywrócenie zachowania TTY do stanu takiego jak było pod sysvinit. Chodzi głównie i startowanie 4 konsoli + na 3 z nich (za wyjątkiem 1) ma być ładowany linuxlogo.

Konsole są odpalane po wciśnięciu via ctrl+alt+fx , co trochę wnerwia, bo jest paru sekundowy lag i trzeba czekać aż się ta konsola odpali i dopiero można się logować.

To ile TTY będziemy mieli do dyspozycji, można określić w pliku /etc/systemd/logind.conf :

Kod:

NAutoVTs=6

Domyślnie jest 6. Ja chcę mieć załadowane 4 z nich — TTY1=logi z boot, TTY4=Xserver, i dwie konsole pomiędzy nimi. Pozostałe dwie TTY5 i TTY6 będą ładowane na żądanie, czyli po przełączeniu się do nich.

Konfiguracja kolejnych terminali odbywa się przez plik /lib/systemd/system/getty@.service i trzeba utworzyć tyle instancji ile TTY chcemy skonfigurować. Ewentualnie można wszystkie skonfigurować tak samo ale nie jest tak w moim przypadku. Muszę określić, które TTY chcę konfigurować przez skopiowanie powyższego pliku do /etc/systemd/system/getty.target.wants precyzując numerek TTY po @ , przykładowo:

Kod:

# cp /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty2.service
# cp /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty3.service
# cp /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty4.service

I powinny być tam 4 konsole:

Kod:

root:/etc/systemd/system/getty.target.wants# ls -al
total 20K
drwxr-xr-x  2 root root 4.0K 2015-01-21 18:35:22 ./
drwxr-xr-x 10 root root 4.0K 2015-01-21 09:11:15 ../
lrwxrwxrwx  1 root root   34 2014-11-27 10:43:17 getty@tty1.service -> /lib/systemd/system/getty@.service
-rw-r--r--  1 root root 1.5K 2015-01-21 18:35:14 getty@tty2.service
-rw-r--r--  1 root root 1.5K 2015-01-21 18:35:18 getty@tty3.service
-rw-r--r--  1 root root 1.5K 2015-01-21 18:35:22 getty@tty4.service

Trzeba te dodatkowe pliki wyedytować i przepisać im linijkę z exec do postaci:

Kod:

[Service]
...
ExecStart=-/sbin/agetty --noclear -f /etc/issue.linuxlogo %I $TERM
...

teraz jeszcze tylko wpisać w terminalu

Kod:

# systemctl daemon-reload

Ostatnio edytowany przez morfik (2015-01-21 19:03:06)

morfik · 2015-01-22 09:51:12

Ogarnąłem chyba już to montowanie zaszyfrowanych zasobów w tym systemd -- innych niż partycje systemowe. Generalnie rzecz biorąc, to ma się do dyspozycji ciekawe narzędzia, które są dostępne pod:

Kod:

# ls -al /lib/systemd/system-generators/
total 416K
drwxr-xr-x 2 root root 4.0K 2015-01-21 21:04:08 ./
drwxr-xr-x 8 root root 4.0K 2015-01-21 21:04:08 ../
-rwxr-xr-x 1 root root  899 2014-09-30 13:01:10 openvpn-generator*
-rwxr-xr-x 1 root root  47K 2015-01-21 13:31:21 systemd-cryptsetup-generator*
-rwxr-xr-x 1 root root  31K 2015-01-21 13:31:21 systemd-debug-generator*
-rwxr-xr-x 1 root root  27K 2015-01-21 13:31:21 systemd-default-display-manager-generator*
-rwxr-xr-x 1 root root  55K 2015-01-21 13:31:22 systemd-fstab-generator*
-rwxr-xr-x 1 root root  31K 2015-01-21 13:31:22 systemd-getty-generator*
-rwxr-xr-x 1 root root  67K 2015-01-21 13:31:22 systemd-gpt-auto-generator*
-rwxr-xr-x 1 root root  35K 2015-01-21 13:31:21 systemd-insserv-generator*
-rwxr-xr-x 1 root root  27K 2015-01-21 13:31:21 systemd-rc-local-generator*
-rwxr-xr-x 1 root root  23K 2015-01-21 13:31:21 systemd-system-update-generator*
-rwxr-xr-x 1 root root  51K 2015-01-21 13:31:22 systemd-sysv-generator*

I to one w dużej mierze mi uprościły życie. Głównie dwa z nich, ten fstab i cryptsetup. Jeden z nich generuje pliki dla systemd w oparciu o /etc/fstab, drugi na podstawie /etc/crypttab . Z tym, że bez dostosowania tych plików, zwłaszcza jak się szyfruje, się nie obejdzie.

Wszystkie pliki wygenerowane przy pomocy tych powyższych skryptów są lokowane w katalogu /tmp pod określonymi nazwami i trzeba te pliki przekopiować do:/etc/systemd/system/ . Poniżej przykładowy zestaw plików:

Kod:

# cat systemd-cryptsetup@kabi.service
# Automatically generated by systemd-cryptsetup-generator

[Unit]
Description=Cryptography Setup for %I
Documentation=man:cryptdisks_start man:cryptdisks_stop man:systemd-cryptsetup-generator(8) man:systemd-cryptsetup@.service(8)
SourcePath=/etc/crypttab
DefaultDependencies=no
BindsTo=dev-mapper-%i.device
IgnoreOnIsolate=true
After=systemd-fsck-root.service
Before=media-Kabi.mount

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=30
ExecStart=/usr/sbin/cryptdisks_start %i
ExecStop=/usr/sbin/cryptdisks_stop %i

[Install]
WantedBy=cryptsetup.target

Kod:

# cat media-Kabi.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
RequiresOverridable=systemd-fsck@dev-disk-by\x2duuid-b47e6dcd\x2d924e\x2d40fa\x2da8b1\x2d7593419f86d7.service
After=systemd-fsck@dev-disk-by\x2duuid-b47e6dcd\x2d924e\x2d40fa\x2da8b1\x2d7593419f86d7.service systemd-cryptsetup@kabi.service

[Mount]
What=/dev/mapper/kabi
Where=/media/Kabi
Type=ext4
Options=defaults,errors=remount-ro,commit=10

[Install]
WantedBy=cryptsetup.target

Pierwszy z nich otwiera kontener przy pomocy narzędzia cryptdisk, drugi montuje to co otworzył pierwszy. Myślałem, by też dorobić osoby skrypt dla fsck ale ten skrypt od mounta automatycznie pociąga fsck i w sumie nie trzeba kolejnego pliku tworzyć. W każðym razie trzeba się pobawić tymi linijkami z after i before by skrypty się w odpowiedniej kolejności odpaliły.

Wredny jest tylko jeszcze fakt, że jeśli nie chce się otwierać jakiegoś kontenera na starcie systemu, to samo "systemctl disable" nie wystarczy i niby usługa jest wyłączona, to i tak startuje. xD Ale i to udało się ogarnąć -- trzeba dodać do /etc/fstab parametr "noauto". Rzecz w tym, że po dopisaniu jego, nie idzie zamontować zasobów via "mount -a". Ale to nie przeszkadza systemd by wywołać usługę via "systemctl start" i ładnie wszystko zamontuje.

W taki sposób z około 2min 30s, udało mi się już zjechać ze startem systemu na:

Kod:

Startup finished in 23.159s (kernel) + 29.679s (userspace) = 52.839s.

Ostatnio edytowany przez morfik (2015-01-27 05:23:34)

morfik · 2015-01-23 03:23:38

Poniżej jest linijka, która się przydaje do debugu systemd:

Kod:

loglevel=debug systemd.log_level=debug systemd.log_target=kmsg log_buf_len=24M

Generuje ona prawie 8k linijek (w porównaniu do 1k przy standardowym boocie) i ciekawe rzeczy można tam wyczytać. W prawdzie tylko przejrzałem ale np. konfiguracja sysctl była tam ładowana chyba z 4 razy. Dwie z nich rozumiem — jedna standardowa i drugą miałem w rc.local .Skąd te dwie pozostałe? xD Poza tym zdiffowałem sobie oba zrzuty konfiguracji sysctl po załadowaniu się systemu — jedna bez wpisu w rc.local, druga z. Wyjście się praktycznie nie różni. Także, już nie trzeba wołać sysctl po załadowaniu się systemu. Przydałoby się tylko ustalić co wywołuje sysctl jeszcze 2x. xD

Zaktualizowałem sobie systemd (chyba z nudów) do wersji z experimentala

Kod:

# apt-cache policy systemd
systemd:
  Installed: 218-4
  Candidate: 218-4
  Version table:
 *** 218-4 0
        130 http://ftp.pl.debian.org/debian/ experimental/main amd64 Packages
        100 /var/lib/dpkg/status
     215-10 0
        500 http://ftp.pl.debian.org/debian/ sid/main amd64 Packages
     215-8 0
        500 http://ftp.pl.debian.org/debian/ testing/main amd64 Packages

Nawet działa, ciekawe kiedy przestanie. xD W każdym razie nie wiem czemu pierwsza konsola TTY się zaczeła czyścić sama z siebie. Wychodzi na to, że by powstrzymać czyszczenie konsoli trzeba stworzyć katalog, a w nim plik konfiguracyjny, który dodatkowo skonfiguruje zachowanie terminala. Nazwy katalogu i pliku zależą od nazwy pliku .service , w tym przypadku trzeba stworzyć katalog /etc/systemd/system/getty@tty1.service.d/ i umieścić w nim plik o chyba dowolnej nazwie + .conf . A poniżej jego treść:

Kod:

[Service]
TTYVTDisallocate=no

Powyższa metoda jest trochę inna od kopiowania całych plików do katalogu /etc/systemd/system , w każdym razie można sobie skopiować plik /lib/systemd/system/getty@.service i odpowiednio go przerobić i wyjdzie na to samo.

Przy okazji natrafiłem też na ciekawą opcję z sysvinit backup. Generalnie chodzi o trzymanie dwóch initów w systemie i jeśli systemd padnie, to można załadować sysvinit. Wcześniej jechałem na paczce systemd-shim , która to dawała mi możliwość posiadania w systemie zainstalowanych obydwu paczek z initami ale to chyba nie jest ok trzymać systemd i systemd-shim razem. xD W każdym razie, przed zmianą initu, czyli przed instalacją paczki systemd-sysv , dobrze jest skopiować sobie init via:

Kod:

# cp -av /sbin/init /sbin/init.sysvinit

i dorobić do tego wpis w extlinuxie z parameterm init=/sbin/init.sysvinit , tak na wszelki wypadek. xD

I jeszcze jedna ciekawa rzecz. Te logi systemd co są trzymane w formie binarnej można wyciągnąć bez zaciągania do tego narzędzia journalctl — przy pomocy programiku strings, przykładowo:

Kod:

# strings /var/log/journal/159815709bbc46c29ef786cfc497afd4/system.journal
...
MESSAGE=Successfully made thread 2302 of process 2234 (/usr/bin/pulseaudio) owned by '1000' RT at priority 5.
_SOURCE_REALTIME_TIMESTAMP=1421975851536177
yah
fR'2
hp*x
Vx.#
MESSAGE=Supervising 2 threads of 1 processes of 1 users.
_SOURCE_REALTIME_TIMESTAMP=1421975851536542
yah
fR'2
hp*x
_SOURCE_REALTIME_TIMESTAMP=1421975851540302
yah
fR'2
hp*x
MESSAGE=Successfully made thread 2303 of process 2234 (/usr/bin/pulseaudio) owned by '1000' RT at priority 5.
_SOURCE_REALTIME_TIMESTAMP=1421975851544291
yah
fR'2
hp*x

Choć tam trochę syfu jest i jedyne użyteczne informacje są w linijkach z MESSAGE — można sobie grepnąć wyjście stringsa. xD

A jeśli już mowa o logach, to jest jakiś dziwny problem na linii rsyslog-journalctl . Chodzi generalnie o te komunikaty:

Kod:

Jan 22 22:13:33 morfikownia systemd-journal[252]: Forwarding to syslog missed 271 messages.

Z jakiegoś powodu cześć wiadomości nie jest forwardowana do rsysloga. W sumie zdarza się to tylko podczas startu systemu. Próbowałem już zmiany net.unix.max_dgram_qlen = 10000 , edycji socketu dla sysloga :

Kod:

# cat syslog.socket
...
[Socket]
...
ReceiveBuffer=24M

Zwiększyłem nawet kolejki w rsyslogu via:

Kod:

$MainMsgQueueSize 150000
$MainMsgQueueLowWatermark 50000
$MainMsgQueueHighWatermark 100000
$MainMsgQueueDiscardMark 140000

I dupa. xD

Została mi jeszcze jedna opcja, czyli uruchomić rsysloga zaraz po journalctl, tak by rozładować kolejkę z komunikatami. Choć to trochę dziwne, bo w /etc/systemd/journald.conf mam:

Kod:

RateLimitInterval=1s
RateLimitBurst=5000

Czyli 5k wiadomości w ciągu 1s może przyjąć, a i tak mimo, że cały boot ma 1,2k wiadomości, częśc z nich nie dochodzi. xD

morfik · 2015-01-24 05:51:23

Chyba ogarnąłem już cały ten system montowania zaszyfrowanych voluminów przez systemd, przynajmniej jeśli chodzi o dodatkowe kontenery, bo zaszyfrowany lvm jest jeszcze poza moim zasięgiem, xD

W każdym razie trochę doczytałem i nieco przerobiłem plik od montowania szyfrowanego zasobu. Obecnie on wygląda mniej więcej tak:

Kod:

[Unit]
Description=Cryptography Setup for %I
Documentation=man:cryptdisks_start man:cryptdisks_stop man:systemd-cryptsetup-generator(8) man:systemd-cryptsetup@.service(8)
SourcePath=/etc/crypttab
DefaultDependencies=no
IgnoreOnIsolate=true
Before=systemd-fsck@dev-mapper-kabi.service media-Kabi.mount umount.target
After=dev-disk-by\x2duuid-f3c10054\x2d0583\x2d4e10\x2d937b\x2ddcdc9a05a25c.device cryptsetup-pre.target systemd-fsck-root.service
BindsTo=dev-mapper-%i.device
BindsTo=dev-disk-by\x2duuid-f3c10054\x2d0583\x2d4e10\x2d937b\x2ddcdc9a05a25c.device
Conflicts=umount.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=30
ExecStart=/usr/sbin/cryptdisks_start %i
ExecStop=/usr/sbin/cryptdisks_stop %i

W linijce z Before znalazł się fsck, z tym, że nie po uuid -- łatwiej się idzie połapać co ma być sprawdzane. Chodzi o to, że w przypadku braku tej usługi w tej linijce, systemd spróbuje sprawdzić volumin chyba chwilę po tym jak dojdzie do jego otwierania, a że ten jest zaszyfrowany, to nie widać jaki on ma system plików, no bo w sumie jeszcze nie ma żadnego. I niby kontener po otwarciu zostanie zamontowany ale w taki sposób nigdy się nie dokona jego skanowanie, a sam fsck zwróci błąd w stylu:

Kod:

Jan 24 04:02:21 morfikownia systemd[1]: Started Cryptography Setup for kabi.
Jan 24 04:02:21 morfikownia systemd[1]: Found device /dev/mapper/kabi.
Jan 24 04:02:21 morfikownia systemd-fsck[8882]: fsck failed with error code 8.
Jan 24 04:02:21 morfikownia systemd-fsck[8882]: Ignoring error.
Jan 24 04:02:21 morfikownia systemd[1]: Started File System Check on /dev/disk/by-uuid/990d110a-1310-4ab2-8a03-c952a408be11.
Jan 24 04:02:21 morfikownia systemd[1]: Mounting /media/Kabi...
Jan 24 04:02:21 morfikownia systemd-fsck[8882]: fsck.ext4: No such file or directory while trying to open /dev/mapper/kabi_unformatted

Czyli niby jest ale jednak nie ma. xD Jeśli się doda fsck do linijki z Before, to wtedy system sobie poradzi:

Kod:

Jan 24 05:15:43 morfikownia systemd[1]: Starting Cryptography Setup for kabi...
Jan 24 05:15:43 morfikownia systemd[1]: Expecting device dev-mapper-kabi.device...
Jan 24 05:15:43 morfikownia cryptdisks_start[31338]: Starting crypto disk...kabi (starting)...
Jan 24 05:15:52 morfikownia cryptdisks_start[31338]: kabi (started)...done.
Jan 24 05:15:52 morfikownia systemd[1]: Started Cryptography Setup for kabi.
Jan 24 05:15:52 morfikownia systemd[1]: Found device /dev/mapper/kabi.
Jan 24 05:15:52 morfikownia systemd[1]: Starting File System Check on /dev/mapper/kabi...
Jan 24 05:15:52 morfikownia systemd-fsck[31426]: kabi: clean, 12249/1966080 files, 7522780/7863808 blocks
Jan 24 05:15:52 morfikownia systemd[1]: Started File System Check on /dev/mapper/kabi.
Jan 24 05:15:52 morfikownia systemd[1]: Mounting /media/Kabi...
Jan 24 05:15:52 morfikownia kernel: [ 5230.287971] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: errors=remount-ro,commit=10
Jan 24 05:15:52 morfikownia systemd[1]: Mounted /media/Kabi.

Dalej w pliku jest dodane After=dev-disk-by\x2duuid-f3c10054\x2d0583\x2d4e10\x2d937b\x2ddcdc9a05a25c.device , a to jest UUID partycji z zaszyfrowanym voluminem i jeśli system nie znajdzie takiego urządzenia, będzie czekał przez jakiś czas w nadziei, że może się pojawi, aż do timeouta -- chyba 1,5min.

Linijki z BindsTo określają (w tym przypadku) urządzenia, które muszą być widoczne przez system -- jeśli z jakichś powodów znikną, ta usługa się zakończy. I ostania linijka z Conflicts precyzuje,target, po dojściu do którego ta usługa wykona to co ma w ExecStop . Oczywiście wszystko w oparciu o odwróconą kolejność w polach After i Before, bo inaczej kontener by był zamontowany i nie dałoby się go zamknąć xD

___

Przeniosłem także suspend/hibernację z pm-utils na systemd. Domyślne ustawienia są dość ubogie, bo dają możliwość jedynie przypisania odpowiednich przycisków pod konkretne akcje w pliku /etc/systemd/logind.conf , przykładowo:

Kod:

HandlePowerKey=hibernate
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend
HandleLidSwitchDocked=ignore

W porównaniu do pm-utils, to trochę mało ale można dość poważnie rozszerzyć tę funkcjonalność -- wystarczy stworzyć kilka plików service, tak ze 4 minimum. xD Dwa z nich będą dla zwykłego użytkownika, a dwa pozostałe dla roota. Chodzi generalnie o wykonywanie pewnych działań z odpowiednimi uprawnieniami

Ja u siebie stworzyłem poniższe pliki:

Kod:

root:/etc/systemd/system# ls -al sleep.target.wants/
total 8.0K
drwxr-xr-x  2 root root 4.0K 2015-01-24 03:13:40 ./
drwxr-xr-x 12 root root 4.0K 2015-01-24 05:13:32 ../
lrwxrwxrwx  1 root root   35 2015-01-24 03:13:40 resume@morfik.service -> /etc/systemd/system/resume@.service
lrwxrwxrwx  1 root root   39 2015-01-24 03:13:40 root-resume.service -> /etc/systemd/system/root-resume.service
lrwxrwxrwx  1 root root   40 2015-01-24 03:13:40 root-suspend.service -> /etc/systemd/system/root-suspend.service
lrwxrwxrwx  1 root root   36 2015-01-24 03:13:40 suspend@morfik.service -> /etc/systemd/system/suspend@.service

Generalnie to tylko dwa z nich mają zastosowanie.-- suspend@morfik.service blokuje ekran przed uśpieniem, a root-resume.service synchronizuje czas itp po wybudzeniu.

Poniżej oba pliki:

Kod:

[Unit]
Description=Local system resume actions
After=sleep.target

[Service]
Type=oneshot
ExecStartPre=/bin/sleep 2
ExecStart=/opt/skrypty/synchronizacja_czasu
ExecStart=/sbin/sysctl -p
ExecStart=/sbin/swapoff -a
ExecStart=/sbin/swapon -a

[Install]
WantedBy=sleep.target

Tutaj taka mała uwaga, ten sleep na początku ma na celu upewnienie, że sieć zdąży się załadować. Bo z tego co sprawdzałem to zwykle gubiony jest pierwszy ping po wybudzeniu, temu dobrze jest ustawić minimum 2s aby połączenie się zestawiło. Inna sprawa to fakt resetowania ustawień sysctl -- nie wiem czemu po hibernacji/uśpieniu te ustawienia się resetują ale to samo miałem na sysvinit. No i ostatnie dwie linijki czyszczą swapa.

A tu plik użytkownika z blokadą ekranu:

Kod:

[[Unit]
Description=User suspend actions
Before=sleep.target root-suspend.service

[Service]
User=%I
Type=oneshot
Environment="DISPLAY=:0"
ExecStart=/usr/bin/xscreensaver-command -lock
ExecStartPost=/bin/sleep 2

[Install]
WantedBy=sleep.target

Linijka z User określa prawa wykonywanych działań i w tym przypadku wskazuje na to co jest po @ w suspend@morfik.service , czyli morfik. Jest także ustawiona zmienna $DISPLAY, bo większość aplikacji graficznych tego wymaga, a dalej to już wywołanie blokady ekranu z efektem wygaszenia (2s). xD

Pozostałe dwa pliki, mają ustawione

Kod:

ExecStart=/bin/true

Tak by same usługi, mimo, że puste, zwracały status SUCCESS. xD

Ostatnio edytowany przez morfik (2015-01-24 21:46:54)

gnejusz pompejusz · 2015-01-24 20:25:11

Czyli skrypt do peerblocka też będziesz przerabiał na systemd?

Ostatnio edytowany przez gnejusz pompejusz (2015-01-24 21:07:31)

Jacekalex · 2015-01-24 21:33:29

gnejusz pompejusz napisał(-a):
Czyli skrypt do peerblocka też będziesz przerabiał na systemd?

Po co? takie skrypty to raczej do crona się pakuje.

morfik · 2015-01-24 21:43:39

gnejusz pompejusz napisał(-a):
Czyli skrypt do peerblocka też będziesz przerabiał na systemd?

Ja u siebie mam iptables peerblock i tc wrzucone w skrypt sysvinit + aktualizacje list w cronie i to działa bez problemu póki co, bo systemd obsługuje te skrypty. Ma co prawda swój wbudowany mechanizm wywoływania zadań w określonym czasie, coś jak cron ale ja zostanę przy cronie pewnie — zobaczę jak to będzie działać z MTA, bo systemd też ma coś wbudowanego, a mnie czasem exim wnerwia. xD Tak czy inaczej napiszę za jakiś czas pliki service od konfiguracji swojej sieci, także będzie też pewnie i peerblock. Póki co mam jeszcze sporo rzeczy do ogarnięcia, np. to: http://www.freedesktop.org/software/systemd/man/bootup.html i póki mi te stare skrypty działają to ich nie ruszam narazie.

morfik · 2015-01-25 23:01:38

Na archlinux wiki pisali coś o tym, że by zbytnio nie używać kilku daemonów od acpi, bo to może prowadzić do dziwnych efektów i prawdopodobnie jeden z nich u mnie wystąpił. Choć nie wiem czy to nie była czasem wina złej konfiguracji, w każdym razie, jak już pisałem wyżej, systemd ma wbudowany własny mechanizm i zgodnie z tym co pisali na wiki, można pozbyć się kilku pakietów. W sumie to było: acpi acpi-support acpi-support-base acpitool . Tam jednak była też wzmianka o tym, że:

systemd cannot handle AC and Battery ACPI events, so if you use Laptop Mode Tools or other similar tools acpid is still required.

I to mnie zastanawia, bo przecie u mnie stan baterii jest pokazywany, nawet na panelu tint2 mam % stanu i bez problemu pokazuje czy się wyczerpuje czy ładuje. Bardziej szczegółowy log jest też w upower:

Kod:

morfik:~$ upower -i /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          BAT0
  vendor:               HP
  power supply:         yes
  updated:              Sun 25 Jan 2015 10:50:45 PM CET (51 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       none
    energy:              42.2528 Wh
    energy-empty:        0 Wh
    energy-full:         48.0394 Wh
    energy-full-design:  48.0394 Wh
    energy-rate:         23.6045 W
    time to empty:       1.8 hours
    percentage:          87%
    capacity:            100%
    technology:          lithium-ion
    icon-name:          'battery-full-symbolic'
  History (charge):
    1422222645  87.000  discharging
  History (rate):
    1422222645  23.604  discharging

Nie wiem czy to tylko u mnie działa czy ten wpis jest nieaktualny ale póki co, po wywaleniu acpi, nic się nie zmieniło w działaniu mojego laptopa. Podświetlanie działa, bateria też i hibernation/sleep/ via sysetmd i hybrid za sprawą upower przy bardzo niskim stanie baterii, lid switch działa, tak samo jak przycisk power. Coś jeszcze? xD

-----

Przepisałem swoją pierwszą usługę z sysvinit na systemd, oczywiście to był dnscrypt-proxy. W sumie wyszło coś takiego:

Kod:

[Unit]
Description=Encrypted DNS resolver
Documentation=man:dnscrypt-proxy
Documentation=file:/usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv
DefaultDependencies=true
Requires=resolvconf.service
After=resolvconf.service
Before=shutdown.target

[Service]
Environment="IP=127.0.2.1"
Environment="PORT=53"
Environment="USER=dnscrypt"
Environment="RESOLVER_NAME=opendns"
EnvironmentFile=-/etc/default/dnscrypt-proxy
Type=simple
ExecStartPre=/bin/sh -c '/bin/mkdir /run/dnscrypt-proxy >/dev/null 2>&1 || true'
ExecStartPre=/bin/sh -c '/bin/echo "nameserver ${IP}" | /sbin/resolvconf -a lo.dnscrypt'
ExecStart=/usr/sbin/dnscrypt-proxy \
    --local-address=${IP}:${PORT} \
    --user=${USER} \
    --resolver-name=${RESOLVER_NAME}
ExecStopPost=/sbin/resolvconf -d lo.dnscrypt
ExecStopPost=/bin/rm -Rf /run/dnscrypt-proxy
Restart=on-failure
RemainAfterExit=no

[Install]
WantedBy=multi-user.target

Z tym, że to jeszcze nie koniec roboty, bo na necie widziałem aktywację via socket ale póki co jeszcze nie udało mi się zrozumieć tego mechanizmu i zwyczajnie implementacja się nie powiodła. xD Zostawiam to narazie tak jak jest wyżej. Z tym, że tam jest też opcja EnvironmentFile=-/etc/default/dnscrypt-proxy , w której można precyzować zmienne i to czyni ten dnscrypt-proxy kompatybilny ze skryptem sysvinit. A ten mały "-" przed ścieżka pliku sprawi, że systemd nie będzie narzekał jeśli tego pliku nie zastanie.

Ten mechanizm działa w oparciu o resolvconf — przed odpaleniem:

Kod:

# cat /etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.1
search mhouse.lh

I po:

Kod:

Jan 25 22:49:07 morfikownia systemd[1]: Starting Nameserver information manager...
Jan 25 22:49:07 morfikownia systemd[1]: Started Nameserver information manager.
Jan 25 22:49:07 morfikownia systemd[1]: Starting Encrypted DNS resolver...
Jan 25 22:49:08 morfikownia systemd[1]: Started Encrypted DNS resolver.
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [NOTICE] Starting dnscrypt-proxy 1.4.3
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [INFO] Initializing libsodium for optimal performance
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [INFO] Generating a new key pair
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [INFO] Done
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [INFO] Server certificate #1408041567 received
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [INFO] This certificate looks valid
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [INFO] Chosen certificate #1408041567 is valid from [2014-08-15] to [2015-08-15]
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [INFO] Server key fingerprint is 8201:4577:3D75:3934:FC25:B83C:8369:72DC:98A2:1368:AA0A:2C18:6C17:D7B4:30E8:CD63
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [NOTICE] Proxying from 127.0.2.1:53 to 208.67.220.220:443

oraz plik resolv.conf:

Kod:

# cat /etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.2.1
search mhouse.lh

Myślałem, że przenoszenie tych usług będzie jakoś bardziej skomplikowane, a to nawet ujdzie w miarę, tylko trzeba obadać te wszystkie parametry używane w plikach. xD

___

Kilka uwag co do plików unitów.

Przy okazji robienia paczki pod dnscrypt-proxy, znalazłem nieco lepszy sposób na tworzenie plików tymczasowych pod chroot dnscrypta. Wprawdzie wcześniej mi do do głowy nie przyszło ale teraz zamiast wpisywać w unit linijki typu:

Kod:

ExecStartPre=/bin/sh -c '/bin/mkdir /run/dnscrypt-proxy >/dev/null 2>&1 || true'
ExecStopPost=/bin/rm -Rf /run/dnscrypt-proxy

Można w katalogu debian/ z budowaną paczką dodać plik dnscrypt-proxy.tmpfile i tam wrzucić:

Kod:

D /run/dnscrypt-proxy 0755 dnscrypt dnscrypt - -

I przy starcie maszyny, ten katalog zostanie automatycznie stworzony i odpowiednio ustawiony.

Druga sprawa to pliki z montowaniem zasobów, czyli te z rozszerzeniem .mount . Zauważyłem, że przy takiej konfiguracji tych plików jak wyżej, system leci do przodu jak gdyby nigdy nic, a sprawdzanie systemu plików odbywa się równolegle i zwykle nawet nie kończy się przed pojawieniem się okienka logowania. Rozwiązałem to przez dodanie do pliku .mount tych linijek:

Kod:

[Install]
WantedBy=basic.target

Zgodnie z tym co jest napisane tutaj: http://www.freedesktop.org/software/systemd/man/bootup.html , basic.target jest przed multi-user.target i graphical.target ale po sysinit.target zatem akurat odpowiednie miejsce by zamontować te dodatkowe dyski. W efekcie system zatrzymuje swoje działanie na parę sekund, na czas sprawdzania fsck, po czym montuje i leci sobie dalej.

___

Wywaliłem właśnie swoje skrypty, za pomocą których to konfigurowała mi się jasność ekranu — chodzi o przywracanie stanu sprzed wyłączenia laptopa. Systemd ma swój własny mechanizm, który powinien działać bez problemu. U mnie jednak nie chciał. xD Sprawa wygląda tak: mój laptop ma pełno bugów w acpi i system rejestruje swój plik od backlightu, czego efektem są dwa — jeden acpi_video0 i drugi intel_backlight .

Kod:

root:~# ls -al /sys/class/backlight/
total 0
drwxr-xr-x  2 root root 0 2015-01-26 05:01:21 ./
drwxr-xr-x 46 root root 0 2015-01-26 05:01:21 ../
lrwxrwxrwx  1 root root 0 2015-01-26 05:01:21 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0/
lrwxrwxrwx  1 root root 0 2015-01-26 05:01:21 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/

W takim przypadku system korzysta z acpi_video0 ale możliwe jest sterowanie jasnością ekranu przy pomocy obu powyższych plików, z tym, że przy przyciskaniu klawiszy na laptopie, wartości zmieniają się jedynie w intel_backlight , co powoduje dwie rzeczy. Pierwsza to skoki jasności — z bardzo ciemniej do bardzo jasnej, w zależności od tego co się używa do zmiany podświetlenia. Drugi objaw to brak zapisywania ustawień po restarcie laptopa. Choć w sumie to te ustawienia są zapisywane, z tym, że skoro systemd operuje na acpi_video0 a my kręcimy intel_backlight , to chyba oczywiste jest, że to działać za bardzo nie będzie. xD

Systemd dostarcza unit /lib/systemd/system/systemd-backlight@.service , który ma się zajmować jasnością ekranu — wywoływany jest tuż przed wyłączeniem maszyny, i zaraz na jej starcie. Przy wyłączaniu, zapisuje odpowiednią wartość ze wszystkich dostępnych backlightów do plików w /var/lib/systemd/backlight/ i przy budzeniu maszyny, te wartości są odczytywane i aplikowane.

Na necie znalazłem instrukcje dla Xservera, z którego backlightu ma on korzystać — w przypadku gdy jest ich kilka. Wystarczy stworzyć pliczek z konfiguracja dla Xorga w /etc/X11/xorg.conf.d/ i dać tam poniższą zawartość:

Kod:

Section "Device"
    Identifier    "Device0"
    Driver    "intel"
    Option    "Backlight"    "acpi_video0"
    BusID    "PCI:0:2:0"
EndSection

I od tej pory narzędzia takie jak xbacklight operujące na backlightach będą referować do ustawionego wyżej acpi_video0 , czyli systemd zacznie widzieć zmiany w jasności ekranu i poprawnie je zapisywać i wczytywać.

Oczywiście można też zabronić sterownikowi acpi rejestrować swojego backlighta, tak by w systemie był tylko jeden, a nie dwa. Bo jakby nie patrzeć np. u mnie przyciski na laptopie operują na intel_backlight a nie na acpi_video0 , zatem nawet jeśli zacznę zmieniać nimi wartość podświetlenia ekranu, to i tak systemd tego nie zobaczy i po resecie wczyta starą wartość. By usunąć tego backlighta od acpi, trzeba dopisać parametr acpi_backlight=vendor do linijki kernela. Po resecie powinien być już widoczny tylko jeden backlight:

Kod:

root:~# ls -al /sys/class/backlight/
total 0
drwxr-xr-x  2 root root 0 2015-01-26 05:23:27 ./
drwxr-xr-x 46 root root 0 2015-01-26 05:21:20 ../
lrwxrwxrwx  1 root root 0 2015-01-26 05:21:44 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/

I w takim wypadku systemd nie ma innego wyjścia i będzie musiał operować na nim, czego efektem będzie stworzenie pliku:

Kod:

root:~# ls -al /var/lib/systemd/backlight/pci-0000\:00\:02.0\:backlight\:intel_backlight
-rw-r--r-- 1 root root 4 2015-01-26 05:32:21 /var/lib/systemd/backlight/pci-0000:00:02.0:backlight:intel_backlight
root:~# cat /var/lib/systemd/backlight/pci-0000\:00\:02.0\:backlight\:intel_backlight
976

I taka rada jeszcze, unikać maksymalnych wartości, czyli nie ściemniać/rozjaśniać na maxa, bo wtedy po restarcie maszyny będą problemy z wartościami.

Ostatnio edytowany przez morfik (2015-01-26 00:50:24)

gnejusz pompejusz · 2015-01-26 17:11:55

Ja mam taki dnscrypt:

Kod:

 [Unit]
Description=OpenDNS Crypt proxy server
After=networking.service
#After=NetworkManager.service
Before=unbound.service

[Service]
Type=forking
#ExecStart=/bin/echo -e "nameserver 127.0.0.2 \n nameserver 0:0:0:0:0:0:7f00:2 \n" > /etc/resolv.conf
ExecStart=/usr/sbin/dnscrypt-proxy -a 127.0.0.2:53 --daemonize 
Restart=on-abort

[Install]
WantedBy=multi-user.target

morfik · 2015-01-26 17:48:49

Taka rada — dobrze jest unikać typów "fork", czyli nie dopisywać w linijkach z exec do daemonów parametrów -d, daemonize, background itp, tak jak jest to możliwe w przypadku dnscrypt. Tu masz wyjaśnienie:

As mentioned classic SysV services daemonize after startup, which usually involves double forking and detaching from any terminal. While this is useful and necessary when daemons are invoked via a script, this is unnecessary (and slow) as well as counterproductive when a proper process babysitter such as systemd is used. The reason for that is that the forked off daemon process usually has little relation to the original process started by systemd (after all the daemonizing scheme's whole idea is to remove this relation), and hence it is difficult for systemd to figure out after the fork is finished which process belonging to the service is actually the main process and which processes might just be auxiliary. But that information is crucial to implement advanced babysitting, i.e. supervising the process, automatic respawning on abnormal termination, collectig crash and exit code information and suchlike. In order to make it easier for systemd to figure out the main process of the daemon we changed the service type to dbus. The semantics of this service type are appropriate for all services that take a name on the D-Bus system bus as last step of their initialization[5]. ABRT is one of those. With this setting systemd will spawn the ABRT process, which will no longer fork (this is configured via the -d -s switches to the daemon), and systemd will consider the service fully started up as soon as com.redhat.abrt appears on the bus. This way the process spawned by systemd is the main process of the daemon, systemd has a reliable way to figure out when the daemon is fully started up and systemd can easily supervise it.

Jacekalex · 2015-01-26 17:55:53

Szczerze Wam współczuję. ;)

Z tym Systemd macie więcej gimnastyki, niż matka z najgorszym łobuzem w dzielnicy.

Nie prościej skołować jakiegoś normalnego inita.

ja mieć OpenRC, a jak coś nie brykać na OpenRC, to być ośla ławka w postaci Daemontools, i generalnie wsio bryka jak powinno.
Przez ostatnie dwa lata sporawy skryptów startowych zajęły mi może ze dwadzieścia minut.

A Systemd?
Potem się słyszy, że wśród informatyków panuje kryzys demograficzny gorszy, niż u feministek. :D

Pozdro
;-)

morfik · 2015-01-26 18:06:21

Przesadzasz. xD Ja na sysvinit operuje ponad 5 lat, i już go opanowałem, zatem działanie na nim nie zajmuje dużo czasu, tak samo tobie openrc -- już pominę fakt, że wszystkie usługi są zintegrowane z tymi initami i praktycznie nie wymagają dostosowania, a jak już to tylko lekkie zmiany w /etc/defalt/. A systemd używam od paru dni i muszę upchnąć całe te 5 lat w 10min? xD Ja mam dość niestandardowy system z całym mnóstwem ficzerów i skoro to było robione pod sysvinit i zajęło mi to czas, to czemu ma nie zająć przy przenoszeniu tego na systemd? Przy czym taka uwaga -- to wszystko działa OOTB, ja nie muszę tego robić by mi systemd odpalił np. tego dnscrypta -- on go odpala przez te skrypty syvinit, które są w pełni kompatybilne z systemd i jeśli masz jakiś skrypt init, to przecie możesz sobie go używać -- nikt cie nie zmusza do przepisywania go na systemd, choć skrypty 200-300 linijkowe można upchąć w unitach 10linijkowych. xD

Tu masz przykład.

Skrypt init:

Kod:

#! /bin/sh
### BEGIN INIT INFO
# Provides:          qbittorrent-nox
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Should-Start:      iptables-persistent pgl
# Should-Stop:       iptables-persistent pgl
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Starts QBittorrent
# Description:       Start qbittorrent-nox on start. Change USER= before running
### END INIT INFO

# Author: Jesper Smith
#

# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="QBittorrent"
NAME=qbittorrent-nox
DAEMON=/usr/bin/$NAME
DAEMON_ARGS=""
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/qbittorrent-nox
USER=morfik:p2p

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

if [ "$START" = "no" ]; then
    echo "Autostart wyłączony -- zobacz /etc/default/$NAME ."
    exit 0
fi
# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

#
# Function that starts the daemon/service
#
do_start()
{
    # Return
    #   0 if daemon has been started
    #   1 if daemon was already running
    #   2 if daemon could not be started
    start-stop-daemon -c $USER -b -t --start --quiet  --exec $DAEMON  \
                || return 1

    start-stop-daemon -c $USER -b --start --quiet --exec $DAEMON -- \
        $DAEMON_ARGS \
        || return 2
    sleep 1
}

#
# Function that stops the daemon/service
#
do_stop()
{
    start-stop-daemon -c $USER --quiet  --stop --exec $DAEMON
    sleep 2
    return "$?"
}

VERBOSE="yes"

case "$1" in
  start)
    [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
    do_start
    case "$?" in
        0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
        2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    esac
    ;;
  stop)
    [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
    do_stop
    case "$?" in
        0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
        2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    esac
    ;;
  status)
       status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
       ;;
  restart|force-reload)
    log_daemon_msg "Restarting $DESC" "$NAME"
    do_stop
    case "$?" in
      0|1)
        do_start
        case "$?" in
            0) log_end_msg 0 ;;
            1) log_end_msg 1 ;; # Old process is still running
            *) log_end_msg 1 ;; # Failed to start
        esac
        ;;
      *)
          # Failed to stop
        log_end_msg 1
        ;;
    esac
    ;;
  *)
    #echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
    echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2
    exit 3
    ;;
esac

Kod:

[Unit]
Description=qbittorrent-nox
Documentation=man:qbittorrent-nox
DefaultDependencies=no
Requires=media-Kabi.mount
After=media-Kabi.mount network-online.target
Conflicts=umount.target

[Service]
User=morfik
Group=p2p
Type= simple
RemainAfterExit=no
ExecStart=/usr/bin/qbittorrent-nox

[Install]
WantedBy=multi-user.target

-----

Poniżej jest to co mnie wnerwiało strasznie na sysvinit, czyli co jeśli odpalę qbittorrenta mając zamknięty kontener LUKSa? xD Na sysvinit rozwala to bazę danych i trzeba robić rehash wszystkiego co się ściągało i zwykle też tworzone są pliki w katalogu /media/. A systemd?

Poniżej log z odpalenia usługi qbittorenta przy zamkniętym kontenerze:

Kod:

Jan 26 18:54:22 morfikownia systemd[1]: Expecting device /dev/mapper/kabi...
Jan 26 18:54:22 morfikownia systemd[1]: Starting Cryptography Setup for kabi...
Jan 26 18:54:22 morfikownia cryptdisks_start[4649]: Starting crypto disk...kabi (starting)...
Jan 26 18:54:31 morfikownia cryptdisks_start[4649]: kabi (started)...done.
Jan 26 18:54:31 morfikownia systemd[1]: Found device /dev/mapper/kabi.
Jan 26 18:54:31 morfikownia systemd[1]: Started Cryptography Setup for kabi.
Jan 26 18:54:31 morfikownia systemd[1]: Starting File System Check on /dev/mapper/kabi...
Jan 26 18:54:31 morfikownia systemd-fsck[4706]: kabi: clean, 450249/9306112 files, 28660477/37193216 blocks
Jan 26 18:54:31 morfikownia systemd[1]: Started File System Check on /dev/mapper/kabi.
Jan 26 18:54:31 morfikownia systemd[1]: Mounting /media/Kabi...
Jan 26 18:54:31 morfikownia kernel: [ 1558.872203] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: errors=remount-ro,commit=10
Jan 26 18:54:31 morfikownia systemd[1]: Mounted /media/Kabi.
Jan 26 18:54:31 morfikownia systemd[1]: Starting qbittorrent-nox...
Jan 26 18:54:31 morfikownia systemd[1]: Started qbittorrent-nox.
Jan 26 18:54:31 morfikownia qbittorrent-nox[4713]: ******** Information ********
Jan 26 18:54:31 morfikownia qbittorrent-nox[4713]: To control qBittorrent, access the Web UI at http://localhost:44444
Jan 26 18:54:31 morfikownia qbittorrent-nox[4713]: The Web UI administrator user name is: morfik
Jan 26 18:54:31 morfikownia qbittorrent-nox[4713]: 26/01/2015 18:54:31 - The Web UI is listening on port 44444
Jan 26 18:54:32 morfikownia qbittorrent-nox[4713]: 26/01/2015 18:54:32 - qBittorrent is successfully listening on interface 192.168.1.150 port: TCP/xaxaxa
Jan 26 18:54:32 morfikownia qbittorrent-nox[4713]: 26/01/2015 18:54:32 - External IP: xa.xa.xa.xa

Co się stanie jak zamknę kontener przy działającym qbittorrencie?

Kod:

Jan 26 18:59:48 morfikownia systemd[1]: Stopping qbittorrent-nox...
Jan 26 18:59:48 morfikownia systemd[1]: Stopping /sys/devices/virtual/block/dm-5.
Jan 26 18:59:50 morfikownia systemd[1]: Stopped qbittorrent-nox.
Jan 26 18:59:50 morfikownia systemd[1]: Unmounting /media/Kabi...
Jan 26 18:59:51 morfikownia systemd[1]: Unmounted /media/Kabi.
Jan 26 18:59:51 morfikownia systemd[1]: Stopping File System Check on /dev/mapper/kabi...
Jan 26 18:59:51 morfikownia systemd[1]: Stopped File System Check on /dev/mapper/kabi.
Jan 26 18:59:51 morfikownia systemd[1]: Stopping /sys/devices/virtual/block/dm-5.
Jan 26 18:59:51 morfikownia systemd[1]: Stopping Cryptography Setup for kabi...
Jan 26 18:59:51 morfikownia systemd[1]: Stopped /dev/mapper/kabi.
Jan 26 18:59:51 morfikownia systemd[1]: Stopped /dev/disk/by-id/dm-name-kabi.
Jan 26 18:59:51 morfikownia systemd[1]: Stopped /dev/mapper/kabi_unformatted.
Jan 26 18:59:51 morfikownia systemd[1]: Stopped /dev/disk/by-uuid/b47e6dcd-924e-40fa-a8b1-7593419f86d7.
Jan 26 18:59:51 morfikownia systemd[1]: Stopped /dev/disk/by-label/kabi.
Jan 26 18:59:51 morfikownia systemd[1]: Stopped /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-f3c1005405834e10937bdcdc9a05a25c-kabi_unformatted.
Jan 26 18:59:51 morfikownia systemd[1]: Stopped /dev/disk/by-id/dm-name-kabi_unformatted.
Jan 26 18:59:51 morfikownia systemd[1]: Stopped /dev/dm-5.
Jan 26 18:59:51 morfikownia systemd[1]: Stopped /sys/devices/virtual/block/dm-5.
Jan 26 18:59:51 morfikownia cryptdisks_stop[4774]: Stopping crypto disk...kabi (stopping)...done.
Jan 26 18:59:51 morfikownia systemd[1]: Stopped Cryptography Setup for kabi.

Full wypas. xD

___

Właśnie skończyłem przenosić konfigurację swojej sieci ze skryptów init na systemd -- ale mi się tam śmieci nazbierało przez ten czas. xD

W każdym razie stworzyłem sobie unit morfinetwork.service i wrzuciłem do niego poniższą treść:

Kod:

[Unit]
Description=morfinetwork
Documentation=man:iptables man:ipset man:tc man:sysctl
DefaultDependencies=no
Before=network-pre.target shutdown.target
Wants=network-pre.target
After=systemd-modules-load.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c "/etc/morfinetwork/ipset.sh"
ExecStart=/bin/sh -c "/etc/morfinetwork/iptables_raw.sh"
ExecStart=/bin/sh -c "/etc/morfinetwork/iptables_mangle.sh"
ExecStart=/bin/sh -c "/etc/morfinetwork/iptables_nat.sh"
ExecStart=/bin/sh -c "/etc/morfinetwork/iptables_filter.sh"
ExecStart=/bin/sh -c "/etc/morfinetwork/ip6tables_raw.sh"
ExecStart=/bin/sh -c "/etc/morfinetwork/ip6tables_mangle.sh"
ExecStart=/bin/sh -c "/etc/morfinetwork/ip6tables_nat.sh"
ExecStart=/bin/sh -c "/etc/morfinetwork/ip6tables_filter.sh"
ExecStart=/bin/sh -c "/etc/morfinetwork/tc.sh"
ExecStop=/bin/sh -c "/etc/morfinetwork/base.sh"

[Install]
WantedBy=multi-user.target

Jak widać wyżej, rozbiłem jeden wielki skrypt init, który miał prawie 800linijek (skąd mi się tego tyle tam wzięło? xD) na kilka mniejszych skryptów wywoływanych w określonej kolejności. Dodatkowo zrobiłem sobie skrypt base.sh, który czyści wszystko i ustawia prostą zaporę NATową, tak by czasem nie zostać bez filtra przy resetowaniu czy wyłączaniu fw.

Mógłbym oczywiście stworzyć 10 osobnych unitów, tylko po co? xD Systemd ładnie zwraca status dla każdego z tych skryptów, przykład:

Kod:

# systemctl status morfinetwork
● morfinetwork.service - morfinetwork
   Loaded: loaded (/etc/systemd/system/morfinetwork.service; enabled; vendor preset: enabled)
   Active: active (exited) since Tue 2015-01-27 02:56:10 CET; 49min ago
     Docs: man:iptables
           man:ipset
           man:tc
           man:sysctl
  Process: 7813 ExecStop=/bin/sh -c /etc/morfinetwork/base.sh (code=exited, status=0/SUCCESS)
  Process: 8143 ExecStart=/bin/sh -c /etc/morfinetwork/tc.sh (code=exited, status=0/SUCCESS)
  Process: 8120 ExecStart=/bin/sh -c /etc/morfinetwork/ip6tables_filter.sh (code=exited, status=0/SUCCESS)
  Process: 8116 ExecStart=/bin/sh -c /etc/morfinetwork/ip6tables_nat.sh (code=exited, status=0/SUCCESS)
  Process: 8112 ExecStart=/bin/sh -c /etc/morfinetwork/ip6tables_mangle.sh (code=exited, status=0/SUCCESS)
  Process: 8107 ExecStart=/bin/sh -c /etc/morfinetwork/ip6tables_raw.sh (code=exited, status=0/SUCCESS)
  Process: 8020 ExecStart=/bin/sh -c /etc/morfinetwork/iptables_filter.sh (code=exited, status=0/SUCCESS)
  Process: 8013 ExecStart=/bin/sh -c /etc/morfinetwork/iptables_nat.sh (code=exited, status=0/SUCCESS)
  Process: 7983 ExecStart=/bin/sh -c /etc/morfinetwork/iptables_mangle.sh (code=exited, status=0/SUCCESS)
  Process: 7955 ExecStart=/bin/sh -c /etc/morfinetwork/iptables_raw.sh (code=exited, status=0/SUCCESS)
  Process: 7902 ExecStart=/bin/sh -c /etc/morfinetwork/ipset.sh (code=exited, status=0/SUCCESS)
 Main PID: 8143 (code=exited, status=0/SUCCESS)

Jan 27 02:56:10 morfikownia systemd[1]: Started morfinetwork.

Ostatnio edytowany przez morfik (2015-01-26 19:03:32)

Jacekalex · 2015-01-27 04:14:04

Po co Ci tyle skryptów do FW?

Ja mam jeden do cgroup, jeden do iptables/arptables i jeden do nftables.

Razem trzy sztuki, a u Ciebie tylko 10 (słownie dziesięć) do samego netfiltera.

Robisz skrypty po trzy linijki?

Bo u nie:

Kod:

for x in `which mynetwork` `which mynetnf` `which cgstart`; do wc -l   $x; done;
336 /usr/local/sbin/mynetwork
163 /usr/local/sbin/mynetnf
1108 /usr/local/sbin/cgstart

Pozdro
;-)

morfik · 2015-01-27 04:35:23

Dużo mam tych reguł i sporo komentarzy i wnerwia mnie trochę ciągłe przewijanie w górę i w dół. xD Poza tym tam jest peerblock i tc.

Kod:

# wc -l *
   81 base.sh
   26 ip6tables_filter.sh
    3 ip6tables_mangle.sh
    3 ip6tables_nat.sh
    3 ip6tables_raw.sh
   28 ipset.sh
  125 iptables_filter.sh
   37 iptables_mangle.sh
   12 iptables_nat.sh
   42 iptables_raw.sh
   68 tc.sh
  428 total

Te 3 skrypty od ip6tables są faktycznie puste ale jakoś tak niesymetrycznie by było. xD

Cgroups jeszcze nie robiłem ale tam też będzie sporo do czyszczenia. Z tego co widzę, to systemd zajebiście fajnie sobie te grupy ogarnia.

Ostatnio edytowany przez morfik (2015-01-27 04:39:15)

Jacekalex · 2015-01-27 04:38:29

Do Peerblocka, to ja mam skrypta w /etc/cron.hourly/, nie narzekam, działa.
Do Spamhausa i Sblamu też mam takie skrypty, w domu ich nie używam, ale w razie czego są i działają.

morfik · 2015-01-27 04:47:38

A ja mam wszystko w jednym miejscu i do tego ładnie pokrojone. xD

----

Kiedyś poszukiwałem czegoś co by mi resetowało daemony jeśli te z jakiegoś powodu nawalą. W sumie nigdy zbytnio się nie zagłębiłem w możliwości monita -- miałem tam tylko jedną regułkę, która w razie potrzeby resetowała fwknopd. W każdym razie systemd ma zaimplementowany ficzer resetowania daemonów i wystarczy dopisać do unita parametr "Restart=on-failure" bu system ją zresetował jeśli ta nawali. Zwykle robi to w przedziale czasu 100ms ale można ten czas zwiększyć przy pomocy "RestartSec=" . I w sumie to mi wystarcza. xD

Kolejne zbędne narzędzie to bootchart, czyli rysowanie wykresów z danymi obrazującymi start systemu. Systemd też to potrafi i nie trzeba się przy tym bawić parametrami kernela. By sobie zrobić taki obrazek wystarczy wpisać w terminalu:

Kod:

$ systemd-analyze plot > plot.svg

I obrazek po chwili zostanie wygenerowany. Można tam przejrzeć sobie dokładną sekwencję startu i ustalić ewentualne problemu z konkretnymi usługami lub też ich nieprawidłową kolejnością.

Przeniosłem sobie także ZRAM. W sumie przy okazji poszukałem info na necie i okazało się, że stosunkowo niedawno wprowadzili spore zmiany w tym mechanizmie, kernele > 3.15. Znalazłem też przy okazji ten projekt -- https://github.com/vaeth/zram-init i generalnie zaimplementowałem sobie sam SWAP, bo TMP coś u mnie rozwala system i nie mam pojęcia przy tym z jakiego powodu. Może uda się to jakoś obejść później.

Ostatnio edytowany przez morfik (2015-01-27 05:13:16)

Jacekalex · 2015-01-27 05:12:24

Systemd Cgroup ogarnia?
to pokaż przykładowo wynik:

Kod:

cat  /proc/`pidof firefox`/cgroup

Niech ja się też pośmieję ;)

Kod:

cat  /proc/`pidof firefox`/cgroup
13:debug:/
12:hugetlb:/
11:net_prio:/
10:perf_event:/
9:blkio:/
8:net_cls:/users/firefox
7:freezer:/
6:devices:/
5:memory:/users/firefox
4:cpuacct:/
3:cpu:/users/firefox
2:cpuset:/
1:name=openrc:/

Kod:

cat  /proc/`pidof pidgin`/cgroup
13:debug:/
12:hugetlb:/
11:net_prio:/
10:perf_event:/
9:blkio:/
8:net_cls:/users/pidgin
7:freezer:/
6:devices:/
5:memory:/users/pidgin
4:cpuacct:/
3:cpu:/users/pidgin
2:cpuset:/
1:name=openrc:/

Bo z moich informacji wynika, że SystemD tak samo ogarnia Cgroup, jak OpenRC, czyli per/user lub poszczególne demony - fajnie na serwer, ale na desktopa to pasuje jak pięść do nosa.

morfik · 2015-01-27 05:17:54

Tutaj to trochę inaczej działa. xD

Ale masz swoje polecenie:

Kod:

# cat  /proc/`pidof firefox`/cgroup
9:cpuset:/
8:perf_event:/
7:devices:/user.slice/user-1000.slice
6:blkio:/user.slice/user-1000.slice
5:cpu,cpuacct:/user.slice/user-1000.slice
4:freezer:/
3:net_cls,net_prio:/
2:memory:/user.slice/user-1000.slice
1:name=systemd:/user.slice/user-1000.slice/session-9.scope

Choć u mnie to chyba jeszcze koliduje z tym moim mechanizmem, bo go wcale nie ruszałem, ale masz więcej poleceń:

Kod:

├─1 /sbin/init
├─system.slice
│ ├─cgrulesengd.service
│ │ └─1694 /usr/sbin/cgrulesengd -n -Q
│ ├─dbus.service
│ │ └─1518 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidf...
│ ├─cron.service
│ │ └─1528 /usr/sbin/cron -f
│ ├─hddtemp.service
│ │ └─1739 /usr/sbin/hddtemp -d -l 127.0.0.1 -p 7634 -s | /dev/sda
│ ├─nfs-common.service
│ │ ├─1476 /sbin/rpc.statd
│ │ └─1490 /usr/sbin/rpc.idmapd
│ ├─exim4.service
│ │ └─2007 /usr/sbin/exim4 -bd -q30m
│ ├─networking.service
│ │ ├─1172 /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan0.pid -i wla...
│ │ └─1278 dhclient -v -pf /run/dhclient.bond0.pid -lf /var/lib/dhcp/dhclient...
│ ├─qbittorrent-nox.service
│ │ └─1517 /usr/bin/qbittorrent-nox
│ ├─atd.service
│ │ └─1538 /usr/sbin/atd -f
│ ├─systemd-journald.service
│ │ └─261 /lib/systemd/systemd-journald
│ ├─dnscrypt-proxy.service
│ │ └─1463 /usr/sbin/dnscrypt-proxy --local-address=127.0.2.1:53 --user=dnscr...
│ ├─upower.service
│ │ └─1536 /usr/lib/upower/upowerd
│ ├─ifplugd.service
│ │ └─1639 /usr/sbin/ifplugd -i eth1 -q -f -u0 -d5 -w -I
│ ├─systemd-logind.service
│ │ └─1565 /lib/systemd/systemd-logind
│ ├─system-getty.slice
│ │ ├─getty@tty6.service
│ │ │ └─29145 /sbin/agetty --noclear tty6 linux
│ │ ├─getty@tty3.service
│ │ │ └─2029 /sbin/agetty --noclear -f /etc/issue.linuxlogo tty3 linux
│ │ ├─getty@tty5.service
│ │ │ └─29143 /sbin/agetty --noclear tty5 linux
│ │ └─getty@tty2.service
│ │   └─2030 /sbin/agetty --noclear -f /etc/issue.linuxlogo tty2 linux
│ ├─systemd-udevd.service
│ │ └─290 /lib/systemd/systemd-udevd
│ ├─polkitd.service
│ │ └─2209 /usr/lib/policykit-1/polkitd --no-debug
│ ├─vnstat.service
│ │ └─1543 /usr/sbin/vnstatd -n
│ ├─rpcbind.service
│ │ └─1466 /sbin/rpcbind -w
│ ├─rsyslog.service
│ │ └─1562 /usr/sbin/rsyslogd -n
│ ├─smartd.service
│ │ └─1546 /usr/sbin/smartd -n --interval=1800
│ └─rtkit-daemon.service
│   └─1551 /usr/lib/rtkit/rtkit-daemon
└─user.slice
  ├─user-1000.slice
  │ ├─user@1000.service
  │ │ ├─35890 /lib/systemd/systemd --user
  │ │ └─35892 (sd-pam)
  │ └─session-9.scope
  │   ├─35857 /bin/login --
  │   ├─35896 /usr/bin/gnome-keyring-daemon --daemonize --login
  │   ├─35898 /bin/sh /usr/bin/startx
  │   ├─35940 xinit /home/morfik/.xinitrc -- /home/morfik/.xserverrc :0 vt4 -...
  │   ├─35941 /usr/bin/X -nolisten tcp :0 vt4 -auth /tmp/serverauth.iOLbebxmI...
  │   ├─35947 /usr/bin/openbox --startup /usr/lib/x86_64-linux-gnu/openbox-au...
  │   ├─35970 dbus-launch --sh-syntax --exit-with-session openbox-session
  │   ├─35971 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --s...
  │   ├─35983 compton --config /home/morfik/.config/compton.conf -b
  │   ├─35986 gpg-agent -s --enable-ssh-support --daemon --write-env-file /ho...
  │   ├─35998 /usr/bin/urxvtd -q -f -o
  │   ├─35999 /usr/bin/urxvtd -q -f -o
  │   ├─36002 tint2 -c /home/morfik/.config/tint2/tint2rc_up
  │   ├─36003 tint2 -c /home/morfik/.config/tint2/tint2rc_down
  │   ├─36005 xscreensaver -no-splash
  │   ├─36013 sg p2p -c megasync
  │   ├─36014 claws-mail
  │   ├─36016 pasystray
  │   ├─36020 megasync
  │   ├─36030 volnoti
  │   ├─36034 /usr/lib/x86_64-linux-gnu/gconf/gconfd-2
  │   ├─36039 /usr/bin/pulseaudio --start --log-target=syslog
  │   ├─36045 /usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd
  │   ├─36048 /usr/lib/pulseaudio/pulse/gconf-helper
  │   ├─36050 conky -c /home/morfik/.conky/.conkyrc_fs
  │   ├─36073 conky -c /home/morfik/.conky/.conkyrc
  │   ├─36076 tmux attach-session -t logi
  │   ├─36082 tmux attach-session -t logi
  │   ├─36083 bash -c cat /dev/logi | ccze -m ansi -p syslog -C
  │   ├─36084 -bash
  │   ├─36085 newsbeuter
  │   ├─36105 cat /dev/logi
  │   ├─36106 ccze -m ansi -p syslog -C
  │   ├─36159 /usr/lib/at-spi2-core/at-spi-bus-launcher
  │   ├─36163 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.c...
  │   ├─36166 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
  │   ├─36642 conky -c /home/morfik/.conky/1c/.conkyrc_1c
  │   ├─36643 conky -c /home/morfik/.conky/1b1/.conkyrc_1b1_int
  │   ├─37179 tmux attach-session -t tmux
  │   ├─37181 su -
  │   ├─37182 -su
  │   ├─39272 /bin/sh -c /opt/firefox/firefox -new-instance -ProfileManager
  │   ├─39273 /opt/firefox/firefox -new-instance -ProfileManager
  │   ├─39309 amarok
  │   ├─39312 kdeinit4: kdeinit4 Running...
  │   ├─39313 kdeinit4: klauncher [kdeinit] --fd=8
  │   ├─39315 kdeinit4: kded4 [kdeinit]
  │   ├─39389 /usr/bin/kglobalaccel
  │   ├─45509 /usr/bin/spacefm
  │   ├─49506 -bash
  │   ├─52650 xsel -b -i
  │   └─52945 systemd-cgls
  └─user-0.slice
    ├─user@0.service
    │ ├─29116 /lib/systemd/systemd --user
    │ └─29118 (sd-pam)
    └─session-3.scope
      ├─ 2032 /bin/login --
      └─29124 -bash

Takżę jak widzisz, o wszystkie procesy przypisuje do grup. xD

Ostatnio edytowany przez morfik (2015-01-27 06:01:42)

Jacekalex · 2015-01-27 05:28:33

Iptables cgroup na OUTPUTach nie ogarnąłeś jeszcze jak widzę, a i tak masz globalnie całą sesję X na jednej grupie i jednym limicie, w lapku to potrzebne, jak łysemu grzebień.

Identycznie działa Cgroup w OpenRC, i ma identyczne wady.
Właśnie dlatego - umiesz liczyć, to licz na siebie, a nie jakichś ćpunów w typie Lennarta P.

Pozdro
;)

morfik · 2015-01-27 05:32:28

Ja jeszcze się tym nie bawiłem ale ja to ogarnę i będzie działać jak trza. xD

___

Właśnie skończyłem czytać wprowadzenie do dziennika — https://docs.google.com/document/pub?id=1IC9yOXj7j6 … gjLUEHIX3MSTs i muszę przyznać, że ciekawe rzeczy tam nawet piszą i nasuneło mi się kilka pytań, np. czy aby na pewno potrzebnych jest xx części logu uzyskanych via logrotate, no bo jakby nie patrzeć co za różnica czy operuje się na 50 plikach czy na 1? No może ten drugi ciężko by otworzyć w graficznym edytorze textu, ale fani vima raczej nie powinni narzekać. xD Ktoś mógłby powiedzieć, że przecie taki jeden plik więcej zajmuje niż 50 kawałków, z czego 49 jest skompresowanych. No w sumie fakt. A to nie lepiej skompresować wszystko zatem? xD No w sumie rsyslog raczej na skompresowanym pliku textowym nie da rady operować, a systemd robi to całkiem nieźle, bo cały ten jego kontener jest skompresowany i mimo tego faktu dostęp do logów uzyskuje się w czasie rzeczywistym. Drugie pytanie, to czy potrzeba jest rozdzielać logi różnych obiektów do różnych plików? Ja w sumie nawet nie zaglądam do /var/log/ bo przecie mam konsolę na pulpicie, która czyta urządzenie /dev/logi, do którego są przesyłane logi ze wszystkich programów. Zatem pojawiają mi się one w jednym miejscu i jakoś nigdy z tego powodu nie narzekałem. Wlazłem za to sobie do katalogu /var/log by zobaczyć co tam słychać i co moje oczy ujrzały?

Kod:

# ls -al /var/log/ | wc -l
284

Co za burdel i to do tego w dużej mierze skompresowany. xD Chyba jednak rotacja dzienna ssie lekko. Tak czy inaczej co za różnica gdy te pliki z miesiąca się upchnie w spakowanym kontenerze, który można przeszukiwać na wiele sposobów, pomijając ten najbardziej trywialny czyli "/bababa", to będzie zakres dat, logi konkretnych usług, logi z błędami czy ostrzeżeniami (i pozostałe też), logi z konkretnych bootowań systemu i co tam jeszcze komu przyjdzie do łba. Tak sobie myślę, że mi to w sumie wszystko jedno i nawet skłaniałbym się do tego spakowanego kontenera by posprzątać ten burdel.

Jeśli już jesteśmy przy rotacji i mam odpaloną konsolę co czyta logi rsysloga, to przy przetasowaniu logów, i restarcie rsysloga, moją konsolę diabli biorą i muszę ją zestawiać jeszcze raz. Z tego co piszą pod tamtym linkiem, to systemd sobie tasuje logi transparentnie i bez takich udziwnień i logi można przeglądać w czasie rzeczywistym.

Chyba jedna z ciekawszych kwestii, która została w podlinkowanym texcie poruszona, czyli problem z bezpieczeństwem logów i ich podatnością na manipulację. Tutaj ciekawy kawałek:

The Internet is a dangerous place. Break-ins on high-profile web sites have become very common. After a successful break-in the attacker usually attempts to hide his traces by editing the log files. Such manipulations are hard to detect with classic syslog: since the files are plain text files no cryptographic authentication is done, and changes are not tracked. Inspired by git, in the journal all entries are cryptographically hashed along with the hash of the previous entry in the file. This results in a chain of entries, where each entry authenticates all previous ones. If the top-most hash is regularly saved to a secure write-once location, the full chain is authenticated by it. Manipulations by the attacker can hence easily be detected.

To już się robi ciekawie. Ktoś wspomniał coś o szyfrowaniu? xD

I jeszcze taka fajna rzecz:

The fields, an entry consists off, are stored as individual objects in the journal file, which are then referenced by all entries, which need them. This saves substantial disk space since journal entries are usually highly repetitive (think: every local message will include the same _HOSTNAME= and _MACHINE_ID= field)

W rsyslogu każda linijka zawiera kopię szeregu elementów, a w journalu systemd rozwiązali to bardziej praktycznie.

Tak sobie myślę, że jeśli by ten journal spełnił 3 takie moje zachcianki, czyli filtrowanie komunikatów trafiających do kontenera + logi sieciowe + przesłanie zawartości dziennika do urządzenia FIFO, tak by można było mieć podgląd zdarzeń w czasie rzeczywistym na desktopowej konsoli, to ja zmieniam rsysysloga na ten journal. xD

morfik · 2015-01-27 19:48:16

Jako, że część ludzi nie rozumie zasady działania hibernacji/uśpienia w wykonaniu systemd, w tym również po części i ja xD, postanowiłem przeprowadzić krótki experyment, by uwidocznić cały proces przechodzenia w sen i wybudzania się z niego.

W doświadczeniu wzieły udział 4 unity -- dwa systemowe (root) i dwa użytkownika (morfik) --może być dowolna ich ilość, chodzi o pokazanie zależności a do tego są potrzebne minimum 4. Poniżej są one zobrazowane:

Kod:

root:/etc/systemd/system# tree -f sleep.target.wants/
sleep.target.wants
├── sleep.target.wants/resume@morfik.service -> /etc/systemd/system/resume@.service
├── sleep.target.wants/root-resume.service -> /etc/systemd/system/root-resume.service
├── sleep.target.wants/root-suspend.service -> /etc/systemd/system/root-suspend.service
└── sleep.target.wants/suspend@morfik.service -> /etc/systemd/system/suspend@.service

A niżej zawartość każdego z plików testowych:

/etc/systemd/system/suspend@.service

Kod:

[Unit]
Description=User suspend actions
Before=sleep.target root-suspend.service

[Service]
User=%I
Type=oneshot
ExecStart=/bin/sleep 3
ExecStart=/bin/sh -c "/bin/echo AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
ExecStop=/bin/sleep 3
ExecStop=/bin/sh -c "/bin/echo BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"

[Install]
WantedBy=sleep.target

/etc/systemd/system/root-suspend.service

Kod:

[Unit]
Description=Local system suspend actions
Before=sleep.target

[Service]
Type=oneshot
ExecStart=/bin/sleep 3
ExecStart=/bin/sh -c "/bin/echo CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC"
ExecStop=/bin/sleep 3
ExecStop=/bin/sh -c "/bin/echo DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD"

[Install]
WantedBy=sleep.target

/etc/systemd/system/root-resume.service

Kod:

[Unit]
Description=Local system resume actions
After=sleep.target

[Service]
Type=oneshot
ExecStart=/bin/sleep 3
ExecStart=/bin/sh -c "/bin/echo EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE"
ExecStop=/bin/sleep 3
ExecStop=/bin/sh -c "/bin/echo FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"

[Install]
WantedBy=sleep.target

/etc/systemd/system/resume@.service

Kod:

[Unit]
Description=User suspend actions
After=sleep.target root-resume.service

[Service]
User=%I
Type=oneshot
ExecStart=/bin/sleep 3
ExecStart=/bin/sh -c "/bin/echo GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG"
ExecStop=/bin/sleep 3
ExecStop=/bin/sh -c "/bin/echo HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH"

[Install]
WantedBy=sleep.target

Ustawiłem je w kolejności w jakiej powinny się odpalać, czyli według liter alfabetu. Pierwszy powinien się odpalić ten z A I B , potem C i D, E i F i na koniec G i H. Każdy skrypt ma jedną akcję startu i stopu ale można wrzucić tam dowolną ich liczbę.

I jak wygląda zatem cały proces uśpienia -- popatrzmy na logi:

SEN:

Kod:

Jan 27 19:23:23 morfikownia systemd-logind[1497]: Lid closed.
Jan 27 19:23:23 morfikownia systemd-logind[1497]: Suspending...
Jan 27 19:23:23 morfikownia systemd[1]: Starting User suspend actions...
Jan 27 19:23:26 morfikownia sh[60513]: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Jan 27 19:23:29 morfikownia sh[60535]: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
Jan 27 19:23:29 morfikownia systemd[1]: Started User suspend actions.
Jan 27 19:23:29 morfikownia systemd[1]: Starting Local system suspend actions...
Jan 27 19:23:32 morfikownia sh[60550]: CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
Jan 27 19:23:35 morfikownia sh[60571]: DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
Jan 27 19:23:35 morfikownia systemd[1]: Started Local system suspend actions.
Jan 27 19:23:35 morfikownia systemd[1]: Starting Sleep.
Jan 27 19:23:35 morfikownia systemd[1]: Reached target Sleep.
Jan 27 19:23:35 morfikownia systemd[1]: Starting Local system resume actions...
Jan 27 19:23:35 morfikownia systemd[1]: Starting Suspend...
Jan 27 19:23:35 morfikownia systemd-sleep[60577]: Suspending system...
...
Jan 27 19:24:02 morfikownia kernel: [11361.084050] PM: Entering mem sleep
...
Jan 27 19:24:02 morfikownia kernel: [11361.825410] ACPI: Preparing to enter system sleep state S3
...
Jan 27 19:24:02 morfikownia kernel: [11361.929175] smpboot: CPU 1 is now offline

Wybudzenie

Kod:

Jan 27 19:24:02 morfikownia kernel: [11361.930507] ACPI: Low-level resume complete
...
Jan 27 19:24:02 morfikownia kernel: [11361.945010] CPU1 is up
Jan 27 19:24:02 morfikownia kernel: [11361.946286] ACPI: Waking up from system sleep state S3
Jan 27 19:24:02 morfikownia kernel: [11362.483260] PM: Finishing wakeup.
...
Jan 27 19:24:02 morfikownia systemd-logind[1497]: Lid opened.
...
Jan 27 19:24:05 morfikownia systemd-sleep[60577]: System resumed.
Jan 27 19:24:05 morfikownia systemd[1]: Started Suspend.
Jan 27 19:24:05 morfikownia systemd[1]: Unit sleep.target is not needed anymore. Stopping.
Jan 27 19:24:05 morfikownia systemd[1]: Stopping Sleep.
Jan 27 19:24:05 morfikownia systemd[1]: Stopped target Sleep.
Jan 27 19:24:05 morfikownia systemd[1]: Starting Suspend.
Jan 27 19:24:05 morfikownia systemd[1]: Reached target Suspend.
Jan 27 19:24:05 morfikownia systemd-logind[1497]: Operation finished.
Jan 27 19:24:05 morfikownia systemd[1]: Unit suspend.target is bound to inactive service. Stopping, too.
Jan 27 19:24:05 morfikownia systemd[1]: Stopping Suspend.
Jan 27 19:24:05 morfikownia systemd[1]: Stopped target Suspend.
Jan 27 19:24:05 morfikownia sh[60677]: EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
Jan 27 19:24:06 morfikownia sh[60706]: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Jan 27 19:24:06 morfikownia systemd[1]: Started Local system resume actions.
Jan 27 19:24:06 morfikownia systemd[1]: Starting User suspend actions...
Jan 27 19:24:09 morfikownia sh[60721]: GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
Jan 27 19:24:12 morfikownia sh[60742]: HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
Jan 27 19:24:12 morfikownia systemd[1]: Started User suspend actions.

Jak widać wyżej, zarówno akcje SART jak i STOP są wywoływane przy usypaniu/wybudzaniu maszyny. Kolejność akcji jest określona w polach Before i After. Przy czym, tutaj taka uwaga, proces usypania jest procesem ciągłym jak widać z powyższego logu -- chodzi o pojawienie się komunikatu "Started Suspend." po wybudzeniu maszyny -- komunikat "System resumed". Czyli z punktu widzenia systemu to wyglądało tak jakby on sobie pracował jak gdyby nigdy nic i jakieś zdarzenie zainicjowało przejście do sleep.target, po czym system wrócił z tego sleep.target do normalnej pracy. No i właśnie temu akcje Before=sleep.target są wywoływane przed uśpieniem, a te mające After=sleep.target po wybudzeniu.

morfik · 2015-01-27 20:59:24

Odkąd zacząłem czytać i zgłębiać temat, okazało się, że wiele osób kompletnie nie ma pojęcia czemu nienawidzi systemd -- nigdy nie używali nic o nim nie wiedzą i nie umieją na nim operować. xD Mnie w sumie uwierały tylko binarne logi ale po przeczytaniu tego wprowadzenia do journala, nie mam pytań, choć mi brakuje części funkcjonalności ale nie mam przy tym jeszcze dostatecznej wiedzy na temat tego czy aby nie da rady zrobić tego co planuje w oparciu tylko o journal, pozbywając się przy tym rsysloga. Także trochę rozwagi, bo póki co mi wsio działa i działa wyśmienicie, pominę fakt, że jadę na wersji z experimentala. xD

morfik · 2015-01-28 02:34:20

Właśnie się natknąłem na narzędzie systemd-nspawn — to jest taki chroot tylko bardziej podrasowany, przy czym to nie jest LXC. Za to lepiej izoluje niż zwykły chroot i działa OOTB bez żadnych dodatkowych modyfikacji. poniżej krotki opis:

More importantly however systemd comes out-of-the-box with the systemd-nspawn tool which acts as chroot(1) on steroids: it makes use of file system and PID namespaces to boot a simple lightweight container on a file system tree. It can be used almost like chroot(1), except that the isolation from the host OS is much more complete, a lot more secure and even easier to use. In fact, systemd-nspawn is capable of booting a complete systemd or sysvinit OS in container with a single command. Since it virtualizes PIDs, the init system in the container can act as PID 1 and thus do its job as normal. In contrast to chroot(1) this tool will implicitly mount /proc, /sys for you.
...
The container will not be able to see any of the processes outside of it. It will share the network configuration, but not be able to modify it. (Expect a couple of EPERMs during boot for that, which however should not be fatal). Directories like /sys and /proc/sys are available in the container, but mounted read-only in order to avoid that the container can modify kernel or hardware configuration. Note however that this protects the host OS only from accidental changes of its parameters.

http://0pointer.net/blog/projects/changing-roots.html

Czyli nawet całkiem nieźle pomyślane jak na minimum wkładu własnego. Szkoda tylko, że:

A process in the container can manually remount the file systems read-writeable and then change whatever it wants to change.

To sie chyba nada się do instalowania debiana po debootstrapie — przetestuje kiedyś tam, jak będę na nowo system stawiał. xD Na archwiki piszą (https://wiki.archlinux.org/index.php/Systemd-nspawn#X_environment), że można również bez problemu odpalać graficzne appki, także to uprości nieco używanie 32bit wine na 64bit systemie.

Ten kontener się robi tak prosto, że chyba prościej to już się nie da:

Kod:

# debootstrap --arch=amd64 unstable debian-tree/
# systemd-nspawn -D debian-tree/

I można instalować system.

Na dobrą sprawę, w ten sposób można chrootnąć każde środowisko, nawet swój system podczas ratunku. Działa również z sysvinit.

Jest też osobne narzędzie do sterowania kontenerem:

Kod:

# machinectl list
MACHINE                          CONTAINER SERVICE
debian-tree                      container nspawn

1 machines listed.


# machinectl status debian-tree
debian-tree
           Since: Wed 2015-01-28 02:23:06 CET; 14s ago
          Leader: 75972 (systemd)
         Service: nspawn; class container
            Root: /media/Kabi/debian-tree
         Address: 192.168.1.150
                  192.168.10.100
                  fe80::80c3:ccff:febb:cb76
                  fe80::28b2:f1ff:fe9c:c887
                  fe80::3e4a:92ff:fe00:4c5b
                  fe80::6cb8:18ff:fe8e:7f7a
                  fe80::fcb1:11ff:fef4:f007
              OS: Debian GNU/Linux 8 (jessie)
            Unit: machine-debian\x2dtree.scope
                  ├─75972 /sbin/init
                  └─system.slice
                    ├─cron.service
                    │ └─76037 /usr/sbin/cron -f
                    ├─systemd-journald.service
                    │ └─75989 /lib/systemd/systemd-journald
                    ├─console-getty.service
                    │ └─76048 /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt102
                    └─rsyslog.service
                      └─76040 /usr/sbin/rsyslogd -n

Można ten kontener nawet ładować przy starcie, wystarczy podlinkować go do /var/lib/container/ i dodać usługę via:

Kod:

 # systemctl enable systemd-nspawn@debian-tree.service

Prosto, łatwo, szybko i przyjemnie. Choć ja i tak tam wolę LXC. xD

Forum Debian Users Gang

Ogłoszenie

#1 2015-01-15 01:25:23

morfik - Cenzor wirtualnego świata

systemd

#2 2015-01-21 04:35:46

morfik - Cenzor wirtualnego świata

Re: systemd

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

#3 2015-01-21 17:31:07

morfik - Cenzor wirtualnego świata

Re: systemd

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

#4 2015-01-22 09:51:12

morfik - Cenzor wirtualnego świata

Re: systemd

Kod:

Kod:

Kod:

Kod:

#5 2015-01-23 03:23:38

morfik - Cenzor wirtualnego świata

Re: systemd

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

#6 2015-01-24 05:51:23

morfik - Cenzor wirtualnego świata

Re: systemd

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

Kod:

#7 2015-01-24 20:25:11

gnejusz pompejusz - Użytkownik

Re: systemd

#8 2015-01-24 21:33:29

Jacekalex - Podobno człowiek...;)

Re: systemd

gnejusz pompejusz napisał(-a):

#9 2015-01-24 21:43:39

morfik - Cenzor wirtualnego świata

Re: systemd

gnejusz pompejusz napisał(-a):

#10 2015-01-25 23:01:38

morfik - Cenzor wirtualnego świata

Re: systemd

Kod:

Kod:

Kod: