Maciej[cc] » linux

Debugowanie kontenerów w kubernetesie – część 2

maciej — Tue, 12 Mar 2024 10:02:11 +0000

Po poprzedniej części zapraszam na kolejną, pokazującą jak poradzić sobie z ograniczeniami które wprowadza Kubernetes podczas debugowania aplikacji sieciowych.

Wykonanie pojedynczego polecenia/shelll

kubectl -n my_namespace exec -it pod -- /bin/some_command

Gdzie zwykle /bin/some_command można zastąpić /bin/bash

Kontener do debugowania

kubectl debug my_pod_name -n my_namespace -it --image=ubuntu:latest /bin/bash

Powyższe spowoduje uruchomienie nowego kontenera w tym samym podzie. Dzięki temu możemy połączyć się do localhost (127.0.0.1) i sprawdzić jak działają nasze serwisy za pomocą curl/wget. W trybie debug mamy też dostęp do roota, dzięki czemu hardening właściwej aplikacji nie jest aż tak straszny i nie ogranicza nas, np. w zainstalowaniu nowych paczek. Taki kontener nie współdzieli też systemu plików z oryginalnymi kontenerami z poda, dzięki temu nie namieszamy zbyt dużo.

Lepszy kontener do debugowania

kubectl debug my_pod_name -n my_namespace -it --image=ubuntu:latest --share-processes -c container_name --copy-to=mg-debug

Jest to trochę bardziej rozbudowana wersja poprzedniego polecenia. Odpalając taki kontener do debugowania możemy wybrać jeden z istniejących kontenerów i kubectl skopiuje jego konfiguracje (zamontowane volumes, sieć i przestrzeń procesów). Zabawa w takim środowisku daje już dość duże możliwości interakcji z innymi kontenerami. Można wysłać przyjacieski sygnał -KILL do procesów, pogrzebać w podmontowanych wolumenach lub sprawdzić sieć, również bez ograniczeń hardeningu.

Shell noda

Link dla zdesperowanych: https://github.com/kvaps/kubectl-node-shell. Skrypt potrafi uruchomić shell na nodzie kubernetesa. Dzięki niemu możemy dostać się jako root na dowolnego noda z klastra jako root i wprost pogrzebać w systemie. Chyba najbardziej “wszechmocna” opcja do zabawy w szukanie dziury w całym.

Miłego debugowania!

Kubernetes – jak działa cluster IP

maciej — Sun, 29 Dec 2019 13:27:08 +0000

Niedawno pisałem o implementacji sieci opartej o Flannel. Zabrakło tam jednak jednej istotnej rzeczy – clusterIP. W tym poście przeczytasz jak dokładnie jest to zaimplementowane.

Jeśli patrzyłeś na organizację interfejsów, adresów itd., to pewnie rzuciło Ci się w oczy, że nigdzie nie było routingu ani żadnego innego śladu po adresach IP przydzielonych do serwisów. Jeśli korzystasz z domyślnej konfiguracji, jaką Kubernetes daje, to jest to pula 10.96.0.0/16. Z niej można wybrać dowolny adres IP który będzie dostępny w całym klastrze Kubernetesa i routowany do konkretnego serwisu:

apiVersion: v1
kind: Service
metadata:
 name: dinemic-io
 labels:
 app: dinemic-io
spec:
 ports:
 - port: 80
 selector:
 app: mnabozny-pl
 clusterIP: 10.96.0.123

Serwis za pomocą definicji z pola selector wyszukuje odpowiednie aplikacje, do których będzie przekierowany ruch na port 80. Będąc w dowolnym miejscu klastra (node lub K8s master) zawsze będziemy mogli połączyć się z tym adresem, na port 80. Patrząc natomaist w tablicę routingu, nie znajdziemy ani jednego wpisu wskazującego na taką pulę adresów:

maciek> ip route show
default via 192.168.1.1 dev eth0 onlink 
10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.1 
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1 
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink 
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink 
10.244.3.0/24 via 10.244.3.0 dev flannel.1 onlink 
10.244.4.0/24 via 10.244.4.0 dev flannel.1 onlink 
...

Pula adresów 10.0.0.0/24 to fizyczna sieć klastra, w którym działa Kubernetes. 10.244.X.0/24 to pula adresów, które Kubernetes przydziela poszczególnym podom na nodach (gdzie X odpowiada nodowi, a konkretny numerek podowi).

Traceroute do adresu powyższego serwisu wychodzi zawsze poza moją sieć, zgodnie z tym, co mówi tablica routingu. Wget na http://10.96.0.123:80 zawsze magicznie dociera do celu. Gdzie więc czai się ta magia?

Iptables dla clusterIP

Popatrzmy w ipsables. Za pomocą sudo iptables-save można wylistować wszystkie regułki, które są aktualnie załadowane do jądra. Jest tego dość sporo, dla tego można wspomóc się grepem:

maciek> sudo iptables-save | grep 10.96.0.123
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.96.0.123/32 -p tcp -m comment --comment "cloudover/dinemic-io: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.96.0.123/32 -p tcp -m comment --comment "cloudover/dinemic-io: cluster IP" -m tcp --dport 80 -j KUBE-SVC-AA7UXNSLITSSEFAY

Do łańcucha KUBE-SERVICES jest przekierowywany cały ruch z łańcucha INPUT. Pierwsza z powyższych reułek oznacza pakiety, które mają być oznaczone do MASQUERADE. Druga natomiast przekazuje je do konkretnego łańcucha – KUBE-SVC-AA7UXNSLITSSEFAY. Obie reguły działają dla docelowego adresu 10.96.0.123, na docelowym porcie 80.

Łańcuch dla konkretnego serwisu

W powyższym outpucie z iptables-save można zobaczyć, że druga regułka przekierowuje druch do konkretnego łańcucha, odpowiadającego serwisowi – KUBE-SVC-AA7UXNSLITSSEFAY. Przyjżyjmy się mu bliżej:

maciek> sudo iptables -nL KUBE-SVC-AA7UXNSLITSSEFAY -t nat
Chain KUBE-SVC-AA7UXNSLITSSEFAY (1 references)
target prot opt source destination 
KUBE-SEP-Q3TQA7ZS25JCTF3F all -- 0.0.0.0/0 0.0.0.0/0

Powyższy serwis przekierowuje cały ruch (100%) do łańcucha odpowiadającemu konkretnemu podowi, na port 80, robiąc przy okazji DNAT:

maciek> sudo iptables -nL KUBE-SEP-Q3TQA7ZS25JCTF3F -t nat
Chain KUBE-SEP-Q3TQA7ZS25JCTF3F (1 references)
target prot opt source destination 
KUBE-MARK-MASQ all -- 10.244.3.115 0.0.0.0/0 
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp to:10.244.3.115:80

Czyli, podsumowując, dowolny pakiet wchodzący do noda (INPUT) lub wychodzący z niego (OUTPUT) jest procesowany przez łańcuch KUBE-SERVICES. W nim natomiast K8S dodaje pojedyncze regułki, które wyłapują ruch kierowany do poszczególnych clusterIP przydzielonych do serwisów. Każdy serwis i clusterIP posiada swój osobny łańcuch KUBE-SVC-…, w którym jest rozdzielany ruch do poszczególnych podów i ich łańcuchów, w których jest realizowany DNAT.

Serwis dla wielu podów

Powyższy przykład pokazywał wpisy dla serwisu, który przekazuje ruch do jednego poda. Co jeśli przeskalujemy go do dwóch instancji? Szybkie kubectl apply -k . i po chwili mamy kilka zmian! Chwila oznacza dokładnie tyle, ile trzeba aby nowy pod się uruchomił i zaczął działać. Popatrzmy jeszcze raz w całe iptables. KUBE-SYSTEM pozostaje bez zmian, dalej kieruje ruch dla clusterIP 10.96.0.123 do naszego serwisu, w łańcuchu KUBE-SVC-AA7UXNSLITSSEFAY.

Natomiast sam łańcuch KUBE-SVC-AA7UXNSLITSSEFAY ma już nowe wpisy:

> sudo iptables -nL KUBE-SVC-AA7UXNSLITSSEFAY -t nat
Chain KUBE-SVC-AA7UXNSLITSSEFAY (1 references)
target prot opt source destination 
KUBE-SEP-Q3TQA7ZS25JCTF3F all -- 0.0.0.0/0 0.0.0.0/0 statistic mode random probability 0.50000000000
KUBE-SEP-OCALVIKCSC2PZKNJ all -- 0.0.0.0/0 0.0.0.0/0

Dodana została na początku nowa regułka kierująca 50% ruchu (popatrz na komentarz – statistic mode, z probability 0.5) do nowego poda, którego ruch jest kształtowany przez łancuch KUBE-SEP-Q3TQA7ZS25JCTF3F. Pozostałe 50% ruchu wpada w ostatnią regułkę, która jest tam od początku. Jeśli przeskalujemy nasz deployment do większej ilości podów, to udział procentowy odpowiednio spadnie do 100/N.

Skalowalność samego cluster IP

Można mieć wrażenie, że każdy pod w klastrze K8S jest w pewnym stopniu single point of failure i jest to prawdą. Natomiast dołożenie nad podami i naszymi aplikacjami abstrakcyjnej warstwy serwisów, które są czymś w rodzaju load balancera, pozwala bardzo łatwo ograniczyć ten słaby punkt. Jeśli nasze pody z aplikacją będą odpowiednio rozproszone po klastrze, w dużej ilości instancji, to awaria dowolnego poda nie wpłynie na dostępność naszego serwisu.

A co z samym clusterIP? Zauważ, że to konkretne IP, na które tu patrzyliśmy nie jest nigdzie “fizycznie” widoczne. Każdy host w klastrze K8S posiada swój własny zestaw regułek, zwykle spójny z innymi, przynajmniej pod kątem clusterIP. Próbując dostać się do konkretnego serwisu, właśnie przez clusterIP tak na prawdę iptables losuje nam IP poda, na który będziemy przekierowani i DNAT’owani.

Również dzięki temu można przekierować/przeroutować ruch np. z VPN lub zewnętrznej sieci do dowolnego noda, który stanie się wtedy gateway’em. Taki node po otrzymaniu pakietu do jednego z clusterIP przekieruje takie zapytanie dalej, do odpowiedniego poda.

Troubleshooting

A wszystko to, bo ostatnio pomieszałem labelki w selektorze aplikacji www i mysql’a :) około połowa połączeń była odrzucana, przez co strona częściej nie działała niż działała. Jeśli doświadczasz losowego connection refused, to prawdopodobnie właśnie przy load balancingu/losowaniu poda K8S przekierowuje Twoje zapytanie do innego poda, który w danej chwili ma uruchomioną inną usługę. Po sprawdzeniu, zmianie labelek i przeładowaniu całego serwisu wszystko zaczyna działać.

Kubernetes – co w sieci piszczy

maciej — Sun, 24 Nov 2019 10:44:57 +0000

Zróbmy wycieczkę pakietem od poda, aż po default gateway całego klastra Kubernetesa. Post ma na celu ułatwienie debugowania ewentualych problemów sieciowych Kubernetesa z Flannelem.

Skoro to czytasz, to zakładam, że masz jako takie pojęcie czym się je Kubernetesa, czym są pody i interfejsy sieciowe. Dobrze, gdybyś też wiedział conieco o kontenerach Dockera. Na tapetę weźmiemy (nie)działającą instalację, która składa się z kilku kontenerów i sieci obsługiwanej przez Flannel. Zaczynajmy!

Wejdźmy do poda

A zanim wejdziemy, zobaczmy jakie mamy pody:

master# kubectl get pods -n cloudover
NAME READY STATUS RESTARTS AGE
cloudover-io-8xxxyyy886-6c86k 1/1 Running 2 10d
cloudover-io-8xxxyyy886-jx479 1/1 Running 2 10d
cloudover-org-xxxyyyc48-4j4j4 1/1 Running 2 10d
cloudover-org-xxxyyyc48-jv59p 1/1 Running 2 10d
dinemic-io-599xxxyyy8-86d49 1/1 Running 2 20d
dinemic-io-599xxxyyy8-t4pq6 1/1 Running 2 20d
dinemic-io-backup-15xxxyyy20-4t2xr 0/1 Completed 0 2d17h
dinemic-io-backup-15xxxyyy20-2x7pp 0/1 Completed 0 41h
dinemic-io-backup-15xxxyyy20-7k8zs 0/1 Completed 0 17h
dinemic-io-mysql-79yyyxxx6d-wfdrh 1/1 Running 2 20d
mnabozny-pl-56xxxyyy45-p9jp2 1/1 Running 2 20d
mnabozny-pl-56xxxyyy45-plzfq 1/1 Running 2 20d
mnabozny-pl-backup-157xxxyyy0-q76s7 0/1 Completed 0 125m
mnabozny-pl-backup-157xxxyyy0-vrzgt 0/1 Completed 0 65m
mnabozny-pl-backup-157xxxyyy0-nt5mm 0/1 Completed 0 5m20s
mnabozny-pl-mysql-86xxxyyy55-q7nhn 1/1 Running 2 20d
pkg-cloudover-org-84xxxyyy78-dxzxr 1/1 Running 2 10d
pkg-cloudover-org-84xxxyyy78-tqb7w 1/1 Running 2 10d
pkg-dinemic-io-xxxyyyfc77-2729k 1/1 Running 2 10d
pkg-dinemic-io-xxxyyyfc77-4vjsq 1/1 Running 2 10d

Mamy więc kilka podów z różnych moich serwisów oraz zakończone cron joby backupu danych (Completed). Weźmy na warsztat poda pkg-dinemic-io-xxxyyyfc77-2729k, który sprawia problemy i zobaczmy jak wygląda jego sieć. Żeby było czym popatrzeć, musimy doinstalować potrzebne narzędzia (polecenie ip). Domyślnie, obraz dockera, z którego odpalony jest ten serwis, jest dość mocno okrojony:

master# kubectl exec -n cloudover -it pkg-dinemic-io-... bash
apt update
apt install -yqq iproute2 traceroute

Kolejną rzeczą jest sprawdzenie na którym nodzie uruchomiony jest pod, który chcemy zbadać i doinstalowanie tcpdumpa.

Mając (prawie) wszystko co potrzeba, możemy zobaczyć jak połączone są interfejsy poda i noda. Linux (docker i cała masa innych narzędzi) wykorzystuje mechanizm veth oraz sieciowe namespace (przestrzenie nazw), netns do oddzielania od siebie ruchu sieciowego kontenerów, wirtualnych maszyn itd. Namespace to grupa procesów (dotyczy to też dowolnego innego zasobu), która współdzieli te same interfejsy, tablice routingu, firewall i trochę innych rzeczy. Działa to prawie tak, jak osobny host w sieci lub wirtualna maszyna, z tą różnicą, że mamy doczynienia z jednym systemem operacyjnym. Jądro Linuksa odseparowuje te zasoby, aby można było używać np. nachodzących na siebie adresacji lub regułek iptables bez żadnych dodatkowych komplikacji.

Druga z przydatnych rzeczy, o której wspomniałem to interfejs typu veth. Najprościej jest porównać je do wirtualnego kabelka ethernetowego, który spina dwa interfejsy. Jeśli pakiet pojawi się na jego jednym końcu, to jest widoczny również na drugim (peer interface). Sparowane interfejsy veth można przekładać pomiędzy różnymi namespaces i przy nieco bardziej zaawansowanej konfiguracji, kształtować ruch sieciowy pomiędzy nimi. Korzysta z tego m.in. openstackowy neuron, flannel, corecluster i prawdopodobnie sporo innych narzędzi.

# dodaj nowa namespace
ip netns add test-ns

# dodaj pare interfejsow veth - veth1 i veth1p, ktore sa wzajemnie sparowane
ip link add veth1 type veth peer name veth1p

# ustaw namespace interfejsu peer na nasza nowa namespace
ip link set veth1p netns test-ns

Powyższy przykład tworzy nazwaną namespace, którą możemy zobaczyć przez ip netns show i usunąć przez ip netns del test-ns.

My za pomocą polecenia ip chcemy zobaczyć jak poukładane są interfejsy sieciowe na nodzie, gdzie jest uruchomiony pod. Sprawdźmy najpierw w samym podzie jakie mamy interfejsy:

pod# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
3: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default 
 link/ether a2:62:74:d8:6e:1c brd ff:ff:ff:ff:ff:ff link-netnsid 0
 inet 10.244.1.80/24 scope global eth0
 valid_lft forever preferred_lft forever

Jak zawsze lo, które jest po prostu lo. Eth0 za to prezentuje się nieco inaczej niż na “zwykłym” systemie. Po nazwie eth0 widzimy @if12. Dwunastka po małpie oznacza id interfejsu peer, który jest sparowany z naszym eth0. Eth0 w tym przypadku veth w przestrzeni namespace, której tutaj nie widzimy, z netnsid 0.

Patrząc po drugiej stronie, czyli na nodzie mamy taką listę interfejsów:

node# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
 link/ether aa:bb:cc:xx:yy:zz brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
 link/ether aa:bb:cc:xx:yy:zz brd ff:ff:ff:ff:ff:ff
...
12: veth7b2f355b@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether 92:04:f7:a2:90:f0 brd ff:ff:ff:ff:ff:ff link-netnsid 5

Ostatni z nich to dźwięcznie brzmiący veth7b2f355b z dopiskiem @if3 Patrząc na pierwszy listing, który zrobiliśmy w podzie, z eth0@if12 widać, że eth0 poda miało id 3. Wszystko wię zatem zgadza. Ostatnią rzeczą, na którą warto rzucić okiem to parametr link-netnsid oznaczający ID namespace, do którego przypisany jest peerowany interfejs. Tak więc, w ip link show bezpośrednio z noda widzimy, że interfejs veth7b2f355b jest speerowany (sparowany? może pożeniony? :) z interfejsem o id 3 z namespace o id 5. W ip link show uruchomionym na podzie, widzimy, że interfejs eth0 jest speerowany z interfejsem o id 12, z namespace 0.

Wszystko się zgadza. Żeby sprawdzić możemy puścić pinga lub traceroute z poda i nasłuchiwać na odpowiadającym mu interfejsie sieciowym, na nodzie. Pakiety powinny się pojawić.

Dalej, w świat po opuszczeniu poda

Pakiety wychodzące z poda są adresowane przez “system operacyjny” poda z adresu interfejsu eth0 (src):

pod# ip route show
default via 10.244.1.1 dev eth0 
10.244.0.0/16 via 10.244.1.1 dev eth0 
10.244.1.0/24 dev eth0 proto kernel scope link src 10.244.1.80

W tym przypadku będzie to 10.244.x.y/24, który skonfigurował automatycznie Kubernetes. Po stworzeniu takiego pakietu i zaadresowaniu, jego warstwa IP nie powinna się zmieniać (chyba, że przejdzie przez magiczne regułki iptables, o czym będzie później). Zatem sam pod odpowiada za przygotowanie naszego pakietu w warstwie trzeciej.

Po przejściu na drugą stronę, czyli do “systemu” noda, pakiet taki pojawia się na interfejsie speerowanym z podem. Patrząc na adresacje tego interfejsu po stronie noda, nie zobaczymy już na nim adresu IP:

node# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host 
 valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
 link/ether b8:27:eb:46:06:69 brd ff:ff:ff:ff:ff:ff
 inet 10.0.0.103/24 brd 10.0.0.255 scope global eth0
 valid_lft forever preferred_lft forever
 inet6 fe80::ba27:ebff:fe46:669/64 scope link 
 valid_lft forever preferred_lft forever
...
5: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default 
 link/ether 9e:2b:2b:16:e2:73 brd ff:ff:ff:ff:ff:ff
 inet 10.244.1.0/32 scope global flannel.1
 valid_lft forever preferred_lft forever
 inet6 fe80::9c2b:2bff:fe16:e273/64 scope link 
 valid_lft forever preferred_lft forever
6: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
 link/ether 5a:a8:5d:84:d7:ee brd ff:ff:ff:ff:ff:ff
 inet 10.244.1.1/24 scope global cni0
 valid_lft forever preferred_lft forever
 inet6 fe80::58a8:5dff:fe84:d7ee/64 scope link 
 valid_lft forever preferred_lft forever
...
12: veth7b2f355b@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP group default 
 link/ether 92:04:f7:a2:90:f0 brd ff:ff:ff:ff:ff:ff link-netnsid 5
 inet6 fe80::9004:f7ff:fea2:90f0/64 scope link 
 valid_lft forever preferred_lft forever

W zasadzie żaden z interfejsów speerowanych z podami nie ma przypisanego adresu. Jak jest zatem organizowany routing i przekazywanie pakietów? Tu zaczyna się nieco trudniejsza zabawa.

Każdy z interfejsów przyłączonych do podów jest zmostkowany z cni0 (żeby wyświetlić, doinstaluj pakiet br-utils):

node# brctl show
bridge name	bridge id		STP enabled	interfaces
cni0		8000.5aa85d84d7ee	no		veth67f9f314
							veth7b2f355b
							veth96d5a04b
							vethe25b43a7
							vethed432234
docker0		8000.02421143bd1a	no

Nasz interfejs veth7b2f355b również tam jest. Zatem pakiety, o ile nie zostaną wycięte przez iptables, są przekazywane przez mostek pomiędzy interfejsami z tego samego noda. Jeśli nie możesz sobie tego wyobrazić, to pomyśl, że cni0 jest switchem, a każdy zmostkowany interfejs jest kabelkiem (veth) prowadzącym do innego komputera (tutaj to namespace).

Dokładnie to samo można sprawdzić przez polecenie ip z pakietu iproute:

node# ip link show
...
6: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default qlen 1000
 link/ether 5a:a8:5d:84:d7:ee brd ff:ff:ff:ff:ff:ff
7: veth67f9f314@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether ce:53:d6:38:84:5c brd ff:ff:ff:ff:ff:ff link-netnsid 0
8: vethe25b43a7@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether a6:16:c1:f9:ae:02 brd ff:ff:ff:ff:ff:ff link-netnsid 1
10: vethed432234@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether 82:a5:3c:69:61:39 brd ff:ff:ff:ff:ff:ff link-netnsid 3
11: veth96d5a04b@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether 7e:af:3a:8a:29:91 brd ff:ff:ff:ff:ff:ff link-netnsid 4
12: veth7b2f355b@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether 92:04:f7:a2:90:f0 brd ff:ff:ff:ff:ff:ff link-netnsid 5

Każdy z interfejsów zmostkowanych z cni0 (lub innym mostkiem) ma parametr master cni0, który odpowiada za “bycie w bridgu” z cni0.

Ok, mamy zatem interfejsy, które są ze sobą połączone warstwą drugą, natomiast nie mamy jeszcze interfejsu, który odpowiadałby za wypchnięcie pakietu z noda lub przekazanie do innego poda. O ile w podzie wszystko jest jasne i routing mówi: wszystko co nie do mnie, idzie przez default gw, to na nodzie tak różowo nie jest.

Pakiety w obrębie jednego noda są routowane pomiędzy nimi, przez cni0 – każdy pod na nodzie ma swój IP z sieci przypisanej do noda – w tym przypadku 10.244.1.0/24. Jeśli pakiet ma być dostarczony do innego noda, to zaczynają się schodki.

Tablica rouringu noda wygląda następująco:

node# ip route show
default via 10.0.0.1 dev eth0 onlink 
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.103 
10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink 
10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1 
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink 
10.244.3.0/24 via 10.244.3.0 dev flannel.1 onlink 
10.244.4.0/24 via 10.244.4.0 dev flannel.1 onlink 
10.244.5.0/24 via 10.244.5.0 dev flannel.1 onlink 
10.244.6.0/24 via 10.244.6.0 dev flannel.1 onlink 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

Cała sieć 10.244.1.0/24 jest routowana do naszego noda przez cni0. Natomiast sieci z innych nodów (10.244.2-6.0/24) są przesyłane przez interfejs flannel.1. Dopisek onlink mówi kernelowi, aby przesyłał ruch do tych sieci, nawet nie mając na tym interfejsie przypisanego adresu ip (inaczej musiałby mieć trasę przez konkretny host).

Interfejs flannel.1 jest tunelem vxlan (ip -d link show pokaże przy nim ID vlanu 1, mówi o tym też dopisek .1 w nazwie). Zatem adresując pakiet z naszego poda z adresem 10.244.1.68, przechodzi on przez interfejsy veth do domyślnego namespace, i pojawia się jako pakiet przychodzący przez port cni0 (łapie się na regułki z łancucha FORWARD z iptables), ale nie adresowany do naszego noda (zatem nie będzie to iptables INPUT). Ponieważ kernel w domyślnym namespace zna regułki mówiące o tym jak dostać się do innych sieci na innych nodach, przesyła taki pakiet przez interfejs flannel.1. Tam już na podstawie zapytań arp odnajnowany jest host z sieci innego noda, obsługującego danego poda, np. 10.244.6.0/32:

node# arp -an | grep flannel.1
? (10.244.4.0) at 2e:ed:ad:yy:aa:xx [ether] PERM on flannel.1
? (10.244.0.0) at d2:79:b7:yy:aa:xx [ether] PERM on flannel.1
? (10.244.3.0) at 1e:42:c2:yy:aa:xx [ether] PERM on flannel.1
? (10.244.6.0) at 5a:2d:9a:yy:aa:xx [ether] PERM on flannel.1
? (10.244.2.0) at c6:52:d3:yy:aa:xx [ether] PERM on flannel.1
? (10.244.5.0) at ce:ec:b4:yy:aa:xx [ether] PERM on flannel.1

Sieć stworzona z interfejsów flannel.1 różnych nodów można znowu wyobrazić sobie jako switcha spinającego po jednym kabelku z różnych nodów. Jednak zamiast par veth mamy tutaj tunele VXLAN, które tworzą wirtualną warstwę 2, niezależną od fizycznej sieci. W powyższym przypadku vxlan stworzony przez flannel.1 jest wypuszczany do fizycznej sieci przez eth0 noda. W vxlanie node za pomocą pakietów ARP poznaje inne hosty w sieci i na ich podstawie jest w stanie poprawnie zaadresować mac adres karty odpowiadającej docelowej sieci, w której będzie pod. Flaga onlink w tablicy routingu trochę to zadanie ułatwia, gdyż normalnie kernel musiałby mieć podanego hosta we wspólnej sieci, łączącej wszystkie nody. Tutaj ten etap jest pominięty i przeniesiony na vxlan i odkrywanie hostów poniekąd przez arp.

Po osiągnięciu docelowego hosta przez vxlan, pakiet przebywa analogiczną drogę do poda.

iptables

Po wpisaniu iptables-save dostajemy całkiem sporo regułek i łańcuchów, które odpowiadają za filtrowanie ruchu i natowanie go. Z ważniejszych rzeczy, na które warto zwrócić uwagę, to na wszystkich nodach mamy mimo wszystko ustawioną politykę FORWARD na DROP z dopuszczeniem przekazywania pakietów z sieci flanella:

:FORWARD DROP [0:0]
...
-A FORWARD -s 10.244.0.0/16 -j ACCEPT
-A FORWARD -d 10.244.0.0/16 -j ACCEPT

Do debugowania ruchu może też się przydać poniższy zestaw regułek:

-A POSTROUTING -s 10.244.0.0/16 -d 10.244.0.0/16 -j RETURN
-A POSTROUTING -s 10.244.0.0/16 ! -d 224.0.0.0/4 -j MASQUERADE --random-fully
-A POSTROUTING ! -s 10.244.0.0/16 -d 10.244.1.0/24 -j RETURN
-A POSTROUTING ! -s 10.244.0.0/16 -d 10.244.0.0/16 -j MASQUERADE --random-fully

Określa on skąd i gdzie pakiety mają być natowane oraz jaki ruch powinien zostać zablokowany.

Dodatkowo w dumpie z iptables-save znajdziemy też całą listę (dość długą) reguł, określających dostęp do klastra k8s, jego serwisów i dns’a.

Uff…

Podsumowując, inżynierowie integrujący flanella zrobili kawał dobrej roboty, który niekoniecznie dobrze się debuguje w razie problemów :) Natomiast ostatnie kilka lub kilkanaście lat pracy nad wirtualizacją i kontenerami daje coraz lepsze narzędzia pozwalające coraz lepiej kontrolować ruch sieciowy w tak zagmatwanych środowiskach jakim jest na przykład kubernetes.

Jak trzymać hasła w pamięci i dlaczego cstringi są czasem lepsze od std::stringów?

maciej — Sat, 16 Feb 2019 08:32:37 +0000

“Poznaj sekret cstringów. Std::stringi ich za to nienawidzą”! A na serio, nie zgapiając od pomponików, będzie trochę na temat trzymania wrażliwych danych w pamięci RAM i o zapobieganiu ich zapisowi na dysk.

Na początek krótkie ćwiczenie: napisałeś program do przechowywania haseł. Taki keepass w wersji DIY. Po uruchomieniu wczytuje zaszyfrowany plik do pamięci, pyta Cię o hasło, odszyfrowuje i pokazuje wybrane hasło. Działa dopóki go nie zamkniesz, na wszelki wypadek, jakbyś potrzebował jeszcze innego hasła. Niby bezpieczne, bo zaszyfrowane, na hasło… ale nie do końca.

Co może pójść nie tak?

Trzymasz odszyfrowany pęk kluczy w pamięci – to pierwszy problem. Dowolne nadpisanie/odczytanie takiej pamięci, np. przez /dev/mem albo /proc/X/mem może skompromitować wszystkie hasła z Twojego pęku – dowolna osoba z uprawnieniami root’a będzie mogła wczytać treść z Twojej pamięci. To może odszyfrowywać tylko gdy tego potrzebujemy? Ok, wtedy trzymamy w pamięci jedynie nasze główne hasło i zaszyfrowane przez prawie cały czas dane.

Osoba atakująca będzie mogła wtedy dość łatwo poznać hasło, którego możesz też przecież używać gdzieś indziej (tak, są tacy ludzie i jest ich dość dużo :) ). Popatrzmy na inny przykład: Linux Kernel posiada wbudowany system szyfrowania dysków – LUKS. Do odszyfrowania jednego dysku można przypisać kilka różnych haseł dla różnych osób. Dzięki temu można uniknąć przekazywania ich i zapisywania na karteczkach. Każdy może użyć wtedy swojego ulubionego hasła :) Jeśli natomiast je zgubi, można zmienić tylko to jedno hasło do dysku, bez zmiany innych haseł. Co więcej zmiana dowolnego hasła nie wymusza re-szyfrowania całego dysku. Jak to działa? Nie ma za tym jakiejś specjalnej magii i matematyki. Każdy z użytkowników, którzy mają swoje hasła tak na prawdę deszyfruje główny klucz do dysku. Dopiero za pomocą tego klucza jest przeprowadzane pełne (de)szyfrowanie.

Podobny mechanizm możesz też zastosować w Twoim pęku kluczy lub podobnej aplikacji. Za pomocą hasła użytkownik może odszyfrować tak na prawdę klucz symetryczny, który posłuży do odczytania pozostałej części danych. Przechowywanie go w pamięci, jeśli to konieczne, jest wtedy nieco bardziej bezpiecznym rozwiązaniem niż ciągłe przechowywanie hasła, lub co gorsze pełnego pęku kluczy.

Gdzie zapisać tymczasowe hasło?

Mimo wszystko Twoje hasło lub klucz deszyfrujący musi być tak czy tak chociaż na chwilę wczytane do pamięci. Jak zabezpieczyć się przed jego wyciekiem? Oprócz możliwości odczytania hasła bezpośrednio z pamięci jest jeszcze jedna możliwość. Atakujący może zaalokować tak dużo pamięci w systemie, że w końcu Twój DIY Keepass zostanie przeniesiony do swapu. A stąd już prosta droga do wyciągnięcia i przeanalizowania danych. Jeśli nie jako dump pamięci z poziomu roota, to śrubokrętem, przenosząc dysk do innego komputera lub bootując komputer z live cd.

Jak się przed tym obronić? Linux posiada trzy funkcje pozwalające Twojej aplikacji określić jak ma się zachowywać jej wirtualna pamięć. Pierwsza z nich to mprotect. Podając adres pamięci (np. blok zwrócony przez malloc) możesz sprawić, że dany obszar będzie dostępny tylko do odczytu, do zapisu lub w cale. Flaga PROT_WRITE jest zwykle stosowana do zabezpieczenia obszaru pamięci, w którym znajduje się Twój plik wykonywalny, aby przypadkowe (lub złośliwe) nadpisanie kodu instrukcji Twojej aplikacji nie było możliwe. PROT_EXEC jest natomiast stosowane do zabezpieczenia pamięci przed wykonywaniem jej kodu, np. w obszarach pamięci przechwujących zmienne. Zapobiega do przypadkowemu uruchomieniu takiego kodu. Wbrew pozorom bardzo użyteczną flagą może być PROT_NONE. Takiego obszaru nie da się ani odczytać, ani zmodyfikować ani wykonać. Jedną stronę takiej pamięci możemy ustawić np. za obszarem, do którego będą zapisywane dane od użytkownika, o nieznanym rozmiarze. Jeśli nasze programowe zabezpieczenia zawiodą i na przykład zaczniemy zapisywać do takiej tablicy bez opamiętania (bez if’a :) to finalnie program spróbuje zapisać coś na stronie pamięci oznaczonym PROT_NONE. W takiej sytuacji zadziała już sprzętowe zabezpieczenie i nasza aplikacja otrzyma stosowny, zwykle bolesny sygnał od systemu operacyjnego.

