-
GAMEPOD.hu
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
nagyúr
válasz bambano #34049 üzenetére
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++;
-
kovaax
őstag
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 -=-
-
nagyúr
válasz urandom0 #34053 üzenetére
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++;
-
urandom0
aktív tag
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...
-
bambano
titán
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
-
ivana
Ármester
válasz urandom0 #34038 üzenetére
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".
-
nagyúr
válasz bambano #34056 üzenetére
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++;
-
bambano
titán
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
-
nagyúr
válasz urandom0 #34055 üzenetére
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++;
-
bambano
titán
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
-
nagyúr
válasz bambano #34061 üzenetére
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++;
-
Vladi
nagyúr
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!
-
nagyúr
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++;
-
ka.laszlo
újonc
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.
-
nagyúr
válasz ka.laszlo #34065 üzenetére
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++;
-
urandom0
aktív tag
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. -
-
nagyúr
válasz bambano #34069 üzenetére
> é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++;
-
bambano
titán
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
-
nagyúr
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++;
-
FNG
kezdő
Ü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
-
bambano
titán
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.
-
-
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.
-
-
Ú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
-
-
bambano
titán
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
-
őstag
-
válasz bambano #34086 üzenetére
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
-
őstag
-
nagyúr
válasz lionhearted #34089 üzenetére
Egyebkent valamennyit er, pl. a ZFS checksumolasa az tok jol mukodhet egy nagy fajl eseten is.
while (!sleep) sheep++;
-
válasz lionhearted #34089 üzenetére
A bitrot elleni védelem pl. ér, meg az is, hogy FS szintű a RAID. És egy szoftver mdraid-en nem igazán van bitrot védelem.
A virtuális diszken meg mondjuk Ext4 van, mivel az alatt már van egy RAID.[ Szerkesztve ]
Mutogatni való hater díszpinty
-
őstag
-
válasz lionhearted #34092 üzenetére
OK, én arra vagyok kíváncsi, hogy melyik a jobb megoldás. Ha a VM egy file, akkor azt könnyebben tudom költöztetni, és diszket növelni, ha cserélem alatta a winyót később. Ha a VM file egy ZFS-en van, ami tükör filerendszer szinten, annak mi a hátránya?
Mutogatni való hater díszpinty
-
WTF. Miért ne lenne ilyen... Ritkábban látok olyat, hogy külön fizikai eszköz van odaadva (kivéve SAN-os storage-okon persze, de általában az sem annyi, hogy 1diszk=valamelyik VM-é).
Backup szempontból is egyszerű, hiszen magán a VM-en is futhat valami, ami az adatot menti máshová, de ha olyan a cucc, akkor akár a diszk file-t magát is mentheted/snapshotolhatod.
De OK, nem kell egy lemeznek lennie, lehet külön a virtuális OS diszk is, meg az is egy virtuális diszk, amin az adat van.[ Szerkesztve ]
Mutogatni való hater díszpinty
-
-
urandom0
aktív tag
Bare metalon jellemzően csak a host(ot) fut(nak), minden más a vm diszkjén van.
-
válasz f_sanyee #34096 üzenetére
Leírtam
SMB általában, amin hozzáférek. Meg SSH. Meg van GUI-ja is, kényelmi okokból (különben mezei Debian). Meg van rajta egy Filebrowser is.Mutogatni való hater díszpinty
-
válasz f_sanyee #34099 üzenetére
Miért ne futhatna?
Most 2 külön gép, két gép helyét foglalja, két macera, főleg ha a RAID-en csinálni kell valamit a NAS-on. Két macera az OS-re odafigyelni, HW-re... a NAS nem sok erőforrás, csak hely kell sok.
És mind a kettő elég régi, ideje lenne cserélni, pénz akad most éppen rá.Mutogatni való hater díszpinty
-
őstag
Persze, hogy ritkán látsz ilyet, hiszen nem szokták keverni a funkcionalitását a fizikai vasnak. Már csak azért sem, mert másra van szükség adott funkcionalitáshoz, más-más az optimum... de szükség törvényt bont, te meg otthonra kendácsolsz, és ehhez próbáltam hozzátenni, teljesen függetlenül attól, hogy mi van enterprise környezetben.
Még azt tudom elképzelni, hogy a KVM-nek ZVol-t adsz (iSCSI target, ahogy egy storage-ről kapnád), ha már nem LVM-ben gondolkozunk.
A fizikai diszket nem tudod könnyen költöztetni? Akármilyen környezetbe viheted, ahol van SATA csatlakozó. ZFS alatt diszket cserélni (bővíteni!!) azért rendesen szívás, de megintcsak, nem mindegy, hogy a host diszkjeit cseréled, vagy a guestnek adottat? Nem látok különbséget. Ugyanazok a ZFS problémák.
Ámde az, hogy egy fájl az egész adattárad, az ad egy extra komplexitás, amivel extra hibát viszel a rendszerbe... ha az valahogy megrottyan, vihet mindent... és igen, ez igaz a fájlrendszerre is, de olyanod ugyanúgy van (ZFS a hoston), sőt, több is egymáson (hiszen a fájlod csak egy block device a guest felé, arra tesz még ő is egy plusz FS-t, pl ext4.) És akkor a ZFS előnyeit egy óriási binárison kell értelmezni. Snapshotolni a qcow2-t, háááát, ha próbáltad, akkor tudod, hogy azt menedzselni nem könnyű. Azt csinálja, hogy lesz 2 fájlod, és az élő rendszer diffeli a régit... abból újra egyet csinálni ugye... performanciáról nem is beszélve. Menteni se poén egy ilyet, de sokat segít, ha külön van az adattár, ha az nagyjából WORM.Nem tudom ki hol találkozott enterprise-szal, vagy én vagyok túlságosan közel a hiperkonvergenciához, de mifelénk nincs a compute node (legyen az kvm vagy kubernetes worker) lokális diszkjein megőrzendő adat. És persze hívhatom a SAN-tól kapott blockdevice-t "VM diszknek", de nem teszem, mert valaki még összekeveri a lokálisan tárolt qcow2-vel. Szóval @urandom0 mondása nálam így végződne: ...minden mást a storage réteg (Ceph, Gluster, SAN, stb.) tárol.
[ Szerkesztve ]
Tegnap még működött...
-
bambano
titán
válasz lionhearted #34101 üzenetére
"Nem tudom ki hol találkozott enterprise-szal,": otthonra kell neki nas. nem enterspájz hiperkonvergált vállalati ócskavastelep
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
őstag
válasz bambano #34102 üzenetére
Ugyanezzel kezdtem, erre írja mindenki, hogy ki mit látott a cégeknél... hát értem én, de kinek az életét könnyíti meg egyetlen otthoni PCn az. Én csökkenteném a komplexitást, hogy kisebb eséllyel legyen kaki a palacsintában, és eszerint osztottam meg az ötletem.
Tegnap még működött...
-
válasz lionhearted #34101 üzenetére
Keverni? Amikor egymás mellett fut 200 gép egy Power vason, az keverés?
" másra van szükség adott funkcionalitáshoz, más-más az optimum... de szükség törvényt bont,"
Igen, ezért kérdeztem, hogy mi az, ami az adott céloknek egyszerre meg tud felelni"A fizikai diszket nem tudod könnyen költöztetni?"
Lássuk, nagyobb diszkre költöznél, akkor a RAID tömböt macerálni kell. Meghal egy diszk, RAID macera. Partíciókat kell macerálni. Stb. Egy qcow2 esetén meg a NAS-nak mindegy, mi van alatta.A plusz réteg meg minden VM esetén megvan, szóval...
"Nem tudom ki hol találkozott enterprise-szal, vagy én vagyok túlságosan közel a hiperkonvergenciához, de mifelénk nincs a compute node (legyen az kvm vagy kubernetes worker) lokális diszkjein megőrzendő adat."
Hát, mi sem ezt mondtuk, hanem hogy a VM diszkjén van adat. És khm, az sem szokás, hogy a VM local diszken, az adat meg SAN-on, akkor már a VM is a SAN-ról fut, a hostban nem is kell legyen diszk. (BTW a SAN storage is mit csinál, valamilyen saját filerendszeren tárol, szóval az is egy plusz réteg, csak nem látod. Azt se feltétlen látod, miről van kiosztva neked hely.)
BTW most muszáj volt némi gépet local diszkre tenni nálunk, mert volt olyan alkalmazás, aminek az optikán lógó SAN lassú volt (másik 20 gép szó nélkül fut róla ) , és csak local diszken hajlandó normálisan működni (magyar bérszámfejtő cégek gyöngyének cucca).Itthon meg nincs storage Szóval ha akarnám sem tudnám egy redundáns, külső SAN-ra tenni.
[ Szerkesztve ]
Mutogatni való hater díszpinty
-
őstag
> Keverni? Amikor egymás mellett fut 200 gép egy Power vason, az keverés?
Nem. Semmi köze nincs ahhoz, hogy 200 gép van-e rajta, az a compute node-ot írja körül. És egy compute node nem úgy néz ki mint egy SAN. Ezt értem keverés alatt.
> Igen, ezért kérdeztem, hogy mi az, ami az adott céloknek egyszerre meg tud felelni
Remélem, hogy értem a kérdést, és legjobb tudásom és pozitív hozzáállás mellett írom, amit írok. Tehát pipa.
> Lássuk, nagyobb diszkre költöznél, akkor a RAID tömböt macerálni kell. Meghal egy diszk, RAID macera. Partíciókat kell macerálni. Stb. Egy qcow2 esetén meg a NAS-nak mindegy, mi van alatta.
De a hostnak nem mindegy. Azt akartam itt kifejezni, hogy teljesen mindegy, hogy a HOST ZFS-t vagy a GUEST ZFS-t kell abajgatni, pontosan ugyanazzal a munkával jár. A diszk csere akkor is a HDD fizikai kicserélésével jár, és pont. Ha pedig azt értjük extra melónak, hogy ezen valamiféle OS is van, akkor mindkét esetben így van (lehet/lesz), az egyik esetben a HOST OS, a másikban a GUEST OS. Ha van plusz diszk, akkor egyik esetben sem kell.
> A plusz réteg meg minden VM esetén megvan, szóval...
Ugye a direkt hozzáférésben az a lényeg, hogy nincs meg, legalább is a storage-et illetően (jelen esetben). "Menedzselni" a KVM-et persze kell, hogy ki kapja meg, ez plusz meló. De nincs FS->QCOW2->FS, csak 1db FS van az adott pár diszkeden, és pont. Pont ott, ahol a legértékesebb adataid vannak.
> És khm, az sem szokás, hogy a VM local diszken, az adat meg SAN-on, akkor már a VM is a SAN-ról fut, a hostban nem is kell legyen diszk.
Szokásokról nem nyitok vitát, amúgy pedig nem pontosan ezt írtam. És magad is hoztál rá példát.
Tegnap még működött...
-
válasz lionhearted #34105 üzenetére
"És egy compute node nem úgy néz ki mint egy SAN. Ezt értem keverés alatt."
Ja, de ha van is local diszkje, akkor sem lesz belőle SAN.
Meg hát mi a helyzet a vSAN-szerű dolgokkal? Ezek nem feltétlen fekete-fehér dolgok."És magad is hoztál rá példát."
Nem, amit én írtam, az az volt, hogy a VM local diszken fut az egyik compute node-on, és a VM virtuális diszkjén van az adat is Egy gép, saját virtuális diszkjeivel.
Ja, meg azért raktunk pl. pár gépet local diszkre, mert olyan szinten dugig volt a közös storage, és késett a csere." A diszk csere akkor is a HDD fizikai kicserélésével jár, és pont. "
Igen, megfogtad a lényeget, az a legnagyobb meló benne, ja, nem"Ugye a direkt hozzáférésben az a lényeg, hogy nincs meg, legalább is a storage-et illetően"
És esetemben a NAS-nak majdnem mindegy teljesítmény szempontjából, hogy direktben kap-e diszket, vagy virtuálisan. Minden más esetben meg kb. kényelmesebb a virtuális diszk.Mutogatni való hater díszpinty
-
őstag
-
bambano
titán
válasz lionhearted #34107 üzenetére
unixon a diszk partíció egy hatalmas blobb...
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz lionhearted #34107 üzenetére
Pont erre voltam kíváncsi. Van valami jellemző hátránya a ZFS vagy egyébnek ilyen szempontból, hogy pl. hajlamos összeborulni? Meg hát ezért lenne RAID-ben.
Amúgy az adatról van backup, a VM-ek nagy része meg nem égető fontos. Amelyik igen, arról van backup
Nyilván az egyszerűbb eset, hogy simán egy winyón vannak az adatok, de egy winyóhiba akkor is egy winyóhiba. VM diszk file meg eddigi tapasztalat alapján nem megy magától tönkre.Mutogatni való hater díszpinty
-
nagyúr
Az a baj, h nem vagy kulonosebben tapasztalt/profi infrastruktura-mernok, de el akarod kezdeni egymas tetejere pakolni az absztrakciokat. Ez az almoskonyv szerint nem vezet jora, mert ha valami elkezd rakoncatlankodni, macerasabb lehet kinyomozni, hogy mi van.
ZFS/RAIDZ1 on bare metal (HBA), ez a megoldas, ami neked kell. Konkretan azt javaslom, hogy TrueNAS-t rakjal fel. Ha gond van, diszk ki/be, resilver, kesz. Ha alkalmazasok, szolgaltatasok kellenek, akkor TrueNAS alatt virtualizalsz.
Lehet ennel bonyolultabban is csinalni, de _szerintem_ nem tartasz ott. Ha nem fontos az adat, akkor persze jatssz vele.
[ Szerkesztve ]
while (!sleep) sheep++;
-
Nem, amúgy nem, ezért kérdezek. És konkrétan ezért érdekelnének a buktatók.
Absztrakciók egymáson, az amúgy is van, és nem látom, hogy különösebb gondot okozna, nem csak itt, hanem nagyobb cuccokon sem. (Meg most az a sok absztrakció egymáson, hogy van egy valamilyen RAID tükröm, és azon egy virtuális diszk file? Hát ha ettől baja lesz, akkor a fél világ virtualizációja össze kéne dőljön naponta...)Truenas-t? Ez volt az eredeti kérdés.
OK, ha jól látom, lehet rajta futtatni VM-et, de... na, nem arra való.
Mezei Debian lesz, a kérdés csak a megvalósítás, meg a filerendszer.Az adat fontos, ezért van róla backup, de az meg ugye online nem elérhető.
[ Szerkesztve ]
Mutogatni való hater díszpinty
-
nagyúr
Elnézést, ha úgy jött le, h esetleg az általános hozzáértésedet vonom kétségbe. Storage építésénél jellemzően a célszoftvernek próbáljuk adni a kontrollt.
TrueNAS rendes Linux, abszolút való virtualizációra. Ha sima Debiant raksz fel, az is működni fog, de a TrueNAS (Scale) ad egy csomó segítséget.
while (!sleep) sheep++;
-
-
Amúgy semmi, csak ide szerintem felesleges, túlságosan NAS. (Meg mondjuk ami most a virtuálhost, és egy ideig a NAS is ez lesz, az egy A8-3850, 16GB RAM-mal.)
Eddig is csak egy mezei Debian volt a NAS, RDP+SSH+SMB+Filebrowserrel, és elég is ez a funkcionalitás.Mutogatni való hater díszpinty
-
urandom0
aktív tag
Másnál is vannak problémák a Fedora 40-nel, vagy csak én vagyok ilyen szerencsecsomag?
Az asztali gépemen tegnap alap dolgok nem működtek, pl. nem tudtam egy fájlkezelőt elindítani, de még csak sudozni se tudtam, az xfdesktop nem indult el, két nm-applet ikon volt a panelen, de az egyik nem reagált semmire, stb. Bebootoltam a 39-es kernelével, akkor minden jó volt. Volt vagy 900 MB-nyi update, azt feltoltam, azóta jónak tűnik.Most a laptopon csinálja ugyanezt. A fájlkezelő nem akar elindulni, sudozni tudok, de nagyon lassan dobja be a promptot, mint ha valami hálózati kapcsolatra várna. A raspberry egyik sftp meghajtója van felcsatolva, de hát az eddig is fel volt, és sosem volt vele probléma. Most itt is van 660 MB-nyi update, meglátjuk, ez megjavítja-e.
-
urandom0
aktív tag
válasz urandom0 #34117 üzenetére
Most, hogy frissítettem Fedora 40-re (nem szoktam elkapkodni...), jött néhány új service is. Ilyenkor mindig meg szoktam nézni, hogy melyik mit csinál, hogy tudjam, ha esetleg nincs szükségem valamelyikre. Most pl. ilyenek vannak:
dracut-shutdown.service - This service unpacks the initramfs image to /run/initramfs. systemd pivots into /run/initramfs at shutdown, so the root filesystem can be safely unmounted.
livesys-late.service - loaded active exited SYSV: Late init script for live image.
livesys.service - loaded active exited LSB: Init script for live image.
mcelog.service - mcelog logs and accounts machine checks (in particular memory, IO, and CPU hardware errors) on modern x86 Linux systems.
pcscd.service - The pcscd daemon is used to manage connections to PC and SC smart card readers.
low-memory-monitor.service - The Low Memory Monitor is an early boot daemon that will monitor memory pressure information coming from the kernel, and, first, send a signal to user-space applications when memory is running low, and then activate the kernel's OOM killer when memory is running really low.
plymouth-quit-wait.service - Hold until boot process finishes up
plymouth-read-write.service - Tell Plymouth To Write Out Runtime Data
plymouth-start.service - Show Plymouth Boot Screen
rpc-statd-notify.service - Notify NFS peers of a restart
systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully
systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev
systemd-tmpfiles-setup.service - Create Volatile Files and Directories
sssd-kcm.service - SSSD Kerberos Cache ManagerEgy kicsit viccesnek találom, hogy most már 3 plymouth service is van, van 3 tmpfiles service, és hogy van külön low memory service, ami azért van, hogy beindítsa a tényleges OOM killert.
-
-
urandom0
aktív tag
válasz Archttila #34119 üzenetére
Néztem, igazából a systemd-tmpfiles-setup* serivce-ek ugyanúgy a systemd-tmpfiles-t hívják meg, csak más paraméterekkel. Konkrétan a systemd-tmpfiles-setup-dev és a systemd-tmpfiles-setup-dev-early között annyi a különbség, hogy a másodiknál van egy --graceful paraméter is.
A plymouth service-nék megint csak szinte ugyanez, a háromból kettő a /usr/bin/plymouth-ot hívja más-más paraméterezéssel, míg a harmadik a /usr/sbin/plymouthd-t, de ExecPost-nak ott is be van írva a /usr/bin/plymouth.
Végső soron nem probléma, hogy ennyi service van, de majd csinálok egy tiszta telepítést, és megnézem, hogy ott mik vannak. -
Lenry
félisten
válasz lionhearted #34101 üzenetére
ZFS alatt diszket cserélni (bővíteni!!) azért rendesen szívás
wut?
zpool replace tank régidiszkid újdiszkid
User részről kész, ő nyilván meg resilverel, de a kötet továbbra is használhatóGvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
Új hozzászólás Aktív témák
- Android alkalmazások - szoftver kibeszélő topik
- A fociról könnyedén, egy baráti társaságban
- Vírusirtó topic
- Star Trek Online -=MMORPG=-
- Ventilátorok - Ház, CPU (borda, radiátor), VGA
- Kertészet, mezőgazdaság topik
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Autós kamerák
- Dragon Age: Origins
- Futás, futópályák
- További aktív témák...
- Új, bontatlan World of Warcraft gyűjtői kiadások
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- PC JÁTÉKOK (OLCSÓ STEAM, EA , UPLAY KULCSOK ÉS SOKMINDEN MÁS IS 100% GARANCIA )
- Windows, Office licencek a legolcsóbban, egyenesen a Microsoft-tól - 2990 Ft-tól!
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen