- Milyen notebookot vegyek?
- Házimozi belépő szinten
- Sony MILC fényképezőgépcsalád
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- HiFi műszaki szemmel - sztereó hangrendszerek
- Vezetékes FEJhallgatók
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Milyen processzort vegyek?
- Kormányok / autós szimulátorok topikja
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
-
PROHARDVER!
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
-
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á. -
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. -
urandom0
senior tag
Bare metalon jellemzően csak a host(ot) fut(nak), minden más a vm diszkjén van.
-
-
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. -
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?
-
-
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. -
válasz
lionhearted #34089 üzenetére
Egyebkent valamennyit er, pl. a ZFS checksumolasa az tok jol mukodhet egy nagy fajl eseten is.
-
-
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. -
-
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.
-
-
Ú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
-
Archttila
veterán
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 -
Archttila
veterán
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)
-
bambano
titán
-
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. -
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.
-
-
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.
-
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?
-
urandom0
senior 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. -
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.)
-
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.
-
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
-
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.
-
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
-
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.
-
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).
-
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.
-
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.
-
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".
-
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.
-
urandom0
senior 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...
-
-
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!
-
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
-
urandom0
senior tag
A sudo teljesen jól el van PAM és polkit nélkül is, aki akarja, mindkettőt kiírthatja alóla.
"Azert hasznaljak a systemd-t a a valo vilagban, mert komplex kornyezetekben is jol mukodik."
Nem, azért használják, mert a Debian átvette, és miután az iparban a Linuxos közösség kb. 90%-a vagy Debian, vagy RHEL alapú disztrót használ, ezért a többi kis disztró gyakorlatilag kénytelen volt adoptálni, mivel nálunk nincs erőforrás arra, hogy külön utakon járjanak.
Van egy rakat sudo alternatíva amúgy.
-
bambano
titán
nem kérdés volt, állítás.
unixon alapvetően minden szövegfájl (a szükséges kivételekkel). erre lett az egész optimalizálva.
a bináris log az olyan, hogyha én beülök egy szték vendéglőbe, akkor nekem hiába magyarázza bárki is, hogy a szója meg a tofu jó, én akkor is sztéket fogok enni. azért van unix a gépeimen, mert szöveges logokat akarok.mindig az az oprendszer van a gépemen, amellyel a legegyszerűbben meg tudom oldani a feladatomat. tehát ha ascii log elég (mindig elég), akkor nem lesz bináris logom, pláne nem lesz xml meg json meg binary blob logom.
-
bambano
titán
Ha tényleg ők a linuxos világ teteje, akkor bajban vagyunk.
"This stuff is not documented ": a valóság az, hogy documented. A resolv.conf-ban szereplő dns szerverhez fordul, pont.Egyébként a systemd-resolvd-ben az documented volt, hogyha nem jó a névfeloldásod, akkor a google névszerverére fallback-kel? Mert egy ilyen ötlettől a linux kapásból alkalmatlanná válik komolyabb helyeken való felhasználásra.
A dbus támogatás meg micsoda? Minek dbus támogatás a rezolváláshoz? Megint ez a csináljunk egy naaaagy monolitikus böszmeséget a unix alapfilozófiájából történet, ahol pottering nem érti, hogy amit csinál, az fundamentálisan rossz. vannak dolgok, amiket el kell fogadni, mint egy axiómát. A unix az KISS. Ami nem KISS, az nem unix, hanem pl. windows. a systemd nem egy tuningolt unix init, hanem egy totál más rendszer initje, ami alatt tévedésből linux kernel van.
De ezek "filozófiai" kérdések. Az alapvető probléma, hogy a systemd nem működik rendesen. Nem teljesíti a saját ígéreteit, a doksiját. Amíg nem az történik, mint ami a kottában van, addig nincs miről beszélni, az csak a mostani munkahelyén normális, hogy a világ a bétatesztelőjük, debianban eddig ez nem volt.
A systemd elkaristol, amíg az alap dolgokhoz akarod használni. Amikor nekem bonyolultabb dolgokhoz kellett volna systemd támogatás, soha nem sikerült megcsinálni, mindig valami bugba futottam bele. Egyébként meg például milyen vicces, hogy a systemd gyűjti a logokat és forwardolja a syslogd-nek. Miért nem lehet ilyenkor kihagyni a systemd-t? bináris log unixon? minek?
A systemd alapvető baja egyébként, hogy működő, tesztelt, normális megoldásokat cserél le egy katyvaszra, látható előnyök nélkül. Miközben ezzel a cserével a rendszergazdákat arra kényszeríti, hogy erőforrásokat áldozzanak a változás követésére. Minek? Ki fizeti azt meg? Én fizessem meg pottering egoizmusát? A linux régen a szabadságról szólt, nem arról, hogy minden mocskot letolnak az ember torkán. Ha azt akarom, hogy pár egoista barom hülyeségéhez kelljen erőszakkal igazodnom, veszek windows licenszet.
-
Mar nemigen emlekszem, mit akartam elinditani vele service-kent; ha jol remlik, 2-3 ilyen probalkozasom volt, aztan hagytam a francba - mert cseszett elindulni. A resolved is hasonlo kaland volt, meloban kellett volna valami flexibilis megoldas, mindenki a resolved-ra mutogatott, hogy az a tuti, de a vege mindig az lett, hogy le kellett tiltani es manualisan konfiguralni az interface-eket. A binaris log, meg mint mondtam, egy egetvero baromsag: ha van text logom, akkor hajszaritoval is elolvasom, mi vagyon irva bele, a binaris loghoz meg kell a sajat kornyezete, hogy olvashato legyen - hurra.
Ez meg messze nem minden, ami miatt a systemd szar, de mivel mar ezeken a hasabokon is leirtam jonehany alkalommal ezeket, nem kezdem elolrol.
-
válasz
sh4d0w #34044 üzenetére
Mi nem mukodott az unittal? Nem tudom, hogy mi az, ami abban nem tud mukodni. Csinalsz egy unit fajlt egy perc alatt, kesz. A harmadik utan mar a vilag legegyszerubb dolga, mindent egy helyen konfigolsz.
"Red Hat megírja a unitokat"
?
resolved: ez az, ami megbizhatoan tudja a kovetkezoket:
- interfeszenkenti DNS feloldas (VPN-ek, kontenerek, stb. eseten letfontossagu)
- DNS over TLS (biztonsag)
- D-Bus tamogatas
- domain-alapu nevfeloldasi szabalyokSzerintem megegyezhetunk abban, hogy a Tailscale mernokei a vilag tetejet kepviselik, ha Linuxos halozatokrol van szo. Ok irjak:
As an aside, one major difficulty in all of this is that name resolution on Linux systems is very poorly specified, and each of these methods results in slightly different behavior. If we do a resolution for
go.akua
, what will happen? Will it go to the resolver for the public internet? Will it go to the right split server? Will it get sent over Tor for some reason? Will it get sent to the potentially dodgy DNS server on the public Wi-Fi hotspot at your local coffee shop? Will it get sent over UDP, TCP or DNS over HTTPS? We don’t know. This stuff is not documented and as a result, you need to figure out what it does through blood, tears and heartbreak. For extra fun, the behavior of glibc and musl differs here too. Please document your behaviors when you write new software. This saves so many people so much time.An example of how to do this right is systemd-resolved. It can do everything a modern split-DNS VPN needs natively, so in theory there’s no extra work (except see below, because reality is not quite as clean as we’d like). The systemd team painstakingly wrote down what they do, and made it unambiguously obvious how you should twiddle things to get what you want. This is the kind of documentation that infrastructure programs should strive to have.
Szoval a resolved
1) mukodik
2) mindent tud, amit egy modern DNS kliensnek tudnia kell
3) reszletesen dokumentaltnincs mas olyan DNS megoldas, ami ezeket igy mind tudja.
A binaris logolas meg egy erdekes tema, kezdve onnan, hogy minden logolas binaris ...
Azert hasznaljak a systemd-t a a valo vilagban, mert komplex kornyezetekben is jol mukodik.
-
Kivéve, hogy rosszabbak. Nem volt még másik *nix probléma, amivel annyit szívtam, mint a resolved ökörségei, a bináris logolás egyenesen baromság, amikor meg unitot kellett volna használnom, sosem működött.
Az "ipar elfogadta": nem, az ipar csak spórol vele, a Red Hat megírja a unitokat, a többiek meg használják. Mindjuk kíváncsi leszek, mit csinál az ipar, ha a Microsoft benyögi annak az arrogáns marhának, hogy conflict of interest nekik a systemd fejlesztése, ezért abba kéne hagyni.
-
-
válasz
fatpingvin #34040 üzenetére
Nem, pl. azert sem, mert a su processz nem az 1-bol fog leszarmazni.
Egyebkent meg:
> Pláne úgy, hogy ez a run0 az egész PAM mechanizmust meg a polkitet berántja maga alá
pont ahogy a sudo is
A sudoval meg az is a gond, h nem all mogotte rendes maintainer garda
-
urandom0
senior tag
És mi a garancia arra, hogy run0-ban nem fognak exploitokat találni? Pláne úgy, hogy ez a run0 az egész PAM mechanizmust meg a polkitet berántja maga alá, és amúgy systemd-run alapon megy, ami mögött meg ott az egész systemd. Lehet, hogy a run0 kódja 5 sor, de ott van mögött az egész systemd a 8000 soros kódjával, meg a pkexec, a polkit, meg a PAM...
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).
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.
-
growler
őstag
sudo helyett run0 ? [link]
-
kovaax
őstag
Egen. Amikor laptotyot vettem, én is Fedorát raktam rá először, hogy minden működik-e. Aztán jött a Debian freeze, és lecsekkoltam a verziókat (kernel, driverek, wayland, fityfene), nagyjából stimmelt, úgyhogy felraktam az RC-t, és az is jó volt, úgyhogy ment rá az, aztán hogy stabil lett, azóta stabil Debian van azon (ezen) is.
-
Vladi
nagyúr
válasz
bambano #34031 üzenetére
igen... smindezt az ingyen kellene topikban.
Egyébként ilyenkor érdmes ránézni, hogy maga a projekt hol tart, aztán megnézni az update-testing tárolót és a rawhide-ot is. Ez utóbbiban szabad rablás van, tehát tolják bele az új kódot egy ideig. Hajlamos összeomlani de a legfrissebb fedorák közül. MOndjuk waylandnál van már 2-3 napos release amit még nem követett le.
-
urandom0
senior tag
Megjelent a Fedora 40: https://fedoraproject.org/
Mondjuk vasárnapig várhattak volna vele
[kép] -
Ablakos
őstag
Van egy /media/backup mappa, ami egy fstab bejegyzésből kapcsolódik fel.
//192.168.200.3/backup /media/backup/
cifs rw,vers=3.0,credentials=/root/.userCredentials
,gid=1000,dir_mode=0775,file_mode=0664
user@P8B75-V-desktop:/media/backup$ ll
drwxrwxr-x 2 root user 0 máj 18 2023 'Android Studio Projects - backup'/
drwxrwxr-x 2 root user 0 márc 31 13:02 Dell-Inspiron-5767/
drwxrwxr-x 2 root user 0 ápr 20 13:18 drupal/
drwxrwxr-x 2 root user 0 ápr 19 13:06 P8B75-V/
drwxrwxr-x 2 root user 0 ápr 12 15:04 Windows11-Desktop/Lehetséges a kiemelt sorban lévő mappát felruházni olyan joggal, hogy írhassa pl. www-data user? (acl: Operation not supported )
-
Rison77
senior tag
Sziasztok!
Nagyon nem találtam ennél megfelelőbb topikot az alábbi kérdésemre. Valakinek esetleg van tapasztalata, "sikerélménye" Azure erőforrások monitorozásában on-prem Zabbix-al? Valami elképesztő zero információ van a neten róla, vagy csak rossz helyen keresgélek.
-
-
-
vicze
félisten
válasz
sh4d0w #34008 üzenetére
Csodás clickbait cím...
Schleswig-Holstein megint megpróbálkozik a Linux-szal. Jól haladnak 2021 óta...
Majd 2027-ben lesz cikk, hogy már 35000 PC-t váltanak...Az egészben az a leghumorosabb, hogy a német közigazgatás még minding 90%-ban papíron zajlik. Szóval végső soron nem Windowsról váltanának, hanem papírról.
Mondjuk úgy hogy egyik állam se költ lószart se digitális átállásra, ja lehet az open Source olcsóbb lesz, de ahogy szokásos megint nem...Szerk: Azt hiszem elolvastam életem legszebb német mondatát.
"Die Zukunft der Verwaltung ist cloudifiziert, automatisiert, algorithmisiert und datenbasiert. " -
kovaax
őstag
válasz
urandom0 #34009 üzenetére
A SLES nem úgy kezeli az alverziókat, mint a RHEL és a Debian, lazán cserélnek csomagokat alverziók közt is, kvázi mintha mind főverzió lenne. 15.5 mikor kijött, marhára nem volt stabil, a supporttal 1 hónapig szopattam magam, míg a végén egy "zypper up" megoldotta a problémámat. Még nem jöttem rá, hogy ugyanaz az install folyamat mikor rak fel exim-et és mikor postfix-et. Ilyenek. Kedvencem az autoyast-os install, mert a lemezeket nem úgy veszi fel, ahogy megkapja a vastól (disk1 -> sda, disk2 -> sdb, stb.), hanem a leggyorsabb lesz az sda, a következő az sdb, stb., tök mindegy, ha azok tök más méretűek.
-
-
kovaax
őstag
Munkában beriasztott SLES-re a szekuriti, hogy XZ backdoor, mondok wtf??? De aztán kiderült, hogy egy konténert Tumbleweed-ből épít a beszállító, és abban benne van. Küldtünk neki öklözőzsírt.
-
Új hozzászólás Aktív témák
Hirdetés
- Milyen notebookot vegyek?
- E-roller topik
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Házimozi belépő szinten
- Apple Watch Sport - ez is csak egy okosóra
- BestBuy ruhás topik
- Sony MILC fényképezőgépcsalád
- Autóápolás, karbantartás, fényezés
- Synology NAS
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- További aktív témák...
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Új, bontatlan World of Warcraft gyűjtői kiadások
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- iKing.Hu - Apple iPhone 14 Pro Max - Gold - Használt, szép állapot
- REFURBISHED és ÚJ - HP USB-C Dock G5 docking station (5TW10AA) - 3x4K felbontás, 120Hz képfrissítés
- LG 27GP95RP - 27" Nano IPS - UHD 4K - 160Hz 1ms - NVIDIA G-Sync - FreeSync Premium PRO - HDR 600
- Fotó állvány eladó
- Dell latitude, precision, xps, magyar világítós billentyűzetek eladóak
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged