Jak používat apt a pár postřehů ze správy Debianu

2.1.2021 13:07 | Přečteno: 4755× | Linux | | poslední úprava: 15.12.2022 17:14

Pár tipů ke správnému používání apt-get/aptitude a souvisejících utilit. A co se hodí občas udělat na systémech, které už zažily mnoho dist-upgradů a adminů, případně na dlouho provozovaném Debianu unstable.

Pravidelný update

Čistě pro úplnost na začátek, i když to asi zná každý:

• apt-get update obnoví seznamy balíčků z repozitářů
• apt-get upgrade nabídne upgrade nainstalovaných balíčků
• apt-get clean smaže soubory stažených balíčků a tím uvolní místo ve /var/cache/apt/archives. Kdybyste pak nějaký balíček chtěli reinstalovat, tak se bude muset znova stáhnout, ale jak často takovou věc děláte.

Hodí se zmínit:

• apt-get dist-upgrade také dělá upgrade nainstalovaných balíčků, ale nebojí se toho, když je kvůli tomu potřeba nainstalovat, nebo naopak odstranit, nějaký jiný balíček. Typický příklad je kernel. Ten se řeší tak, že si nainstalujete balíček např. linux-image-amd64, který je prázdný (viz dpkg -L linux-image-amd64), avšak závisí vždy na aktuálním linux-image-nějaké-číslo (viz apt-cache show linux-image-amd64, řádek Depends). Když vyjde nový kernel s nekompatibilním ABI, tak se změní tato závislost, a když uděláte apt-get dist-upgrade, tak se zjistí, že je nová verze linux-image-amd64, ale aby šla nainstalovat, je potřeba nainstalovat i tuto novou závislost. Smyslem celého tohoto cirkusu je, aby vám zůstal nainstalovaný i starší kernel, a tím jednak byly dostupné moduly i do rebootu (například ArchLinux tohle kdysi nedělal, a po upgrade kernelu tak až do rebootu nešlo zavést žádný modul), a jednak šlo v zavaděči vybrat starší kernel, pokud ten nový nefunguje.

  Že je potřeba udělat apt-get dist-upgrade a nestačí apt-get upgrade poznáte tak, že vám to vypíše „The following packages have been kept back“.

  Setkal jsem se s adminem, který o tomhle nevěděl, a měl proto na systému originální několik let starý kernel, i když ostatní věci updatoval.

• apt-get autoremove odstraní balíčky, které „byly nainstalovány automaticky“. Co to znamená? Představte si, že nainstalujete GIMP. Ten si jako závislost přitáhne libjpeg. Potom GIMP odinstalujete. Chcete pravděpodobně odstranit i libjpeg, protože proč mít v systému knihovnu, kterou už zase nikdo nepoužívá. A to právě dělá autoremove. Některé jiné programy pro správu balíčků, například aptitude, toto defaultně dělají automaticky, tj. když děláte jakoukoli operaci, tak rovnou nabídnou odinstalaci těchto balíčků.

  Opět příklad z praxe, setkal jsem se s uživatelem, který nainstaloval myslím balíček ubuntu-desktop, což je jednoduchý způsob, jak nainstalovat GNOME, Firefox, LibreOffice, Evince a tisíc dalších věcí, které si uživatel běžného grafického prostředí může ke své práci přát. Potom ale usoudil, že nějaký program, třeba LibreOffice, nechce, a odinstaloval ho, čímž se samozřejmě odinstaloval i ubuntu-desktop, protože tím nebyly splněny všechny jeho závislosti. Tím se ale staly všechny ostatní nainstalované balíčky automaticky instalovanými a nabídlo mu to tak odstranění i toho GNOME, Firefoxu a vůbec všeho. Tento uživatel potom šířil fámu „Ubuntu je nesmysl, nejde odinstalovat něco tak zbytného jako LibreOffice, aniž by se odinstaloval celý systém“. Přitom řešení je jednoduché - balíček se dá nastavit jako instalovaný ručně tak, že uděláte apt-get install balíček, resp. jak v diskuzi podotkli apt-mark manual balíček. Samozřejmě ho to nebude znovu instalovat, jenom to řekne „balíček byl nainstalovaný automaticky, teď jste požádali o instalaci, tedy ho označuji jako nainstalovaný ručně a už ho nebudu nabízet k odstranění“, což je přesně to, co chcete.