Drugą funkcją służącą do modyfikowania zachowania pamięci jest madvise. Podobnie jak mprotect przyjmuje ona adres i rozmiar obszaru pamięci, który chcemy zmodyfikować. Za jej pomocą możemy powiedzieć systemowi (doradzić) jak będziemy korzystać z tego obszaru. Czy na przykład będą to losowe odczyty i cache’owanie na wyrost nie ma sensu, czy też podczas forka procesu ten obszar pamięci ma pozostać nieskopiowany. Flag jest sporo, warto przeglądnąć je w przyjaznym manualu.

Ostatnia funkcja, warta wspomnienia to mlock. Ponownie, przyjmuje jako pierwsze parametry adres i rozmiar obszaru pamięci. Zapobiega ona przenoszeniu stron pamięci na swap. Oznaczając w ten sposób obszar gdzie trzymamy klucz deszyfrujący oraz sam keychain, możemy zabezpieczyć się przed wspomnianym wcześniej wymuszeniem zrzutu pamięci na swap.

Korzystając z wszystkich trzech powyższych funkcji możemy wymusić na systemie operacyjnym nieco lepsze potraktowanie naszych danych przesiadujących w pamięci. Za pomocą mprotect możemy przez większość czasu zapobiegać dostępowi do pamięci, ustawiając jej flagę PROT_NONE, i “odbezpieczając” tylko gdy użytkownik potrzebuje hasła. Za pomocą madvise mona zapobiec skopiowaniu tej pamięci przez fork (i prawdopodobnie zabezpieczyć się też na kilka innych okoliczności), a z mlock zapobiegniemy wyrzuceniu na swap.

Cstring vs. std::string

Przy okazji wychodzi czemu czasami zarządzanie pamięcią przez malloc i standardowe stringi z C są bardziej użyteczne. Korzystając z std::string nie mamy tak dokładnej kontroli nad tym, gdzie będą trzymane dane ze stringa, jak również nie mamy gwarancji że po dopisaniu kolejnych znaków nie zostanie on w całości przeniesiony w inne miejsce. Trudniejsze staje się też zabezpieczenie strony tuż za stringiem. Nie jest to jednak niemożliwe, jednak wymaga dodatkowej pracy i dogłębnej wiedzy jak jest alokowana w tym przypadku pamięć. Dodatkowo, gdy std::string zwalnia pamięć, musimy też ręcznie posprzątać po nim, aby inny obiekt nie dostał obszaru z PROT_NONE.

W przypadku c stringów, wszystkie operacje przenoszenia, zabezpieczania i odbezpieczania musimy zrobić tak czy tak ręcznie, jednak z punktu widzenia czytelności kodu i jego obsługi jest to znacznie czytelniejsze.

Swap też jest szyfrowany

Tak, od jakiegoś czasu dystrybucje wspierają to domyślnie. Strony pamięci zrzucane do swapu są w locie szyfrowane, także odczytanie ich po wyłaczeniu komputera nieco się komplikuje. Przykładowy wpis z Arch wiki:

swap /dev/sdX# /dev/urandom swap,cipher=aes-xts-plain64,size=256

Przy każdym starcie system generuje losowy klucz do zaszyfrowania swapu z /dev/urandom. Nawet jeśli coś się na swapie pojawi, to będą to tylko losowe znaki dla osoby, która nie zna klucza. Problem pojawia się jednak przy wsparciu dla disk suspend – uśpienia komputera i zrzucenia stanu pamięci na dysk. W tym przypadku sprawy się nieco komplikują, ale to historia na inny wpis.

Wirtualne maszyny

O ile wszystkie powyższe sposoby mają się całkiem dobrze na “gołym” PC, to już korzystając z wirtualizacji nie mamy gwarancji, że ktoś nie zrobi zrzutu pamięci oraz dysku w locie i nie będzie próbował analizować tego offline. W takim wypadku jedynym rozwiązaniem minimalizującym ryzyko przechwycenia cennych danych jest tylko chwilowe odszyfrowywanie ich. Nie gwarantuje to jednak pełnego bezpieczeństwa. Na własnych systemach można zapobiegać temu odpowiednimi opcjami dla wirtualnych maszyn, dzięki którym gospodarz nie będzie przenosił ich stron na swap. Służy do tego m.in. opcja locked w libvircie. Jednak w publicznych chmurach nie mamy takiej gwarancji.

Bezpieczeństwo różnych algorytmów

Na koniec warto wspomnieć o bezpieczeństwie samych algorytmów szyfrujących. Co, jeśli któryś okaże się podatny na ataki? Często aplikacje oferujące szyfrowanie pozwalają na złożenie kilku algorytmów na raz. O ile Twoje hasło pozostaje prawdopodobnie najsłabszym punktem, to szansa na skompromitowanie dwóch algorytmów szyfrujących na raz znacznie spada. Pomyśl, że lata temu używałeś MD5 do potwierdzania integralności plików. Algorytm się “zepsuł”. Wykonanie SHA1(MD5(…)) nieco ratuje sprawę. W ten sposób zabezpieczają się np. adresy portfeli z Ethereum. Skompromitowanie jednego algorytmu (co powodowałoby że łatwo wygenerować inny portfel z tym samym adresem) znacznie maleje.

Pobieranie czegokolwiek z youtuba w fullhd z konsoli

maciej — Mon, 11 Feb 2019 22:41:12 +0000

Niektórzy lubią filmy, inni muzykę, a jeszcze inni po prostu potrzebują zapisać na dysk filmiki z kotami. Powód wymyślcie sobie sami :)

Od niedawna wszelkiego rodzaju pobieraczki youtubowe przestały oferować jakość full HD z dźwiękiem. No cóż, trzeba sobie radzić inaczej. Za pomocą youtube-dl można pobrać osobno dowolną ścieżkę audio z youtube oraz dowolną ścieżkę video, o wybranym bitrate, codecu oraz rozdzielczości.

Co będzie potrzebne?

Potrzeba nam dwóch narzędzi. A w zasadzie trzech – pipem pobierzemy downloader:

sudo apt install ffmpeg python3-pip
sudo pip3 install youtube_dl

Pakiet pip będzie nam służył do pobrania właściwego narzędzia w pythonie – youtube-dl. Za jego pomocą można zobaczyć co dany film oferuje do pobrania – wszystkie wersje audio i video oraz umożliwia pobranie ich. Ffmpeg posłuży do połączenia osobnych ścieżek audio oraz video w jeden plik.

Pobranie audio i video

Po pierwsze wybierzmy jakieś interesujące video. Na przykład to: https://www.youtube.com/watch?v=G1IbRujko-A.

Za pomocą youtube-dl można wyświetlić listę dostępnych ścieżek audio i video:

~> youtube-dl -F 'https://www.youtube.com/watch?v=G1IbRujko-A'
[youtube] G1IbRujko-A: Downloading webpage
[youtube] G1IbRujko-A: Downloading video info webpage
[youtube] G1IbRujko-A: Downloading js player vflYv1bWD
[info] Available formats for G1IbRujko-A:
format code extension resolution note
249 webm audio only DASH audio 117k , opus @ 50k, 272.51MiB
250 webm audio only DASH audio 136k , opus @ 70k, 351.10MiB
140 m4a audio only DASH audio 162k , m4a_dash container, mp4a.40.2@128k, 545.84MiB
171 webm audio only DASH audio 191k , vorbis@128k, 577.59MiB
251 webm audio only DASH audio 207k , opus @160k, 667.00MiB
160 mp4 256x144 144p 170k , avc1.4d400c, 24fps, video only, 205.76MiB
133 mp4 426x240 240p 237k , avc1.4d4015, 24fps, video only, 543.85MiB
278 webm 256x144 144p 281k , webm container, vp9, 24fps, video only, 401.04MiB
242 webm 426x240 240p 302k , vp9, 24fps, video only, 467.08MiB
134 mp4 640x360 360p 338k , avc1.4d401e, 24fps, video only, 968.71MiB
243 webm 640x360 360p 528k , vp9, 24fps, video only, 1.41GiB
135 mp4 854x480 480p 690k , avc1.4d401e, 24fps, video only, 2.24GiB
244 webm 854x480 480p 739k , vp9, 24fps, video only, 2.37GiB
247 webm 1280x720 720p 1090k , vp9, 24fps, video only, 3.61GiB
136 mp4 1280x720 720p 1154k , avc1.4d401f, 24fps, video only, 4.41GiB
137 mp4 1920x1080 1080p 2373k , avc1.640028, 24fps, video only, 9.32GiB
248 webm 1920x1080 1080p 2647k , vp9, 24fps, video only, 5.18GiB
43 webm 640x360 medium , vp8.0, vorbis@128k, 3.06GiB
18 mp4 640x360 medium 485k , avc1.42001E, mp4a.40.2@ 96k (44100Hz), 2.04GiB
22 mp4 1280x720 hd720 1179k , avc1.64001F, mp4a.40.2@192k (44100Hz) (best

W tym przypadku można pobrać gotowy plik – ścieżkę 22. W niektórych filmach, np. w teledyskach nie ma połączonej wersji audio + video i jest możliwość pobrania tylko osobnego audio i osobnego video. Zróbmy więc tak:

youtube-dl --format 171 'https://www.youtube.com/watch?v=G1IbRujko-A'
youtube-dl --format 136 'https://www.youtube.com/watch?v=G1IbRujko-A'

Ścieżka o id formatu 171 to audio w kontenerze webm, z kodekiem vorbis i bitrate 191k (powyższa tabelka). Ścieżka 136 to video 1280x720 mp4. W bieżącym katalogu powinieneś widzieć dwa nowe pliki – jeden z rozszerzeniem webm, a drugi mp4. Po otworzeniu w dowolnym odtwarzaczu pierwszy z nich będzie grał, a drugi wyglądał.

Łączenie w całość

Na koniec pozostaje połączyć jedno i drugie w jeden plik MP4:

ffmpeg -i [plik].webm -i [plik].mp4 -acodec copy -vcodec copy plik-calosc.mp4

Powyższe polecenie przekopiuje ścieżkę audio (-acodec copy) oraz ścieżkę video (-vcodec copy) bez ponownej kompresji. Obie ścieżki zostaną zapisane w pliku plik-calosc.mp4. I to wszystko.

Fish – fajniejszy shell

maciej — Thu, 11 Oct 2018 21:22:02 +0000

Jeśli wzdryga Cię na myśl o pisaniu czegoś w konsoli, bo lubisz klikać lub chciałbyś usprawnić swoją pracę w bashu – spróbuj powłoki fish.

Jest to dość świeży projekt, dostępny w większości dystrybucji. Aby zainstalować ten interpreter wpisz (w Ubuntu):

apt install fish

Można też pobrać wersję dla Mac OS.

Co to daje?

Jeśli nie masz zwyczaju pisać pętli i funkcji w terminalu, to początki będą takie same jak w bashu. Po prostu możesz przejść do katalogu, czytać pliki, przekierowywać strumienie danych (tak, |, < i > działają tak samo) i ogólnie pracować jak dawniej.

Jednak po dłuższym czasie fish uczy się co i gdzie robiłeś. Ja na przykład często w ostatnim czasie pracuję nad biblioteką dinemic. Stąd też, gdy zaczynam pracę w katalogu domowym, po wpisaniu cd fish automatycznie podpowiada:

Po wciśnięciu strzałki w prawo automatycznie uzupełni się pełna ścieżka. Mała rzecz, a przydatna. Nieco większym ułatwieniem jest wyszukiwanie w historii. W Bashu trzeba było przebrnąć się przez kilkakrotne wciśnięcie Ctrl+R aby przeglądnąć kilka poleceń wstecz. W Fishu, jeśli wpisywałeś podobne polecenie wcześniej albo dostaniesz gotową podpowiedź jak powyżej, albo strzałką w górę będziesz mógł przeglądnąć poprzednie wywołania, włącznie z tymi, które zawierają dany ciąg znaków, który wpisałeś (poniżej checkout):

Przy okazji ładnie podświetlane jest samo polecenie, jego parametry i szukany string.

No dobra, co jeszcze możemy zrobić? Skoro już jesteśmy w wybranym katalogu, w gałęzi master, to zróbmy merge! Po wpisaniu git merge fish podpowiada tak jak poprzednio ostatnie polecenie:

Chcemy jednak zrobić merge innej gałęzi. Wciśnij raz tab. Fish wyświetli jakie masz dostępne gałęzie, które możesz zmergować do tej, na której aktualnie jesteś:

a jeśli chcesz coś więcej, to możesz wyświetlić też samą pomoc do gita, wciskając tab po poleceniu:

można w tym trybie przechodzić strzałkami pomiędzy poszczególnymi poleceniami i wybrać enterem to, którego szukasz:

Na pierwszy rzut oka może to się wydawać zbędnym bajerem (no bo przecież każdy szanujący się Linuksiarz zna wszystkie polecenia ;) ), ale czasami trafi się na to jedno, którego nie znamy i nie trzeba sięgać do manuala.

Podobna pomoc jest też do całej masy innych poleceń, m.in. find, grep, /bin/true i innych. Podobnie jak w cd możemy też je filtrować wpisując pierwsze litery.

Fajne ścieżki i uzupełnianie z historii

No ok, podpowiedziało w katalogu C++/libdinemic co ostatnio robiłem. Wpisując tam np. rm fish podpowie, że pewnie znowu chcę usunąć pliki *.o. Natomiast po wejściu do innego katalogu, C++/netdinemic fish pamięta, że tam za pomocą rm usuwałem ostatnio co innego – katalog /tmp/dinemic_keys. Mała rzecz, a wciskając strzałkę w prawo na klawiaturze można wykonać ostatnie akcje w kontekście danego katalogu, w którym jesteśmy.

Z innych rzeczy, warto spróbować podpowiadania (tab) np. w poleceniu ssh albo scp. Fish potrafi podpowiedzieć ostatnio używane hosty:

