V linuxových systémech byly odhaleny dvě závažné zranitelnosti – CVE-2025-6018 v rámci PAM (Pluggable Authentication Modules) a CVE-2025-6019 v knihovně libblockdev, kterou lze zneužít prostřednictvím služby udisks. Ta je součástí většiny běžně používaných distribucí, jako jsou Ubuntu, Debian nebo Fedora. Kombinací obou zranitelností může útočník s minimálním úsilím získat root přístup. Vzhledem k jednoduchosti zneužití
… více »OpenSSL Corporation zve na den otevřených dveří ve středu 20. srpna v Brně a konferenci OpenSSL od 7. do 9. října v Praze.
Něco z IT bulváru: Mark Russinovich pozval Billa Gatese, Linuse Torvaldse a Davida Cutlera na večeři a zveřejnil společné selfie. Linus se s Billem ani s Davidem do té doby nikdy osobně nesetkal. Linus a David měli na sobě červená polotrika. Mark a Bill byli v tmavém [LinkedIn].
Evropská unie nově prověřuje obchod, při němž americký miliardář Elon Musk prodal svou sociální síť X dříve známou jako Twitter vlastnímu start-upu xAI za 33 miliard dolarů (712 miliard Kč). Unijní regulační úřady zvažují, zda firmě X neudělit pokutu podle nařízení Evropské unie o digitálních službách (DSA).
Vývojáři postmarketOS vydali verzi 25.06 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Svobodný kancelářský balík ONLYOFFICE (Wikipedie) byl vydán ve verzi 9.0. Jak online Docs, tak i offline Desktop Editors. Přehled novinek také na YouTube.
Byla vydána nová verze 5.2.0 programu na úpravu digitálních fotografií darktable (Wikipedie).
XLibre Xserver je fork X.Org Serveru. Enrico Weigelt včera oznámil vydání verze 25.0 se slovy "tento fork je nezbytným, protože je výslovným přáním většiny současné skupiny X.Org (IBM / Red Hat) opustit projekt, nechat ho navždy shnít a blokovat jakékoli podstatné příspěvky, natož nové funkce".
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Experti na kybernetickou bezpečnost potvrdili (en) největší dosud zaznamenaný únik dat. Hackeři při něm odkryli skoro 16 miliard přihlašovacích údajů z celého světa včetně účtů společností Google, Apple, Facebook, dalších sociálních sítí nebo některých serverů státní správy.
/var/log
Ty máš křišťálovou kouli, že víš co mu zabírá nejvíc místa? Každopádně truncate nic nemaže. Je to použitelné řešení v situaci, kdy máš zaprásknutý disk až do mrtě.
ls =l
? Ak tie rôzne čísla porovnáš, tak sa dostaneme ku sparse súborom, a na čo som narážal pri reakcii "nejvíce zbytnělý log ve /var/log". Medzi také súbory ktoré sa začiatočníkovi javia ako moc veľké patria vo /var/log aj [last,fail]log.
Ale s tým truncate, tak mi prezraď ako uvoľní miesto na disku ak sú inody skracovaného súboru obsadené bežiacim procesom. Skús to vysvetliť tvojím začiatočníckym spôsobom.
Toľko ku tým tvojím žvástom akými sa chváli lamička ktorú na MDD nikto nechce.
/var/log
má smysl jen když něco řešíš. U lamy tedy většinou žádný. Truncate používám jen v případě, že potřebuji uvolnit alespoň tolik místa, aby zafungoval journalctl. Zkrátím velikost na 0 bajtů, ty stávající data se zahodí a ten proces začne zapisovat nová. Si to vyzkoušej mameluku.
Ohľadne tej infraštruktúry ktorú akože spravuješ, tak by som poprosil sieťový rozsah. Rád si ho preventívne zablokujem.
Beze všeho: 192.168.x.y – za x a y si dosaď libovolné číslo od 0 do 255
Mimochodem, ten tvůj /var/log/wtmp
obsahuje data, která jsou úplně k hovnu. Viz /var/log/wtmp
Je to jen zbytečný bordel zabírající místo, který se při restartu může s klidnou duší zahodit, protože (u mne) jsou klíčové informace uložené jinde, ve výrazně srozumitelnější formě. Soubor, ve kterém jsou veškeré informace za posledních 334 dní má všeho všudy 65MB
A největší log /var/log/lastlog
má u mne trapných 100MB
Je rok 2025. Na co systmd-journald
poštve nějaké zkracování, to je věcí jeho konfigurace. A ne, podstatná část diskového prostoru se opravdu (ale opravdu (ale opravdu)) neuvolní zkrácením (binárních, komprimovaných) logů.
Budeš se divit, ale jo. Speciálně u zaplácnutého Btrfs. A příkaz journalctl --vacuum-time=1d
sem tam také použiju.
Nevím, no. Když mám podezření, že je něco špatně, podívám se na journalctl -f
. Pokud se něco objevuje častěji než jednou za (se)kundu, obvykle je potřeba řešit příčinu toho problému, ne až následek. Dokonce mám na některých stojích alert odvozený od „produktivity“ journalctl -f
.
Přečti si prosím ještě jednou, od samého počátku tuhle diskuzi prosím.
Pořádné sračky. Až to bolí číst. Hlavně tedy ten truncate
.
Mysli si o tom co chceš, pro mne je důležité, že to funguje0.
(0) Před 15+ lety by to možná fungovalo [pozn. red.].
Pohled do kalendáře mě utvrzuje v jistotě, že nezáleží na tom, co si kdo myslí. Věci v té strohé realitě prostě už nějak jsou.
zkrácením (binárních, komprimovaných) logůMožná mám journald špatně nastavený, ale zabírá mi mnohem víc prostoru, než ekvivalentní textová reprezentace. Konkrétní experimenty:
journalctl | wc -c
ukáže 1325903166
(1.3 giga), ale /var/log/journal
má 4.3 GB. Člověk by čekal, že tam ještě budou efektivně uložené timestampy a další metadata.
Textový /var/log/syslog
, do kterého podle mě přeposílám veškeré zprávy co jsou v journalu, má od neděle 327 MB. journalctl --since "6 days ago"| wc -c
ukáže 267377143 (267 mega), čili řádově by to odpovídalo. Následně jsem spustil journalctl --vacuum-time=6d
a /var/log/journal
se zmenšilo na 782 MB, stále je tedy 2-3x větší než hloupý textový syslog.
Obsah adresáře /var/log/journal
jsem zkopíroval a zkusil zkomprimovat defaultním gzipem. Zmenšil se na 175 MB (4.5x). To znamená, že původní data vůbec nejsou komprimována, naopak.
Též jsem gzipem zkomprimoval textový /var/log/syslog
. Ten se zkomprimoval na 22.5 MB (skoro 8x lépe než komprimovaný binární journal). Tedy ani například transparentně komprimující souborový systém by s journalem tolik nepomohl.
Naposledy jako zpětná kontrola: teď když jsem udělal vacuum za 6 dní, tak mám
journalctl | wc -c
: 245 megajournalctl | gzip | wc -c
: 12.5 megadu -sh --si /var/log/journal/
: 782 megadf -h
, protože může být nějak hloupě rozdělený. Dál lze pátrat po velikosti jednotlivých adresářů příkazem du
viz příklady třeba zde.
Vlákno bylo přesunuto do samostatné diskuse.
sudo bash
cd /
du -sh * |sort -h
zoradi podla velkosti
Tiskni
Sdílej: