C

url może być pomocnym narzędziem przy debugowaniu. Gdy na rozpoznanie problemu składają się problemy z: siecią, DNS, serwerem lub wydajnością samej webaplikacji – możemy bez wahania po niego sięgnąć. W celu izolacji problemu możemy uruchomić curl’a w następujący sposób:

curl -w "$(date +%FT%T) dns: %{time_namelookup} connect: %{time_connect}\
 firstbyte: %{time_starttransfer} total: %{time_total} HTTP: %{http_code}\n"\
 -o /dev/null -s "https://apka.dev"

Polecenie takie puszczone w pętli da nam ładny podgląd na każde żądanie HTTP:
[ czytaj całość… ]

W

edług “Wprowadzenia do systemów rozproszonych” charakterystyczne opóźnienie pomiędzy węzłami ( serwerami / agentami / procesami / aktorami ) wynika z: operacji wewnątrz samych węzłów, które są “szybkie“; operacji pomiędzy węzłami, które są “wolne” – co jest szybkie, a co wolne zależne jest od tego, co wykonuje sam system. Za przykład posłuży nam klaster, który komplet danych utrzymuje po części na każdym węźle wchodzącym w jego skład. Czyli klient odpytując klaster o część interesujących go danych może odpytać o nie dowolny węzeł, ale musi poczekać aż jego odpowiedź zostanie złożona z danych zwróconych przez każdego uczestnika w klastrze. Tak na przykład działa shardowanie danych w Elasticsearch.
[ czytaj całość… ]

A

by zaoszczędzić dodatkowych wywołań systemowych na serwerze przez chodzący proces – wystarczy ustawić zmienną środowiskową TZ na wartość: :/etc/localtime. Spowoduje to, że glibc nie będzie wykonywać zbędnych, dodatkowych wywołań systemowych. Szczególnie sprawdza się to w systemach, w których ustawienie strefy czasowej nie jest cyklicznie przestawiane – lub istnieje możliwość restartu danego procesu, kiedy to występuje (w większości przypadków taka zmiana występuje tylko raz – zazwyczaj w polskich realiach jest to przestawienie z UTC na CET).
[ czytaj całość… ]

Jeśli podczas łatania np. DirtyCow na naszym serwerze wyposażonym w Ubuntu Trusty lub Xenial zainstalowane zostało jądro w wersji 4.4.0-59-generic i nagle wcześniej działające bez problemu aplikacje oraz daemony zaczęły zaliczać błędy typu: out of memory (brak pamięci) jest wielce prawdopodobne, że jest to spowodowane błędem, który wkradł się podczas rozwoju wersji. Tymczasowym rozwiązaniem do czasu aż zostanie wydany kolejny patchset naprawiający to zachowanie jest cofnięcie się do wersji: 4.4.0-57.

Więcej informacji: mm, oom: prevent premature OOM killer invocation for high order request

J

ak sprawdzić czas utworzenia pliku w systemie plików ext2/ext3/ext4? Na początku należy za pomocą stat pobrać numer i-node pliku, a następnie posłużyć się debugfs, aby wyświetlić jego szczegóły na danym urządzeniu:

root@darkstar:~# stat -c %i plik
131124
root@darkstar:~# debugfs -R 'stat <131124>' /dev/sda2

Inode: 131124   Type: regular    Mode:  0755   Flags: 0x80000
Generation: 2191072338    Version: 0x00000000:00000001
User:     0   Group:     0   Size: 8988
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 24
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x57ae0ac4:22d8c824 -- Fri Aug 12 19:43:32 2016
 atime: 0x57ae0abf:1c2bc7bc -- Fri Aug 12 19:43:27 2016
 mtime: 0x57ae0abf:1c2bc7bc -- Fri Aug 12 19:43:27 2016
crtime: 0x57ae0abf:1c2bc7bc -- Fri Aug 12 19:43:27 2016
Size of extra inode fields: 32
EXTENTS:
(0-2):557400-557402

Więcej informacji: Birth is empty on ext4

T

CPxtract jest narzędziem używanym do ekstrakcji konkretnego zestawu plików z zrzutów sieciowych w formie plików pcap poprzez zaglądanie w sesje TCP i odszukiwaniu skonfigurowanych sygnatur – technika ta nazywa się data carving. W przypadku ruchu sieciowego możemy go wykorzystać na przykład, jeśli chcemy dowiedzieć się, co dokładnie ściąga złośliwe oprogramowanie lub przeanalizować wybrany scenariusz ataku – ustawiając wcześniej sniffer na nasłuchiwanie i nagrywanie sesji połączeń. Przykład wydobycia plików .html oraz .jpg z nagranej sesji HTTP:

~:# tcpxtract -f ff.pcap -o dump/
Found file of type "html" in session [192.168.1.10:34262 -> 81.225.61.6:20480],
exporting to dump/00000000.html
Found file of type "html" in session [192.168.1.10:34262 -> 81.225.61.6:20480],
exporting to dump/00000001.html
Found file of type "jpg" in session [81.225.61.6:20480 -> 192.168.1.10:35030],
exporting to dump/00000008.jpg

Więcej informacji: tcpxtract, tcpxtract version 1.0

G

dyby kogoś zdziwiły wpisy z przeszłości w logach np. dotyczące różnego rodzaju zadań wykonywanych w dość małych odstępach czasowych to nie należy się stresować:

May 19 18:55:01 darkstar CRON[7328]: (test) CMD (/bin/echo "test")
May 15 07:45:01 darkstar CRON[7942]: (test) CMD (/bin/echo "test")
May 19 19:05:01 darkstar CRON[7945]: (test) CMD (/bin/echo "test")
May  9 10:55:01 darkstar CRON[8563]: (test) CMD (/bin/echo "test")
May  4 18:50:01 darkstar CRON[8880]: (test) CMD (/bin/echo "test")
May 19 19:35:01 darkstar CRON[9819]: (test) CMD (/bin/echo "test")
May  9 19:45:01 darkstar CRON[10093]: (test) CMD (/bin/echo "test")
May 19 19:40:01 darkstar CRON[10143]: (test) CMD (/bin/echo "test")

Bug do Ubuntu zgłoszony już w 2015 roku, ale jakoś team rsyslog’a nie pali się do jego poprawienia.

Jeśli otrzymujemy taki “warning” przy zakładaniu partycji w programie parted – zamiast konkretnej liczby bajtów lub sektorów wystarczy w przy ostatniej lub obydwu granicach podać wartość procentową np. mkpart primary ext4 0% 100%.

O

statnio podczas testów linków 10G zauważyłem ciekawą zależność. Testując różne wersje jądra w systemie Ubuntu 12.04 ze względu na różne problemy z obsługą systemu plików ext4 na świat wyszedł inny błąd powiązany z sterownikiem sieciowym. Dla wersji jądra: Linux darkstar 3.13.0-32-generic #57~precise1-Ubuntu SMP test linków za pomocą iperf prezentuje się następująco:
[ czytaj całość… ]

P

roblem: aplikacja uruchomiona na serwerze tomcat7 z nieznanych powodów w dość powolny, ale wykładniczy sposób zaczyna otwierać i przetrzymywać deskryptory plików. Z czasem skutkuje to osiągnięciem limitu otwartych plików i błędem: java.net.SocketException: Too many open files.
[ czytaj całość… ]