Vlákno názorů k článku Co se systemd… a Linuxem od Kotrfa - Mluví autor o složitosti kódu, nebo užívání? S...
-
Kotrfa (neregistrovaný)
Mluví autor o složitosti kódu, nebo užívání? S užíváním to tedy rozhodně není strašné!
Musím se přidat k některým z předchozích komentujících - práce se systemd (používám Arch linux) mi přijde skvělá a mnohem jednoduší a transparentnější než dříve na Ubuntu. Je pravda, že jsem dost pokročil, co se týká znalostí, ale i tak. 99% práce se systemd jsem schopen s touto znalostí:
* systemctl status/start/stop/restart/enable/disable <unit>
* že konfiguráky jsou v /usr/lib/systemd/system/*další features, které jsem v ubuntu prostě jednoduše nenašel (ne, že by na to nebyly nějaké bizardní balíky), je systemd-analyze. Díky možnosti si vyplotovat boot sequence v svg jsem si opravil plno věcí, co mi na jiném linuxu nechodilo - něco se startovalo před něčím, co nemělo atp. (opět by to šlo asi i na jiných distribucí, ale tady to je out-of-the-box jeden příkaz).
Informace o jednotkách (systemctl status <unit>) jsou také parádní - vše na jednom místě, od stdout po všechny další detaily.
Další věc co vítám je journalctl - naprosto primitivní používat i nastavovat (jeden konfigurák v /etc). Možnost uložení v paměti atp. též vítám.
Pár mých kamarádů teď přešlo také na Arch - naučit je se systemd obnášelo přesně jen tyto informace a spokojenost. Editovat jeden řádek "exec" tak, aby to dělalo co chcete, je primitivní.
Na RPi jsem také s radostí využil networkd (místo netctl) a timsyncd, který bohužel potřebuje právě ten networkd, ale ten může v základu žít jen tak vedle. Nahradilo to netctl, fake-hwclock i ntp. Konfiguráky už nemůžou být pro tyto služby jednoduší.
Nazval bych se pokročilejším uživatelem a systemd si zkrátka nemohu vynachválit ať už možnostmi, tak ovládáním.
Co se týká kódu tak do toho nemohu moc mluvit. Četl jsem pár děsivých blogů o tom, jak je systemd složitý a jak je pravděpodobně prošpikovaný backdoory od Red Hatem, která je financovaná US Army a podobně... To asi nebudu raději hodnotit a věřím tu vývojářům - je-li to zbytečně složité, pak je to zbytečně složité. Ale jako uživatel jsem nenašel nic jiného a principiálně si nedokážu nic jednoduššího představit.
-
muf (neregistrovaný)
Se znalostmi, které uvádíte, ale daleko nedojdete.
Se systemd se samozřejmě dá žít, ale pokud od něj budete chtít něco víc, brzy narazíte na problémy, které budou díky jeho neprůhlednosti velmi špatně řešitelné.
Věnoval jsem dokumentaci dost času, takže snad něco vím a přesto narážím na těžko řešitelné problémy, které se starým initem prostě neexistovaly... Z triviality se náhle stane velká akce.
Malý příklad z poslední doby:
Potřeboval jsem na jednom stroji při shutdownu spustit můj vlastní shell script, který něco dělá přes SSH protokol na jiném serveru. Je pro to třeba nějaký čas a potřebuje k tomu funkční připojení do síťe. Bohužel systemd během shutdownu síť předčasně ukončí, script tudíž nemůže práci dokončit...
Pochopitelně jsem to dělal tak, aby byly služby shazovány ve správné sekvenci. Zkoušel jsem to řešit pomocí network.target, pomocí network-online.target, .... atd.... Bohužel, shození sítě je sice spuštěno po mém scriptu, ale na jeho dokončení nepočká...
Dříve trivialita, dnes pakárna... Nakonec to vyřeším, ale ten čas mně magor Poetering nevrátí. -
Kotrfa (neregistrovaný)
Rozumím Vám. Jak jsem říkal, hlouběji do systemd nevidím, nicméně na povrchní uživatelská část je to nejpříjemnější, co jsem na Linuxových init systémech viděl (a pravda, nebylo jich moc...)
Ještě bych se systemd zastal z jednoho hlediska - přeci jen jde o relativně mladý projekt. I upstart je o 4 roky starší. Ovšem pokud jeho komplexita roste, do ničeho lepšího to asi nespěje. Ale zrovna to o čem mluvíte bych řekl, že se do čtyř let vyřeší :).
-
muf (neregistrovaný)
To jsem vše pochopitelně zkoušel - na to logicky přijdete, když čtete dokumentaci. Bez úspěchu.
Budu to muset ještě projít, jestli jsem někde něco nepřehlédl - nejspíš ano... Ale je na tom krásně vidět debilita podobných překombinovaných nástrojů tváří v tvář úplně triviálním problémům.
Nechce se mně věřit, že by to nešlo, ale vůbec bych se nedivil, pokud by Poetering(nebo nějaký jeho poskok) začal s přednáškou, jak je špatné to, co chci udělat a že správný moderní frikulín takové věci dělat nepotřebuje, protože ON se rozhodl, že to není nutné...Mohu to pochopitelně nějak nabastlit, ale chtěl jsem čisté systémové řešení :-) Ve světě systemd je to možná přemrštěný požadavek :-)
-
To je presne to co dela systemd spatnym - jeho "proramovaci" jazyk, ma neomezenou mnozinu prikazu, protoze ruznepodobne a hruzne direktivy se pridavaji jak se kde zaplatuje nejaky problem. Pamatovat si pak vsechny tyto "prepinace" jz uz temer nemozne. Opet nedelal jsem studii jak moc je ta mnozina jiz stabilni, ale driv se to menilo s kazdou verzi systemd.
-
Michal2 (neregistrovaný)
Co nutí lidi cpát do slova "bizarní" to d navíc, to je značná záhada. Převzaté z jiného jazyka to není, snad žádný tam to d nemá (a rozhodně ho tam nemá etymologický zdroj toho slova- francouzština). Je to delší, je to divné jak v psané tak mluvené podobě... Snad autor toho příspěvku by mi to mohl vysvětlit.
-
BobTheBuilderStříbrný podporovatelChyby v cizích slovech se hodí k článku, kde úpí gramatika 3. třídy ZŠ, namátkou: "Nelze neocenit Lennartovi schopnosti...", "...aby mu vyšli binárně stejné balíčky...".
-
ppp (neregistrovaný)
GNU usiluje, mimo jiné o to, aby si každý mohl sestavit svou distribuci kompletně sám a to tak, aby mu vyšli binárně stejné balíčky...
Ona i ta první lichá čárka člověka trochu rozhodí... :-)
A pokud jde o ten konec, tak správně přece je aby mu vyšli binárně stejní balíčci, ne? :-))) -
> Další věc co vítám je journalctl - naprosto primitivní používat i nastavovat (jeden konfigurák v /etc). Možnost uložení v paměti atp. též vítám.
journalctl a journald su vyslovene skvele veci pre kazdeho, kto logy v skutocnosti nepotrebuje citat :) Zatial vzdy, ked sa mi podarilo system rozbit, journald a ten jeho blob padol prvy. Hladanie problemu je potom vyslovena sranda.
-
Bohuzel poskozeni blobu journald uz jsem take zazil. Zatim stale jeste loguji i pres rsyslog ale otazka je, jak dlouho to jeste pujde - existoval problem s tim, ze v textovych log souborech byly zaznamy ruzne prehazany a Lennart na to reagoval tim, ze to neni problem journald ale neschopnosti syslogu... jeste vic by me zajimala kompatiblita blobu z ruznych verzi systemd/journald...
-
Mě hlavně překvapilo to, že se by default loguje do paměti a taky to, že "na rozdíl od syslogu" řeší důvěryhodnost a nezměnitelnost logů (prý použitelné v případě napadení stroje). Syslog umí odesílat logy na jiný server, útočník je tedy nemůže smazat ani změnit a když ten stroj spadne tak se, jako v případě journald, o ty logy nepřijde. Journald logy na jiný server odesílat neumí. Ale určitě je to v plánu. ;-)
-
Kotrfa (neregistrovaný)
Logování na server v journalctl pochopitelně je (speciální service file)...
Logování do paměti jsem ocenil na RPi, kde je snížení zápisů na disk žádané. To že je to defaultně nemohu potvrdit. Mám za to, že jsem to musel měnit. Nicméně je to opět jeden (hned první) řádek v journalctl.conf.
-
"Logování na server v journalctl"
Tak fajn, ještě před několika lety to tam nebylo. Konečně se journalctl blíží klasickým syslogů,
"Logování do paměti jsem ocenil"
Logování do paměti lze snadno rozběhat i se syslogem. Prostě /var/log připojíte na tmpfs či jiný fs v paměti. Všimněte si, jak je toto řešení univerzální, nezávisí na tom, zda tuto funkci poskytuje samotný program a lze jej použít i na jiné věci, než jen logy.
-
...ktery jsem vytvoril prave pouzitim toho "reseni".
typicka situace:
nejaky proces se zblazni a do logu zacne hustit giga nejakych debugovacich hlasek. nebo treba brute force password attack na ssh. nebo logy z netfilteru od podivnych packetech. proste cokoliv co zacne floodovat log. (a ne, vsechno to neuhlidas).
to nasledne vede k tomu, ze v lepsim pripade se logovani zasekne (coz je jeste ok, pokud sluzba jede, ale stejne je neprijemne, ze clovek netusi, co se deje prave TED - ma jen stare logy). v horsim pripade (a to byva castejsi) se kvuli tomu podela kde co (napriklad protoze do /var nejde odkladat data nebo failujici logovani shodi proces, ktery se snazi logovat, coz je nase dulezita sluzba, ktera musi bezet, atd...).
no, anebo nebudeme bastlit vlastni "chytra reseni" a proste pouzijeme logovani do pameti, tak jak je skutecne zamysleno (kruhovy buffer) a mame po problemech.
-
> A jak jednodušeji na headless mini homeserveru zjistit brutal force útoky, kterých jsem si jich nebyl vědom?
DenyHosts? Alebo obdobny nastroj, existuje ich viac nez par. Spolu s automatickym banovanim, synchronizaciou medzi strojmi a pripadne globalnym blacklistom.
Zial, o tom, ze by niektory z nich podporoval Journald nic neviem.> Systém si nerozbijím (Arch)
Arch pouzivam viac-menej spokojne uz nejakych 6 rokov. S rozbijanim nikdy prilis pomahat nepotreboval, vacsinou na to stacilo spravit update :)
-
Kotrfa (neregistrovaný)
Update dělám denně. V IgnPkg nemám ani jeden balíček a za ty necelé 3 roky mi systém ani jednou neprovedl to, že by nenabootoval. Momentálně, pravda, mám problém s Bluez, ale to nedávám za vinu Archu, ale naprosto nepochopitelném vedení toho, jak se Bluez vede (například - najděte mi dokumentaci k Bluez 5 - GRRR!).
A DenyHost rozhodně není jednodušší. V journalctl jsem si toho všiml sám - prostě si projdu jestli někde není nějaký problém a nemusím na 5 služeb instalovat speciální utility či procházet 5 různých logů (nginx, sshguard, ssh, svftp...).
Btw. sshguard podporuje journalctl, jen se o tom nikde moc nedozvíte.
-
Vy proste robite to, co DenyHost automatizuje, rucne. Jasne, nic proti tomu, aj to je riesenie. Pravdepodobne spolahlivejsie, nez DenyHost pod Archom :(
Len taka drobnost, neuspesne prihlasenia sa pod Archom (a hadam i vsade inde) vzdy logovali do toho isteho suboru - /var/log/auth.log. V tomto journalctl ziadnu vyhodu nepriniesol.
-
"A jak jednodušeji na headless mini homeserveru zjistit brutal force útoky, kterých jsem si jich nebyl vědom?"
Když jste si jich nebyl vědom a patrně ani nijak neovlivnily chod serveru (potom byste si jich asi byl vědom), proč je chcete zjišťovat a řešit? (To, že ono "řešení" nastíněné v dalších komentářích není řešením nechávám stranou.) Evidentně tento jev nepředstavuje problém.
-
Ano, bootchart je pěkná funkce, ale vnikla spíše jako z nouze cnost. Tím, že je start se systemd mnohem složitější než v klasickém SysVInit, přišli autoři (s poměrně pěkným) nástrojem jak jej zobrazit jednoduše. Ale v klasickém sysvinit (kromě toho, že i tam bootchart lze aplikovat) to nebylo potřeba. Na svém serveru mám 14 služeb, z toho 14, které tam chci a úmyslně jsem je zařadil do bootu. Vyznat se v tom není problém, na vylistování stačí obyčejný příkaz
ls. Všimněte si, jak je toto řešení univerzální. Příkaz ls můžete používat i na jiné věci, než jen zobrazování obsahu adresáře/etc/rcX.d.Na své pracovní stanici se systemd mám asi 30 položek, z toho dvě bych tam chtěl (sshd a lightdm) a zbytek jsou prostě závislosti ve stromu unit (ano, já vím co jsou a co dělají, ale rozhodně to není přehlednější).
ČLÁNKY DO MAILU