Forum Debian Users Gang

1509

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:08:28)

Testuję sobie właśnie ten wbudowany w systemd mechanizm synchronizacji czasu, chodzi o:

root:~# timedatectl status
      Local time: Fri 2015-01-30 09:02:20 CET
  Universal time: Fri 2015-01-30 08:02:20 UTC
        RTC time: Fri 2015-01-30 08:02:20
       Time zone: Europe/Warsaw (CET, +0100)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  Sun 2014-10-26 02:59:59 CEST
                  Sun 2014-10-26 02:00:00 CET
 Next DST change: DST begins (the clock jumps one hour forward) at
                  Sun 2015-03-29 01:59:59 CET
                  Sun 2015-03-29 03:00:00 CEST

Już pominę fakt, że widać, kiedy jest zmiana czasu. xD Chodzi głównie o ten NTP, bo jakby nie patrzeć, nie mam u siebie wgranego żadnego pakietu z ntp. Za wszystko odpowiada usługa systemd-timesyncd.service , którą się konfiguruje via  /etc/systemd/timesyncd.conf :

[Time]
NTP=0.pl.pool.ntp.org 1.pl.pool.ntp.org 2.pl.pool.ntp.org 3.pl.pool.ntp.org
FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org

Po aktywacji, system zaczyna synchronizować czas ale to też w ciekawy sposób:

Jan 30 08:27:43 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 64s/-0.013s/0.020s/0.005s/+397ppm
Jan 30 08:28:47 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 128s/-0.032s/0.021s/0.014s/+274ppm
Jan 30 08:30:55 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 128s/-0.051s/0.018s/0.046s/+74ppm
Jan 30 08:33:04 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 256s/-0.024s/0.020s/0.043s/+27ppm
Jan 30 08:37:20 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 512s/-0.036s/0.021s/0.039s/-7ppm
Jan 30 08:45:52 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 512s/-0.056s/0.023s/0.034s/-62ppm
Jan 30 08:54:24 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 1024s/-0.022s/0.020s/0.030s/-73ppm
Jan 30 09:11:29 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 2048s/-0.023s/0.021s/0.025s/-79ppm

Jak widać, odstępy między kolejnymi synchronizacjami zwiększają się, aż do osiągnięcia maksymalnych 2048sekund (34min). Nie wiem jaki jest cel takiego rozwiązania  ale jeśli się przyjrzeć, to z jakichś powodów czasem czas (xD) nie ulega podwojeniu. Być może mają coś wspólnego z tym te cyferki, tylko co? xD

W każdym razie jeśli chodzi o czas, to chciałem nadać temu procesowi od synchronizacji wyższy priorytet i tu z początku wystąpił problem -- jak niby to zrobić no bo raczej nie przez:

# nice -n -20 ionice -n 0 -c 1

Poszukałem i znalazłem. Oczywiście chodzi o parametry unitów, a  yych dotyczących priorytetów jest z 10 i są tam miedzy innymi te 3, które widać wyżej i działa to dokładnie na takiej samej zasadzie co powyższa linijka, z tym, że procesy nie są wywoływane na zasadzie, że pierw odpala się nice, którego proces przybiera określony priorytet, potem wywołuje proces potomny, który dziedziczy ten priorytet i ustawia priorytet dla IO i wywołuje następny proces potomny, który dziedziczy oba te priorytety. xD Tu jest tylko jeden proces z założonymi już priorytetami.

Poniżej są te 3 parametry:

Nice=-20
IOSchedulingClass=1
IOSchedulingPriority=0

Nice przybiera wartości od -20 do 19, IOSchedulingClass od 0 do 3, a IOSchedulingPriority od 0 do 7 . Wszędzie im niższy numer tym większy priorytet. Cała filozofia. xD

No to teraz sobie wyprofiluje system, bo jakby nie patrzeć to ile razy nadawaliście skryptom init priorytety? A ile razy nadpisała wam to aktualizacja pakietu? xD

Ostatnio edytowany przez morfik (2015-01-30 09:30:01)

W końcu udało mi się odtworzyć konsolę, którą miałem na pulpicie, wykorzystując do tego celu journalctl . Wcześniej wykorzystywałem do tego urządzenie FIFO + rsyslog . W tej chwili już nie potrzebuje ani jednego ani drugiego. xD Całość sprowadza się do wpisania w config tmuxa poniżej linijki:

new -d -s logi -n logi "journalctl -b --no-pager | ccze -m ansi && journalctl -n 0 -f | ccze -m ansi"

Są tam dwa wywołania journalctl, z których jeden czyta logi od startu maszyny, drugi zaś nasłuchuje kolejnych. Oba logi są pokolorowane. Na dobrą sprawę z wierzchu, to niczym się ta konsola nie różni. Jest tylko trochę więcej komunikatów + dodatkowo będą wyświetlane logi z wczesnego startu systemu, bo tego rsyslog nie potrafił. Dodatkowa zaleta tego rozwiązania jest taka, że jeśli mi tmux zdechnie, to po tym jak się odpali, dostaję kompletny log, a nie tak jak w przypadku tego urządzenia FIFO, tracone było wszystko i log zaczynał się w miejscu urwania.

I taka sprawa jeszcze:

