Kez by. Posledni issue mam s nmbd daemonem, spusten z commandline s debug funkcni, pres systemd "visi" a neresolvuje. Po spusteni z commandline bez debug taky funkcni.
Pres systemd zacal fungovat az na desaty restart, ale proc jsem se ze zadneho logu niky nedozvedel. Jediny rozdil, ze systemd ma bohuzel primo pro winbind nejakou extra konfiguraci.
Obdobne obcas problemy s docker, rsyslog a dalsimi sluzbami, do nichz to "strka rypak".
Takova zverstva se mi treba na Solaris s jejich startup systemem nedeji, a ani s init je pochopitelne nepamatuji.
Jiste, vubec neprakvapi ze blb jako Sten, kterej vo tom vi lautr hovno vubec netusi, ze zcela libovolnej logdemon prebira ty logy od ty systemd sracky a kdyz nefunguje ta, tak nezaloguje NIC. Narozdil od systemu z LIBOVOLNYM jinym initem, kde se loguje zcela standardne a nezavisle na dalsich vecech.
Nechci vám vstupovat do vaší vytříbené mluvy, ale co přesně znamená, že loguje zcela standardně? Loguje přes Syslog protokol, na standardní výstup, do souboru, do souboru a řeší si sám rotaci?
A proc by log daemon mel resit rotaci?
Opravdu je váš komentář reakcí na zmínku, že aplikace může logovat do souboru a sama řešit rotaci logovacích souborů (jako alternativa k případu, kdy aplikace loguje do souboru a zapisuje do něj tak dlouho, dokud někdo tu aplikaci nevypne a soubor nepřejmenuje, nebo dokud nedojde místo na disku)?
A kdo tady mluvi o aplikaci? Rec je o logovacim daemonu a ten nema co rotovat, na to je tu logrotate. Nechapu, o cem mluvite.
Reagoval jsem na následující Jéčkovo větu:
Narozdil od systemu z LIBOVOLNYM jinym initem, kde se loguje zcela standardne a nezavisle na dalsich vecech.
Ptal jsem se tedy na to, co je ono „standardní logování“. Logovací daemon přijímá logovací zprávy a nějak s nimi nakládá, tady se ale bavíme o produkci těch logovacích zpráv, což dělá ta která konkrétní aplikace.
Tak kvotujte. Snad jste si uz vsiml, jak uzasne prehledne tu funguji diskuse po par urovnich.
Ten můj komentář je i teď přímo pod komentářem Jéčka, píšu tam ironicky o vytříbené mluvě a z Jéčkova komentáře tam cituji (pravda, bez uvozovek) spojení „loguje zcela standardně“. Ta diskuse plynule přecházející v chat mi zde také vadí, ale tohle na to opravdu nesvedete.
V tom pripade totalne nechapu, proc v komentari na jecko kvotujete kus meho vyroku.
Radši už se v tom nešťourejte, evidentně jste se v těch komentářích ztratil. Bavíme se o tomto mém prvním komentáři. Nejprve jste tomuto komentáři vytknul, že v něm „nekvotuju“, teď si zase u toho samého komentáře stěžujete, že v tom komentáři „kvotuju“ kus vašeho výroku.
Tímto prohlašuji, že v mém komentáři „nekvotuju“ kus vašeho výroku ani žádného jiného, pouze jsem v něm bez uvozovek citoval část Jéčkova komentáře, na který jsem reagoval, a který je zobrazen stále těsně před mým komentářem.
>> Rec je o logovacim daemonu a ten nema co rotovat, na to je tu logrotate.
A důvod, proč by to tak mělo být / zůstat?
Jen pro upřesnění, logrotate tu nebylo v době unixů / kořenů sysvinit. Je to obezlička, která byla doprogramovaná na usnadnění správy logů. Kdyby všechny programy logovaly přes syslogd, bylo by na snadě, aby se o správu logů (rotaci, archivaci, ...) staral syslogd. Bohužel, kdekdo loguje vlastní cestou, proto se to muselo řešit odděleným programem.
Logrotate má spoustu omezení, např. to, že musíte definovat práva odrotovaných souborů, což je z principu náchylné na chybu administrátora. Nebo že nejde nastavit centrální politika pro rotování.
Není tedy pravda, že logrotate je nejlepší a historicky zakořeněný systém.
Podobnou obezličkou je např. anacron, který doplňuje v praxi chybející vlastnosti prastarého cronu.
A důvod, proč by to tak mělo být / zůstat?
Protoze NIX. Cpat vsechnodo jdnoho programu maji za zvyk v Redmondu. Nevidim, proc to delat i v Linuxu, logrotate takto nemusite pouzit a muzete nasadit neco jineho.
Jen pro upřesnění, logrotate tu nebylo v době unixů / kořenů sysvinit. Je to obezlička, která byla doprogramovaná na usnadnění správy logů.
Vazne? Ja u toho nebyl, tak nic nemuzu tvrdit, ale napada me, se to tak muze byt prave proto, ze si nekdo rekl, ze rotace logu patri jinak, snizovala by spolehlivost a zvysovala komplexitu logovaciho daemonu a take si rekl, ze se na to casem napise extra aplikace.
Není tedy pravda, že logrotate je nejlepší a historicky zakořeněný systém.
Coz nikdo netvrdi. Ale aspon mate moznost ho nahradit jinou kostkou stavebnice, kdyz se vam znelibil.
Podobnou obezličkou je např. anacron, který doplňuje v praxi chybející vlastnosti prastarého cronu.
Prastary cron nemusite pouzivat, existuji ruzne implementace a dost mozna se i staraji i o prosvihnute tasky, takze nemusite pouzivat ani anacron.
>> Prastary cron nemusite pouzivat, existuji ruzne implementace a dost mozna se i staraji i o prosvihnute tasky, takze nemusite pouzivat ani anacron.
Ale jo, já si nijak nestěžuju. Cítím se poměrně volný v tom, jaký výběr systémů mám. Jen jsem Vám chtěl uvést i argumenty PRO, když chrlíte argumenty PROTI.
Ale jo, já si nijak nestěžuju. Cítím se poměrně volný v tom, jaký výběr systémů mám. Jen jsem Vám chtěl uvést i argumenty PRO, když chrlíte argumenty PROTI.
A ze vas tedy prekvapuje, kdyz ja si stezuju na systemd, ktery pohlcuje stale vetsi cast systemu tak, ze moznost volby zustava spise na teoreticke urovni?
>> A ze vas tedy prekvapuje, kdyz ja si stezuju na systemd, ktery pohlcuje stale vetsi cast systemu tak, ze moznost volby zustava spise na teoreticke urovni?
Ne, mě rozčiluje, když se k věci takto radikálně vyjadřuje někdo, kdo není ochotný přiložit ruku k dílu - už jen třeba tím, že začne používat, nebo dokonce podporovat takovou distribuci, která si dál drží sysvinit. Problém tedy nemám s tím, že se Vám systemd nelíbí, ale v tom, že máte moc silná slova a k nim nulové činy.
Ne, mě rozčiluje, když se k věci takto radikálně vyjadřuje někdo, kdo není ochotný přiložit ruku k dílu - už jen třeba tím, že začne používat, nebo dokonce podporovat takovou distribuci, která si dál drží sysvinit. Problém tedy nemám s tím, že se Vám systemd nelíbí, ale v tom, že máte moc silná slova a k nim nulové činy.
To je pozoruhodny argument. Vy sice rad hazite marxisty na vsechny strany, ale argumentujete jak komunisti, kdyz nekdy pred prestavbou hospodarskeho mechanismu (aby byl jeste lepsi), prodelavali obdobi konstruktivni kritiky, kdy vyzyvali vsechny ke kritice, ktera ale musela byt konstruktivni. Byla toho plna televize, uplne ke zbliti.
Podle vas maji narok kritizovat akorat vyvojari, uzivatele maji drzet hubu. Presne takto vznikaji systemy, ktere uzivatele nenavidi. Dokonce i v Redmodnu si vsimli, ze lide nadavaji na nektere vyfikundace v novych Widlich pocinaje osmickovou radou a urychlene to upravili u desitek a snad i tech osmicek. Ale v Linuxu mame drzet hubu a krok, byt vdecni, mit doma sosku Poetteringa a te se klanet a zapalovat vonne tycinky.
>> Podle vas maji narok kritizovat akorat vyvojari, uzivatele maji drzet hubu.
Vůbec ne. Uživatelé mají být slyšet, ale tak nějak se očekává, že čím hlučnější jste, tím víc byste měl přidávat i činy. Já si troufám vyjadřovat se jen kvůli tomu, že používám jak Linux v instalacích s sysvinit, tak systemd, tak používám i freebsd, i windows. V každém z těchto systémů vidím jak pozitiva, tak negativa. Hlučné výrazy od někoho, kdo není ochotný udělat ani to, aby ty systémy používal, nemohu brát.
Váš marxismus nesouvisí s touto diskusí, resp. jen okrajově. Důsledkem marxismu-leninsmu byla socialistická zřízení, kdy také všichni pracovali pro všechny - tedy slovy. Činy každý dělat všechno pro to, aby pracovali ti ostatní, a on mohl mít jen ten podíl na plodech práce. A souvislost s tématem je právě a jedině tato, a pak také to, že Vaše komentáře zavánějí plytkým populismem, bez promyšlení toho, jak to zařídit v praxi.
Vazne? Ja u toho nebyl, tak nic nemuzu tvrdit, ale napada me, se to tak muze byt prave proto, ze si nekdo rekl, ze rotace logu patri jinak, snizovala by spolehlivost a zvysovala komplexitu logovaciho daemonu a take si rekl, ze se na to casem napise extra aplikace.
No upřímně, to jak některé programy zachází se svými logy je prostě prasárna a logrotate je jen záplatou na tuhle prásárnu. Pokud program aktivně vytváří log soubor, měl by se o něj postarat kompletně (tj rozdělovat podle různých kritérií, mazat staré apod.). Některé programy to tak dělají.
Jiné to explicitně přenechávají na externí programy a to buď psaním na stdout (nebo err) nebo do socketu (kde může čekat syslog v libovolné implementaci). Potom je pochopitelně na externím programu, aby si s logem poradil způsobem naznačeným výše.
Stav, kdy program blije log do souboru a ten log roste do nekonečna a na to se nasadí logrotate, který v nějaké chvíli (zpravidla nesouvisející s aktuálně logovanými událostmi), ten log vezme, přejmenuje a na program pošle nějaký signál, fakt považuju za prasárnu. To už je fakt lepší, když to hrne na stdout a tím ten program explicitně oznámí světu, že jeho logy jsou starostí někoho jiného.
Ono jako ne všechny hacky, které fungují, jsou skutečně něco hodného následování.
Jo, to tu rotaci ale pak musite konfigurovat a padesati mistech. To mi zas ta logrotate zaplata pripada lepsi.
No to mě připadá lepší, pokud ten program umí logy psát do socketu a postará se o to jedna služba (tj syslog). Nebo rovnou na stderr a postará se o to něco, co to bude strkat do socketu a bude to končit v syslogu.
Prostě pro obecný logrotate nevidím místo a podle mě je to škaredý hack, který řešil škaredou situaci.
>> Jo, to tu rotaci ale pak musite konfigurovat a padesati mistech. To mi zas ta logrotate zaplata pripada lepsi.
Houby, stačilo by logovat přes syslog a na něm to nechat. Mimo jiné by šlo logovat vše do jednoho místa z celé sítě. Takto aby se admini posrali, hlavně že si mohou nakonfigurovat logrotate. Problémy začínají ve chvíli, kdy na logrotate špatně nastavíte práva, nebo nedejbože je log na NFS.
Houby, stačilo by logovat přes syslog a na něm to nechat. Mimo jiné by šlo logovat vše do jednoho místa z celé sítě. Takto aby se admini posrali, hlavně že si mohou nakonfigurovat logrotate.
Jo, stacilo by. Bohuzel ne vsichni to tak delaji. To, ze nam soudruh Poettering nadeli journald, asi neznamena, ze se na tom neco zmeni.
Problémy začínají ve chvíli, kdy na logrotate špatně nastavíte práva, nebo nedejbože je log na NFS.
A proc chcete logovat na NFS, kdys si muzete nekde rozjet vzdaleny log?
Protoze NIX.
Původní princip Unixu byl „všechno je text“ a „programy si mezi sebou budou posílat texty přes standardní vstup a výstup“. Tomuhle přístupu odpovídá to, když program loguje na standardní výstup. Mně se takový přístup líbí i proto, že ten program pak úplně stejně funguje i když ho spustím normálně z příkazového řádku nebo ho spustím v debuggeru, funguje dokonce i na Windows. Nedochází pak k případům kdy řeším nějaký problém s programem, potřeboval bych se podívat do logů – a rázem řeším jiný problém, kam ten program vlastně loguje.
No, a když program loguje na standardní výstup, a má běžet jako služba, potřebuji jinou službu, která se připojí na standardní výstup toho programu, a logované zprávy bude zpracovávat – filtrovat, zapisovat do souboru, odesílat po síti… Rovnou podotýkám, že přesměrovat výstup do souboru, který na věky poroste, nepovažuju za dobrý nápad.
systemd tohle umí, uměly to před ním už třeba daemontools, pro mne je to jedna z klíčových vlastností správce služeb a důvod, proč jsem už dávno používal daemontools.
V čem že je ten druhý systém lepší?
Minimalne v tom, ze to bude v textovem souboru, ktery *vzdy* prectu, coz u journald s jeho zhovadilymi binarnimi logy neni jiste. A pokud uz je prectu, tak abych se sral s nejakymi utilitkami, ktere tomu rozumi a nemusi byt nutne k dispozici.
Dale v textovych souborech se blbe skryva detske porno, v binarnich nedomyslenych od journald to jde v pohode: https://ksdjhflkasdjhflkajdshf.wordpress.com/2014/03/08/child-porn-in-systemd-journal-yes-we-can/ Za detske porno si dosadte jakekoliv v logu nezadouci informace.
BTW, vzhledem k castym problemum se systemd bych se nedivil, kdyby se nebortily jen logy, ale i sam journald.
Windows binární logy používají od nepaměti (přes dvě dekády), problém s jejich čtením či (ne)dostupností nebývá. Tak proč by měl být najednou na linuxu?
Tak na Widlich je to celkem jedno, uzitecnost widlich logu je obvykle nulova a stejne je tam asi porad ani neni cim parsovat. Nicmene si cvicne vyzkousejte se k widlologum dosta v simulovane situaci, kdy vam system nebotuje. Pravda, i tehdy jsou obvykle na hovno, protoze nebootujici Widle se obvykle resi ritualem svate reinstalace. Ale v Linuxu tomu tak neni a nevidim duvodu, proc to, co je blbe ve Widlich, by melo byt blbe i v Linuxu.
>> Ja toho o Widlich chci vedet co nejmene. Uzil jsem si jich dost od verze 2.x.
Pak byste se k nim ale neměl vyjadřovat, bylo by spíš na místě pokorně položit dotaz těm, kteří o tom něco vědí. S logováním bootu a rešením nestartujících windows jste se hodně netrefil, ale hlavně že jste o tom všem přesvědčený :).
Pak byste se k nim ale neměl vyjadřovat, bylo by spíš na místě pokorně položit dotaz těm, kteří o tom něco vědí. S logováním bootu a rešením nestartujících windows jste se hodně netrefil, ale hlavně že jste o tom všem přesvědčený :).
Az budu chtit vedet neco o Widlich (pan buh s nami a cert pryc), tak si to najdu na Guuglu. A o logu bootovani jsem nikde nemluvil. Mluvil jsem o dolovani systemovych/aplikacnich logu ze spadle masiny.
Dale v textovych souborech se blbe skryva detske porno
Vážně? Stačí nevhodně nastavené logování DB, data ukládaná třeba do BYTEA a v textovém logu se objeví base64 kodovaný field s těmi vkládanými daty. Úplně stejně jako v tom journalu. Journal umožňuje ukládat textové fieldy do určité velikosti a tím se jinak neliší od všech ostatních systémů, které umožňují totéž.
Jako taky systemd nemusím, ale tahle kritika už je trochu přes čáru.
Vážně? Stačí nevhodně nastavené logování DB, data ukládaná třeba do BYTEA a v textovém logu se objeví base64 kodovaný field s těmi vkládanými daty. Úplně stejně jako v tom journalu.
Vy jste ten clanek zretelne necetl. Admin by musel byt uplne blby, aby si v textaku nevsiml, ze tam ma nejaky divny hexa nebo podobny vypis, ktery tam zretelne nema byt. V systemd si ale niceho nevsimnete.
"Systemd journal uses structured binary log files to store logs. These are to be read via journalctl utility. Journalctl utility by default shows only a finite subset of all fields that has been logged to journal. Hence it’s not showing anything else, so it’s quite easy to store some malicious content, e.g. child pornography, malware or extremist material there without being noticed."
Vy jste ten clanek zretelne necetl.
Ale jo četl a s journal jsem si užil své.
Admin by musel byt uplne blby, aby si v textaku nevsiml, ze tam ma nejaky divny hexa nebo podobny vypis, ktery tam zretelne nema byt.
Tak asi čteme jiné logy, já tam tohle mívám docela běžně. A nemám v mozku base64 a jpeg dekodér, takže si fakt nevšimnu, zda je to chtěný nebo nechtěný obsah. Prostě je to jeden z mnoha fieldů.
V systemd si ale niceho nevsimnete.
Dobře a co teda má být pointou? To, že do různých systémů můžu skrýt různá data vím. Stejně jako nekontroluju počty záznamů v DB, takže i tam by někdo šikovný mohl skrýt BYTEA s CP a toho bych si taky nevšiml. Dokonce bych si toho nevšiml ani v případě, kdyby někdo dostatečně malý obrázek vložil jako data do pdf učebnice fyziky (pdf má sekce, které se nezobrazují a přeskakují a dá se do nich umístit ledacos). Pokud to někdo bude chtít skrýt, tak k tomu má milion možností.
Takže pokud jde jen o to, že někdo může do journald dostat nevhodné materiály a chtít tak dostat admina třeba do kriminálu, tak sorry, k tomu má už dnes nebo před journal nepřeberný počet možností. Fakt v tom nevidím problém (spíš teda vidím problém v tom, že aby admin měl být trestně odpovědný za to, co má v kdejakém souboru na disku v multiuser prostředí).
Tak asi čteme jiné logy, já tam tohle mívám docela běžně. A nemám v mozku base64 a jpeg dekodér, takže si fakt nevšimnu, zda je to chtěný nebo nechtěný obsah. Prostě je to jeden z mnoha fieldů.
Patrne ano. Mohl byste prozradit, co vam lohuje v base64? Ja mel za to, ze ucelem textoveho logu je to, aby byl za jakehokoliv pruseru citelny. A kdyz uz vam neco takhle veprove loguje, tak aspon vidite rovnou, ze to tam je.
Mohl byste prozradit, co vam lohuje v base64?
Jsem to psal, jde o db, konkrétně o postgresql, stačí logovat všechny dotazy běžící déle než limit (slow query), nebo prostě všechny dotazy (při určitém debugu se to hodí) a už to tam je. A insertují se mimo jiné i data typu BYTEA (bytové pole - binární data). No a v logu jsou celé dotazy, tedy i včetně toho datového pole. Tj přesně to, co admin chce.
Ja mel za to, ze ucelem textoveho logu je to, aby byl za jakehokoliv pruseru citelny.
No tento log čitelný je. To, že obsahuje pole, která pro člověka čitelná nejsou, na tom nic nezmění. Prostě jsou to nějaká data, která se měla insertnout.
A kdyz uz vam neco takhle veprove loguje, tak aspon vidite rovnou, ze to tam je.
No to vidím, ale kdyby to bylo CP, tak to stejně nepoznám.
Naopak, to pujde velice rychle. Systemd za 7 let ma pres milion loc, jadro za > 20 let ma 20 milionu loc. Na prvni pohled by se zdalo, ze jadro bobtna rychleji. Ano, je tomu tak, ale jen do doby, kdy systemd zahrne svuj vlastni virtualizacni SW a k tomu nekolik vlastnich verzi jader nekolika OS, tedy minimalne Linuxu a par BSD.