Podobnie jak w bashu, działa Ctrl + U (usunięcie linijki i zapisanie jej w schowku) i wklejenie ze schowka przez Ctrl + Y. Ctrl+W (kasowanie ostatniego słowa) działa tu na ścieżkach co / i na kreskach, a nie tylko na spacjach.

Czym się różni od basha?

Po za całym podpowiadaniem, nieco inaczej wyglądają funkcje i zmienne. Zamiast export trzeba używać set. Zamiast $0 mamy $status. Różnic jest dość dużo i chcąc używać czegoś bardziej zaawansowanego trzeba już przejść przez manuala.

Wykorzystanie systemd zamiast crona, initd i automatu do kawy

maciej — Sun, 14 Jan 2018 09:55:56 +0000

Kilka lat temu w większości Linuksów zagościł na dobre daemon systemd odpowiedzialny za obsługę startu, całego cyklu życia i wyłączenia systemu operacyjnego. Do czego ten kombajn może się przydać?

Sysvinit

Systemd zastąpił dość stary mechanizm zarządzania skryptami startowymi sysvinit, który po załadowaniu jądra był inicjowany przez program /sbin/init. Brał on kolejne serwisy z katalogów /etc/rc[runlevel].d/ i uruchamiał z odpowiednim parametrem. Nowsze lub bardziej rozbudowane dystrybucje potrafiły dodatkowo wprowadzić wymagane serwisy lub podsystemy, które były potrzebne do uruchomienia danego serwisu.

Systemd wprowadził natomiast format opisowych plików, które pełnią podobną funkcję, natomiast nie są skryptami samymi w sobie, tak jak sysvinit.

Prosy serwis

Popatrzmy na przykładowy serwis z CoreCluster, który startuje podsystem agentów:

[Unit]
Description=CoreCluster cloud
After=network.target
Requires=network.target

[Service]
Type=simple
ExecStartPre=-/usr/sbin/cc-manage configure
ExecStart=/usr/sbin/cc-manage agent start
ExecStop=/usr/sbin/cc-manage agent stop

[Install]
WantedBy=multi-user.target

Zawiera on sekcję Unit, która opisuje serwis i mówi daemonowi systemd, co jest wymagane do uruchomienia go. Na pierwszy rzut oka wpisy Requires i After mogą sprawiać wrażenie zduplikowanych, jednak oba mają pewne znaczenie. Ponieważ systemd działa przez cały czas, od startu systemu i monitoruje stan systemu, możemy określić, że do działania naszego serwisu wymagana jest sieć (parametr Requires). Oba parametry gwarantują, że po nasz serwis corecluster.service zostanie po niej uruchomiony. After=network.target określa kolejność i spowoduje, że serwis będzie mógł być uruchomiony dopiero po uruchomieniu sieci. Requires spowoduje, że serwis będzie musiał zostać wyłączony jak tylko wyłączy się jakikolwiek z wymaganych serwisów, czyli tutaj sieć.

Idźmy dalej. Sekcja Service opisuje co i jak uruchomić. Powyższy przykład pokazuje jak włączyć proces, który zatrzyma się dopiero podczas zatrzymania samego serwisu. Czyli polecenie zawarte w ExecStart zakończy się. To, jak ma się zachować uruchamiany proces określamy parametrem Type=simple z tej sekcji. Po uruchomieniu danego polecenia serwis będzie widoczny jako uruchomiony tak długo, jak proces będzie działał i ni zwróci żadnego kodu wyjścia.

Innym rozwiązaniem są procesy, które odrazu przechodzą do działania w tle lub kończą się (np działają trybie daemon). Zobaczmy na przykład serwisu zarządzającego nodami CoreCluster:

[Unit]
Description=CoreCluster cloud
After=network.target
Requires=network.target

[Service]
Type=oneshot
ExecStartPre=-/usr/sbin/cc-node configure
ExecStart=/usr/sbin/cc-node start
ExecStop=/usr/sbin/cc-node stop
RemainAfterExit=1

[Install]
WantedBy=multi-user.target

Zamiast Type=simple możemy wpisać Type=oneshot. Oznacza to, ze proces powinien zakończyć się, a systemd nie przyjmie tego jako błędu.

W każdym przypadku możemy uruchomić dodatkowe polecenia przed i po uruchomieniu właściwego serwisu. Można dzięki temu skonfigurować środowisko lub posprzątać.

Okresowe uruchamianie procesów

Od lat robione cronem. Nikt go nie wyrzuca, ale systemd daje większe możliwości :) Po pierwsze systemd wie więcej o stanie systemu (czy mamy sieć, środowisko graficzne itd). Po drugie systemd pozwala łatwiej kontrolować to, co się dzieje, jeśli jesteśmy rootem.

[Unit]
Description=Run foo weekly and on boot

[Timer]
OnBootSec=15min
OnUnitActiveSec=1w
Unit=serwis_do_uruchomienia.service 

[Install]
WantedBy=timers.target

Powyższy przykład uruchomi serwis serwis_do_uruchomienia (parametr Unit) 15 minut po starcie systemu i następnie co tydzień. Zamiast OnUnitActiveSec możemy też określić w sekcji Timer konkretne daty, podobnie jak w Cronie: OnCalendar=*-*-* 00:00:00. Taki wpis spowoduje wykonanie timera dokładnie o północy każdego dnia.

Instalacja serwisu i timera

Jeśli Twój serwis jest dostarczany przez pakiet instalacyjny deb lub rpm, to możesz zawrzeć opis Twojego serwisu w odpowiednim pliku podczas budowania paczki (patrz przykłady z CoreCluster). W przeciwnym wypadku możesz dodać serwisy jako odpowiednie pliki w katalogu /usr/lib/systemd/system/. Odpowiednio, pliki serwisów będą miały nazwy kończące się na .service, czyli np. serwis_do_uruchomienia.service, a pliki timerów .timer.

Aby nasz serwis lub timer zadziałał, musimy go włączyć poleceniem systemctl enable serwis_do_uruchomienia.service. Spowoduje to, że systemd załaduje ten plik. Jeżeli z jakiegoś powodu będziemy chcieli zmienić jego zawartość (np. zmienić czasy wykonywania timera), to należy później poinformować o tym fakcie demona systemd i przeładować zawartość pliku poleceniem systemctl daemon-reload. Nie musimy się przy tym martwić linkami symbolicznymi oraz kolejnością uruchamiania serwisów przez systemd, jak to miało miejsce w przypadku sysvinit. Po nieco dłuższym zaznajomieniu się z systemd i jego sposobem zarządzania procesami będziesz mógł bardzo dokładnie dopasować uruchamianie procesów w Twoim systemie. Np. uruchamiając je po podłączeniu konkretnego urządzenia: After=dev-sdb.device (ich listę znajdziesz po wpisaniu systemctl --all --full -t device).