Engem mondjuk leginkább ez a syslog helyettesítő journal zavar benne, ha valakinek erre van szüksége, miért nem csinál egy új projectet rá, minek beleerőlteni az initbe?
ne adj nekik ötleteket. egyébként a journal azért van benne mert:
yes, it's a job for rsyslog or another syslog implementation. Having
the log files as text, i.e. unstructured, is a technological step
backwards: you loose information which allows for indexing and seeking
and easy parsing, and gain almost nothing in return. The only
advantage is that certain tools (like grep) can be more conveniently
used with text files, but grep and friends also work on journalctl
output, so it's not a compelling argument.
én nem szertem a systemd. együtt élek vele, de szerintem úgy tolják mintha egy vállalat lenne. ez van, ezt kell szeretni.
olvastátok a manuálját? na az kész őrület. a 'disable' nem tiltja le véglegesen a cuccot ahhoz maskolni kell és így tovább.
a binális idító állományokkal az a baj, hogy ha valami hiba van benne, te nem tudsz belenyúlni hogy javítsd vagy át paraméterezni. vagy fordítasz újat vagy vársz a javításra ami sokszor nem kivitelezhető.
vlamint, nem otthoni gépeken, kit érdekel a boot idő. komolyan, milyen rendszer tervezés az ahol a boot idővel számolni kell. egy fürtözött szolgáltatásnál nem lesz@rom hogy 4 vagy 8 perc amíg a node feljön? addig a többinek bírni kell a terhelést.
szóval szerintem hogy a RH 7 már systemd használ..... hát...
--
A legértékesebb idő a pillanat amelyben élsz. https://sites.google.com/site/jupiter2005ster/
Hát a boot időt én otthoni gépen is leszarom mióta SSD van. Szűz boot + belépés + wifi-hez csatlakozás hamarabb megvan, mintha standby-ból visszahozom, aztán másodpercek alatt észreveszi hogy nincs az AP-hez csatlakozva, aztán nagy kegyesen felcsatlakozik rá.
A szerver meg úgyis tetvészkedik pár percet mielőtt elindulna a boot folyamat, szóval ott se túl kritikus hogy 270 sec vagy 280 sec egy reboot...
pontosan. szóval a csodálatos systemd csak a programozóknak jó. én személy szerint nagyon nem szeretem.
--
A legértékesebb idő a pillanat amelyben élsz. https://sites.google.com/site/jupiter2005ster/
Hát a boot időt én otthoni gépen is leszarom mióta SSD van.
pontosan. szóval a csodálatos systemd csak a programozóknak jó.
Nyilván, mert csak a programozóknak kényelmes pl. a multi-seat support (pl. minden korszerű disztóban ott van a Pluggable USB-s multi-seat cuccainak a támogatása Gnome-al különösen - ez a másik oldalon külön OS-t igényel (Windows MultiPoint Server) CAL-okkal, btw.), az erőforrás kezelés, a processzek hatékony követése és kezelése, a szolgáltatások on-demand indítása és az összes többi felesleges szutyok. Rohadt programozók, hogy így ránk akarják erőltetni a szutykaikat. Fúúj.
Boot-idő, az... (hint: BEVALLOTTAN egy pozitív MELLÉKTERMÉK, soha nem volt cél)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Fúj, tényleg, a kurva anyjukat, amiért csináltak egy rendszert, amiben ezt kényelmesen meg lehet oldani. Ami miatt mondjuk random helyen, ahol hasonló szoftverekkel dolgoznak többen, racionalizálni lehet a számítógépeket (munkahelyek, iskolák stb.) és így olcsóbban fenntartható, környezetbarát stb. rendszereket lehet építeni. Rohaggyanak meg.
A lista többi elemére, esetleg, valami? Vagy azokkal nem foglalkozunk mert fúj systemd és az mindent csak rosszul csinálhat.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Nem érted. Van rohadtsok hátránya (lásd eredeti post) te kimeltél pár előnyt én meg az egyikről leirtam, hogy kb senkit se érint. Ezért az előnyért biztos, hogy nem kell szivatni a maradék 99.999%-ot.
A többiről előnyről meg mindenki eldöntheti, hogy megéri-e neki a sok hátrányt, azok már nyilván több embert érinthetnek.
Systemd nélkül nem lehet megoldani linuxon a többuseres géposztást? (windows-ban license korlátozza csak)
Akkor még egyszer: milyen technikai hátránya van? (most tekintsünk el a "jaj-gonosz-[RedHat/Lenard/KiskutyaAkiLepisiliAFalat]-összeesküdtek-és-ki-akarják-sajátítani-a-Linux-ökoszisztémát" című dolgoktól ami az eredeti poszt)
Windows-ban sem csak licensz korlát van, külön, erre készített Windows verzió kell hozzá - ezt Lenard-ék (csak azzal, hogy kaptak egy pár próbaeszközt a Pluggable-től) megoldották, hogy bármilyen Linuxon, bármilyen DE-vel, ami követi az ajánlásaikat (http://www.freedesktop.org/wiki/Software/systemd/writing-display-manage…), működjön. És igen, systemd nélkül is meg lehet ezt csinálni korábban és a mai napig is: kártyavárazással, kezdve onnan, hogy kézzel kell összeszedegetned a hardware azonosítókat, a bennragadt processzek azonosíthatatlanságának a problémájáig (ezt a logind oldja meg a user slice-ok létrehozásával). Továbbra is: a systemd "csak" elkezdte kihasználni a kernelben levő lehetőségeket (igen, ezzel bukta a portolást, ez van) hogy olyan infrastruktúrát építsen ki, amikkel ezek megvalósíthatók.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Milyen bináris indító állomány? A systemd executable-re gondolsz? Az valóban az, de a SysV init beli init is az volt. Vagy arra, hogy nem kell 160+ soros init script mindenhez, hanem egy SZÖVEGES konfigurációs állományban leírod 5-10 sorban ugyanazt?
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
+1
Illetve azt se teljesen értem, hogy minek bele DHCP kliens.
Mindazonáltal még mindig jobbnak tartom mint a SysV Initet. Gyorsabb, a szkriptek nekem átláthatóbbak, tetszik a függőségkezelése. Viszont csak user vagyok, nagyon ritkán kell belenyúlnom.
Az nem kifejezetten a systemd, hanem a systemd-networkd - ami messze opcionális, csak egy ifup replacement ha a teljes NetworkManager azért sok lenne. (A DHCP szerver meg majd a systemd konténerekhez kell)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Az a networkd tényleg nem rossz, csak azt is minek a systemd-vel együtt szállítani? Jó, mondjuk így ha kell, ha nem, fel lesz telepítve, mint az összes többi bloat.
systemctl stop systemd-networkd.service && systemctl disable systemd-networkd.service
'oszt problem solved. (de pl. az openSUSE Factory-hoz elérhető systemd 210-ben nem is látom a networkd-t)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Értem én, hogy nem kötelező használni, de akkor is, miért nem lehet ez is egy önálló project? Akkor talán akinek tetszik, használhatná systemd nélkül is, ha olyanja van. Ez az árukapcsolás nagyon gáz már, és nem látni a végét, hogy mikor mondják azt, hogy na, ezt már mégse ide kéne tenni.
Akkor ez nem systemd, hanem arch döntés, aminek nem örültem. Ott régebben a netcfg volt egy nagyon jól használható konzolos hálózatbeállító eszköz, ezt nagyrészt leváltotta a networkd. Persze érthető, miért dolgozzanak ezen az arch-osok, ha valaki megcsinálja ugyan azt, kicsivel bonyolultabb szintaxissal.
Ezt ugyan biztos megvalaszolja egy FAQ, de ime egy ravezeto kerdes: hogyan oldanad meg, hogy egyreszt elkapd az early boot loguzeneteket ASAP, a daemonok stdout/stderrjet, es mellesleg upgradekor ne legyen logvesztesed?
(Mellesleg amig nem kozpontositot logolast hasznalsz, journal > syslog. Ha kozpontit, akkor meg nem valtozott semmi.)
Mondjuk amíg elindul a logger, addig gyűlik valahol? A systemd hová teszi, amíg nem indul el a journald? Azért ezt meg lehet oldani anélkül, hogy az init részévé tennél egy loggert. Ha meg valakinek a mániája a bináris log, indíthat nyugodtan bináris loggoló projectet, de így ráerőltetni mindenkire, mert tudja, hogy neked ez kell, kissé szemét dolog.
Olvasd el a tobbi requirementet is, ne csak a korai gyujtest. Azt tenyleg meg lehet oldani maskepp, bar nehez ugy, hogy nem az inittel szorosan egyuttmukodve.
Egyebkent ez systemdben ugy van megoldva, hogy systemd maga csattan ra a /dev/log-ra, o tartja nyitva az FD-t amig a Journal el nem indul. Ez a legkezenfekvobb megoldas egyebkent, amivel nem kell kolosszalisat szopni, hogy a corner caseket lekezeld.
A binaris log meg messze hatekonyabb, mint szovegben greppelni. Aki 2014-ben logot kezzel greppel, celeszkoz helyett, az valamit rosszul csinal.
Nem ugy van az, h okosabb meghagyni a hujenek a valasztas lehetoseget? Nyilvan, ha van vmi, ami telefossa a logot (mondjuk apache), ott nem feltetelenul az a jo, de a napi nehany szaz soros log grep-elesevel mi faj?
Ez a valamit rosszul csinál kicsit olyan mint amikor a gépklónozást szólták le, mert aki nem puppetet (vagy valami hasonlót) használ az már nem is ember. Aztán lehet hogy mégis, csak mások a feltételek, körülmények, elvárások.
Kivancsian hallgatom milyen esetben praktikusabb es/vagy hatekonyabb a grep, mint a journalctl, vagy barmilyen mas celeszkoz. (Nyilvan van egyebkent kivetel, de nem az az altalanos.)
Két féle választ adnék. Egyik a szőröző, szó szerinti:
"logot kezzel greppel" - "mások a feltételek" - "esetben praktikusabb"
Minden olyan esetben, amikor az alkalmazás saját logot ír, saját formátummal és agybajjal. A céleszköz meg nem biztos hogy adott a gépen amin épp matatni kell, míg a grep és társai azért gyanítható. De nyilván nem erről van szó, nem is akarom ebbe az irányba elvinni a dolgot, bár remek értelmetlen vitát lehetne belőle szítani.
A másik az érdemi, mert nyilván nem az egyedi esetekről van szó(*): szerintem nagyon sok helyen sokkal fontosabb szempont a visszafelé kompatibilitás a meglévő és működő rendszerekkel, mintsem az, hogy fancy céleszközökkel lehessen sokkal hatékonyabban csinálni valamit, vagy hogy egy új megoldásból, új eszközökkel lehessen előállítani a visszafelé kompatibilis adatot (a jelen esetben a logfájlokat).
És még egyszer, nem állítom hogy a grep a legjobb megoldás, de az, hogy valaki valamit rosszul csinál... hát picit túlzásnak érzem.
*) bár én, mint üzemeltető, olyan sok egyedi esettel találkoztam már, hogy néha azt hiszem, hogy az egyedi esetek az általánosak :) Gondolom másnak is van hasonló érzése.
Számomra az a negatívum a céleszközökben, hogy nem járulnak hozzá a rendszer egyszerűségéhez, hanem tovább növelik a komplexitást. Ez az ára a további hatékonyságnak. Viszont nem érdemes szerintem kijelenteni, hogy mindig minden helyzetben megéri ez az ár. Van amikor nem.
Ilyen alapon tovább lehetne fejleszteni sok területre további céleszközöket. A végén rohadt sok céleszköz lenne (lásd windows a millió shareware cuccal), melyeket nem is biztos hogy össze lehet kapcsolni igény szerint. Nagy valószínűséggel elfejlődnének olyan irányba, amely már független az eredeti problémától, és további inkompatibilis és különböző interface-ek jelennének meg, melyek megint rátesznek egy lapáttal a bonyolultságra. Ezekhez lehet hogy megint további céleszközök kellenének a hatékony kezeléshez vagy összekapcsoláshoz.
Nem azt mondom hogy ne fejlődjön valami, de gond az ha további egyedi megoldást visznek be a rendszerbe a többi elemmel való összekapcsolhatóság és visszírányú kompatibilitás nélkül. Márpedig nagyon ez a gyakorlat ahogy láthatjuk sok esetben. És ez konkrétan probléma. Egy speciális dolgot megold, sokat meg megoldatlanul hagy. Pl. mi van ha a célszoftver keresési feltételek által adott eredményeiben akarok greppelni vagy azt tovább szűrni valamilyen módon?
Szerk.:
A vége meg az, hogy van rohadt sok "jó" eszköz, csak alig van aki használja.
Egyébként meg lehetne szerintem tömni az egyszerű eddig eszközt is további tudással, és akkor nem veszne az egyszerűség és kompatibilitás. Pl. grep-et felokosítani kern.log tudással stb stb. Nem feltétlen ezt, de hasonlót jobb megoldásnak tartanék.
Egész pontosan hány általános eszközt kell összetákolnod ahhoz, hogy egy log fájlból kigyűjtsd mondjuk a tegnap előtti, adott szolgáltatáshoz, adott szintű naplókat? És ha ugyanezt pl. csak locale-k közt hordozhatóra akarod megírni? Hány olyan projekt is van netszerte, aminek a célja, hogy a /var/log/*-ból kereshető, érdemi információkat gyűjtsön ki?
És a journalctl nem veszi el ezen eszközök használatának a lehetőségét, ha akarod simán bepipeolod a teljes naplót amibe akarod: viszont hatékonyabbá teszi a naplókkal való foglalkozást.
A másik oldal, a visszafelé-kompatibilis fejlődés: a systemd valóban nem A tökéletes init-rendszer, de pl. többnyire kompatibilis visszafelé a SysV init-tel. Viszont nagyon sok jól kitalált plusz eszközt ad mint a fejlesztő, mint az üzemeltető kezébe: számold meg, hogy a gépeden futó random démonok közül hányban különböző képpen implementálva a chroot-olás, a jogosultságok eldobása stb. És hogy ezt hányféle módon kell konfigolni. És így jutunk el oda, hogy az egyszerű rendszerhez kell egy 160 soros shell script sablon(*), amit minden egyes szolgáltatáshoz másolgatni kell. Plusz munka a fejlesztőnek (már ha foglalkozik vele), a csomagkészítőnek, az üzemeltetőnek (csak úgy fejből: random démon önmaga dobja el a privilégiumait, vagy egy köré tett shell script? Önmagát zárja be, vagy köré tett shell script teszi?), stb. ...és figyelj, az új, systemd-specifikus feature-ökről [pl. kényelmes cgroup támogatás, erőforrás limitálás, mindenféle aktiválás stb.] egy szót sem szóltam!. Ugyanez van a journalctl-el: Turing teljes a bash, meg lehet benne írni N+1. alkalommal is azt a szűrőt, de ha meg lehet oldani hatékonyabban, jobb eszközökkel, EGY HELYEN, akkor miért ne?
BlackY
(*): Debian initscripts csomagban levő /etc/init.d/skeleton
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Mert ez az érv, hogy "miért ne?" nem érv. Illetve persze, érv, de nem ott, ahol az elsődleges (és a másodlagos is) szempont a rendszerek üzemeltetése.
Van egy komplex rendszerem, hozza a max. kiesés 10%-át. Az átállással, ami munka, tehát költség is, elérem azt, hogy a kiesés lecsökken... vagy nem.
Nyilván vannak olyan helyzetek, ahol viszont egy váltás (és nem feltétlen a jelen systemd-sysvinit, hanem bármilyen), az mérhető előnyökkel jár. Az egy másik történet.
Nekem pl. régi vágyam - és nem találtam még rá megoldást - hogy riasztást kapjak arról, ha egy kolléga pl. új IP tartományból jelentkezik be az IMAP szerverre. Tehát nem otthonról, sem az irodából, hanem hirtelen pl. egy kínai címről. Egy jól strukturált bináris loggal, ami külön mezőben tartalmazza a loginnevet és az IP címet, ez már nem is olyan nagy puki, bár még mindig tákolni kell rajta, hogy ebből riasztás legyen, de az már könnyebben megoldható.
Átfogalmazom, a 'miért ne' tényleg rosszul veszi ki magát: végre van egy rendszerük, ami kihasználja az alsóbb réteg (kernel) lehetőségeit, modern IPC-t használ és nyújt (oks, a D-Bus nem igazán systemd találmány, a kdbus már inkább, de eléggé használja), van rengeteg könyvtáruk (mind publikus, mind "belső"), amikkel egyszerűen fejleszthetők az ilyenek - pusztán azért, mert már rendelkezésre áll az alsóbb réteg és nem több projektet kell összefogni egyszerű feladatokhoz .
Triviális példa: loginctl és a multi-seat esete - igen, saját udev szabályok faragásával, a nem fejlesztett ConsoleKit konfigolásával és raklap bash kóddal. Vagy, mivel megvan hozzá az alapozás (pl. processzek követésére a slice-ok, az eszközök hozzáadására/eltávolítására a udev stb.), megoldhatják ők maguk, lényegesen kevesebb karbantartandó kóddal. És igen, lehet, hogy ehhez kell pár sornyi kód a DM-be, hogy ki is használja (lásd: Gnome, a KDE pl. egy időben tervezte dobni a KDM-et, mert túl régi és túl sok munka lenne kitakarítani), cserébe nem 10 projekten átnyúló konfigturkálás következik.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Lehet hogy nem is a céllal van a baj hanem a megvalósítással.
Személy szerint rengeteg szoftverből hiányolom az egyszerűséget. Tudjon sokat, de faragják már össze úgy, hogy biztosítson egy faék interface-t is, amely egy jól átgondolt módon mutatja az alap lehetőségeket - vagy biztosítja az elérését ezen alap dolgoknak man túrás nélkül meg powershell-re hajazó km hosszú paraméterekkel. Na ez nagyon nincs meg szerintem.
És hiába a szuper API meg alrendszer, ha a managelése szar. Ez két külön dolog. És mindkettőnek jónak kellene lennie.
Illetve eleve minek a --unit kapcsoló? Na mindegy. Nem a humán oldalt segíti, hanem a gépit.
Úgy tudom megfogalmazni amit mondani akartam a fentiekkel, hogy szarul van megcsinálva a CLI interface. Ez a bajom. Márpedig ez a legfontosabb, mert ezen keresztül kell turkálni.
Mondjuk az azért sem mindegy, hogy egyszer megtanulom a grep/awk-t, és tetszőleges szolgáltatásnál ugyanúgy, vagy 77 izénél 77 hatkékony eszköz egyedi szintakszisát kell kb fejben tartani...
Gyanítottam hogy nem olyan dolgot találtam ki, amit még senki más. De ezért az egy dologért nem akarok olyan rendszert telepíteni, aminek amúgy ez csak egy apró funkciója. Plusz nem akarom kifizettetni a céggel.
Pláne hogy minden információ adott a számomra, csak egyszer neki kéne ülni és megkalapálni.
De én vagyok a hülye... legközelebb olyan gyakornokot kérek aki amúgy kóder és megíratom vele... hogy erre miért nem gondoltam már évekkel ezelőtt... ehh...
A grep nem hatekony eszkoz erre. Es nem, nem donti el, mit hasznalsz logolasra. Ugyanugy hasznalhatsz syslog-ot, a Journal folott. Mindossze az valtozott meg, mi van alatta: nem kozvetlenul a kernel, hanem egy userspace program. Ennyi.
(Es mivel a Journal alapbol nem perzisztens, meg helyet se foglalnak a nem hasznalt Journal logok, csak egy keves memoriat.)
És ha én olyan hülye vagyok, hogy csak a grepet akarom használni? Vagy nekem az a kevés memória is számít? Vagy egyáltalán nem akarok logolást? Vagy ha én FreeBSD-n akarom használni, mert annyira tetszik? Hagy döntsem már el, hogy mi a jó nekem...
Én nem azt mondom, hogy nincs létjogosultsága a journald-nek, hanem azt, hogy nem kell árukapcsolással eladni. Ha olyan jó, akkor úgyis elterjed. Persze gondolom a RedHat support már megunta a sok okos admin által használhatatlanra beállított rsyslogot, és jött az ötlet, hogy akkor már legyen bent valami, ami mindig működik, és senki nem fog a kikapcsolásával szenvedni.
Ja, még egy, ami eszembe jutott, cron is van benne, de persze nem tudja az összes funkcionalitást, amit az eredeti, pl. hét egyes napjaira nem tud időzíteni. És kérdem én, ez minek?
Egyébként a man page meg egyébként a paraméterezés egy katasztrófa. Ezt komolyan gondolták innovációnak humanoidoknak?
journalctl _SYSTEMD_UNIT=avahi-daemon.service
Mi van ha az összes olyan log-ot látni akarom, amelyben szerepel az avahi kifejezés? grep helyett tud valaki hatékonyabb és _egyszerűbb_ eszközt mutatni? Mert mindig osztom a hatékonyságot az egyszerűséggel. Hiába az előbbi ha nincs meg a másik.
Én most azt próbálom kitalálni, hogy hogyan találom meg journalctl-el hogy egy user az adott napon kapott-e emailt. Mármint grep nélkül. Olyat keresek - egyébként - hogy milyen mezők szerepelnek a logokban, ezek azok?
Ez különben megint olyan számomra, mint Python kontra Ruby (Python bántása nélkül): Matz azt írja, hogy olyan nyelvet akart tervezni, amiben arra törekedik, hogy jobban segítse a humán oldalt, és ne a gépit. Python-nál fordított irányba mentek; a gépi oldal (interpreter) segítéséhez vezettek be dolgokat, pl. a sima print helyett zárójelezni kell azt is meg mindent stb. Tehát humán oldalról nehezebb és kényelmetlenebb lett.
Systemd-nél dettó ezt látom. Értem hogy jobb több szempontból meg jobban programozható, de abból a szemszögből amit most te felvetettél - nem találom jobbnak. Mert nem egyszerűbb. Ha úgy csinálják meg hogy amit felsoroltak tudja, és mellette egyszerű marad, akkor le a kalappal. De nem ez van szerintem.
Najó, de anno aix-on is az volt a bajom az errpt-vel (asszem), hogy abban is úgymond kézzel kellett keresni. Bár tény, hogy túl keveset dolgoztam aix-on, és néha nagyon-nagyon hiányzik pár finom dolga. Na nem baj, majd frissítem az itthoni masinát, úgyis komplett diskcsere lesz, és majd meglátom.
Nem akarom leszólni, de a magyarázat sem jön be nekem a váltásra, meg a szintaxis sem.
Egyébként pont arról szól a magyarázat megint, hogy az interpretert fejlesztő oldalt segítség. Tehát ne a humán kódert. Ruby-nál pont fordított erőfeszítések vannak (meg Matz alapból ezt az irányelvet deklarálta). Nekem ezek fő prioritások egy nyelvnél.
De nem flame-nek szánom. Elfogadom hogy így jobb nekik.
Jó, de amíg a rubyt eleve úgy találták ki, hogy kb. bármit bárhogy leírhass benne, addig a pythont pont ellenkezőleg, rákényszerít egy szigorú szintaktikára annak érdekében, hogy minden python kód ugyanúgy nézzen ki. Ebből a print pont kilógott, szerintem jó döntés volt függvénnyé tenni.
És ha én olyan hülye vagyok, hogy csak a grepet akarom használni?
Feladathoz eszközt... egyébként meg... Unix alapelv: pipe. journalctl | grep...
Vagy ha én FreeBSD-n akarom használni, mert annyira tetszik?
Semmi akadálya, portold az összes kernel feature-t, amit eddig senki nem használt, mert nem POSIX, viszont amitől használható lett a systemd...
Ja, még egy, ami eszembe jutott, cron is van benne, de persze nem tudja az összes funkcionalitást, amit az eredeti ... És kérdem én, ez minek?
Viszont cserébe garantáltan ugyanúgy fogja indítani a szolgáltatásokat, mint ahogy az init teszi - mert egész pontosan ő fogja tenni. Szemben a kártyavár: ott van a Monit, nagyon jó program, hasznos (az ilyen aktív monitorozást spec. hiányolom is a systemd-ből), FAQ: inkább kapcsold ki az init.d-vel indított szolgáltatásokat és hagyd, hogy a monit indítsa őket. Vagyis: egy technikai deficit miatt (gyk.: nincs összefüggés processz és service között) bizonyíthatóan lehetetlen race-free módon megcsinálni valamit, ezért a megoldás, hogy kihúzzuk azt a rendszert, amivel mindenki számol (és amiért mindenki oly nagyon sír - a SysV-t) és helyettesítjük egy kicsit mással. Systemd mellé (és le merem fogadni, hogy nemsokára lesz rá projekt) egyszerűen lehetne ilyen monitorozó ügynököt írni: lefuttatja a tesztet, ha nem jött be, D-Bus-on szól a PID 1-nek. Ezért kell árukapcsolás: feleslegesen duplikált (és karbantartott, auditált stb.) kódok helyett moduláris, de egy ernyő alá tartozó rendszermenedzser.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Jó, ne a grepen lovagoljunk már...
A journalhoz meg milyen hatalmas kernel featurek nincsenek meg vajon a FreeBSD-ben (nem ismerem, én nem tudom)?
Ha moduláris lenne, akkor lehetne hozzá kapcsolódó projectekben megvalósítani a logolást, a cront, meg még ki tudja mit, amikre nem is gondolok most, nem kéne egyben az ember nyakába önteni mindet, akár akarod, akár nem. A monithoz már volt szerencsém, ott ha kell neked ez a monitorozó izé, akkor használod, ha nem kell, akkor nem. A sysv init ilyet tényleg nem csinál, és ezt mondjuk tényleg intézehetné a systemd (mint mindent, ami egy service elindításával, menedzselésével kapcsolatos), ehelyett log, cron, hálózatbeállítási, meg még a jó ég tudja, milyen feladatokat pakolnak bele.
Nekem tetszett maga a systemd, és a service managelési megoldásai, de amikor a journalt belerakták, ott kezdtem el arra gondolni, hogy remélem ezt az ámokfutót leállítja valaki. (Ja, igen, van valami time service is benne, hát az is nagyon fontos...)
Én úgy nézem, azt csak azért teszi, hogy legyen _SYSTEMD_CGROUP és még egy pár mező a metaadatok közt. Nem hinném, hogy ez portolhatatlan. De így, hogy egybe van csomagolva a systemd-vel, ki fog ezzel szórakozni. Vagy mi van akkor, ha valaki írna egy még jobb log rendszert, ami ráadásul multiplatformos? Mivel mindenhová be lesz drótozva a journal, a kutya se fogja használni.
Meg pl. a _SYSTEMD_UNIT, amivel szolgáltatáshoz tudod kapcsolni.
Mivel mindenhová be lesz drótozva a journal, a kutya se fogja használni.
A journal leginkább csak a systemd-be van bedrótozva, random app nem nagyon fogja a natív journal protokollt beszélni (ők továbbra is syslog-olnak). Ha pedig arra gondolsz, hogy itt árukapcsolással irtják a konkurenciát: eddig is volt jó néhány log server, amik egymással "versenyeztek", most lesz még egy - senki nem tiltja, hogy a journal helyett/mellett/felett rsyslog-ot, syslog-ng-t, ... használj.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Meg pl. a _SYSTEMD_UNIT, amivel szolgáltatáshoz tudod kapcsolni.
Ilyeneknél kell a portnál kitalálni valami okosat (elsőre nyilván elhagyni).
A journal leginkább csak a systemd-be van bedrótozva, random app nem nagyon fogja a natív journal protokollt beszélni
Pedig ha születne egy ilyen struktúrált log API, talán még használná is bármilyen random app, de így, hogy csak systemdvel lehet, nem is baj, hogy nem cuppannak rá a fejlesztők.
senki nem tiltja, hogy a journal helyett/mellett/felett rsyslog-ot, syslog-ng-t, ... használj.
A többség meg nem fog két log démont futtatni, csak kényszerhelyzetben, ha már nem elég a systemd megoldása. Aki nem akar központi loggolást, annak "elég jó" lesz a journal is. A helyette sajnos meg nem játszik, lévén teljesen nem lehet kiiktatni.
Ez végképp kivégzi a syslogot systemd-s rendszereken. Persze lesz egy-két renegát régi motoros, aki még ideig-óráig fogja használni, aztán szépen elfelejtődik Linuxos körökben. De én remélem, hogy inkább a journal fog kikopni a systemd-ből.
Ez egyreszt nem opcio olyan rendszereken, ahonnan a sysvinitet mar kiirtottak. Masreszt akkor sem opcio, ha olyan programot akarsz hasznalni, ami systemd szolgaltatasokon dependal.
Nem igazán értem, mi ez a lázadás a systemd ellen. Nem vagyok üzemeltető, ezért egészen mások a szempontjaim nyilván, de Fedorán talán 3 éve van már systemd, eddig nem volt vele különösebb problémám.
Illetve érteni vélem, mi a probléma. A Debiant is elérte a systemd, s felkavarta az állóvizet. :) A systemd-vel talán egy bajom van, hogy nem tanultam meg, de azt érzékelem, hogy remek lehetőségek rejlenek benne. Ha majd reszelnem kell valamit, úgyis utánaolvasok.
A systemd szerintem egy egész jó ötlet nagyon nem jól megcsinálva. Főleg a *ctl eszközök és a config állományok.
Persze majd beletanulunk. És lehet majd meg is szokjuk.
Csak abban nem bízom, hogy stabil lesz. Ez az ami a sysV-ben megvolt. A faék bonyolultság egy ilyen kritikus rendszerelemnél szerintem amúgy is előny. Bár talán mindenhol az.
Illetve nem igazán tetszik ez a mostanság divatos mindent-összedrótozunk-mindennel dolog. Settingsdaemonok és egyébb perverziók.
részemről egy alkalmazás a beállításait tárolja vagy /etc/xy -ban vagy ~/.config/xy -ban lehetőleg .ini vagy .json formában (az XML kedves ötlet de halál kézzel írni)
a /usr/share/X11/xorg.conf.d/ egy rossz vicc.
És nem kell feltétlen 2^30 mennyiségű config file sem.
A *NIX filozófia egy jó dolog. És ha már *NIXra fejleszt az ember akkor esetleg érdemes követni.
### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch
The tasks mentioned that systemd already covers include, "init system, journal logging, login management, device management, temporary and volatile file management, binary format registration, backlight save/restore, rfkill save/restore, bootchart, readahead, encrypted storage setup, EFI/GPT partition discovery, virtual machine/container registration, minimal container management, hostname management, locale management, time management, random seed management, sysctl variable management, and console managment."
Tasks being worked on are support for a local DNS cache, mDNS responder, LLMNR responder, DNSSEC verification, IPC support in the kernel (KDBUS), time synchronization with NTP, better integration with containers, and many other services.
Hozzászólások
Engem mondjuk leginkább ez a syslog helyettesítő journal zavar benne, ha valakinek erre van szüksége, miért nem csinál egy új projectet rá, minek beleerőlteni az initbe?
Mert a fő fejlesztőnek ez a mániája és valami rokonának amúgy tézis munkája volt :)
Amúgy meg ntp-t is raknak bele, miert miért ne?
/me the troll
Na már itt is a rokonok :)
ne adj nekik ötleteket. egyébként a journal azért van benne mert:
én nem szertem a systemd. együtt élek vele, de szerintem úgy tolják mintha egy vállalat lenne. ez van, ezt kell szeretni.
olvastátok a manuálját? na az kész őrület. a 'disable' nem tiltja le véglegesen a cuccot ahhoz maskolni kell és így tovább.
a binális idító állományokkal az a baj, hogy ha valami hiba van benne, te nem tudsz belenyúlni hogy javítsd vagy át paraméterezni. vagy fordítasz újat vagy vársz a javításra ami sokszor nem kivitelezhető.
vlamint, nem otthoni gépeken, kit érdekel a boot idő. komolyan, milyen rendszer tervezés az ahol a boot idővel számolni kell. egy fürtözött szolgáltatásnál nem lesz@rom hogy 4 vagy 8 perc amíg a node feljön? addig a többinek bírni kell a terhelést.
szóval szerintem hogy a RH 7 már systemd használ..... hát...
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
Hát a boot időt én otthoni gépen is leszarom mióta SSD van. Szűz boot + belépés + wifi-hez csatlakozás hamarabb megvan, mintha standby-ból visszahozom, aztán másodpercek alatt észreveszi hogy nincs az AP-hez csatlakozva, aztán nagy kegyesen felcsatlakozik rá.
A szerver meg úgyis tetvészkedik pár percet mielőtt elindulna a boot folyamat, szóval ott se túl kritikus hogy 270 sec vagy 280 sec egy reboot...
pontosan. szóval a csodálatos systemd csak a programozóknak jó. én személy szerint nagyon nem szeretem.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
Nyilván, mert csak a programozóknak kényelmes pl. a multi-seat support (pl. minden korszerű disztóban ott van a Pluggable USB-s multi-seat cuccainak a támogatása Gnome-al különösen - ez a másik oldalon külön OS-t igényel (Windows MultiPoint Server) CAL-okkal, btw.), az erőforrás kezelés, a processzek hatékony követése és kezelése, a szolgáltatások on-demand indítása és az összes többi felesleges szutyok. Rohadt programozók, hogy így ránk akarják erőltetni a szutykaikat. Fúúj.
Boot-idő, az... (hint: BEVALLOTTAN egy pozitív MELLÉKTERMÉK, soha nem volt cél)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
"Pluggable USB-s multi-seat cuccainak"
Érintheti kb. a userek 0.001%-át. Mindkét oldalon.
Fúj, tényleg, a kurva anyjukat, amiért csináltak egy rendszert, amiben ezt kényelmesen meg lehet oldani. Ami miatt mondjuk random helyen, ahol hasonló szoftverekkel dolgoznak többen, racionalizálni lehet a számítógépeket (munkahelyek, iskolák stb.) és így olcsóbban fenntartható, környezetbarát stb. rendszereket lehet építeni. Rohaggyanak meg.
A lista többi elemére, esetleg, valami? Vagy azokkal nem foglalkozunk mert fúj systemd és az mindent csak rosszul csinálhat.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Nem érted. Van rohadtsok hátránya (lásd eredeti post) te kimeltél pár előnyt én meg az egyikről leirtam, hogy kb senkit se érint. Ezért az előnyért biztos, hogy nem kell szivatni a maradék 99.999%-ot.
A többiről előnyről meg mindenki eldöntheti, hogy megéri-e neki a sok hátrányt, azok már nyilván több embert érinthetnek.
Systemd nélkül nem lehet megoldani linuxon a többuseres géposztást? (windows-ban license korlátozza csak)
Akkor még egyszer: milyen technikai hátránya van? (most tekintsünk el a "jaj-gonosz-[RedHat/Lenard/KiskutyaAkiLepisiliAFalat]-összeesküdtek-és-ki-akarják-sajátítani-a-Linux-ökoszisztémát" című dolgoktól ami az eredeti poszt)
Windows-ban sem csak licensz korlát van, külön, erre készített Windows verzió kell hozzá - ezt Lenard-ék (csak azzal, hogy kaptak egy pár próbaeszközt a Pluggable-től) megoldották, hogy bármilyen Linuxon, bármilyen DE-vel, ami követi az ajánlásaikat (http://www.freedesktop.org/wiki/Software/systemd/writing-display-manage…), működjön. És igen, systemd nélkül is meg lehet ezt csinálni korábban és a mai napig is: kártyavárazással, kezdve onnan, hogy kézzel kell összeszedegetned a hardware azonosítókat, a bennragadt processzek azonosíthatatlanságának a problémájáig (ezt a logind oldja meg a user slice-ok létrehozásával). Továbbra is: a systemd "csak" elkezdte kihasználni a kernelben levő lehetőségeket (igen, ezzel bukta a portolást, ez van) hogy olyan infrastruktúrát építsen ki, amikkel ezek megvalósíthatók.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Milyen bináris indító állomány? A systemd executable-re gondolsz? Az valóban az, de a SysV init beli init is az volt. Vagy arra, hogy nem kell 160+ soros init script mindenhez, hanem egy SZÖVEGES konfigurációs állományban leírod 5-10 sorban ugyanazt?
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Boot ido szamit a cloud-ban.
Nem mindegy menyi cpu ido pazarolsz arra, hogy egy uj node munkaba aljon.
Nem mindegy mennyire elore kell tudodnod, hogy tobb nodra lesz szukseged.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
+1
Illetve azt se teljesen értem, hogy minek bele DHCP kliens.
Mindazonáltal még mindig jobbnak tartom mint a SysV Initet. Gyorsabb, a szkriptek nekem átláthatóbbak, tetszik a függőségkezelése. Viszont csak user vagyok, nagyon ritkán kell belenyúlnom.
Az nem kifejezetten a systemd, hanem a systemd-networkd - ami messze opcionális, csak egy ifup replacement ha a teljes NetworkManager azért sok lenne. (A DHCP szerver meg majd a systemd konténerekhez kell)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Az a networkd tényleg nem rossz, csak azt is minek a systemd-vel együtt szállítani? Jó, mondjuk így ha kell, ha nem, fel lesz telepítve, mint az összes többi bloat.
systemctl stop systemd-networkd.service && systemctl disable systemd-networkd.service
'oszt problem solved. (de pl. az openSUSE Factory-hoz elérhető systemd 210-ben nem is látom a networkd-t)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Értem én, hogy nem kötelező használni, de akkor is, miért nem lehet ez is egy önálló project? Akkor talán akinek tetszik, használhatná systemd nélkül is, ha olyanja van. Ez az árukapcsolás nagyon gáz már, és nem látni a végét, hogy mikor mondják azt, hogy na, ezt már mégse ide kéne tenni.
Akkor ez nem systemd, hanem arch döntés, aminek nem örültem. Ott régebben a netcfg volt egy nagyon jól használható konzolos hálózatbeállító eszköz, ezt nagyrészt leváltotta a networkd. Persze érthető, miért dolgozzanak ezen az arch-osok, ha valaki megcsinálja ugyan azt, kicsivel bonyolultabb szintaxissal.
Ezt ugyan biztos megvalaszolja egy FAQ, de ime egy ravezeto kerdes: hogyan oldanad meg, hogy egyreszt elkapd az early boot loguzeneteket ASAP, a daemonok stdout/stderrjet, es mellesleg upgradekor ne legyen logvesztesed?
(Mellesleg amig nem kozpontositot logolast hasznalsz, journal > syslog. Ha kozpontit, akkor meg nem valtozott semmi.)
--
|8]
Nekem csak a bináris loggal van bajom. Sőt igazából csak a journalctl-lel, lehet csak valami használhatóbb logolvasó kliensre volna szükségem.
Pedig jo az. Szoveges loghoz is kell egy hasznalhato logolvaso, anelkul se fule se farka nem lesz. :)
Cserebe Journal indexelt, tobb info van benne, es sokkal gyorsabb keresni benne.
--
|8]
Mondjuk amíg elindul a logger, addig gyűlik valahol? A systemd hová teszi, amíg nem indul el a journald? Azért ezt meg lehet oldani anélkül, hogy az init részévé tennél egy loggert. Ha meg valakinek a mániája a bináris log, indíthat nyugodtan bináris loggoló projectet, de így ráerőltetni mindenkire, mert tudja, hogy neked ez kell, kissé szemét dolog.
Olvasd el a tobbi requirementet is, ne csak a korai gyujtest. Azt tenyleg meg lehet oldani maskepp, bar nehez ugy, hogy nem az inittel szorosan egyuttmukodve.
Egyebkent ez systemdben ugy van megoldva, hogy systemd maga csattan ra a /dev/log-ra, o tartja nyitva az FD-t amig a Journal el nem indul. Ez a legkezenfekvobb megoldas egyebkent, amivel nem kell kolosszalisat szopni, hogy a corner caseket lekezeld.
A binaris log meg messze hatekonyabb, mint szovegben greppelni. Aki 2014-ben logot kezzel greppel, celeszkoz helyett, az valamit rosszul csinal.
--
|8]
Nem ugy van az, h okosabb meghagyni a hujenek a valasztas lehetoseget? Nyilvan, ha van vmi, ami telefossa a logot (mondjuk apache), ott nem feltetelenul az a jo, de a napi nehany szaz soros log grep-elesevel mi faj?
Ez a valamit rosszul csinál kicsit olyan mint amikor a gépklónozást szólták le, mert aki nem puppetet (vagy valami hasonlót) használ az már nem is ember. Aztán lehet hogy mégis, csak mások a feltételek, körülmények, elvárások.
Kivancsian hallgatom milyen esetben praktikusabb es/vagy hatekonyabb a grep, mint a journalctl, vagy barmilyen mas celeszkoz. (Nyilvan van egyebkent kivetel, de nem az az altalanos.)
--
|8]
Két féle választ adnék. Egyik a szőröző, szó szerinti:
"logot kezzel greppel" - "mások a feltételek" - "esetben praktikusabb"
Minden olyan esetben, amikor az alkalmazás saját logot ír, saját formátummal és agybajjal. A céleszköz meg nem biztos hogy adott a gépen amin épp matatni kell, míg a grep és társai azért gyanítható. De nyilván nem erről van szó, nem is akarom ebbe az irányba elvinni a dolgot, bár remek értelmetlen vitát lehetne belőle szítani.
A másik az érdemi, mert nyilván nem az egyedi esetekről van szó(*): szerintem nagyon sok helyen sokkal fontosabb szempont a visszafelé kompatibilitás a meglévő és működő rendszerekkel, mintsem az, hogy fancy céleszközökkel lehessen sokkal hatékonyabban csinálni valamit, vagy hogy egy új megoldásból, új eszközökkel lehessen előállítani a visszafelé kompatibilis adatot (a jelen esetben a logfájlokat).
És még egyszer, nem állítom hogy a grep a legjobb megoldás, de az, hogy valaki valamit rosszul csinál... hát picit túlzásnak érzem.
*) bár én, mint üzemeltető, olyan sok egyedi esettel találkoztam már, hogy néha azt hiszem, hogy az egyedi esetek az általánosak :) Gondolom másnak is van hasonló érzése.
+1
Számomra az a negatívum a céleszközökben, hogy nem járulnak hozzá a rendszer egyszerűségéhez, hanem tovább növelik a komplexitást. Ez az ára a további hatékonyságnak. Viszont nem érdemes szerintem kijelenteni, hogy mindig minden helyzetben megéri ez az ár. Van amikor nem.
Ilyen alapon tovább lehetne fejleszteni sok területre további céleszközöket. A végén rohadt sok céleszköz lenne (lásd windows a millió shareware cuccal), melyeket nem is biztos hogy össze lehet kapcsolni igény szerint. Nagy valószínűséggel elfejlődnének olyan irányba, amely már független az eredeti problémától, és további inkompatibilis és különböző interface-ek jelennének meg, melyek megint rátesznek egy lapáttal a bonyolultságra. Ezekhez lehet hogy megint további céleszközök kellenének a hatékony kezeléshez vagy összekapcsoláshoz.
Nem azt mondom hogy ne fejlődjön valami, de gond az ha további egyedi megoldást visznek be a rendszerbe a többi elemmel való összekapcsolhatóság és visszírányú kompatibilitás nélkül. Márpedig nagyon ez a gyakorlat ahogy láthatjuk sok esetben. És ez konkrétan probléma. Egy speciális dolgot megold, sokat meg megoldatlanul hagy. Pl. mi van ha a célszoftver keresési feltételek által adott eredményeiben akarok greppelni vagy azt tovább szűrni valamilyen módon?
Szerk.:
A vége meg az, hogy van rohadt sok "jó" eszköz, csak alig van aki használja.
Egyébként meg lehetne szerintem tömni az egyszerű eddig eszközt is további tudással, és akkor nem veszne az egyszerűség és kompatibilitás. Pl. grep-et felokosítani kern.log tudással stb stb. Nem feltétlen ezt, de hasonlót jobb megoldásnak tartanék.
-1
Egész pontosan hány általános eszközt kell összetákolnod ahhoz, hogy egy log fájlból kigyűjtsd mondjuk a tegnap előtti, adott szolgáltatáshoz, adott szintű naplókat? És ha ugyanezt pl. csak locale-k közt hordozhatóra akarod megírni? Hány olyan projekt is van netszerte, aminek a célja, hogy a /var/log/*-ból kereshető, érdemi információkat gyűjtsön ki?
És a journalctl nem veszi el ezen eszközök használatának a lehetőségét, ha akarod simán bepipeolod a teljes naplót amibe akarod: viszont hatékonyabbá teszi a naplókkal való foglalkozást.
A másik oldal, a visszafelé-kompatibilis fejlődés: a systemd valóban nem A tökéletes init-rendszer, de pl. többnyire kompatibilis visszafelé a SysV init-tel. Viszont nagyon sok jól kitalált plusz eszközt ad mint a fejlesztő, mint az üzemeltető kezébe: számold meg, hogy a gépeden futó random démonok közül hányban különböző képpen implementálva a chroot-olás, a jogosultságok eldobása stb. És hogy ezt hányféle módon kell konfigolni. És így jutunk el oda, hogy az egyszerű rendszerhez kell egy 160 soros shell script sablon(*), amit minden egyes szolgáltatáshoz másolgatni kell. Plusz munka a fejlesztőnek (már ha foglalkozik vele), a csomagkészítőnek, az üzemeltetőnek (csak úgy fejből: random démon önmaga dobja el a privilégiumait, vagy egy köré tett shell script? Önmagát zárja be, vagy köré tett shell script teszi?), stb. ...és figyelj, az új, systemd-specifikus feature-ökről [pl. kényelmes cgroup támogatás, erőforrás limitálás, mindenféle aktiválás stb.] egy szót sem szóltam!. Ugyanez van a journalctl-el: Turing teljes a bash, meg lehet benne írni N+1. alkalommal is azt a szűrőt, de ha meg lehet oldani hatékonyabban, jobb eszközökkel, EGY HELYEN, akkor miért ne?
BlackY
(*): Debian initscripts csomagban levő /etc/init.d/skeleton
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
"akkor miért ne?"
Mert ez az érv, hogy "miért ne?" nem érv. Illetve persze, érv, de nem ott, ahol az elsődleges (és a másodlagos is) szempont a rendszerek üzemeltetése.
Van egy komplex rendszerem, hozza a max. kiesés 10%-át. Az átállással, ami munka, tehát költség is, elérem azt, hogy a kiesés lecsökken... vagy nem.
Nyilván vannak olyan helyzetek, ahol viszont egy váltás (és nem feltétlen a jelen systemd-sysvinit, hanem bármilyen), az mérhető előnyökkel jár. Az egy másik történet.
Nekem pl. régi vágyam - és nem találtam még rá megoldást - hogy riasztást kapjak arról, ha egy kolléga pl. új IP tartományból jelentkezik be az IMAP szerverre. Tehát nem otthonról, sem az irodából, hanem hirtelen pl. egy kínai címről. Egy jól strukturált bináris loggal, ami külön mezőben tartalmazza a loginnevet és az IP címet, ez már nem is olyan nagy puki, bár még mindig tákolni kell rajta, hogy ebből riasztás legyen, de az már könnyebben megoldható.
Átfogalmazom, a 'miért ne' tényleg rosszul veszi ki magát: végre van egy rendszerük, ami kihasználja az alsóbb réteg (kernel) lehetőségeit, modern IPC-t használ és nyújt (oks, a D-Bus nem igazán systemd találmány, a kdbus már inkább, de eléggé használja), van rengeteg könyvtáruk (mind publikus, mind "belső"), amikkel egyszerűen fejleszthetők az ilyenek - pusztán azért, mert már rendelkezésre áll az alsóbb réteg és nem több projektet kell összefogni egyszerű feladatokhoz .
Triviális példa: loginctl és a multi-seat esete - igen, saját udev szabályok faragásával, a nem fejlesztett ConsoleKit konfigolásával és raklap bash kóddal. Vagy, mivel megvan hozzá az alapozás (pl. processzek követésére a slice-ok, az eszközök hozzáadására/eltávolítására a udev stb.), megoldhatják ők maguk, lényegesen kevesebb karbantartandó kóddal. És igen, lehet, hogy ehhez kell pár sornyi kód a DM-be, hogy ki is használja (lásd: Gnome, a KDE pl. egy időben tervezte dobni a KDM-et, mert túl régi és túl sok munka lenne kitakarítani), cserébe nem 10 projekten átnyúló konfigturkálás következik.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Lehet hogy nem is a céllal van a baj hanem a megvalósítással.
Személy szerint rengeteg szoftverből hiányolom az egyszerűséget. Tudjon sokat, de faragják már össze úgy, hogy biztosítson egy faék interface-t is, amely egy jól átgondolt módon mutatja az alap lehetőségeket - vagy biztosítja az elérését ezen alap dolgoknak man túrás nélkül meg powershell-re hajazó km hosszú paraméterekkel. Na ez nagyon nincs meg szerintem.
És hiába a szuper API meg alrendszer, ha a managelése szar. Ez két külön dolog. És mindkettőnek jónak kellene lennie.
Mi az, ami bonyolult a journalctl-ben?
Komolyan, példa: szűrjük ki a rendszer naplóból az sshd üzeneteit.
Szemben:
Tényleg az az egyszerű és jó interfész, aminél kell egy Turing teljes programozási nyelv és reguláris kifejezések egy egyszerű lekérdezéshez?
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Lásd lejjebbi hozzászólás.
Illetve eleve minek a --unit kapcsoló? Na mindegy. Nem a humán oldalt segíti, hanem a gépit.
Úgy tudom megfogalmazni amit mondani akartam a fentiekkel, hogy szarul van megcsinálva a CLI interface. Ez a bajom. Márpedig ez a legfontosabb, mert ezen keresztül kell turkálni.
Mert egy awk script megírása tényleg humánusabb...
Mondjuk az azért sem mindegy, hogy egyszer megtanulom a grep/awk-t, és tetszőleges szolgáltatásnál ugyanúgy, vagy 77 izénél 77 hatkékony eszköz egyedi szintakszisát kell kb fejben tartani...
"új IP tartományból jelentkezik be az IMAP szerverre"
SIEM rendszerek tudjak ezt neked okosan :)
Gyanítottam hogy nem olyan dolgot találtam ki, amit még senki más. De ezért az egy dologért nem akarok olyan rendszert telepíteni, aminek amúgy ez csak egy apró funkciója. Plusz nem akarom kifizettetni a céggel.
Pláne hogy minden információ adott a számomra, csak egyszer neki kéne ülni és megkalapálni.
De én vagyok a hülye... legközelebb olyan gyakornokot kérek aki amúgy kóder és megíratom vele... hogy erre miért nem gondoltam már évekkel ezelőtt... ehh...
Szerintem a grep is egy eszköz. És ne az init döntse már el, hogy mit használok logolásra. Legközelebb mit tesznek bele? A waylandet?
Már megint egy ötlet nekik! :-)
Mondjuk inkább írnak egy systemd-displayserverd-t, vagy mit :)
keresed szamukra parancs, tessek: http://www.phoronix.com/scan.php?page=news_item&px=MTc2Nzk - Systemd 216 Piles On More Features, Aims For New User-Space VT
A grep nem hatekony eszkoz erre. Es nem, nem donti el, mit hasznalsz logolasra. Ugyanugy hasznalhatsz syslog-ot, a Journal folott. Mindossze az valtozott meg, mi van alatta: nem kozvetlenul a kernel, hanem egy userspace program. Ennyi.
(Es mivel a Journal alapbol nem perzisztens, meg helyet se foglalnak a nem hasznalt Journal logok, csak egy keves memoriat.)
--
|8]
És ha én olyan hülye vagyok, hogy csak a grepet akarom használni? Vagy nekem az a kevés memória is számít? Vagy egyáltalán nem akarok logolást? Vagy ha én FreeBSD-n akarom használni, mert annyira tetszik? Hagy döntsem már el, hogy mi a jó nekem...
Én nem azt mondom, hogy nincs létjogosultsága a journald-nek, hanem azt, hogy nem kell árukapcsolással eladni. Ha olyan jó, akkor úgyis elterjed. Persze gondolom a RedHat support már megunta a sok okos admin által használhatatlanra beállított rsyslogot, és jött az ötlet, hogy akkor már legyen bent valami, ami mindig működik, és senki nem fog a kikapcsolásával szenvedni.
Ja, még egy, ami eszembe jutott, cron is van benne, de persze nem tudja az összes funkcionalitást, amit az eredeti, pl. hét egyes napjaira nem tud időzíteni. És kérdem én, ez minek?
Nem értem, miért megy a vita azon, hogy grep vagy nem. Ilyet lehet csinálni:
journalctl | grep 'regexp'tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Amit írtál, journalctl nélkül század mp alatt lefut, abból pipe-olva meg ~5 sec alatt nálam. Ez a megoldás biztos hogy kilőve.
Egyébként a man page meg egyébként a paraméterezés egy katasztrófa. Ezt komolyan gondolták innovációnak humanoidoknak?
journalctl _SYSTEMD_UNIT=avahi-daemon.service
Mi van ha az összes olyan log-ot látni akarom, amelyben szerepel az avahi kifejezés? grep helyett tud valaki hatékonyabb és _egyszerűbb_ eszközt mutatni? Mert mindig osztom a hatékonyságot az egyszerűséggel. Hiába az előbbi ha nincs meg a másik.
Én most azt próbálom kitalálni, hogy hogyan találom meg journalctl-el hogy egy user az adott napon kapott-e emailt. Mármint grep nélkül. Olyat keresek - egyébként - hogy milyen mezők szerepelnek a logokban, ezek azok?
http://www.freedesktop.org/software/systemd/man/systemd.journal-fields…
:D tudod mikor fogom ezeket fejben tartani...
Ez különben megint olyan számomra, mint Python kontra Ruby (Python bántása nélkül): Matz azt írja, hogy olyan nyelvet akart tervezni, amiben arra törekedik, hogy jobban segítse a humán oldalt, és ne a gépit. Python-nál fordított irányba mentek; a gépi oldal (interpreter) segítéséhez vezettek be dolgokat, pl. a sima print helyett zárójelezni kell azt is meg mindent stb. Tehát humán oldalról nehezebb és kényelmetlenebb lett.
Systemd-nél dettó ezt látom. Értem hogy jobb több szempontból meg jobban programozható, de abból a szemszögből amit most te felvetettél - nem találom jobbnak. Mert nem egyszerűbb. Ha úgy csinálják meg hogy amit felsoroltak tudja, és mellette egyszerű marad, akkor le a kalappal. De nem ez van szerintem.
Najó, de anno aix-on is az volt a bajom az errpt-vel (asszem), hogy abban is úgymond kézzel kellett keresni. Bár tény, hogy túl keveset dolgoztam aix-on, és néha nagyon-nagyon hiányzik pár finom dolga. Na nem baj, majd frissítem az itthoni masinát, úgyis komplett diskcsere lesz, és majd meglátom.
":D tudod mikor fogom ezeket fejben tartani..."
Nem is kell, a scriptet egyszer akarod megírni, nem? Egyszer rászánni 5 percet hogy elolvasd a dokumentációt igazán nem nagy energiabefektetés.
A print -> print() váltásnak semmi köze az interpreterhez. A valódi magyarázata itt elolvasható.
--
♙♘♗♖♕♔
Nem akarom leszólni, de a magyarázat sem jön be nekem a váltásra, meg a szintaxis sem.
Egyébként pont arról szól a magyarázat megint, hogy az interpretert fejlesztő oldalt segítség. Tehát ne a humán kódert. Ruby-nál pont fordított erőfeszítések vannak (meg Matz alapból ezt az irányelvet deklarálta). Nekem ezek fő prioritások egy nyelvnél.
De nem flame-nek szánom. Elfogadom hogy így jobb nekik.
Jó, de amíg a rubyt eleve úgy találták ki, hogy kb. bármit bárhogy leírhass benne, addig a pythont pont ellenkezőleg, rákényszerít egy szigorú szintaktikára annak érdekében, hogy minden python kód ugyanúgy nézzen ki. Ebből a print pont kilógott, szerintem jó döntés volt függvénnyé tenni.
Feladathoz eszközt... egyébként meg... Unix alapelv: pipe. journalctl | grep...
Semmi akadálya, portold az összes kernel feature-t, amit eddig senki nem használt, mert nem POSIX, viszont amitől használható lett a systemd...
Viszont cserébe garantáltan ugyanúgy fogja indítani a szolgáltatásokat, mint ahogy az init teszi - mert egész pontosan ő fogja tenni. Szemben a kártyavár: ott van a Monit, nagyon jó program, hasznos (az ilyen aktív monitorozást spec. hiányolom is a systemd-ből), FAQ: inkább kapcsold ki az init.d-vel indított szolgáltatásokat és hagyd, hogy a monit indítsa őket. Vagyis: egy technikai deficit miatt (gyk.: nincs összefüggés processz és service között) bizonyíthatóan lehetetlen race-free módon megcsinálni valamit, ezért a megoldás, hogy kihúzzuk azt a rendszert, amivel mindenki számol (és amiért mindenki oly nagyon sír - a SysV-t) és helyettesítjük egy kicsit mással. Systemd mellé (és le merem fogadni, hogy nemsokára lesz rá projekt) egyszerűen lehetne ilyen monitorozó ügynököt írni: lefuttatja a tesztet, ha nem jött be, D-Bus-on szól a PID 1-nek. Ezért kell árukapcsolás: feleslegesen duplikált (és karbantartott, auditált stb.) kódok helyett moduláris, de egy ernyő alá tartozó rendszermenedzser.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Jó, ne a grepen lovagoljunk már...
A journalhoz meg milyen hatalmas kernel featurek nincsenek meg vajon a FreeBSD-ben (nem ismerem, én nem tudom)?
Ha moduláris lenne, akkor lehetne hozzá kapcsolódó projectekben megvalósítani a logolást, a cront, meg még ki tudja mit, amikre nem is gondolok most, nem kéne egyben az ember nyakába önteni mindet, akár akarod, akár nem. A monithoz már volt szerencsém, ott ha kell neked ez a monitorozó izé, akkor használod, ha nem kell, akkor nem. A sysv init ilyet tényleg nem csinál, és ezt mondjuk tényleg intézehetné a systemd (mint mindent, ami egy service elindításával, menedzselésével kapcsolatos), ehelyett log, cron, hálózatbeállítási, meg még a jó ég tudja, milyen feladatokat pakolnak bele.
Nekem tetszett maga a systemd, és a service managelési megoldásai, de amikor a journalt belerakták, ott kezdtem el arra gondolni, hogy remélem ezt az ámokfutót leállítja valaki. (Ja, igen, van valami time service is benne, hát az is nagyon fontos...)
Triviálisan a cgroup: a systemd/journald/journald-server.c több függvényt hív a cgroup-util.c-ből.
A modularitás alatt azt értettem, hogy ha megnézed a http://cgit.freedesktop.org/systemd/systemd-stable/tree/configure.ac?h=… fájl alján, lehet látni, hogy melyik systemd komponensek azok, amiket configure szintjén ki lehet ütni (a journald valóban nincs köztük).
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Én úgy nézem, azt csak azért teszi, hogy legyen _SYSTEMD_CGROUP és még egy pár mező a metaadatok közt. Nem hinném, hogy ez portolhatatlan. De így, hogy egybe van csomagolva a systemd-vel, ki fog ezzel szórakozni. Vagy mi van akkor, ha valaki írna egy még jobb log rendszert, ami ráadásul multiplatformos? Mivel mindenhová be lesz drótozva a journal, a kutya se fogja használni.
Meg pl. a _SYSTEMD_UNIT, amivel szolgáltatáshoz tudod kapcsolni.
A journal leginkább csak a systemd-be van bedrótozva, random app nem nagyon fogja a natív journal protokollt beszélni (ők továbbra is syslog-olnak). Ha pedig arra gondolsz, hogy itt árukapcsolással irtják a konkurenciát: eddig is volt jó néhány log server, amik egymással "versenyeztek", most lesz még egy - senki nem tiltja, hogy a journal helyett/mellett/felett rsyslog-ot, syslog-ng-t, ... használj.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Meg pl. a _SYSTEMD_UNIT, amivel szolgáltatáshoz tudod kapcsolni.
Ilyeneknél kell a portnál kitalálni valami okosat (elsőre nyilván elhagyni).
A journal leginkább csak a systemd-be van bedrótozva, random app nem nagyon fogja a natív journal protokollt beszélni
Pedig ha születne egy ilyen struktúrált log API, talán még használná is bármilyen random app, de így, hogy csak systemdvel lehet, nem is baj, hogy nem cuppannak rá a fejlesztők.
senki nem tiltja, hogy a journal helyett/mellett/felett rsyslog-ot, syslog-ng-t, ... használj.
A többség meg nem fog két log démont futtatni, csak kényszerhelyzetben, ha már nem elég a systemd megoldása. Aki nem akar központi loggolást, annak "elég jó" lesz a journal is. A helyette sajnos meg nem játszik, lévén teljesen nem lehet kiiktatni.
Az is lesz előbb-utóbb: http://fedoraproject.org/wiki/Changes/Remote_Journal_Logging
A helyette meg annyiban játszik, hogy simán átküldöd a journal-t egy syslogba (ForwardToSyslog) és letiltod a tárolást (Storage=none)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Ez végképp kivégzi a syslogot systemd-s rendszereken. Persze lesz egy-két renegát régi motoros, aki még ideig-óráig fogja használni, aztán szépen elfelejtődik Linuxos körökben. De én remélem, hogy inkább a journal fog kikopni a systemd-ből.
apt-get install sysvinit-core systemd-sysv-
Ez egyreszt nem opcio olyan rendszereken, ahonnan a sysvinitet mar kiirtottak. Masreszt akkor sem opcio, ha olyan programot akarsz hasznalni, ami systemd szolgaltatasokon dependal.
--
|8]
Nem igazán értem, mi ez a lázadás a systemd ellen. Nem vagyok üzemeltető, ezért egészen mások a szempontjaim nyilván, de Fedorán talán 3 éve van már systemd, eddig nem volt vele különösebb problémám.
Illetve érteni vélem, mi a probléma. A Debiant is elérte a systemd, s felkavarta az állóvizet. :) A systemd-vel talán egy bajom van, hogy nem tanultam meg, de azt érzékelem, hogy remek lehetőségek rejlenek benne. Ha majd reszelnem kell valamit, úgyis utánaolvasok.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
A systemd szerintem egy egész jó ötlet nagyon nem jól megcsinálva. Főleg a *ctl eszközök és a config állományok.
Persze majd beletanulunk. És lehet majd meg is szokjuk.
Csak abban nem bízom, hogy stabil lesz. Ez az ami a sysV-ben megvolt. A faék bonyolultság egy ilyen kritikus rendszerelemnél szerintem amúgy is előny. Bár talán mindenhol az.
Illetve nem igazán tetszik ez a mostanság divatos mindent-összedrótozunk-mindennel dolog. Settingsdaemonok és egyébb perverziók.
részemről egy alkalmazás a beállításait tárolja vagy /etc/xy -ban vagy ~/.config/xy -ban lehetőleg .ini vagy .json formában (az XML kedves ötlet de halál kézzel írni)
a /usr/share/X11/xorg.conf.d/ egy rossz vicc.
És nem kell feltétlen 2^30 mennyiségű config file sem.
A *NIX filozófia egy jó dolog. És ha már *NIXra fejleszt az ember akkor esetleg érdemes követni.
### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch
'(az XML kedves ötlet de halál kézzel írni)'
yaml
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
Az is simán megteszi. Mivel könnyű kézzel írni, és szemmel olvasni.
### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch
Az "igazi UNIX", az OS X, launchd és az egyszerűség jutott eszembe így egyben.
--
trey @ gépház
sub
The tasks mentioned that systemd already covers include, "init system, journal logging, login management, device management, temporary and volatile file management, binary format registration, backlight save/restore, rfkill save/restore, bootchart, readahead, encrypted storage setup, EFI/GPT partition discovery, virtual machine/container registration, minimal container management, hostname management, locale management, time management, random seed management, sysctl variable management, and console managment."
Tasks being worked on are support for a local DNS cache, mDNS responder, LLMNR responder, DNSSEC verification, IPC support in the kernel (KDBUS), time synchronization with NTP, better integration with containers, and many other services.
Hát ez kész...