Ha neked elég az ASCII log, akkor több lehetőséged is van azt használni. A világ elég jó részének nem optimális, mert túl komplex (igen - egy JSON logban szűrni sokkal egyszerűbb).

A probléma az, hogy azt gondolod, hogy egy sztékes helyen ülsz, de a többiek azt látják, hogy egy enyhén pityókás, morcos bácsi morog a Hawaii bowl-os helyen valami olyasmiről, hogy ez régen egy jó grillező volt, és követeli, hogy neki adjanak rendes húst

[ Szerkesztve ]

while (!sleep) sheep++;

Egy sérült ASCII log még olvasható, egy bináris már nem feltétlenül. Mindenben egyetértek bambano-vel. Én mondjuk unixokon nőttem fel, sokáig csak otthon használtam linuxot, és elég korán (bőven a systemd előtt) beláttam, hogy a linux a unix windows-a. Ez a véleményem azóta se változott, sőt!

-=- There's no place like /home -=-

A JSON is ASCII
De egyébként vannak olyan flat file db formátumok, amik közel ugyanolyan jól dolgozhatók fel, mint a bináris fájlok, ellenben ember által is olvashatók. Van némi overheadjük ugyan, de az elhanyagolható.

Nem olvashatók ember által, mert ahhoz is beépített eszközök kellenek...

Le tudod írni, hogy mi az a use case, ami journallal nem megoldható vagy nagyon nehéz, a régi fájlonkénti text logokkal pedig könnyű? Ellenpéldat tudok mondani.

Nem ASCII egyébként.

[ Szerkesztve ]

while (!sleep) sheep++;

Egy szimpla ASCII fájl olvasásához bármilyen text editor jó, ami kéznél van. Nano, pico, joe, emacs, vi, vim, nvim, akármi. A journalt legfeljebb a journalctl-el tudod olvasni.

Le tudod írni, hogy mi az a use case, ami journallal nem megoldható vagy nagyon nehéz, a régi fájlonkénti text logokkal pedig könnyű? Ellenpéldat tudok mondani.

Írták már, ha pl. megsérül a diszk, a bináris logot nehezebb helyreállítani. Vagy ha maga a journald crashel, cseszheted a logokat. Vagy ha egy szép napon Poettering azt mondja, hogy bocsi, most megváltoztattuk a journalctl-t, nem kompatibilis a régi logokkal...

Oké, menjünk éttermi hasonlattal.
Régen volt mindenféle étterem, majd jött a maffia, mindet erőszakkal átvette, és azóta mind vegán étterem. De az ételt mindig elsózzák és kozmás.

Tehát ne csak azt az állításomat figyeld, hogy a unix filozófiájának nem felel meg a systemd, hanem azt is, hogy egyébként a systemd jelenlegi állapotában egy bughalom.

Más: az előbb jutott eszembe, míg szűkös magányomban agyaltam ( ), hogy a legújabb gyerekvédelmi szabály(tervezet) fényében a systemd-resolvd nem törvénysértő?

Alaposabban belegondolva mondhatjuk, hogy a tailscale a saját megoldása miatt erősen elfogult, tehát az, hogy szerintük mi a jó dns rezolválás, messze van az általános objektív valóságtól.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Egyébként a sudo legtöbb sebezhetősége ilyen snassz buffer overflow és hasonlók voltak, ilyesmik ellen meg nem véd a systemd sem (főleg, hogy azt is C-ben írták).

Kell hozzá a SUID bináris, az a fő gond. Ha nincs SUID bináris máris sokkal kevésbé problémás pl. egy buffer overflow.

A SUID/GUID koncepció lehet, hogy rossz, de erre vannak módszerek a különféle LSM-ek képében, mint pl. a SELinux és az AppArmor. Védekezzünk egy szar architektúra ellen ágyúval? Az SELinux egy katasztrófa, borzalmasan nehezen konfigurálható. Az AppArmor egy fokkal jobb, de azt is adott rendszerre kell belőni.

(#34044) sh4d0w Volt nem túl régen olyan projektünk amit valami ruszkik gányoltak SysVinit-el, na az egy kalap fos volt. Közben Yocto-s embedded rendszeren systemd-vel annyi egy unit fájl, hogy megírod a service fájlt (aminek eléggé RTFM manuálja van) és "inherit systemd".

Ezek ilyen filozofalgatasok, neked ez az elkepzelesed az Unixrol, masnak meg mas. Es jelenleg akik alakitjak a Linuxot, ok mashogy akarjak.

> Alaposabban belegondolva mondhatjuk, hogy a tailscale a saját megoldása miatt erősen elfogult, tehát az, hogy szerintük mi a jó dns rezolválás, messze van az általános objektív valóságtól.

A Tailscale szeretne valamit megvalositani. Olyasmit, amire oriasi igeny van. Az oprendszernek nem az a feladata, hogy valami filozofianak megfeleljen, hanem hogy lehetove tegyen kulonfele use case-eket. A dinamikus DNS konfiguracio fontos. Ezt resolv.conf hekkelessel nem tudod elegansan es robusztusan megoldani.

while (!sleep) sheep++;

egyébként meg ha nem ezt a túlmodernizált módszert tolod, hogy mindent sudo-val, akkor nem kell sudo és nincs a sudo-val biztonsági probléma.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Journalt is tudod massal olvasni. Egyebkent meg journalctl-t pipeolhatod vim-be, ha akarod.

> Írták már, ha pl. megsérül a diszk, a bináris logot nehezebb helyreállítani.

Miert lenne nehezebb? A journal formatum append-only, ugyanugy helyre lehet allitani. Lattal mar eletben ilyen problemat?

Sot, a valosag _pont_ az ellenkezoje. A syslog joval erzekenyebb a crashekre, a journalban atomikus append van, integrity check, tud pl. kriptografikus szignalast (tuti biztos lehetsz benne, h utolag nem nyult valaki bele a logfajlodba).

while (!sleep) sheep++;

nem nekem van elképzelésem a unixról, hanem az alkotóinak. és a teljes rendszert ahhoz igazították. az, hogy csővezeték van, olyan parancssori cuccok vannak, amilyenek, az átirányítás meg a file descriptorok rendszere, mind azt mutatja, hogy szöveges feldolgozásra optimalizálták a kernelt. minden más elhajlás. jelen esetben indokolatlan és helytelen.

ha az operációs rendszer nem felel meg az eredeti, alapvető tervezési filozófiájának, akkor katyvasz lesz belőle. lásd még: m$

majd meglátjuk, hogy a dinamikus dns konfiguráció a fontos-e vagy a jogszabály. mellesleg most is dinamikus a konfig, a dhcp kliens átírja a resolv.conf-ot.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

1. Az Unix alkotoinak az elkepzeleseit te is csak ertelmezed, nyilvan a sajat szemszogedbol.
2. Valtozik a vilag, nem kotelessegunk azt csinalni, amit a PDP-11-et hasznalva gondoltak az alkotok. Miert lenne?

> ha az operációs rendszer nem felel meg az eredeti, alapvető tervezési filozófiájának, akkor katyvasz lesz belőle

tok jok ezek a levegobol vett allitasok, nyilvan lehetetlen ertelmes beszelgetes folytatni roluk

> majd meglátjuk, hogy a dinamikus dns konfiguráció a fontos-e vagy a jogszabály

na jo

while (!sleep) sheep++;

Ne haragudj, de ez nem vélmény kérdése. Az egész műszaki világot szabványok határozzák meg, ha nem akkor nem egyéb mint kiscsaj picsogás. van olyan, hogy posix szabvány.

Nem kell feljeszteni azért, hogy fejlesztve legyen. Az meg a minimum lenne, hogy a 21. században a mérnöktársadalom elfogad legalább minimális morális elveket. pl: ha nem romlott el ne javítsd meg, vagy kiss, vagy azt, hogy itt embereknek készülnek a cuccok.

A mérnök tervezzen eszközt az emberek számára és ne a marketinges tervezzel terméket a fogyasztónak.

Nem félünk! Nem félünk! Itthon vagyunk e földön. Nem félünk! Nem félünk! Ez nem maradhat börtön!

A legtöbb Linux nem POSIX certified. A szabványok elsődleges célja az interoperabilitás és a minőségbiztosítás. Ha a termék szabványos, de nem oldja meg a problémádat, akkor nem vagy kisegítve. A systemd olyan problémákat old meg, amire korábban nem volt megfelelő megoldás (legalábbis a Linuxos közösség jó része úgy értékelte, hogy nem volt). De a Linux FLOSS, ezért azt használsz, amit akarsz. Ez a fo elonye, szoval nem ertem a gyaszolast

[ Szerkesztve ]

while (!sleep) sheep++;

Például log forwarding kissé nehézkes volna, remote logelemzésre. Nyilván ez otthon nem jellemzően kerül terítékre. De a rendszered logolási stratégiáját is kacifántosabb így kialakítani, mint a megszokott facility-kkel, ez viszont meg igényfüggő. Logrotálást egyébként hogyan gondolnád a binárissal kivitelezni? Mindent egybe, ahogy a journald odalöki? Az pedig, hogy a journald nyomja a logokat rsyslogba vagy syslog-ng-be, közröhej.

Nem, egy JSON-ban szűrni sokkal kevésbé egyszerű, mint egy plaintext logfájlban, ha minimális regex ismeretei vannak valakinek. A "világ jó részének" azért komplex feladat egyébként, mert a szakma felhígult.

Sajnos a systemd valóban, mint a kolléga fentebb leírta, az ipar szájába lett taposva, és a legkevésbé sem fogadták el örömmel - inkább lenyelték a békát. Nem nagyon látod jól tehát a helyzetet. Ha tetszik, ha nem: a Red Hat diktál, a kutya ugat (a Debian projekten is volt hőzöngés, és lett is Devuan, csakhogy egyébként sok választásuk nem volt, ha az enterprise terepen meg akartak maradni); és aki kicsit is ismeri a nagyobb cégeket, hogy miként tudnak ilyen-olyan projektek felfutni, az gyaníthatja, hogyan is lett sláger a systemd. Annak ellenére egyébként, hogy irgalmatlanul pocsék a dokumentációja a mai napig; hogy teljesen értelmetlenül ráfekszik mindenre; hogy minden pontján jól érezhetően egy önjelölt revolucionista "csakazértisfordítva" szellemben elkövetett alkotása.

Valóban vannak kézreálló tulajdonságai, például épp egy service unitot megírni viszonylag egyszerű. Mondjuk ha ez kicsivel komplexebb, mint xy tech userrel indítani egy httpd-t, és nem kézenfekvő a unit type, akkor már indokolatlanul macerás. Mellesleg sysvinit alatt sem ördöngösség egy service megírása, csak ugye kevésbé olvasmányos, lásd felhígult szakma. Viszont a systemd a KISS diszciplína célzott arculköpése, pedig az ilyesmiket annak idején elég okos emberek találták ki, még ha nem is huszonévesek voltak very senior divatdevops pozícióban 2,5 éves szakmai tapasztalattal. Már magára ne vegye senki terészetesen.

A log forwardingot pont nagyon tudja a journal, resze volt az eredeti celkituzeseknek. A logrotalas detto, hiszen a journal seekable, ergo a klasszikus logrotalasra nincs is szukseg. Logrotalasra alapvetoen azert van szukseg, mert a regebbi logokat idovel kidobjuk helysporolas miatt, es ezt ugy szokas megcsinalni, hogy a fajlokat dobjuk el, mert a szoveges logokban nem lehet egyszeruen ido szerint seekelni, plusz a fajl elejet truncate-elni maceras. A journalnal nincsenek ilyen problemak.

Tehat a journal alapvetoen kozelebb van a KISS-hez, mint a szoveges logfajlok rotalgatasa, mert arra van kitalalva, hogy logokat taroljon (ellenben a sima szoveges logokkal).

> Nem, egy JSON-ban szűrni sokkal kevésbé egyszerű, mint egy plaintext logfájlban, ha minimális regex ismeretei vannak valakinek.

Nem ertek egyet,
1) a komplex regex nagyon lassu tud lenni
2) minden program hajlamos sajat formatumba logolni, tehat egyszerre tobb program logjat szeretned korrelalni/szurni, akkor az seggfajas.

A tobbi filozofalgatas, szoval nem mennek bele.

Nem tudom, h ti mekkora meretu logfajlokkal dolgoztok, ahol en dolgozom, ott ~ terabajt nagysagrendu log van naponta. Ti grep-et es regexet hasznalnatok arra, h keresgeljetek ennyi logban? (Nyilvan mi is hasznalunk regexeket, stb., de nem ugy, hogy bemegyek a szerverre ssh-val, es a syslog fajlokat elkezdem grepelni.)

[ Szerkesztve ]

while (!sleep) sheep++;

Miert lenne nehezebb? A journal formatum append-only, ugyanugy helyre lehet allitani. Lattal mar eletben ilyen problemat?

Igen, láttam ilyet, volt hogy leakadt a SAN, és kb. két és fél órás művelet volt csak az, míg sikerült bebootoltatni a rendszert. Onnantól fogva, vagy vissza tudod varázsolni a journalt, vagy nem, és sok esetben sajnos nem. De amikor a journalctl --verify is csak annyit tud mondani, hogy "invalid argument", na akkor tudod, hogy hosszú napod lesz.

Ez egy kb. 5-6 evvel ezelotti bug, nem? Ez egy bug, nem a journal jellemzoje. Ha a btrfs-nek 2015-ben volt egy data loss bugja, az nem azt jelenti, hogy a btrfs design-ja hibas, es mindenkinek ext2-t kell hasznalnia. Szerintem.

while (!sleep) sheep++;

miért nincsenek olyan macerák a journalnál, amiről azt hiszed, hogy text lognál vannak?

és ti a terabyte nagyságrendű logokat összeöntitek egybe?

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

> és ti a terabyte nagyságrendű logokat összeöntitek egybe?

Persze, hogy keresnél egyébként? Mármint nyilván szénné van indexelve, de nem az van, h van óránként meg szolgáltatásonként egy fájl.

De természetesen strukturált logra van szükség ekkora mennyiségnél.

> miért nincsenek olyan macerák a journalnál, amiről azt hiszed, hogy text lognál vannak?

Mondj egy konkrét példát, és beszélhetünk róla. Legyen mondjuk a log rotation?

[ Szerkesztve ]

while (!sleep) sheep++;

hogy rotálod a bináris logokat? eldobálsz fájlokat, nem?
a jobb syslogd-knek meg lehet adni, hogy milyen nevű fájlba logoljon. hogy a gép nevét bele lehet-e rakni a logfájl nevébe, azt még nem próbáltam. hogy dátumot bele lehet-e, tetszőleges formátumban, azt igen, működik. simán tudsz csinálni

/var/log/%Y/%m/%d/syslog

nevű fájlt. nem kell rajta rotálni semmit, max. ráteszel egy linket a hagyományos helyéről.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Persze, hogy keresnél egyébként?

elk

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Ez kb. 2 éve történt. Nem systemd bug, hanem egyszerűen sérült volt a journal, és a journalctl nem tudta még verifikálni sem.

Ez egy systemd bug volt, v240 korul fixaltak, akkor fordult elo, amikor a fajl nem volt lezarva rendesen. Lehet, h regi verziot hasznaltatok.

while (!sleep) sheep++;

Pontosan, ELK, vagy hasonlo stack. Ezeket celszeruen strukturalt logot etetsz. Persze megcsinalhatod a parszolast sajat szabalyokkal, viszont ha journalbol jon, akkor a melo jo reszet mar megcsinalta helyetted a rendszer. Tehat valami miatt itt csomoan azt szeretnek, ha pl. a severity level beallitasara nekik kene megirni a regexet egyenkent minden processzre, de nem tudom, h ez miert elvezetes.

[ Szerkesztve ]

while (!sleep) sheep++;

Üdv!
Egy awk script megírásához kérném a segítségeteket. Adott egy szamok.txt és egy szoveg.txt fájl.
A szamok.txt fájl teljes tartalmát be kellene illeszteni a szoveg.txt fájl minden 10. sorába.
Ezzel próbálkoztam:
awk '1; NR%10 == 0 { getline < "szamok.txt"; print }' szoveg.txt
Ezzel az a baj, hogy nem a szamok.txt fájl teljes tartalmát, hanem mindig csak egy sort, először az első, utána a második, aztán a harmadik és így tovább sort illeszti be 10 soronként.

Nintendo Friend Code: SW-6329-0332-2133

Egyrészt van script topic, szerintem ez oda való.
Másrészt ha a szamok.txt nem túl nagy, akkor én egyszer beolvasnám egy tömbbe, és utána onnan írnám ki, amikor kell.
Diszk használat szempontjából mindenképpen gyorsabb, ha elfér a memóriában, akkor az a jobb megoldás.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

RPI4 (home server) NFS client/server konfig szerintetek igy rendben van?

CLIENT
rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=14,retrans=2,sec=sys,clientaddr=NNN.NNN.NNN.NNN,local_lock=none,addr=NNN.NNN.NNN.NNN

SERVER
NNN.NNN.NNN.0/24(insecure,rw,async,no_subtree_check,no_auth_nlm,all_squash,anonuid=1000,anongid=1000)

[ Szerkesztve ]

Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.

én bele szoktam tenni, hogy hanyas verzió az nfs, mert a régebbiek nem kezelik rendesen az ékezeteket.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Köszi!
Biztos ami biztos, az insecure-t töröltem.

Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.

Nem tudom az async mennyire jo otlet... azt viszont igen, hogy az uj NFS konfiggal a max 30MB/s w speed 100-ra ugrott a kis Raspberry-vel.
Sysctl-be is raktam még par optimalizalast:

net.core.rmem_max=16777216                                                                                              
net.core.wmem_max=16777216                                                                                              
net.ipv4.tcp_rmem=4096 262144 16777216                                                                                  
net.ipv4.tcp_wmem=4096 262144 16777216                                                                                  
net.ipv4.tcp_mem=4194304 4194304 4194304                                                                                
net.ipv4.udp_rmem_min = 8192                                                                                            
net.ipv4.udp_wmem_min = 8192                                                                                            
net.ipv4.tcp_fastopen = 3

