Dnes a zítra probíhá vývojářská konference Google I/O 2025. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).
V Bostonu probíhá konference Red Hat Summit 2025. Vybrané přednášky lze sledovat na YouTube. Dění lze sledovat na síti 𝕏 (#RHSummit).
Společnost Red Hat oficiálně oznámila vydání Red Hat Enterprise Linuxu 10. Vedle nových vlastností přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.
Tuto sobotu 24. května se koná historicky první komunitní den projektu Home Assistant. Zváni jsou všichni příznivci, nadšenci a uživatelé tohoto projektu. Pro účast je potřebná registrace. Odkazy na akce v Praze a v Bratislavě.
Troy Hunt představil Have I Been Pwned 2.0, tj. nový vylepšený web služby, kde si uživatelé mohou zkontrolovat, zda se jejich hesla a osobní údaje neobjevili v únicích dat a případně se nechat na další úniky upozorňovat.
Microsoft představil open source textový editor Edit bežící v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
V Seattlu a také online probíhá konference Microsoft Build 2025. Microsoft představuje své novinky. Windows Subsystem for Linux je nově open source. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Z příspěvku Turris Sentinel – co přinesl rok 2024 na blogu CZ.NIC: "Za poslední rok (únor 2024 – únor 2025) jsme zachytili 8,3 miliardy incidentů a to z 232 zemí a z jejich závislých území. Tyto útoky přišly od 6,2 milionu útočníků (respektive unikátních adres). SMTP minipot je stále nejlákavější pastí, zhruba 79 % útoků bylo směřováno na tento minipot, 16 % útoků směřovalo na minipot Telnet, 3 % útoků směřovaly na minipot HTTP a 2 % na minipot FTP. Dále jsme zaznamenali 3,2 milionu unikátních hesel a 318 tisíc unikátních loginů, které útočníci zkoušeli."
Byla vydána (Mastodon, 𝕏) nová verze 3.0.4 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Byla vydána nová stabilní verze 7.4 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 136. Přehled novinek i s náhledy v příspěvku na blogu.
Potřeboval jsem povýšit kubernetí cluster na novější verzi. Běžně se o něj nestarám, nemám na to time, řeší to jiní. Řekl jsem si, že to tedy vezmu z čisté louky, naladím patche na OS, na docker a pak povýším kubernetes. Koukám, že jeden node stále visí na verzi AlmaLinux 8.6, přitom ostatní jsou na 8.7. To bylo ještě předtím, než jsem nějaký upgrade začal. Říkám si WTF. Dívám se na ten node, dávám upgrade a dnf mi hlásí, že nemůže detekovat verzi OS. Začínám pátrat proč, což byla otázka chvilky. dnf neznal jediný nainstalovaný balíček, rpm vypisoval 0 nainstalovaných balíčků. Někdo smazal rpm db, nebo jí v rámci migrace nějakým divným omylem nezmigroval.
Nějaký srábotka by ten node zahodila a nahodila nový z template. Mě ovšem zajímalo, zda z toho existuje cesta ven. Zda lze v takové situaci OS zachránit, jak moc je to zdlouhavé, náročné atd. Inu, node jsem v rámci kubernetu odpojil a jal se po večerech hrát si, co a jak. K celému problému jsem přistupoval tak, že nemám nikde stejný node. Prostě simulace toho, že mám jeden server, který mi běží, a nemám nic na porovnání. Ono totiž, když bych to vzal jinak, tak stačí vylistovat seznam rpm z jednoho node a všechny balíky znovu nainstalovat.
Jak tedy řešit osamocený, unikátní server, který ztratí db s nainstalovanými balíky?
Všichni asi víme, že lze k souboru na filesystému dohledat náležitý balík. Je tedy třeba mít aktuální db se seznamem balíku z mirroru. Ověříme si tedy, jakou verzi OS máme, podle toho si naladíme seznam balíků. tj.:
cat /etc/almalinux-release AlmaLinux release 8.6 (Sky Tiger) # nainstalujeme příslušný release balíček rpm -ivh almalinux-release-8.6-2.el8.x86_64 # uděláme update dnf --releasever=8.6 update
Teď tedy máme lokální cache se seznamem balíků z repositářů a můžeme začít porovnávat. Budeme porovnávat jen soubory v "/etc" a "/usr". Je to plně dostatečné a nejsou tam zbytečné soubory navíc. Našel jsem tento tip:
# projdi soubor po souboru a zeptej se pomocí dnf, zda k tomu existuje nějaké balík find /usr /etc -type f -print0 | xargs -0 -P$(nproc) dnf --cacheonly whatprovides | sort -u > /tmp/packages.txt # výsledkem po dlouhé době je tento soubor: cat /tmp/packages.txt | wc -l 31242
Rovnou říkám, že takto pitomě neoptimalizovaně to na relativně malé instalaci trvá cca 30h, než se ten seznam balíků dohledá. Záleží hlavně na výkonu cpu a počtu jader.
Ve vygenerovaném souboru je spousta balastu:
"Filename :" "Repo :" "Matched from:" "Last metadata expiration check:" "Waiting for process with pid"takže ho odsud odebereme:
# odebrat řádky s hloupostma cat packages.txt | sed '/^Filename :/d' | sed '/^Repo :/d' | sed '/^Matched from:/d' | sed '/^Last metadata expiration check:/d' | sed '/^Waiting for process with pid/d' > packages2.txt # následně už máme mnohem menší soubor cat packages2.txt |wc -l 1461 # tento soubor má v sobě tento formát ... docker-ce-3:19.03.13-3.el8.x86_64 : The open-source application container engine docker-ce-3:19.03.14-3.el8.x86_64 : The open-source application container engine docker-ce-3:19.03.15-3.el8.x86_64 : The open-source application container engine docker-ce-3:20.10.0-3.el8.x86_64 : The open-source application container engine docker-ce-3:20.10.10-3.el8.x86_64 : The open-source application container engine ... docker-ce-cli-1:19.03.13-3.el8.x86_64 : The open-source application container engine docker-ce-cli-1:19.03.14-3.el8.x86_64 : The open-source application container engine docker-ce-cli-1:19.03.15-3.el8.x86_64 : The open-source application container engine docker-ce-cli-1:20.10.0-3.el8.x86_64 : The open-source application container engine docker-ce-cli-1:20.10.10-3.el8.x86_64 : The open-source application container engine ... containerd.io-1.3.7-3.1.el8.x86_64 : An industry-standard container runtime containerd.io-1.3.9-3.1.el8.x86_64 : An industry-standard container runtime containerd.io-1.4.10-3.1.el8.x86_64 : An industry-standard container runtime containerd.io-1.4.11-3.1.el8.x86_64 : An industry-standard container runtime containerd.io-1.4.12-3.1.el8.x86_64 : An industry-standard container runtime containerd.io-1.4.13-3.1.el8.x86_64 : An industry-standard container runtime ... systemd-239-68.el8.x86_64 : System and Service Manager systemd-libs-239-68.el8_7.1.i686 : systemd libraries systemd-libs-239-68.el8_7.1.x86_64 : systemd libraries systemd-libs-239-68.el8_7.2.i686 : systemd libraries systemd-libs-239-68.el8_7.2.x86_64 : systemd libraries ...
Musíme tedy z toho souboru vykostit spoustu duplicit a nejlépe i balíky, které mají v sobě verzi. Nejjednodušší je si obsah splitnout podle architektur:
# ověříme si počet řádků, zda nám něco nezmizí, takže nejdřív celkový a poté pro jednotlivé architektury cat packages2.txt |wc -l 1461 cat packages2.txt |grep ".noarch" |wc -l 148 cat packages2.txt |grep ".i686" |wc -l 246 cat packages2.txt |grep ".x86_64" |wc -l 1064 148 + 246 + 1067 = 1461 # pokud máme číslo nižší, tak si ověříme, co je ten zbytek: grep -v i686 packages2.txt | grep -v x86_64 |grep -v noarch # dáme si tedy split cat packages2.txt |grep ".noarch" > packages-noarch.txt cat packages2.txt |grep ".i686" > packages-i686.txt cat packages2.txt |grep ".x86_64" > packages-x86_64.txt # na další filtrování nám stáčí sort a awk. Sort chceme reverzní pořadí, abychom awkem mazali nejstarší balíčky a nechali případně univerzální bez definování verze sort -r packages-noarch.txt | awk -F' : ' '!seen[$2]++' >> packages-final.txt sort -r packages-i686.txt | awk -F' : ' '!seen[$2]++' >> packages-final.txt sort -r packages-x86_64.txt | awk -F' : ' '!seen[$2]++' >> packages-final.txt
Ověříme si, co máme:
# výsledný seznam si můžeme projít takto: sort packages-final.txt # počet řádků/balíčků je stále trochu vyšší: cat packages-final.txt |wc -l 822 # následně ho ještě okostíme od popisku, tj. aby tam nebylo "docker-ce-cli-1:19.03.13-3.el8.x86_64 : The open-source application container engine", ale jen název balíčku "docker-ce-cli-1:19.03.13-3.el8.x86_64" cat packages-final.txt | awk '{print $1}' > packages-final2.txt
Tak, máme seznam balíčků, které zřejmě potřebujeme. Jdeme je stáhnout:
mkdir /var/cache/dnf/temp cd /var/cache/dnf/temp dnf download $(</root/packages-final2.txt)
a teď je všechny nainstalujeme:
dnf install * Last metadata expiration check: 0:05:51 ago on Wed 01 Mar 2023 05:38:34 PM CET. Error: Problem 1: package docker-ce-rootless-extras-23.0.1-1.el8.x86_64 requires docker-ce, but none of the providers can be installed - conflicting requests - package docker-ce-3:19.03.13-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:19.03.14-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:19.03.15-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.0-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.1-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.10-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.11-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.12-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.13-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.14-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.15-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.16-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.17-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.18-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.19-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.2-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.20-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.21-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.22-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.23-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.3-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.4-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.5-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.6-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.7-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.8-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:20.10.9-3.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:23.0.0-1.el8.x86_64 is filtered out by exclude filtering - package docker-ce-3:23.0.1-1.el8.x86_64 is filtered out by exclude filtering Problem 2: package containerd.io-1.6.9-3.1.el8.x86_64 conflicts with runc provided by runc-1:1.1.4-1.module_el8.7.0+3407+95aa0ca9.x86_64 - conflicting requests Problem 3: package coreutils-8.30-13.el8.x86_64 conflicts with coreutils-single provided by coreutils-single-8.30-13.el8.x86_64 - conflicting requests Problem 4: package fwupd-1.7.8-1.el8.alma.x86_64 obsoletes dbxtool < 9 provided by dbxtool-8-5.el8_3.2.x86_64 - conflicting requests Problem 5: package docker-ce-cli-1:23.0.1-1.el8.x86_64 conflicts with docker provided by podman-docker-3:4.2.0-8.module_el8.7.0+3407+95aa0ca9.noarch - conflicting requests Problem 6: package libcurl-minimal-7.61.1-25.el8.x86_64 conflicts with libcurl(x86-64) provided by libcurl-7.61.1-25.el8.x86_64 - conflicting requests Problem 7: package syslog-ng-logrotate-3.23.1-3.el8.x86_64 conflicts with rsyslog provided by rsyslog-8.2102.0-10.el8.x86_64 - conflicting requests (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Na výpisu vidíme, kde je prolém. Generování seznamu balíčků na základě existence souboru je pěkná věc, ale spousta balíků může mít společné soubory. Tj. konfliktní balíky. V mém případě stačilo pořešit takto:
# konflikt syslogu dnf instal rsyslog rm syslog-ng-logrotate-3.23.1-3.el8.x86_64.rpm # podman nepoužíváme, jen docker rm podman-docker-4.2.0-8.module_el8.7.0+3407+95aa0ca9.noarch.rpm # curl minimal také ne, takže naladíme curl a stažený minimal mázneme dnf install libcurl rm libcurl-minimal-7.61.1-25.el8.x86_64.rpm # to samé coreutils dnf install coreutils rm coreutils-single-8.30-13.el8.x86_64.rpm # to samé fwupd dnf install fwupd rm fwupdate-11-3.el8.alma.1.x86_64.rp rm dbxtool-8-5.el8_3.2.x86_64.rpm # taktéž nepoužíváme, takže pryč rm runc-1.1.4-1.module_el8.7.0+3407+95aa0ca9.x86_64.rpm # příliš nová verze, pryč rm docker-ce-rootless-extras-23.0.1-1.el8.x86_64.rpm
Hahá, hotovo, jde to konečně naladit:
dnf install * Error Summary ------------- Disk Requirements: At least 1451MB more space needed on the /usr filesystem.
Nojo, on dnf neví, že přeinstalovává již nainstalované balíky, takže zbytečně chce alokovat další místo, které nepotřebuje. Dočasně si tedy vypneme kontrolu místa
nano /etc/yum.conf ... diskspacecheck=0
Tak snad už:
# a znovu (můžeme asi přidat i parametr --noscripts) dnf install * # následně update dnf update # volné místo skoro neubylo, balíčků trochu přibylo rpm -qa |wc -l 874
Porovnání počtu balíčků jiný node a tento opravený:
# jiný node rpm -qa |wc -l 655 # náš opravený rpm -qa |wc -l 874
Je to prosté, těch 200 navíc jsou totiž i686, tj. 32bit balíčky, protože mají stejné konfigurační soubory v "/etc" a další věci. Co s tím? Jo, to nevím :). Na osamocenmém OS můžete naslepo odinstalovávat 32bit balíčky, o kterých si myslíte, že je nepotřebujete. Já už jsem tuto třešničku nechtěl řešit, takže jsem si nakonec vyjel porovnání s jiným node.
# zjištění, které balíky přebývají v opraveném OS grep -v -f rpm-list-node-ok.txt rpm-list-node-opraveny.txt > packages.txt # odinstalace se zachováním 64bit verze dnf remove $(<packages.txt) -x '*.x86_64' # vyřešení problému s protected package rpm -e systemd.i686 # nebo asi i takto: dnf --disableplugin=protected_packages erase systemd.i686 # porovnání, co chybí na opraveném node grep -v -f rpm-list-node-opraveny.txt rpm-list-node-ok.txt > packages1.txt ...
Při přeinstalování by možná bylo dobré vypnout scripty, jelikož jsou již provedeny, takže:
rpm -ivh --noscripts --notriggers *
Taktéž se teoreticky nemusí balíky přeinstalovávat, stačí je jen zaindexovat:
rpm -ivh --noscripts --notriggers --justdb *rpm
Problém s indexací je ale ten, že si nejste jisti, jakou verzi balíku máte reálně nainstalovanou. Takže doporučuji přeinstalovat.
Po přeinstalaci je pak dobré udělat update na aktuální verze baklíčků:
dnf update
Výše uvedený postup není jediný, který lze aplikovat. Vše záleží, co vám zbylo, co máte k dispozici. Další možný postup je popsán např. v KB RedHatu:
How to recover rpm database using /var/log/rpmpkgs?
Takže ano, opravit to jde, počítejte, že to může být na delší dobu a nebude to hned a budete mít nejspíše pár 32bit balíčků navíc, oproti původnímu plánu. Akce to byla zábavná a rád jsem si s tím pohrál :D.
Ještě dodám, že příkazy ohledně parsování, generování apod. píši čitelně. Některé mám rozdělené schválně do více kroků, aby to bylo i přehledné a jasné, co se v kterém kroku děje. Tím chci říci, že připomínky, že používám zbytečně "cat", zbytečně volám 4x sed, místo abych ho volal jednou s více podmínkami apod., jsou zbytečné.
Jistě přijde v diskusi i řeč na to, jak se taková věc může stát z procesního hlediska. Tj. jak je možné, že to někdo podělá, že ty nody někdo aktualizuje a nevšimne si, že to na jednom neprobíhá atd. Vzhledem k tomu, že se to stalo, tak je zřejmé, že na to nemohu mít uspokojivou odpověď. Každopádně snažíme se psát playbooky v ansible, všechno postupně automatizovat a postupně víc logovat a testovat, aby se podobné věci odhalily hned, resp. se nestaly.
Zdar Max
Tiskni
Sdílej: