Chcemy usunąć snapshoty, które w nazwie mają „test” z sierpnia 2024
Listujemy, które snapshoty zostaną usunięte:
# zfs list -t snapshot -H -o name | grep "test.*2024-08" | xargs -n1 echoUsuwamy
# zfs list -t snapshot -H -o name | grep "test.*2024-08" | xargs -n1 zfs destroyGdy nasza domena nie jest używana do rozsyłania poczty, możemy dodać do dnsu wpisy, które będa utrudniać przyjmowanie poczty z naszej domeny przez inne serwery.
SPF – nie zgadzamy się na wysyłanie poczty z żadnego adresu IP
nasza.domena.pl TXT v=spf1 -allDMARC – Informujemy odbiorcze serwery poczty, aby w przypadku nie zgodności polityk DMARC odrzucały maile
_dmarc.nasza.domena.pl TXT v=DMARC1;p=reject;Wygasłe certyfikaty powinny się odnowić przy ponownym uruchomieniu k3s:
# systemctl restart k3sJeżeli certyfikaty się nie odnowią i widzimy komunikat:
# kubectl get nodes
Unable to connect to the server: x509: certificate has expired or is not yet validMożemy wymusić wygenerowanie nowych.
Zabezpieczamy katalog z dotychczasowymi sekretami TLS
# tar -czvf /var/lib/rancher/k3s/server/apphost-cert.tar.gz /var/lib/rancher/k3s/server/tlsUsuwamy plik
# rm /var/lib/rancher/k3s/server/tls/dynamic-cert.jsonUsuwamy zbuforowany certyfikat z sekretów kubernetes
# kubectl --insecure-skip-tls-verify=true delete secret -n kube-system k3s-servingUruchamiamy ponownie usługę K3s, aby odnowić certyfikaty
# systemctl restart k3sUsługa GoogleUpdater często zmiania swoją nazwę a Zabbix nas o tym informuje. Zmienimy ustawienia Zabbixa aby nie monitorował tej usługi.
Możemy stworzyć configmapę na podstawie dowolnego pliku. W naszym przypadku bedzie to plik appsettings.json.
$ kubectl create configmap ares-api-config --from-file=Configuration/appsettings.json -n testTa metoda nie pozwoli nam zaktualizować configmapy bez jej usunięcia z klastra. Aby rozwiązać ten problem możemy najpierw utworzyć na podstawie naszego pliku appsettings.json plik yaml, następnie go zaaplikować. Gdy będziemy chcieli zmienić obiekt configmap w klastrze to powtarzamy ten proces.
$ kubectl create configmap ares-api-config --from-file=Configuration/appsettings.json -n test --dry-run=client -o yaml > configmap.yaml
$ kubectl apply -f configmap.yaml -n testGdy potrzebujemy przetestować przebieg połączenie ssl z serwerem http, poczty lub innym wykorzystującym protokół ssl/tls, możemy spróbować połączyć się z serwerem używając openssl w trybie klienta.
# openssl s_client -connect google.com:443
CONNECTED(00000003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services, CN = WR2
verify return:1
depth=0 CN = *.google.com
verify return:1
---
Certificate chain
0 s:CN = *.google.com
i:C = US, O = Google Trust Services, CN = WR2
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
v:NotBefore: Jun 3 06:35:38 2024 GMT; NotAfter: Aug 26 06:35:37 2024 GMT
1 s:C = US, O = Google Trust Services, CN = WR2
i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Dec 13 09:00:00 2023 GMT; NotAfter: Feb 20 14:00:00 2029 GMT
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
v:NotBefore: Jun 19 00:00:42 2020 GMT; NotAfter: Jan 28 00:00:42 2028 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIOTTCCDTWgAwIBAgIQag+0Dl9hY5UKDMPiKzcGqDANBgkqhkiG9w0BAQsFADA7
MQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMQww
. . . . .W wyniku polecenia zobaczymy cały przebieg połączenia który może ułątwić nam identyfikację problemów z certyfikatami
Gdy chemy sprawdzić start tls smtp do do polecenia dodajemy parametr -starttls smtp lub -starttls ftp
Gdy moniturujemy porty w switch Cisco korzystając z templates „Cisco IOS SNMP” i w pewnym momencie świadomie wyłączamy kabel sieciowy np z portu 1 i nie będziemy chwilowo korzystać z tego portu to Tiger pokazuje nam cały czas błąd „Port down” zaciemniając listę innych problemów
Aby ten alarm się nie pokazywał dodajemy makro do konfiguracji monitorowanego switcha: {$IFCONTROL:"Ethernet1/0/1"} = 0
Macro to wymusi skasowanie błędu.
Gdy alert zostanie usunięty z listy problemów to usuwamy to macro z konfiguracji i w przyszłości gdy ponownie będziemy używać tego portu to Zabbix będzie nas informował o problemach.
Jeżeli zainstalowaliśmy wersję Windows Svr Std Eval 2022 w celach testowych możemy przekonwertować ją do Windows Svr Std 2022. Unikniemy w ten sposób ponownej instalacji Windows Serwera
Wszystkie polecenia uruchamiamy w PowerShell z uprawnieniami admina.
Sprawdzamy wersję którą posiadamy:
DISM /online /Get-CurrentEditionSprawdzamy do jakich wersji możemy przekonwerować:
DISM /online /Get-TargetEditionsKonwerujemy:
DISM /online /Set-Edition:<target edition> /ProductKey:<product key> /AcceptEulaPo konwersji system poprosi o restart.
Najpierw aktualizujemy nody Master następnie workery. Aktualizujemy do najnowszej wersji pomocniczej (minor) następnie do najnowszej następnej wersji minor
1.27.7 -> 1.27.11 -> 1.28.11 -> 1.29.5
Dostępne wersje możemy sprawdzić na stronie https://github.com/rancher/rke2/releases
Na podstawie https://docs.rke2.io/upgrade/automated_upgrade
Instalacja system-upgrade-controller. (Sprawdzić czy nie ma nowej wersji) https://github.com/rancher/system-upgrade-controller/releases
W url podmieniamy xxxxxxx na aktualny numer wersji np” v0.13.4
# kubectl apply -f https://github.com/rancher/system-upgrade-controller/releases/download/xxxxxxx/system-upgrade-controller.yamlPrzygotować plan aktualizacji osobno dla nodów master i worker
# cd /opt/kubernetes/auto-upgarde
# nano upgrade_plan.yaml
# Server plan
apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
name: server-plan
namespace: system-upgrade
labels:
rke2-upgrade: server
spec:
concurrency: 1
nodeSelector:
matchExpressions:
- {key: rke2-upgrade, operator: Exists}
- {key: rke2-upgrade, operator: NotIn, values: ["disabled", "false"]}
# When using k8s version 1.19 or older, swap control-plane with master
- {key: node-role.kubernetes.io/control-plane, operator: In, values: ["true"]}
tolerations:
- key: "CriticalAddonsOnly"
operator: "Equal"
value: "true"
effect: "NoExecute"
serviceAccountName: system-upgrade
cordon: true
# drain:
# force: true
upgrade:
image: rancher/rke2-upgrade
version: v1.27.7-rke2r2
---
# Agent plan
apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
name: agent-plan
namespace: system-upgrade
labels:
rke2-upgrade: agent
spec:
concurrency: 1
nodeSelector:
matchExpressions:
- {key: rke2-upgrade, operator: Exists}
- {key: rke2-upgrade, operator: NotIn, values: ["disabled", "false"]}
# When using k8s version 1.19 or older, swap control-plane with master
- {key: node-role.kubernetes.io/control-plane, operator: NotIn, values: ["true"]}
prepare:
args:
- prepare
- server-plan
image: rancher/rke2-upgrade
serviceAccountName: system-upgrade
cordon: true
drain:
force: true
upgrade:
image: rancher/rke2-upgrade
version: v1.27.7-rke2r2Dodajemy etykiety do wszystkich nodów
# kubectl label node --all rke2-upgrade=trueSprawdzamy aktualną wersję
# kubectl get nodesZmieniamy w upgrade_plan.yaml version pilnując ścieżki upgrade i aplikujemy nowy plan
# kubectl apply -f upgrade_plan.yamlZaraz po aplikacji nowego plany rozpocznie sie upgrade klastra
Możemy sprawdzić działanie
# kubectl -n system-upgrade get plans -o yaml
# kubectl -n system-upgrade get jobs -o yaml
# kubectl get nodesMialem przypadek, że jeden z nodów nie chał się zaktualizować automatycznie. Aby rozwiązać problem skasowałem plan i wykonałem aktualizacje ręczną tego noda.
# kubectl delete -f upgrade_plan.yamlZdarzyło mi się, że po aktualizacji ręcznej system nadal cały czas próbuje go zaktualizować blokując noda. Aby usunąć problem odczytałem z innego noda label „plan.upgrade.cattle.io/agent-plan” i nadpisałem label w problematycznym nodzie.
# kubectl get node NODE-NAME-OK -o yaml
...
metadata:
labels:
plan.upgrade.cattle.io/agent-plan: xxxxxxxx
...
# kubectl label node NODE-NAME-PROBLEM plan.upgrade.cattle.io/server-plan=xxxxxxxx --overwrite
lub w przypadku workera
# kubectl label node NODE-NAME-PROBLEM plan.upgrade.cattle.io/agent-plan=xxxxxxxx --overwrite
# kubectl uncordon k8s-worker02
Na każdym nodzie MASTER uruchamiamy
# kubectl cordon NODE-NAME - zapobiega uruchomieniu nowych podów
# kubectl drain --ignore-daemonsets NODE-NAME - migruje pody zwalniając noda
# curl -sfL https://get.rke2.io/ | INSTALL_RKE2_VERSION=v1.27.12+rke2r1 sh -
# systemctl restart rke2-server
# kubectl uncordon NODE-NAMENa każdym workerze
# kubectl cordon NODE-NAME
# kubectl drain --ignore-daemonsets NODE-NAME
# curl -sfL https://get.rke2.io/ | INSTALL_RKE2_TYPE="agent" INSTALL_RKE2_VERSION=v1.27.12+rke2r1 sh -
# systemctl restart rke2-agent
# kubectl uncordon NODE-NAMESprawdzenie domyślnej polityki haseł
# samba-tool domain passwordsettings showUstawienie domyślnej polityki haseł
# samba-tool domain passwordsettings set --complexity=on --store-plaintext=off --history-length=12 --min-pwd-length=8 --min-pwd-age=0 --max-pwd-age=30 --account-lockout-duration=30 --account-lockout-threshold=10 --reset-account-lockout-after=15Lista użytkowników
# samba-tool user listInformacje o użytkowniku
# samba-tool user show <username>