[ Szerkesztve ]

Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.

elvileg manapsag az async a default

forditva, mostmar a sync a default, bocs

[ Szerkesztve ]

while (!sleep) sheep++;

Hat nem tudom... media tartalmaknak async, szenzitiv cuccoknak meg egyelore marad a sync.

Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.

Újra aktuális kérdés.

NAS átalakítás. Elvekkel ellentétben a virtuális hostom és a NAS összevonódna, hogy csak 1 ház foglalja a helyet. A jelenlegi hostra kerülne minden, 2x4TB HDD-re (esetleg egy SSD vagy "nem érdekes mi van vele" gépeknek HDD.). (Később maga a host is cserélődne, valami újabbra, de amúgy a proci, RAM most is elég.)
Az érdekelne, hogy melyik architektúra az értelmesebb, és pl. milyen filerendszerrel.
(Ezek a gépek alapból sleep vagy offban vannak, WOL vagy bekapcsgombbal ébrednek, szóval fogyasztás nem annyira érdekes.)

- A hostra kerül egy GUI (a hoston most nincs, a NAS néha van azzal is használva, kényelmi okokból), a NAS tartalma külön partíción van, amúgy a KVM elvan, ha kell, akkor indítok virtuálgépet. A NAS tartalma is valamilyen RAID-ben van

- A NAS virtuális gép, a diszkje egy 3TB-os file (praktikusan qcow2), így a jelenlegi hoston semmit nem kell macerálni, csak +2 diszk, valami RAID-ben

- A NAS virtuális gép, de a tartalma egy sima partíción van (nem szimpatikus)

Milyen filerendszer lenne jó ez alá? Btrfs nem ajánlott elvileg VM alá (lassú), azt tudom. RAID mindenképpen kéne, és filerendszer szinten (tükörben a 2x4TB). (ZFS? )
Mennyire értelmezhető ilyen 3-4TB-os diszk imagek kezelése KVM-en? Eddig a legnagyobb VM-em 250GB volt, Android fordításhoz, az azért nem egy nagy cucc. Mondjuk mivel a KVM használatos azért komolyabb helyeken is, gondolom nincs gond több terás virtuál diszkekkel.

Köszi minden javaslat

[ Szerkesztve ]

Mutogatni való hater díszpinty

Update : Lehet az az eset is, hogy 2x4T RAID, meg mellé n db 500GB HDD/SSD OS-nek, virtuálnak. Az a NAS-ból kijövő 5db + 2-3 játszós elég lesz

Mutogatni való hater díszpinty

szerintem mindent, ami állandó, és nincs túl nagy igény a biztonsági szeparációra, azt egy helyre kell tenni.
veszed a vasat, ráraksz egy alap debiant, és azon összedrótozod a kvm hostot meg a nast.

egyébként meg az is kérdés, hogy neked mi az, hogy nas? nekem a nas az egy nfs szerver és pont. nincs mit virtualizálni rajta. ha guesteket akarsz rátenni, akkor lvm2.

Szerintem nem kell túlbonyolítani semmit, fájlrendszer az ext4 és jónapot. Arra kell figyelni, hogy alap beállítással kvm-et ne rakj raid1-re.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

A NAS-nak, ha VMként képzeled el, akkor direktben add neki az eszközöket, ne ZFSen valami qcow vagy ilyenek... Főleg ha zfs.

Tegnap még működött...

Na, itt az van, hogy a NAS az kb. egy archív. Redundánsnak kell lennie, amin van, de nyilván van róla backup is.
A KVM host meg egy mezei asztali gép.

@lionhearted : Miért?
Néztem, hogy 2012-es fórumokon meg előadásokon van szó több terás guest diszkekről KVM-en.

A ZFS csak egy lehetőség. Pont az a kérdés, hogy ha ilyen eset van, akkor mit érdemes, ami RAID0, FS szinten, és jó VM alá.
Az Ext4 nem olyan jó, az FS szintű tükröt nem tud, a software raid mondjuk OK, de elég rugalmatlan.
Janos666 kifejtette múltkor, de ott még csak NAS felhasználás volt a cél.

Mutogatni való hater díszpinty

Röviden: Mert semmit nem ér a jó fájl rendszer egyetlen bináris fájlra (virtuális diszk), amiben amúgy lehetnek belső ellenőrzések is.

[ Szerkesztve ]

Tegnap még működött...

Egyebkent valamennyit er, pl. a ZFS checksumolasa az tok jol mukodhet egy nagy fajl eseten is.

while (!sleep) sheep++;