• Občas (poprvé jsem na to narazil u Busteru při přechodu z testingu na stable) je potřeba apt-get --allow-releaseinfo-change update (on si řekne, že se info změnilo a že to musíte explicitně povolit).

Když jsem ještě adminoval hromadu serverů, tak jsem měl skript, který se připojil na všechny mnou spravované servery, a spustil tam apt-get update && apt-get dist-upgrade && apt-get clean && apt-get autoremove. A pak ještě na fyzických serverech s RAIDem zkontroloval /proc/mdstat. Spouštěl jsem ho podle nálady, případně když se v mailinglistu debian-security objevil nějaký problém, který se mě týkal.

Navrhované a doporučované balíčky (recommends)

Další věc hodná zmínění je systém doporučovaných (recommends) a navrhovaných (suggests) balíčků. Používá se v případě, kdy máte velký program, který lze spustit s nějakou minimální funkcionalitou, ale hodí se k tomu doinstalovat něco navíc, aby se používal lépe. Například si opět představte GIMP. Teoreticky by mohl fungovat bez libjpeg (vymyšlený příklad, možná se bez toho nedokáže spustit) - spustíte ho, nakreslíte obrázek, v pořádku, libjpeg tedy striktně řečeno není potřeba kvůli GIMPu instalovat. Většina uživatelů ale opravdu bude chtít v GIMPu načítat a ukládat JPEG obrázky, a k tomu libjpeg bude potřeba. Právě jsem popsal vztah GIMP doporučuje libjpeg. O něco méně důležité programy, u GIMPu by to byla třeba podpora nějakých obskurnějších formátů, které využije jen někdo občas, se pak nastavují do suggests.

Defaultní nastavení je takové, že se instalují recommends a neinstalují se suggests. Toto automatické instalování lze vypnout pomocí apt-get --no-install-recommends install balíček. Pokud tedy instalujete nějaký program, a zdá se vám, že má příliš mnoho „závislostí“, zkuste tento parametr.

Opět příklad z praxe, potkal jsem uživatele, který si chtěl na Raspberry Pi nainstalovat VLC kvůli streamování webkamery. Zadal apt-get install vlc, což mu nabídlo instalaci gigabajtu balíků, a prohlásil doslova vlc je velka picovina. mi pride sialene ze musim instalovat vlc so 100 zavislostami ked chcem streamovat. Ve skutečnosti šlo ale jen o to, že to chtělo instalovat podporu pro všechny možné video formáty, což typický uživatel, který si instaluje VLC na desktop, přesně chce, zde to ale bylo zbytečné. Stačilo vypnout instalaci doporučovaných balíků. Mimochodem i pak to bylo zbytečně velké, neboť se instaluje grafické VLC, které na headless nepoužijete. Pokud nainstalujete balík vlc-bin, ve kterém je jenom commandlinové cvlc, tak to nainstaluje doslova tři závislosti místo původní stovky. Obdobně existuje například balík vim-nox, což je textový editor vim bez podpory grafického rozhraní - což přesně chcete instalovat na servery.

Nastavování těchto parametrů je z pohledu správce distribuce velmi nevděčná činnost, protože vám uživatelé nadávají, že jim nějaký program natáhl spoustu nepotřebného bordelu (úplně tragické to je když si na desktop, kde používáte převážně GTK programy, nainstalujete nějaký program z KDE, nebo naopak), a současně vám nadávají, že si něco nainstalovali, a není tam podpora pro formát/hardware/..., který zrovna chtějí použít.

localepurge

Když už jsme u zbavování se zbytečných věcí, existuje program localepurge, který se zeptá na používané jazyky (locales), a smaže manuálové stránky a překlady z ostatních jazyků. Tímhle se dá ušetřit třeba půl giga místa. Při instalaci se ptá, jestli má používat dpkg path-exclude. Doporučuji odpovědět ne, díky čemuž to vyčistí lokalizaci i již nainstalovaných balíčků. Později se to dá změnit direktivou USE_DPKG v /etc/locale.nopurge.

apt-get, apt, aptitude

Určitě se teď někdo chce zeptat, proč v předchozím textu všude používám apt-get, když existuje modernější apt. Důvod je jednoduchý, apt zobrazuje na posledním řádku terminálu progressbar, a mně to v terminálu rozbíjí scrolling -- když dělám nějakou větší operaci, tak samozřejmě prolítnu výpis a hledám v něm chyby.

aptitude mi přijde pomalejší a má chytřejší dependency solver -- který mi ale občas přijde až moc chytrý. aptitude zkouším jen v případech, kdy si jednoduchý solver v apt-get neumí poradit.

eatmydata

Další občas se objevující stížnost je, že instalace balíků je pomalá. To je naprostá pravda. apt-get a dpkg si dávají strašný pozor na konzistenci dat: v podstatě se snaží zaručit, že když v jakémkoli okamžiku během instalace vypadne elektřina, tak systém v pořádku najede a stav bude konzistentní. To bohužel znamená, že neustále dělají fsync, a to trvá. Když mi na téhle garanci nezáleží a radši bych, aby to proběhlo několikanásobně rychleji, používám program eatmydata.

~ # eatmydata bash -c 'echo $LD_PRELOAD'
libeatmydata.so

Když s ním spustíte nějaký program, tak pomocí LD_PRELOAD natáhne knihovnu, která nahradí sync a fsync funkcemi, které nic nedělají.

Vypsání balíčků ze špatné verze distribuce

Udělali jste povýšení na novou verzi Debianu, ale to vám nezaručuje, že stále nemáte nainstalované nějaké balíčky z předchozích verzí -- například protože v nové verzi už nejsou. Udělejte proto

aptitude search "?narrow(?installed,?not(?archive(stable)))"

což vám vypíše všechny balíčky, které máte nainstalované, a které nejsou v aktuálním stable. S tím už si musíte poradit ručně, většinu lze odstranit, u některých naleznete, že se třeba přejmenovaly a je potřeba nainstalovat náhradu (což se ale většinou stane automaticky díky tomu, že se takové přechody typicky dělají tak, že se z toho v jedné verzi udělá prázdný balíček, který závisí na své náhradě, a až v další verzi se ten prázdný balíček smaže). Typicky u postgresql je ale potřeba to ručně zmigrovat. Já administraci postgresql vůbec nerozumím, ale vždycky jsem dělal tohle a fungovalo to:

pg_lsclusters
pg_dropcluster --stop 9.4 main   # smažu prázdný nový, který se vytvořil při upgradu/instalaci nové verze
pg_lsclusters
pg_upgradecluster 9.1 main       # upgrade starého na poslední verzi
pg_dropcluster --stop 9.1 main   # smazání starého starého
pg_lsclusters

debsums

Nyní se pomalu dostáváme k situacím „přebírám systémy po předchozím adminovi“ a „zavolali mě k serveru, o kterém nikdo nic neví, nikdo se o něj nestaral, spadla kritická služba a je potřeba s tím něco udělat“.

debsums ověří kontrolní součty všech souborů trackovaných balíčkovacím systémem. Hodí se to občas spouštět, například tím zjistíte na svých Raspberry Pi, že jste už zase narazili na sérii vadných microSD karet. Nepovažujte to úplně za kontrolu, zda je v systému nainstalovaný backdoor, protože útočník s právy roota může samozřejmě program debsums znefunkčnit, ale na detekci neúmyslných chyb se to hodí. Používá se to s dvěma parametry:

• debsums -c zkontroluje nainstalované binárky. Kromě hardwarových závad tím můžete třeba zjistit, že někdo byl prase a nainstaloval ručně kompilovaný program přímo do /usr místo do /usr/local nebo /opt a přeplácl tím něco systémového.
• debsums -ce vypíše změněné konfigurační soubory. To se hodí pro rychlé získání přehledu, jaká konfigurace se vlastně používá a co je změněno oproti defaultu.

Kompletní audit všech souborů v systému

Trochu hardcore je projít všechny soubory v systému, které nepatří žádnému balíčku (soubory z balíčků jsme zkontrolovali pomocí debsums v předchozí kapitole). To jsem provedl takto:

locate \* | grep -vE "^/(home|tmp|mnt|boot|opt|root|srv|usr/local|var/cache|var/lib|var/log|var/tmp|var/mail|var/www)/" | sort -u > /tmp/allfiles
sort -u /var/lib/dpkg/info/*.list > /tmp/allfiles2
comm -23 /tmp/allfiles /tmp/allfiles2 |less

První příkaz vypíše všechny soubory na systému (vyžaduje mít nainstalován balíček mlocate a provést updatedb (to se jinak spouští denně z cronu), což stejně doporučuju) a z výpisu vyfiltruje očekávané adresáře, kde se soubory nepocházející z balíčků nacházejí přirozeně. Druhý příkaz vypíše naopak všechny soubory z balíčků. A třetí příkaz vypíše soubory, které se nacházejí pouze v první množině.

Výsledek vyžaduje trochu lidské péče a ručního posouzení, protože tam bude i spousta věcí, které jsou zcela oprávněné. Takže je to spíš o tom projít si to a udělat si přehled. Opět dva příklady ze života:

• Na virtualizačním serveru (KVM) docházelo občas k podivným chybám na filesystému uvnitř virtuálů. Následně se ukázalo, že ačkoli balík os-prober není nainstalovaný, z nějakého důvodu zůstaly nějaké jeho zbytky, které se spouštěly při update-grub. Tyto zbytky byly navíc z historické verze, která obsahovala drsné bugy a poškození filesystému způsobovala (mimochodem o tomhle se moc neví: když přimountujete ext4 (a možná i jiné FS) readonly, tak stejně dojde k přehrání žurnálu a výsledky přehrání se zapíšou na to zařízení!).
• Uvnitř KVM virtuálu jednou za čas zmizela většina modulů z /lib/modules, pochopitelně s důsledkem, že to pak už nenabootovalo (nenašlo to driver na filesystém nebo tak něco). Následně se ukázalo, že po migraci virtuálu z OpenVZ do KVM tam zůstal skript /etc/init.d/modules_dep.sh, jehož smyslem je… mazat moduly, které jsou uvnitř OpenVZ kontejnerů zbytečné.

Odinstalace balíčků, na kterých už nic nezávisí

Výše jsme si řekli, že balíčky, které byly nainstalovány jako závislosti nějakého programu, ale ten už na nich nezávisí (protože už není nainstalován, nebo vyšla nová verze, která už je nepotřebuje), by mělo identifikovat apt-get autoremove, případně se taky dají identifikovat pomocí deborphan. Z nějakého důvodu tohle nefunguje úplně vždycky. Další způsob, jak se vám v systému můžou hromadit nepotřebné knihovny, je, že jste něco kompilovali, a to vyžadovalo tyto závislosti, tak jste je nainstalovali, ale pak už jste je neodinstalovali. Chtěli bychom tedy ještě nějak jinak zjistit, jak najít balíčky, na kterých nic nezávisí.

K tomu se prý dají použít tři způsoby:

• apt-cache rdepends --installed
• aptitude why balíček
• apt-rdepends -r balíček

Mně bohužel ani jedno nějak moc nefungovalo, tak jsem přišel s vlastním řešením, kdy se každý balíček v systému prostě pokusíme odstranit, a pokud to s sebou vezme i nějaké jiné balíčky, tak to znamená, že na něm něco závisí. Odstranění pak abortneme.

for p in `dpkg -l | grep ^ii | cut -d " " -f 3 | grep -E "^lib"`; do
  echo "if [ \`apt-get -s purge $p | grep -E \"^(Purg|Inst|Conf)\" | wc -l\` -eq 1 ]; then echo $p; fi"
done | parallel

(parallel je GNU Parallel z balíčku parallel). Uvedené je vhodné spustit po první vlně odstraňování ještě jednou, protože tím, že jsme odstranili nějaké listové balíčky, se z některých jiných balíčků nově listové staly.

Aktualizace 2022: Tady je varianta, která vypisuje balíčky podle velikosti, od největšího - pokud chcete odstranit nepoužívané balíčky, možná to děláte kvůli místu, takhle stačí projít prvních několik a ušetříte nejvíc místa.

for p in `dpkg-query -W --showformat='${Installed-Size;10}\t${Package}\n' | sort -k1,1n| tac | tr -s " " | cut -f 2`; do
  if [ `apt-get -s purge $p | grep -E "^(Purg|Inst|Conf)" | wc -l` -eq 1 ]; then echo $p; fi
done

Nesouvisející s Debianem: rozumné chování syslogu a logrotate

Oprava jedné věci co mě vytáčí a jedné věci co rozbíjí zálohování:

• Zprávy v syslogu (/var/log/syslog, mail.log a dalších) mají datum ve formátu Jan 2 12:17:01 . No to je příšerné, takže si rychle udělejte soubor /etc/rsyslog.d/time.conf s tímto obsahem

  $template myTemplate,"%timestamp:::date-year%-%timestamp:::date-month%-%timestamp:::date-day% %timestamp:::date-hour%:%timestamp:::date-minute%:%timestamp:::date-second% %HOSTNAME% %syslogtag%%msg%\n"
  $ActionFileDefaultTemplate myTemplate
  

  Od teď bude čas v normálním formátu 2021-01-02 12:17:01.
• logrotate dělá soubory /var/log/syslog.1 až /var/log/syslog.10.gz (podle toho, jak dlouhou historii si nastavíte). Každou noc to všechny soubory popřejmenuje. Pokud ale používáte zálohování se snapshoty a historií po souborech, tak to znamená, že se tam pokaždé úplně všechny logy uloží znovu. Takže do /etc/logrotate.d/rsyslog přidejte dateext a od teď to bude generovat soubory /var/log/syslog-20210101.gz, které se už nadále nemění.

       

Komentáře

[Miriam (ta pravá)]

první!!!!

[Heron]

Pěkný článek.

pg_upgradecluster 9.1 main

K tomuto bych poznamenal jen tolik, že tato výchozí verze udělá pg_dumpall do sql souboru a ten se vám na disk musí vejít společně se starou i novou DB. Pokud se migruje "prázdná DB", tak to není nutné řešit, ale pro normální DB o velikostech desítky GB už je na to potřeba myslet (ale ty mají doufejme své správce).

Pokud přece jen narazíte na větší db, tak, pokud máte nějakou externí zálohu celého stroje (což byste měli mít ještě před samotnou administrací), tak lze použít metodu update na místě, pomocí parametrů --method=upgrade --link. To překonvertuje datové soubory na místě a je to velmi rychlé i na stovky GB (těch změn tam obvykle není mnoho). Debian na to má skripty, na jiných systémech si musíte poradit ručně.

[Josef Kufner]

Jaký je tedy na Debianu ten správný nástroj?

[Heron]

Pokud máš PG nainstalovaný debianní cestou, tak je správné používat debianní nástroje, tedy ten pg_upgradecluster. A předat mu případné parametry pro pg_upgrade. Takto upgraduju mnoho serverů napříč verzemi debianu a už taky mnoho verzí PG. Malé DB neřeším, tam nechám výchozí způsob, tedy dump, větší db si pohlídám zvlášť a většinou dělám metodou upgrade, link (tj pg_upgradecluster --method=upgrade --link 9.1 main). Případně u některých serverů proběhne čistá instalace a přenos DB přes pg_dump -h stary.stroj | psql -h novy.stroj. Každopádně, pokud je to Debian, používat jeho nástroje ( pg_createcluster, pg_dropcluster, pg_lsclusters, pg_upgradecluster). Lze mít navíc více instancí PG na jednom stroji i v různých verzích (většinou teda stará a nová), automaticky jim to přiřadí další číslo portu apod, ale v dnešní době snadno dostupné virtualizace tato výhoda asi padá.

[Josef Kufner]

Díky. U těch pár malých databází, co tu mám, jsem to zatím nemusel moc řešit, ale časem se to bude hodit.

[deda.jabko]

Pokud máš PG nainstalovaný debianní cestou, tak je správné používat debianní nástroje, tedy ten pg_upgradecluster. A předat mu případné parametry pro pg_upgrade. Takto upgraduju mnoho serverů napříč verzemi debianu a už taky mnoho verzí PG.

Na tomto jsem se uz spalil. Pokud jsou pouzity nejake rozsireni typu PostGIS, ktere taky potrebuji upgrade a ktere maji vazby na externi knihovny, je to cesta, jak si rozbit databazi.

Z toho duvodu se mi osvedcilo provozovat vedle sebe puvodni i novou databazi, kazdou na jinem portu a postupne prenaset data ze stare do nove pres pg_dump a pripadne udelat korekce, a nakonec prehodit porty.

[k3dAR]

btw:

apt autoremove

=>

apt --purge autoremove

[Jendа]

Vidíš, tak se možná stalo, že tam zbyl ten init skript na mazání modulů.

[ByCzech]

Na označení balíčku jako manuálně instalovaný místo automaticky, se používá nástroj apt-mark manual balíček...

[Gréta]

se jako určitě někdy brzy bude moct hodit ;D

btw je nějakej lepšejší způsob jak si de nainstalovaný balíčky seřadit podle toho kolik jakoby zabíraj místa hele bez použití aptitude?? :O :O

dpkg-query -Wf '${db:Status-Status} ${Installed-Size}\t${Package}\n' | sed -ne 's/^installed //p'|sort -n

[BiCzech]

A komu tím jako prospějete, co?

[Gréta]

druhý straně :D :D hele :D :D ;D ;D

[AsciiWolf]

apt-get a dpkg si dávají strašný pozor na konzistenci dat: v podstatě se snaží zaručit, že když v jakémkoli okamžiku během instalace vypadne elektřina, tak systém v pořádku najede a stav bude konzistentní.

Tohle mám na apt osobně dost rád. Již mnohokrát jsem opravoval systémy s yum/dnf, kde výpadek elektřiny či (častěji) zásek systému rozbil rpm db.

[Bherzet]

Naprosto luxusní blog!

[trekker.dk]

balíček se dá nastavit jako instalovaný ručně tak, že uděláte apt-get install balíček. Samozřejmě ho to nebude znovu instalovat, jenom to řekne „balíček byl nainstalovaný automaticky, teď jste požádali o instalaci, tedy ho označuji jako nainstalovaný ručně a už ho nebudu nabízet k odstranění“, což je přesně to, co chcete.

Nebo taky apt-mark manual ...

aptitude mi přijde pomalejší a má chytřejší dependency solver

Aptitude jsem ze serverů odinstaloval poté, co podruhé napáchal bordel, který se s apt neděl.

[k3dAR]

pridam par dalsich postrehu

# zobrazeni odkud, jake verze je/lze instalovat balicek
apt policy balicek

# zobrazeni v kterem nainstalovanem balicku se nachazi konkretni soubor (ci cesta/soubor)
dpkg -S bin/mc

# vypis souboru z daneho balicku
dpkg -L balicek

# seznam nainstalovanejch balicku
dpkg -l

# vyhledani v seznamu balicku (a jejich popisu) dostupnych z nastavenych repositaru
apt-cache search balicek_nebo_cast_popisu

apt-mark byl jiz zminen pro nastaveni stavu na "instalovan rucne", ale dalsi:

# nastaveni balicku stav instalovan auto
apt-mark auto balicek

# podrzeni balicku v aktualni verzi a ingrorovani pripadnych aktualizaci
apt-mark hold balicek

# zruseni podrzeni balicku v aktualni verzi
apt-mark unhold balicek

# zobrazeni balicku instalovanych jako auto, nebo jako manual, nebo jako hold
apt-mark showauto
apt-mark showmanual
apt-mark showhold

[zito]

Pěkný článek. Ad vim. Normálně mně na server tedy stačí balíček vim. Balíček vim-nox je tučnější varianta se zakompilovanou podporou ruby, tcl, pythonu. Já se přiznám, že většinu balíčkování na unstable (svůj desktop) dělám aptitude a mám tendenci pak řešit i upgrade serveru v aptitude. Asi to není úplně přímočaré, ale jak jsem zvyklý... Před upgradem označím všechno v sekci libs jako automaticaly installed - stisk M na sekci libs. Ono se vůbec vyplatí projít instalované balíčky a na všech co ta nejsou z mojí vůle dát automaticaly (A) - stiskem M. Pokud je to všechno pěkně označeno, tak upgradne navrhne snadno i aptitude. Snahou se pochopitelně nemít v serveru nic co tam být nemusí.

Na smazání balíčků, po kterých zbyly konfiguráky většinou stačí

aptitude purge ~c

Ale používám občas i apt update && apt upgrade a až potom třeba aptitude.

[Jakub Lucký]

Na odstraňování nepotřebných balíčků je ještě super deborphan