- Android alkalmazások - szoftver kibeszélő topik
- Profi EKG-s óra lett a Watch Fitből
- Honor 400 Pro - gép a képben
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Samsung Galaxy A54 - türelemjáték
- Milyen okostelefont vegyek?
- Telekom mobilszolgáltatások
- Apple iPhone 16 Pro - rutinvizsga
- India felől közelít egy 7550 mAh-s Redmi
-
Mobilarena
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
-
#34951
urandom0
senior tag
lionhearted
#34949
urandom0
senior tag
válasz
lionhearted
#34949
üzenetére
Egy plusz védelmi vonal.
-
urandom0
senior tag
válasz
.-..-.
#34946
üzenetére
"Currently failed" a jelenleg aktív próbálkozások száma? Azaz 17 olyan IP címről próbálkoznak ami még nem érte el a "Max retry" értéket?
Igen, jól érted. Csak ugye itt a "jelenleg" egy adott időablakot (findtime) jelent, amin belül számolja a probálkozások számát. Ha jól emlékszem, ez alapértelmezetten 10 perc. Tehát e "currently failed" azon próbálkozások száma, amik az elmúlt 10 percben történtek, és még nem érték el a maxretry értéket.
Ha nem feltétlen kell a publikus neten lógnia a szervernek, egy VPN-t felhúzhatsz elé.
-
urandom0
senior tag
válasz
.-..-.
#34942
üzenetére
Akkor normális.
Nálam most így néz ki a helyzet.$ sudo fail2ban-client status sshdStatus for the jail: sshd|- Filter| |- Currently failed: 2| |- Total failed: 39| `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd`- Actions|- Currently banned: 7|- Total banned: 7`- Banned IP list:
Az sshd logját érdemes megnézegetni néha az ssh logját, illetve add ki néha alastlogés alastbparancsokat, és nézegesd meg azokat is. -
urandom0
senior tag
-
urandom0
senior tag
válasz
daninet
#34885
üzenetére
annyira nyakatekertnek és bonyolultnak tartom selinuxot
Ezzel nem vagy egyedül.
De a disztrók mentségére legyen mondva, hogy újabban már elég jó policyket szállítanak alapértelmezetten is. Emlékszem, régebben mindig első dolgom volt kikapcsolni a SELinuxot, mert állandóan kötözködött a programokkal. Többek közt a Docker sem ment miatta, de egy nyomorult helloworld.c-t nem tudtam lefordítani, mert az neki nem tetszett.
Egy ideje én már nem futok bele ilyen problémákba, úgyhogy nem is kapcsolgatom ki a SELinuxot. -
urandom0
senior tag
válasz
.-..-.
#34847
üzenetére
A mutter változott, bekerült a triple buffering, amit 4 éve csiszolgattak. Elméletileg pont, hogy gyorsabbnak és simábbnak kellene lennie az animációnak... milyen GPU-d van?
Állítólag a 48rc-re való downgrade megoldja a problémát:sudo pacman -U https://archive.archlinux.org/packages/m/mutter/mutter-48rc-1-x86_64.pkg.tar.zst
De itt is írnak releváns dolgokat, nézegesd át őket:
https://gitlab.gnome.org/GNOME/mutter/-/issues/4000 -
urandom0
senior tag
qemu-ovmf-x86_64 csomagról van szó, ez valóban egyébként az edk2-s csomag, Tumbleweed azért tette elé a qemu prefixumot, mert ez itt kifejezetten a Qemu-hoz készült.
daninet, ha ilyen van, rollbackelj vissza egy korábbi snapshotra, és bootolj be onnan, ez a legegyszerűbb. Aztán majd frissítesz, ha kijavították a bugot.
-
urandom0
senior tag
válasz
Vasti74
#34767
üzenetére
Ezt a véleményt abszolút adom. A cégnél pont ilyen Fuji gépeket használunk, imádom őket. Kis kompakt, könnyen szerelhető gépek ezek. Itthon egy régebbi típus van, sosem volt vele gondom.
A Thinkcentre meg Thinkcentre, azt nem is kell ragozni. Én ha gépet veszek, elsősorban Lenovót veszek, és azt is ajánlom mindenkinek, főleg a Thinkpadeket, azzal nem lehet mellélőni. Magamnak is Thinkcentret vettem, de a feleségemnek megtetszett, és kikönyörögte magának
És utána szereztem be a Fujit. -
urandom0
senior tag
válasz
bambano
#34699
üzenetére
Mivel én nem használok DRBD-t, életemben kb. kétszer láttam, így nem tudom, mi okozhatja nálad a problémát. De azt ugye érted, hogy ennek az ég világon semmi köze sem a SysV inithez, sem a Systemdhez?
De én most le vagyok sokkolódva attól, hogy van, aki úgy grepeli ki a journalból az infókat. Azért nem ezt gondoltam volna, főleg olyantól, aki régóta a szakmában dolgozik...
Mondom én, hogy itt arról van szó, hogy ti nem akarjátok megismerni a Systemd-et, jól elvagytok ti a régi világban, és nektek az úgy oké. Egyébként szeretném jelezni, hogy a Systemd képes SysV init scripteket futtatni, úgyhogy tulajdonképpen nem olyan nagy baj, ha nem akartok közelebbi kapcsolatba kerülni a Systemddel. -
urandom0
senior tag
-
urandom0
senior tag
válasz
Rhino666
#34696
üzenetére
Én meg sokszor rólatok gondolom az, hogy a Systemd utálat nagyrészt abból fakad, hogy nem akarjátok megismerni, és ragaszkodtok a régi megoldásokhoz.
10 éve használok desktopon Linuxot, előtte 3 évig használtam már szerveren is, és soha nem találkoztam az általad írtakkal. Soha nem láttam korrumpálódott journalt, soha nem okozott problémát beleolvasni, soha nem volt olyan, hogy ne lett volna hozzáférhető, és soha nem volt nehezebb archiválni.
Ha nem indult el a rendszer, bebootoltam live CD-ről, és tudtam olvasni a logokat.Egy adatbazis eseten nem szamit hogy binaris-e vagy sem, ugyanis alapvetoen...
Abból a szempontból nagyon is számít, hogy a bináris feldolgozás sokkal gyorsabb. És ha az még az oda-vissza konvertálásnak van is némi plusz erőforrásigénye, cserébe sokkal gyorsabb keresni a bináris logban, sokkal gyorsabban és egyszerűbben szűrhető, sokkal gyorsabban, és szerintem ezek sokkal gyakoribb use casek, mint az, hogy 10 év múlva is olvasni kell.
És mindemellett grepelhető is, és exportálható szöveges formátumban, ha valaki azt szeretné. Nem is értem a syslog melletti ragaszkodást, a journal kb. minden szempontból többet tud. -
urandom0
senior tag
válasz
Rhino666
#34694
üzenetére
Én pl. sosem hallottam még egy indokot a binary log ellen. Az, hogy a log nagy mennyiségű, gyorsan változó adat, amelyet célszerű indexelni és metaadatokkal ellátni, az már eleve implikálja, hogy érdemes bináris formában tárolni.
Nem véletlenül alakultak ki a bináris fájlformátumok, jpg-t sem szöveges dokumentumban tárolunk, és az adatbázisok is jellemzően binárisak. És a log sem egyéb, mint adatbázis.
Na mindegy, a lényeg, hogy mindenki megtalálhatja az a disztrót, ami számára a legszimpatikusabb. -
urandom0
senior tag
válasz
Rhino666
#34692
üzenetére
Persze, minden megoldható, ha újraírjuk, átírjuk, szabványosítjuk, gyököt vonunk belőle, deriváljuk és hozzáadjuk a jogosultságkezelést
A szabványosítás egyébként megtörtént, úgy hívják, bináris log. Itt van hozzá a leírás, itt meg a referencia implementáció.
Amiket leírtál, annak kb. a felét pont a binary log oldja meg, pl. az indexelést vagy a metaadatok hozzáfűzését. Lehet plain textet indexelni, de senki nem csinálja, főleg nem logban, ahol folyamat jönnek és jönnek az adatok, így folyamatosan újra és újra kellene indexelni az egészet.Az 1.-es pl. megoldható manuális munkával (és reménykedsz benne, hogy nem crashel tőle a program), de a journal-ban alapból ott a program PID-je.
A plain textetet is lehet szabványosítani, persze, csak nem annyira jó dolog a flat file db, mert lassú, mert az indexelhetősége közel nulla, stb.... -
urandom0
senior tag
válasz
Rhino666
#34690
üzenetére
A legtöbb pont nem értelmezhető bináris log nélkül, azaz vagy nem lehet megcsinálni szöveges loggal, vagy nem lehet normálisan megcsinálni.
Meg lehet csinálni pl. a logban mezők hozzárendelését valamilyen flat file adatbázis formátummal, mondjuk CSV-vel, az akár nyers formában is olvastható. De attól az még nem lesz indexelhető, attól még lassú lesz (ami embedded eszközökön érezhetően lassít a működésen), stb. -
urandom0
senior tag
válasz
vargalex
#34688
üzenetére
Rosszat nézel, az első 14 pontot kell nézni.
A második 14 pont nem a Syslog ellenében definiálja a Journalt, hanem azokat a követelményeket magyarázza, amiket a Journal tervezése során figyelembe vettek.
Azt nem állítja senki, hogy a második 14 pont közül a szöveges log egyet vagy többet ne tudna teljesíteni. -
urandom0
senior tag
válasz
sh4d0w
#34672
üzenetére
miert kell elbaltazni valamit, ami jol mukodik?
Miért, el van baltázva? Nem logol a rendszered? Vagy nem tudod elolvasni őket?
Én elsősorban a könnyű kereshetőség, szűrhetőség miatt szeretem a bináris logot, és szerintem ez kicsit gyakoribb use case, mint az, hogy 10 év múlva is szükség lesz a logokra. De itt még van pár érv.
Ha nem systemd service, akkor se induljon el - ha mar ugyis rakkent terjedt szet a systemd.
Ha nem systemd serviceként definiálsz valamit (és nem is timer, nem mount unit), akkor
hogy várod el, hogy a systemd kezelje?semmi koze a lokalis systemdnek ahhoz, hogy a tavoli rendszeren mennyi eroforrast zabal a process
Én távoli processzről beszéltem. A távoli processzt a távoli OOM killer lelövi, ha túl sok memóriát eszik.
Egyébként az OOM killer nem systemd feature, hanem kernel feature, és kikapcsolható (ha tényleg ez lövi ki a processzt).ha a userneved szammal kezdodott, akkor root jogosultsagot kaptal
Ez ugyanaz a hiba, mint amiről korábban beszéltünk. A számmal kezdődő usernevet a Systemd invalidnak tekinti (ilyen nevű user nem létezhet a Systemd policyja szerint), ezért fallbackelt rootra. Egyébként 2017-ben lett javítva.
-
urandom0
senior tag
válasz
sh4d0w
#34668
üzenetére
Pl. azert akarhatsz logokat olvasni 10 ev mulva, mert torveny irja elo.
De ez nem 10 év múlva derül, hogy hoppá, vissza kéne olvasni, hogy mi volt 2015 március 18-n, hanem ezt tudja az ember. Ha pedig tudja, akkor nyilván fel is készül rá, átküldi log szerverre, amit aztán archivál.
lehetne, hogy ne huzza fel a halozatot, ha valamiert nem sikerul betolteni a tuzfal konfigot?
Biztos lehet, kérdés, hogy hogy van megoldva a tűzfal konfig betöltése. Ha az egy systemd service, és hibára fut, akkor meg lehet adni a network service-nek is, hogy ne induljon el.
Lehetne, hogy a screenben inditott tavoli processeket ne loje le?
Én tmuxot használok, de sosem lőtte még le a systemd egyetlen processzemet sem. Amikor mégis ilyesmi történt, az az OOM Killer okozta, de hát annak pont az a dolga, hogy lelőjje a túl sokat zabáló processzt.
Lehetne, hogy az alaplap EFI ertekei ne valtozokba toltodjenek be, hanem konstansokba?
Itt nem tudom, mire gondolsz, én a dmidecode és a biosdecode programokat ismerem, de azoknak semmi köze a systemdhez.
-
urandom0
senior tag
válasz
bambano
#34665
üzenetére
Az svr4 init is újraindít processzeket, ehhez csak az inittabba kell egy sor. Nem rakás unit file szerteszéjjel szórva a komplett fájlrendszerben.
Nincsenek szerte szét szórva, minden egy könyvtárban van...
Elhiszem, hogy a doksiban el tudtad olvasni, hogy tud dependelni. A valóságban nem működik rendesen.
Nálam eddig mindig működött. Pont a napokban csináltam rsync-hez egy service-t, ami fájlokat szinkronizál két RPi között,
A szöveges logokat is lehet szűrni grep-pel. Nem találjuk fel újra a kereket.
Hát persze, amíg egy-egy kifejezésre akarsz szűrni, ez addig jó. De ha kicsit pontosabban akarsz szűrni, mondjuk X-Y dátumtartományon belül szeretnéd szűrni egy adott service-től érkező üzenetek közül a critical üzeneteket, de azok közül is csak azokat, amik adott usertől érkeznek, úgy, hogy szerepeljenek benne plusz adatok (pl. a teljes cmd line, a hostname, ...), az journaldctllel egy sor. Grepeld ki ugyanezt...Azokat a beállításokat, amiket a journald-nek meg lehet adni, csak bináris naplózással lehet megadni?
A beállításokat szöveges conf fájlban adjuk meg.
Van biztosíték arra, hogy azokat a bináris naplókat 10 év múlva is fogod tudni olvasni bármivel?
Miért akarnék 10 év múlva logokat olvasni? 10 év múlva jó eséllyel a mostani rendszerek fele sehol sem lesz, nem hogy a logjaikat olvasgassam.
De ha annyira fontosak a logok, be lehet állítani a journal.conf-ban, hogy továbbítsa a syslognak, vagy systemd-journal-remote-tal átkültheted log szerverre.
Egyébként a Systemd-et le fogod tudni fordítani 10 év múlva is.Az, hogy amit svr4 initben 20 másodperc alatt egy darab vi-jal elintézek, azt systemd-nél három nap guglizás után se lehessen elintézni, az nonszensz.
Pl?
-
urandom0
senior tag
válasz
bambano
#34660
üzenetére
Ha be van állítva DNS cím, akkor nem fallbackkel, még akkor sem, ha nem elérhető a DNS szerver. Ha viszont nincs beállítva statikus DNS cím, és a kliens nem kap sehonnan sem DNS címet, akkor lép életbe a fallback DNS.
Egy processz elszállhat tőle független okokból is, viszont van értelme újraindítani a processzt az ok megszűnése után.
De én nem ezért szeretem a Systemd-t, hanem mert úgy általában lehet dependelni a szolgáltatásokra, nagyon egyszerűen. Pl. a network-wait-online-re (vagy a network-pre.targetre) dependelve biztos lehetek benne, hogy addig nem fog elinduli a service-em, amíg nincs hálózat.
És én a logolást is szeretem, nagyon könnyen lehet szűrni egy unitra, vagy adott időtartományra, stb. A journald-nak van egy csomó beállítása, meg lehet adni, hogy meddig logoljon, mennyi tárhelyet használhat maximum, és ezt megint viszonylag egyszerűen.
De ha csak arról van szó, hogy egy sima service-t kell indítani, azt is pár perc összerakni...Ha mást akarsz, mint amit a csomagkarbantartók kitaláltak, akkor nem meglepő, hogy falakba ütközöl, azért ez nem egyedi jelenség.
-
urandom0
senior tag
A Debian pl. nem is Systemd-rá állt át először, hanem azt hiszem, Upstartra. Aztán amikor más disztrók váltottak Systemdre, a Debian a következő kiadást is már azzal adta ki.
Ha jól emlékszem, volt erről szavazás Debianon belül, és akkor döntöttek a Systemd mellett.
De hogy miért döntött az összes fő disztrók a Systemd mellett, annak szerintem a legfőbb oka a praktikum, ugyanis a Red Hat adja a Linuxos fejlesztések egy nagy részét, és ha a Red Hat valamit bevezet, az rendszerint előbb-utóbb megjelenik a többi disztróban is (persze, vannak kivételek). Ugye a Red Hatnál főállású fejlesztők dolgoznak a Linuxon, a közösségi disztrók folyamatosan maintainer hiánnyal küzdenek...
Szóval így könnyebb lekövetni a változásokat. Mert pl. a Gnome is támaszkodik a Systemd-re, és ha egy disztró támogatja a Gnome-ot, akkor ez kevesebb munkát jelent neki hosszútávon, ha eleve Systemd-es. -
urandom0
senior tag
válasz
bambano
#34651
üzenetére
Ismerem a nézeteid a Systemdről, és tudom, hogy ha ezer hozzászólást írnék arról, hogy szerintem miért nincs így, akkor te az 1001-ben leírnád, hogy de, így van
Én is Linux (és Windows) üzemeltetésből keresem a kenyerem, és sosem volt gondom a Systemddel.Csak ezekre válaszolok:
Aki olyan baromságot csinál, hogy ha nemlétező user alatt kellene futtatni egy programot, akkor falbackkel rootra, és azóta sem látszik, hogy javult volna a hozzáállása, azt nem engedjük be komoly rendszerbe.
Ez jelen pillanatban úgy működik, hogy ha nem létező user-t adsz meg, akkor nem indul el a service ("Failed to determine user credentials: No such process").
Lásd még fallback google dns-re.
Ez tényleg rossz lépés volt, de úgy látom, javítva lett, most már megadva FallbackDNS, csak lehetőségek vannak felsorolva:
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google: 8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9: 9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net -
urandom0
senior tag
válasz
Rhino666
#34647
üzenetére
Akkor lenne monolitikus, ha egy bináris lenne az egész, vagy több bináris, de annyira összehegesztve, hogy egyik nélkül nem működne a másik.
Nem tudom, mit jelent az, hogy minden átfut rajta. De simán lehet olyan Systemd buildet csinálni, ahol csak a core van, semmi más. -
urandom0
senior tag
válasz
Rhino666
#34642
üzenetére
- ebbol kifolyolag tulsagosan osszetett, bloatware
- ebbol kifolyolag tele van biztonsagi resekkel
- ebbol kifolyolag mesterseges fuggosegeket general
Ez nem igaz, a systemd moduláris. Van az init része, a service része, meg a journald, ez a core, de ezek is el vannak osztva több, különböző binárisra (és nem is kötelező mindegyiket futtatni). Minden más része opcionális.
De alapvetően az egyes szolgáltatásokat valakinek el kell látnia, teljesen mindegy, hogy azt most a független X bináris látja el, vagy a Systemd projektből jövő Y bináris. Semmivel nem vagy előrébb, ha a systemd-networkd helyett a dhcpcd fut, ha udev helyett eudev fut, ha systemd-journald helyett syslog fut...- azt hazudja hogy ujraindult a service, mikor nem is
Sosem találkoztam ilyennel. A journal corupptiont is csak hallomásból ismerem, de ahogy utána olvastam, sok esetben kiderült, hogy fájlrendszer hiba, vagy lemez hiba okozta.Szerintem a Systemd ellenességnek nincs értelme, már csak azért sem, mert egy csomó pluszt nyújt a Systemd. Szedett-vetett init scriptek helyett egységes, normális (függőségkezelt) service unitok, szűrhető, kereshető, jól használható log, stb.
A UNIX filozófia meg már az X-nél megbukott.
-
urandom0
senior tag
válasz
Rhino666
#34625
üzenetére
Én sem azt mondtam, hogy mindenkinek vannak
De Vasti végigpróbált már ki tudja hány disztrót, több géppel is, és mindegyiknél előjöttek a problémái. Csak bizonyos hardverek, szoftverek és beállítások kombinációja esetén állnak fenn ezek a problémák.
A VRR állapota jelenleg:
Ha te nem esel bele ebbe a körbe, az tök jó, de sokan igen.A HRD monitor támogatás pedig így néz ki:
- KDE Plasma 6.0 introduced experimental HDR support for Wayland session.
- DRM clients can directly pass HDR metadata, but this is not available from regular userspace clients, only specialized software can use it.
- COSMIC developers have promised HDR support in the initial stable release.
- Hyprland introduced HDR support since #8715.
- Wlroots, "Add HDR signalling" MR.
- GNOME 48-beta introduces HDR support and toggle under Wayland.
Ettől függetlenül persze meg lehet próbálni a Voidot, hátha patcheltek benne valamit, ami megoldja a problémákat.
-
urandom0
senior tag
válasz
Rhino666
#34623
üzenetére
Ezek architekturális gondok, nem azért vannak, mert egy-egy disztróban gond van a csomaggal, hanem mert a desktop Linux, szépen kifejezve, kissé le van maradva 4K támogatásban (és VRR-ben is, mint ahogy HDR-ben is).
A Void egyébként nem rossz, én régebben használgattam, nem volt vele gondom. Mondjuk az már tényleg rég volt, 2017 környékén.
-
urandom0
senior tag
válasz
sh4d0w
#34543
üzenetére
ujabb fekete pont a systemd bizonyitvanyaba.
Na, hát mondom. Ha megcsinálná, akkor meg az lenne a baj, hogy miért akar a Systemd mindent megcsinálni
Na mindegy, szerintem is hagyjuk. A lényeg az, hogy hálózati fájlrendszernél meg kell a _netdev paramétert, különben nincs garancia arra, hogy előbb fog felépülni a hálózat, mint hogy a Systemd megpróbálná felcsatolni a megosztást. -
urandom0
senior tag
válasz
sh4d0w
#34538
üzenetére
Na pont ez az, ha a Systemd mindent megcsinál, akkor az a baj, ha nem csinál meg mindent, akkor az a baj... mindegy, csak lehessen szidni a Systemd-et.
Tudsz mondani ilyen peldakat?
Csak a systemd-mount man oldalát kell fellapoznod, ott rögtön találsz egyet:
Mount units referring to local and network file systems are distinguished by their file system type specification. In some cases this is not sufficient (for example network block device based mounts, such as iSCSI), in which case
_netdevmay be added to the mount option string of the unit, which forces systemd to consider the mount unit a network mount.
Mondjuk ha egy SAN egyik LUN-ját akarod felcsatolni, az pont így néz ki, és azt jellemzően a /dev/mapper vagy simán csak a /dev alatt éred el. -
-
urandom0
senior tag
válasz
Vasti74
#34531
üzenetére
Másik rendszerről hoztad át a vm-et? Milyen formátumban, csak simán kimásoltad? Én megpróbálnám OCI formátumba exportálni, és azt importálni a Fedorás Virtualboxba, az működni szokott. Én pont visszafelé, Fedora és Ubuntu között csináltam ilyet.
A Virtualbox egyébként megy, nincs vele gond?
-
urandom0
senior tag
válasz
bambano
#34530
üzenetére
Mert a Systemd nem tudja, hogy melyik fájlrendszer lokális és melyik hálózati, és ez így van jól. A rendszergazda majd eldönti.
Vasti74
Érdemes még beleírni a reconnect és a x-systemd.mount-timeout=5 opciókat is. Az előbbi arra utasítja a rendszert, hogy próbáljon meg újracsatlakozni, ha valamiért lecsatlakozna, a második pedig arra, hogy ne tartson tovább 5 másodpercnél a csatlakozási kísérlet. Mert ha próbál csatlakozni, de nem tud, akkor a fájlkezelőt megakaszthatja.
-
urandom0
senior tag
válasz
Vasti74
#34495
üzenetére
Gondoltam majd a disztribúció váltás megoldja: hát nem, a Neon rövid próbálgatása alatt is előjött a hiba - így szép az élet ;-)
A Mint és a Neon is Ubuntu alapú, ugyanazt a kernel használják. Ha az egyiket cseréled a másikra, akkor gyakorlatilag nem csináltál semmit
Ilyenkor egy teljesen másik családba tartozó disztrót kell kipróbálni, Fedora, Suse, Arch, bármi. Ha megpróbálod Fedorával vagy Endeavourrel, valamelyikkel lehet, hogy működni fog.
Vagy esetleg mainline kernellel kell kipróbálni, Ubuntuéknál ez a HWE kernel. -
#34499
urandom0
senior tag
lionhearted
#34491
urandom0
senior tag
válasz
lionhearted
#34491
üzenetére
Nem azért szeretjük a linuxot, mert bármi megoldható?
De, csak nem mindegy, hogy mekkora munkával, és hogy milyen problémákat okozol azzal, ha megpróbálsz olyasmit ráerőszakolni a disztróra, amit gyárilag nem tartalmaz.
Ahogy a disztró kijön a fejlesztő kezei közül, az úgy van összeállítva és tesztelve.Egy példa: ott van a Guefi nevű program, ez Slackware-hez lett kitalálva. Viszonylag könnyen elindítható más disztrón is, csak kicsit meg kell patchelni. De egy átlagos felhasználó nem fog nekiállni megpatchelni.
Vagy ott a transactional-update, ami SUSE rendszerekhez készült. Biztos, hogy lefordítható más rendszerekhez is, de szerintem néhány lelkes fejlesztőn kívül senki nem foglalkozik ezzel. Arra pedig pláne nem vállalkozik senki a fejlesztőkön kívül, hogy elkezdjen tranzakció alapú frissítéseket használni olyan disztrón, ami nem ehhez lett kitalálva.
De egyszerűbb példa a szóban forgó RPMFusion, ami csak egy plusz repó, mégis képes csomagproblémákat okozni Fedorán. -
urandom0
senior tag
-
urandom0
senior tag
válasz
kovaax
#34483
üzenetére
Logikusan belegondolva ilyen szempontból olyan nagy különbség nem lehet a disztrók között (kivéve a rollingokat), mert valahogy csak meg kell kapni a csomagok friss verzióit.
Ha kevesebb frissítés jön, az azt jelenti, hogy kevésbé frissek a programok. A friss csomagoknak az az ára, hogy több frissítés jön. -
urandom0
senior tag
válasz
kovaax
#34481
üzenetére
A Fedora sok frissítést tölt le? Akkor te még nem láttál Tumbleweed-et
Szerintem nem tölt le sokat. Azért nem egy nem rolling disztró, akármennyire is friss. Két kiadás között megpróbálja tartani a programok főverzió számát, a programok többségénél ez sikerül is. Alapvetően csak biztonsági frissítéseket és javításokat tölt le, és amit lehet, azt delta RPM-ben (bár tapasztalataim szerint ez nagyon-nagyon kicsike méretcsökkenést jelent csak).
Azt mivel mérted ki, hogy mennyit ír a frissítésekkel?Debian testinget nem szokták ajánlani napi használatra, mert lassabban kap biztonsági frissítéseket, mint a stable.
-
urandom0
senior tag
válasz
Vasti74
#34472
üzenetére
Nem kell félni a Fedorától sem, annyira nem más világ. De szerintem ezen a problémádon a disztró váltás nem fog segíteni, ez kernel+libek és asztali környezet kérdése.
Alapvetően, ha a GPU driver és a VA libek telepítve vannak, akkor illik mennie a HW gyorsításnak, legalább a lejátszóprogramokban. A böngésző már más kérdés, nem mindegyik tud HW gyorsítást, és azon belül sem mindegyik tud HW videó gyorsítást. Én letesztelném Chrome-mal és Firefox-szal is, a flatpakos és a nem flatpakos verziókkal is.Idővel biztos lesz majd HW gyorsított frakcionális skálázás, az elkövetkezendő 10 évben
A Gnome sajna tényleg le van maradva ebben, a KDE az egyetlen, ami nincs.
Ha esetleg mégis kipróbálnád a Fedorát, ezt ajánlom átböngészésre: A DNF csomagkezelő -
urandom0
senior tag
Egyik lehetőség, hogy használod a find -o kapcsolóját, ami VAGY logikai kapcsolatot jelent a minták között:
find . -iname "img_*.jpg" -o -iname "img_*.png" -o -iname "img_*.heic" ...
És felsorolod az összes lehetséges mintát.
A man oldal ezt írja az -o kapcsolóról:
expr1 -o expr2
Or; expr2 is not evaluated if expr1 is true.A másik lehetőség, hogy reguláris kifejezés alapú mintát használsz, abból is az egrep típusút. Ez bonyolultabb, mint a find alapértelmezett glob típusú mintái, de emiatt több lehetőséget is nyújt, van pl. benne VAGY operátor ("|"):
find . -regextype egrep -iregex ".*img.*(jpg|png|heic|mp4)$"A zárójeles részben felsorolod az összes kiterjesztést, amit keresel. És szerintem érdemes mindenhol a kapcsolók i-típusú változatait használni, mert az nem tesz különbséget a kis- és nagybetűk között.
Itt van egy rövidebb és egy hosszabb leírás az extended regexpről:
https://en.wikibooks.org/wiki/Regular_Expressions/POSIX-Extended_Regular_Expressionshttps://pressbooks.senecapolytechnic.ca/uli101/chapter/extended-regular-expressions/
-
#34374
urandom0
senior tag
gyuri860213
#34370
urandom0
senior tag
válasz
gyuri860213
#34370
üzenetére
-
-
urandom0
senior tag
válasz
bviktor93
#34339
üzenetére
Lehet, hogy Windowst kéne először telepítened, és arra a GNS-t, lehet hogy tényleg az ő VM-jükkel van valami gebasz.
Vagy esetleg tényleg meg lehetne próbálni egy KVM-es VM-et felállítan, és oda behúzni a Virtualbox vhd-ját (át kell majd konvertálni).
Nekem erős a gyanúm, hogy ez egy Ubuntu bug lesz. -
urandom0
senior tag
OOM-nél szerintem simán kilőné a rendszer a processzt. És nem is úgy néz ki, mint egy processz összeomlás, mert akkor stack trace-t is logol.
Fogalmam sincs, mi lehet ez, de én első körben megpróbálnám, hogy egy nem Debian/Ubuntu alapú rendszer is ugyanezt csinálja-e. -
urandom0
senior tag
válasz
CPT.Pirk
#34332
üzenetére
A Github oldalon írnak róla:
The etc directory of the repo contains sample configuration files for different init(1) systems, e.g. FreeBSD's rc.d, Gentoo's openrc, and systemd which is used in most contemporary Linux distros. Those files may be used as templates. They are likely to require adjustments to the actual distribution/installation where they are to be used.
A Github repóból másold ki a /etc/systemd/wsdd.service fájlt, másold be a saját /etc/systemd/system könyvtáradba, a wsdd.defaults fájlt pedig mentsd le egy /etc/default/wsdd nevű fájlba. Aztán mondd neki, hogy
systemctl daemon-reload, majdsystemctl enable --now wsdd.service, és elmiletileg már fut is a service. -
#34328
urandom0
senior tag
Roland861010
#34325
urandom0
senior tag
válasz
Roland861010
#34325
üzenetére
Én nem játszok, csak azt tudom, hogy a Nobara Linux kifejezetten játékosokra szabva van összerakva. Sose próbáltam, de szerintem tegyél vele egy próbát.
-
urandom0
senior tag
válasz
Ablakos
#34309
üzenetére
Én megnézném az /usr/lib/systemd/system/ és a /etc/systemd/system/ mappákban milyen .mount és .automount fájlok vannak, ha vannak egyáltalán. Ha vannak, én kitörölném őket.
Aztán megnézném, hogy nincs-e valamilyen felesleges mount vagy automount a systemctl -type=mount,automount paranccsal. Innen is lehet első körben tiltogatni, aztán reset, majd ha elérhető a megosztás, akkor törölni is. Esetleg megnézni, nincs-e valamilyen service, ami ilyet okozhat. -
urandom0
senior tag
válasz
cog777
#34304
üzenetére
Ahol csak lehet, kerülöm a JavaScript-es/TypeScript-es szutykokat. Egyszer csináltam eg gyors összehasonlítást VS Code és Sublime Text között (a Sublime-t nagyrészt C++-ban írták). Egy frissen telepített gépre feldobtam mindkettőt, pluginok, stb., minden extra nélkül. Mondanom sem kell, hogy a Sublime sokkal gyorsabban indul, és sokkal kevesebb memóriát ill. procit eszik.
Egy darabig használtam a VS Code-ot, amíg a Copilot-ot próbálgattam, de aztán úgy voltam vele, hogy nem éreztem előnyét.Most Eclipse-ben dolgozom (feldobtam a legfrissebb verziót, a repómban lévő 2020-as van), tulajdonképpen meg vagyok elégedve vele. Annyi előnye van a Kate-hez képest, hogy ez on-the-fly buildel, kevesebbet kell kézzel fordítanom, illetve van benne refactorálás, szól a hiányzó vagy a felesleges importok miatt, ilyesmik.
-
urandom0
senior tag
Na, igaz. Mondjuk régebben a Dart LSP-akartam összekötni Kate-tel, az nem sikerült, ezért örülök most ennek nagyon.
Mondjuk felmerülhet a kérdés, hogy méér nem használok normális IDE-t. Imádom az IntelliJ-t például, öröm nézni, ahogy a 8GB RAM-ból megeszik 4-et csak az, amikor elkezdi beindexelni a projektet
A többit meg hagyjuk, a Netbeans és az Eclipse is gagyi, de legalább nehézkes. -
-
urandom0
senior tag
válasz
galaxy55
#34267
üzenetére
Úgy tűnik igen, hitelesítés nélkül is beenged. Van róla külön blogbejegyzés is: https://www.unifore.net/product-highlights/hacking-accessing-dahua-dvr-nvr-ip-camera-via-telnet.html
Én nem tudom kipróbálni, nincs Dahua eszközöm, de szerintem Tibor barátunk fel tud világosítani ez ügyben.
-
urandom0
senior tag
-
urandom0
senior tag
válasz
cog777
#34234
üzenetére
- EFI partíciót meghagyod, és állítsd be rá ESP és boot flageket. Bár a Grub-nak egyik sem szükséges, elméletileg simán bebootol akkor is, ha nincsenek beállítva, de a Windowsnak nem árt.
- Lehet, de ha a swap partíciót is titkosítani akarod, akkor kicsit nehezebb dolgod lesz. Itt van egy útmutató: https://askubuntu.com/questions/1441208/encrypted-partitions-luks-with-login-password-hibernate
- Ezt nem tudom, de szerintem igen. -
#34228
urandom0
senior tag
lionhearted
#34226
urandom0
senior tag
válasz
lionhearted
#34226
üzenetére
Gondolom azért futtatnak helyben szervert, mert valami olyasmi is fut rajta, amit nem lehet, vagy nehéz megoldani máshogy.
-
urandom0
senior tag
Az unauthenticated itt nem arra vonatkozik, hogy bárki bejöhet sshd-n keresztül. Hanem azt az időtartományt takarja, ami között létrejön az SSH kapcsolat a szerver és a kliens között, és amíg megtörténik a bejelentkezés, tehát a felhasználó beírja a jelszót, vagy amíg a rendszer ellenőrzi a kulcsot... ez a szakasz unathenticated, mert ekkor még nem autentikált a kliens.
Ennek az időtartamát lehet állítani az sshd_config-ban a LoginGraceTime paraméterrel. -
urandom0
senior tag
Távoli, root jogosultságú kódfuttatást lehetővé tevő sebezhetőséget találtak az OpenSSH-ban:
https://www.qualys.com/regresshion-cve-2024-6387/
https://hup.hu/cikkek/20240701/root_jogokhoz_juttathatja_a_tamadot_a_regresshion_openssh_szerver_serulekenyseg -
urandom0
senior tag
válasz
roseben
#34203
üzenetére
Szerintem az sem mindegy, hogy armv6, armhf, armv8, aarch64, ... vagyis hogy pontosan milyen architektúráról van szó.
A legtöbb disztrónak egyébként van ARM portja, az alkalmazások messze túlnyomó többsége le van fordítva.
Az más kérdés, hogy Linux modulok mennyire vannak egy ilyen géphez. Lehet, hogy feltelepítenél egy akármilyen disztrót, aztán se wifi, se normális kép, stb. -
urandom0
senior tag
Vagy wgettel, curllal indítanak kéréseket, vagy valami PHP script csinálja, de szerintem ez utóbbi. Ahogy írtam, ha az auditd fent és van rendesen be van konfigolva, az képes logolni a kimenő kapcsolatokat.
ausearchprogrammal elég részletesen lehet keresgélni a logokban.
De a php-fpm logjait, és az httpd logjait is nézegesd, pl. ha sok 404-es hiba van bennük, az máris gyanús.Amit még elfelejtettem, hogy a cron logokat és a cron feladatokat is nézd át, minden usernél egyesével.
-
urandom0
senior tag
De pontosan mit csinál az a bot? Más szerverek honlapjain próbálkozik 80-as vagy 443-as porton? Vagy SSH-t próbál feltörni? Vagy mit csinál?
Más szerverek felé irányuló kapcsolat indítható közvetlen a te szervereden futó bináristól, ezt a legkönnyebb észrevenni, nézegesd, hogy milyen processzek futnak a szerveren, milyen kapcsolatoknak nyitnak kifelé (lsof, netstat, ss, tcpdump, wireshark). Valamint állítsd be netfilter/iptables logot, és telepítsd az auditd-ot, és ahhoz is állíts be szabályt.
Indítható kapcsolat PHP-ból is, vagy bármilyen szerver oldali nyelvből. Ezt nem is tudom, hogy lehetne rendesen logolni, én a php-fpm log_leveljét állítanám maxra. Végső soron persze ez is az oprendszer szintjén fog kijönni.
Vagy ha más környezeted is van (Nodejs pl.), akkor annál is maxra kell állítani a log_level szintjét. -
-
-
urandom0
senior tag
válasz
bambano
#34146
üzenetére
Ebbe így még nem gondoltam bele.
Én 2000 fölé szoktam rakni az SSH portot a WAN felől elérhető eszközeimnél. Most ha lenne valamilyen kártevő valamelyik gépemen, akkor első körben le kéne állítania az sshd-t, hogy bindelni tudjon a portjára, de ehhez már eleve root jog kell (ha csak nincs valami local privilege escalation vulnerability a rendszerben), de ha már van root joga, akkor cseszhetem. Akkor ellophatja a privát kulcsomat, stb.
Te hát mindenképp kell neki root jog, ha át akar verni. -
urandom0
senior tag
válasz
#78522999
#34136
üzenetére
Én a védelmet még kiegészíteném annyival, hogy:
- SSH-hoz publikus kulcs alapú ÉS jelszavas védelmet állíts be
- a root belépést tiltsd, és explicit ad meg, kik léphetnek be (AllowUsers)
- ne RSA kulcsot használj, hanem ed25519-et
- nem baj, ha használod az openscap-scanner-t (RHEL-en oscap néven fut)
- auditd-ot már írták, azt én is tudom javasolni (https://sematext.com/glossary/auditd/)
- rendszeresen nézegesd a cron logjait, a tmp mappa tartalmát, journald-ban az SSH belépések forrását, időpontjait, ha bármiben bármi gyanúsat látsz, azonnal derítsd fel
- csinálhatsz ún. geofence-t is, ez azt jelenti, hogy rendszeresen (naponta 1x) lehúzod az országokhoz tartozó IP címek listáját, és egy scripttel tiltod azokhoz az országokhoz tartozó címeket nftables-ben, amelyek felé nem nyújtasz szolgáltatást, nálam tipikusan ilyen szokott leni Kína, Dél-Korea, Oroszország... -
urandom0
senior 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. -
urandom0
senior 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
senior 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
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 --verifyis csak annyit tud mondani, hogy "invalid argument", na akkor tudod, hogy hosszú napod lesz. -
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...
-
-
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.
-
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.
-
urandom0
senior tag
Megjelent a Fedora 40: https://fedoraproject.org/
Mondjuk vasárnapig várhattak volna vele
[kép]
Új hozzászólás Aktív témák
Hirdetés
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Gyermek PC játékok
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- AKCIÓ! Intel Core i9 14900K 24 mag 32 szál processzor garanciával hibátlan működéssel
- ÁRGARANCIA!Épített KomPhone i9 14900KF 32/64GB RAM RX 9070 XT 16GB GAMER PC termékbeszámítással
- REFURBISHED - HP USB-C Universal Dock G1 docking station (DisplayLink)
- HP Probook 650 G4 15,6 i5-8350u 8. gen. GYÁRI MAGYAR VILÁGÍTÓ BILL!!!
- Microsoft Surface Laptop 3 - 15 col - Fekete
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest