Kategoria: Linux

Opublikowane w

Linux – co warto seedować?

Jakiś czas temu postawiłem NAS w domu (jest zaległy szkic wpisu od… dawna, pewnie w końcu się zbiorę i go opublikuję). Łącze jest przyzwoite (2 Mbit uploadu) i słabo wykorzystane, a nie chciałem, żeby leżało odłogiem i postanowiłem wesprzeć projekty open source poprzez seedowanie plików.

Minęło jakieś półtora miesiąca od ostatniej zmiany plików, więc można pokusić się o jakieś wnioski. Plik/katalog i ratio:

tails-i386-0.22.1 - 15,0
debian-7.4.0-amd64-netinst.iso - 4,4
debian-7.4.0-amd64-CD-1.iso - 7,1
debian-7.4.0-i386-netinst.iso - 5,1
debian-7.4.0-i386-CD-1.iso - 7,8
debian-7.4.0-armel-netinst.iso - 1,6
debian-7.4.0-armel-CD-1.iso - 1,2

Jak widać, największym zainteresowaniem cieszy się opisywana kiedyś dystrybucja T(A)ILS, w przypadku Debiana zaskakuje niemal równa popularność architektur i386 oraz amd64 (liczyłem, że będzie duża przewaga amd64, przecież to niemal każdy współczesny procesor wspiera). IMO zupełnie nie warto seedować obrazów z architekturą armel.

Zdaję sobie sprawę, że lista jest mocno niekompletna, ale niestety nadal nie kupiłem docelowego dysku i miejsce mnie mocno ogranicza. Przy najbliższej wymianie plików wyleci armel, a pojawi się jakieś Ubuntu albo i Kali Linux.

UPDATE: Próbka jest na razie bardzo mała bo jakieś 4 dni, ale wygląda, że Kali Linux (architektura amd64, następca BackTrack, czyli dystrybucja Linuksa przeznaczona dla pentesterów) jest strzałem w dziesiątkę. Ratio 2,44, kolejny w kolejności ma 1,07…

UPDATE2: Zdecydowanie Kali Linux! Amd64 – ratio 37,3 , i386 – 25,9 w ciągu 4 tygodni.Tails – 5,01 w ciągu 2 tygodni, czyli po normalizacji czasu ratio ok. 10. Dość podobnie jak w krótkim okresie, jak widać.

Opublikowane w

One apt to rule them all

Zdarza się, że mamy więcej niż jednego czy dwa hosty do zarządzania. Zdarza się, że wykonując aktualizację na desktopie zapomnimy o innych hostach. Albo, po prostu chcemy sobie uprościć aktualizacje i nie musieć się ręcznie logować w kilka(naście, -dziesiąt) miejsc.

Jest przyjemne, konsolowe narzędzie, które ułatwi takie zadanie. Chodzi o apt-dater, czyli narzędzie do automatycznej aktualizacji wielu hostów, działające w ncurses. Działa z pochodnymi Debiana, ale również z systemami wykorzystującymi managery pakietów rug czy yum. Zasada działania jest prosta i nieco podobna do rozwiązań typu clusterssh. Na systemie docelowym dodajemy (dla pochodnych Debiana) użytkownika, który ma dodane w /etc/sudoers:

user ALL=NOPASSWD: /usr/bin/apt-get, /usr/bin/aptitude

Dodatkowo należy umożliwić temu użytkownikowi logowanie po kluczach (pamiętamy o używaniu kluczy z hasłem!) z maszyny, z której będziemy zarządzać. No i oczywiście skonfigurować hosty, którymi apt-dater będzie zarządzać. Domyślna konfiguracja znajduje się w plikach w katalogu:

$XDG_CONFIG_HOME/apt-dater/

Definiujemy tam grupy hostów, użytkowników na poszczególnych systemach, hosty (IP lub FQDN) oraz port. Przykładowa zawartość pliku hosts.conf:

[GRUPA1]
Hosts=localhost;pi@mojeraspberry:222

[GRUPA2]
Hosts=user1@serwer.www;user2@serwer.db:222;user3@serwer.poczty:222

[GRUPA3]
Hosts=user1@kolejny.serwer,user1@kolejny.serwer2

Jednym przyciśnięciem klawisza można wywołać aktualizację listy pakietów lub instalację aktualizacji w całej grupie hostów lub na pojedynczym hoście. Oczywiście jest możliwość podłączenia się do wybranego hosta i dokładnego sprawdzenia sytuacji.

Korzystanie nie jest oczywiste – trzeba się chwilę pobawić i przywyknąć. Nie podoba mi się też wykorzystanie aptitude, którego nie trawię i który AFAIK korzysta z innego algorytmu ustalania zależności, niż apt-get[1]. Wolałbym wajig albo gołego apt-get. Domyślnie wykorzystywany jest apt-get, ale można zmienić go na aptitude w pliku /etc/apt-dater-host.conf. Niemniej rozwiązanie jest ciekawe i mało znane, więc informuję i polecam wypróbowanie. A nuż komuś się spodoba. Ja używam pół na pół – czasem aktualizacje przy pomocy apt-dater, czasem po prostu aktualizuję tradycyjnym wajig daily-upgrade.

PS Dzięki K. za informację o tym programie.

[1] Z tego powodu kiedyś był zalecany przy aktualizacji wersji Debiana. Od jakiegoś czasu zalecany jest apt-get.

UPDATE: Poprawione błędy w nazwach plików, dodana informacja o wyborze programu używanego do aktualizacji.

Opublikowane w

Zabbix i monitorowanie ruchu na porcie

Niedawno na kanale IRCowym #zabbix padło pytanie, jak monitorować ruch na porcie. Po upewnieniu się, że chodzi o port protokołu, a nie o interfejs w switchu (co jest zresztą chyba bardziej popularnym znaczeniem, szczególnie w kontekście monitoringu), padły propozycje.

Moja ulubiona ostatnimi czasy metoda, czyli czytanie danych o ruchu z flowów. Poważnie, sflow i nfdump rządzą, a wrapper do Zabbiksa, który łyka parametry i używa nfdump jest trywialny do napisania, lekki i działa znakomicie, a wyciąganie dowolnych danych o ruchu jest bardzo wygodne. No ale do tego trzeba mieć zboczenie sieciowe i/lub sprzęt obsługujący flowy, ew. uruchomić zrzucanie flowów na maszynie z Linuksem, co może być zbędnym jej obciążeniem i ogólnie strzelaniem z armaty do muchy.

Prostszym rozwiązaniem jest odczyt danych bezpośrednio z iptables. Przypuśćmy, że chcemy monitorować w Zabbiksie, ile ruchu trafia do serwera na porcie 80, a ile na 443. W tym celu tworzymy reguły, które będą dopuszczały, a jednocześnie zliczały ruch na danym porcie:

iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Zakładam, że trafią w odpowiednie miejsce w łańcuchu tak, że ruch będzie przez nie przechodził. Do wyświetlania wartości posłuży iptables -L -n -v. Jak widać, w pierwszej kolumnie jest ilość pakietów, w kolejnej ilość bajtów. W /etc/zabbix/zabbix_agentd.conf dodajemy linię:

UserParameter=traffic.incoming.dstport[*], iptables -L -n -v | grep "dpt:$1" | \
sed 's/K/000/;s/M/000000/;s/G/00000000/' | awk '{print $$2}'

Kolejno: grep po parametrze wywołanym z Zabbiksa, w tym przypadku za parametr posłuży numer portu (czyli czytamy dwie wartości: traffic.incoming.dstport[80] oraz traffic.incoming.dstport[443]), zamiana (zgrubna, bo kilo to 1000, nie 1024) K, M i G na cyfry i wyłuskanie w awk drugiej kolumny, czyli ilości bajtów. Widoczny podwojony $ – bez tego zabbix_agent potraktuje $2 jako drugi parametr przekazany z serwera.

I to by było tyle w temacie. Oczywiście można w prosty sposób rozbudować. Gdyby były jakieś błędy/uwagi/sugestie to walcie śmiało – pisałem na sucho, ja tego typu dane biorę z flowów…