Jan 31 22:17:12 morfikownia su[46070]: + /dev/pts/2 morfik:root
Jan 31 22:17:12 morfikownia su[46070]: pam_unix(su:session): session opened for user root by (uid=1000)
Jan 31 22:30:37 morfikownia systemd[1]: Stopping Flush Journal to Persistent Storage...
Jan 31 22:30:37 morfikownia systemd[1]: Stopping Journal Service...
Jan 31 22:30:37 morfikownia systemd-journal[257]: Journal stopped
Jan 31 22:30:37 morfikownia systemd-journal[50572]: Permanent journal is using 116.7M (max allowed 300.0M, trying to leave 1.7G free of 4.6G available → current limit 300.0M).
Jan 31 22:30:37 morfikownia systemd-journald[257]: Received SIGTERM from PID 1 (systemd).
Jan 31 22:30:37 morfikownia systemd[1]: Starting Journal Service...
Jan 31 22:30:37 morfikownia systemd-journal[50572]: Journal started
Jan 31 22:30:37 morfikownia systemd[1]: Started Journal Service.
Jan 31 22:30:37 morfikownia systemd[1]: Starting Flush Journal to Persistent Storage...
Jan 31 22:30:37 morfikownia systemd[1]: Started Flush Journal to Persistent Storage.

Jak widać wyżej, log jest ciągły, nawet pomimo zresetowania journala -- gdybym zresetował rsysloga, konsolę by mi szlag trafił i trzeba by ją odpalać jeszcze raz.

No to już jedną nogą jestem przy pozbyciu się rsysloga. Jeszcze muszę nauczyć ten journalctl łapać logi z sieci oraz filtrować logi usług, bo sporo komunikatów jest zbędnych -- jeśli te dwie rzeczy uda mi się zaimplementować, to wywalam rsysloga razem z logrotate i uprzątnę ten burdel co mi się zrobił przez ostatnie miesiące w /var/log/ . xD

Doszukałem się trochę info na temat tego ficzera z szyfrowaniem dziennika:

One key is the "sealing key" which is kept on the system, and the other is the "verification key" which should be securely stored elsewhere. Using the FSPRG mechanism, a new sealing key is generated periodically using a non-reversible process. The old key is then securely deleted from the system after the change.

The verification key can be used to calculate the sealing key for any given time range. That means that the attacker can only access the current sealing key (which will presumably be used for the next sealing operation), while the administrator can reliably generate any sealing key to verify previous log file seals. Changing log file entries prior to the last seal will result in a verification failure.

http://lwn.net/Articles/512895/[/quote]
By z skorzystać z tej opcji, trzeba w /etc/systemd/journald.conf mieć ustawione:

Kod:

...
Storage=persistent
Seal=yes
...

Trzeba także wygenerować sobie dwa klucze, a te z kolei zaś najlepiej tworzyć z mniejszym interwałem niż jest domyślnie czyli 15min:

Kod:

# journalctl --setup-keys --interval=60s

Po stworzeniu kluczy trzeba zatrzymać dziennik, usunąć wszystkie pliki dziennika i wystartować go jeszcze raz.

I tu jest mały problem, z tym, że nie wiem czy to tylko u mnie, czy to jakiś bug/ficzer, że ten mechanizm nie działa. xD Jeśli popatrzeć na sam klucz:

Kod:

root:/var/log/journal/159815709bbc46c29ef786cfc497afd4# ls -al
total 8.1M
drwxr-sr-x+ 2 root systemd-journal 4.0K 2015-02-01 07:16:13 ./
drwxr-sr-x+ 3 root systemd-journal 4.0K 2015-01-22 19:22:30 ../
-rw-------+ 1 root systemd-journal  482 2015-02-01 07:18:00 fss
-rw-r-----+ 1 root systemd-journal 8.0M 2015-02-01 07:18:00 system.journa
l
root:/var/log/journal/159815709bbc46c29ef786cfc497afd4# ls -al
total 8.1M
drwxr-sr-x+ 2 root systemd-journal 4.0K 2015-02-01 07:16:13 ./
drwxr-sr-x+ 3 root systemd-journal 4.0K 2015-01-22 19:22:30 ../
-rw-------+ 1 root systemd-journal  482 2015-02-01 07:19:00 fss
-rw-r-----+ 1 root systemd-journal 8.0M 2015-02-01 07:18:00 system.journal

to widać wyraźnie, że się generuje co 1min ale jeśli chodzi o sprawdzanie dziennika, to przed pieczętowaniem jest ok:

Kod:

# journalctl --verify --verify-key 48738d-de9093-2f6b15-9416f8/181f35-35a4e900
PASS: /var/log/journal/159815709bbc46c29ef786cfc497afd4/system.journal
=> No sealing yet, 14.775ms of entries not sealed.

ale po zapieczętowaniu, już nie jest ok i wyrzuca błędy o nieprawidłowych wiadomościach.

Nie mam pojęcia co z tym zrobić — jest dokładnie to samo na wersji eksperymentalnej i sidowej. Próbowałem na standardowych ustawieniach, jak i na swoich własnych i ciągle to samo. Znalazłby się ktoś, kto by przetestował czy ten mechanizm u niego działa normalnie? xD