- sh4d0w: Csak a profit - emberélet nem számít
- vrob: Az IBM PC és a játékok a 80-as években
- gban: Ingyen kellene, de tegnapra
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Magga: PLEX: multimédia az egész lakásban
- bb0t: A könyvelő szakma halott?
- Geri Bátyó: B550 szűk keresztmetszet, de mi és miért?
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
-
LOGOUT
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
-
#34949
lionhearted
őstag
urandom0
#34947
-
.-..-.
tag
válasz
urandom0
#34947
üzenetére
Nálam 30perc a "findtime", de igen, így értettem én is az "aktív próbálkozások száma"-t.
Sajnos kell a publikus net (nginx, apache tomcat webapps, etc), ezért a VPN nem lehetséges.
De amúgy amíg a "zsiványok" az ajtó előtt toporognak nincs baj.
Csak arra voltam kíváncsi, hogy másnál is ilyen mennyiségben próbálkoznak-e. -
-
daninet
veterán
válasz
urandom0
#34886
üzenetére
tanultam újakat most
SElinux nem kezeli a fuse csatolt meghajtókat így onnan mindent blokkol. Például egy NTFS partíció. Ez azért van, mert nincs fájl címkézés NTFS alapon és nincs rá mód onnan bármit engedélyezni. Persze, linux, használjak más partíciót, de egy hordozható HDD-t nem tudok ext4-re formázni, hogy használható legyen mindenhol. -
bambano
titán
válasz
urandom0
#34706
üzenetére
"Mivel én nem használok DRBD-t": nem te mondtad, hogy annyi az egész, hogy csinálunk egy unitot és akkor működik?
Nem kell tudod, hogy mi az a drbd, nem kell tudnod, hogy hogyan konfigurálódik be maga a drbd, elég, ha azt tudod, hogy systemctl enable drbd.unit (most nem írom a betű szerint pontos parancsot) elindítja.Ezek után azt kell tudnod, hogyan csinálj egy olyan működő mount unitot, ami egy blokkos eszközt megadott csatolási pontra felmountol.
Utána azt kell tudnod, hogy hogyan szinkronizálod össze azt, hogy a drbd unit csak a hálózat éledése után induljon, és a unit, ami a lightdm-et indítja, megvárja, hogy ez a specifikus mount unit lefusson.
Ezt így kell csinálni a systemd-ben.
CSAK NEM MŰKÖDIK!
Akármennyi doksit olvastam, gugliztam, NEM MŰKÖDIK!
Ami erről a systemd doksijában van, az NEM IGAZ.
NAGYON SOK napot elcsesztem erre, gugliztam, rebootoltam ezerszer ÉS NEM MŰKÖDIK.Tessék, itt van előtted a pálya, bizonyítsd be, hogy én vagyok a hülye. Ja, és ez az első forduló, ha megoldottad és nekem is működik, akkor jön a következő feladat
Meg kellene kis magyarázatocska, hogy a szerteszéjjel össze-vissza linkelt unitok (a wants meg a provides meg a társai) mitől egyszerűbbek, mint két sor az rc.local-ba.
Érdekelne az is, hogy erre csinálok egy mount unitot, az nem működik, csinálok egy exec unitot, amiben egy darab mount parancs van, az működik.
Mellesleg abba az rc.local-ba, amire külön systemd unitot kell engedélyezni, hogy a systemd bootkor lefuttassa. sysv initben meg belinkeled a runcontrol szkripteket oszt jónapot.
-
salaud
aktív tag
válasz
urandom0
#34697
üzenetére
10 éve használok desktopon Linuxot
Csóró kezdő vagy, én több mint húsz éve. És akkor mi van?
Systemd-es rendszert használok, mert lusta vagyok átállni openrc-re, vagy bármi más normális init rendszerre, de közben pontosan tudom, hogy a systemd nélküli rendszer kisebb, gyorsabb, hibatűrőbb. Egyszer majd ha lesz sok időm és türelmem, megszabadulok tőle. -
bambano
titán
válasz
urandom0
#34697
üzenetére
"10 éve használok desktopon Linuxot": örülök, hogy fiatal pályakezdők is elkezdenek linuxozni
Ez egyébként valami isteni gondviselés lehet, mert nekem pont két órával ezelőtt szállt el egy gépem memória hiba miatt. Óriási csodának gondolom, hogy nem dőlt össze a komplett root fájlrendszer.
-
bambano
titán
válasz
urandom0
#34681
üzenetére
tehát neked kell egy összekonfigurált drbd meg egy komplett teszt rendszer, ahol egy ilyenre rá tudsz nézni, és megfelelő mennyiségű találgatás után esetleg lesz megoldás.
ha te kérdeznéd ugyanezt, hogy oldjam meg sysv inittel, én fejből megmondanám, hogy mit csinálj.
Hát EZ a nagy különbség.
-
válasz
urandom0
#34695
üzenetére
Akkor olvass vissza, elhangzott nehany.
De itt egy par:
- konnyebben korrumpalodik
- nehezebb beleolvasni
- indokolatlanul komplikalt
- plusz eroforrast igenyel oda-vissza konvertalni
- kritikus esetben nem hozzaferheto
- nehezebb archivalni
- stb.Az, hogy ember altal feldolgozando adatot tartalmaz, indukalja, hogy ember altal olvashato formatumban erdemes tarolni, ugyanugy ahogy a hangfajlokat sem jpg-ben es a tablazatokat sem pdf-ben taroljuk. Megtehetnenk, csak lof@sz ertelme sem volna, ugyanugy ahogy a logokat binariskent tarolni sincs.
Egy adatbazis eseten nem szamit hogy binaris-e vagy sem, ugyanis alapvetoen (normalis esetben) nem turkal benne az ember, mint mondjuk ahogy a logok kozott es ott kritikus szerepe van a gyors eleresnek, nem ugy mint a logok eseteben.
Foggal-korommel ragaszkodsz egy sz@r megoldashoz, csak mert ehhez szoktal hozza...
De ha tegyuk fel ezek nem volnanak megfelelo indokok a binary log ellen, az meg nem elegendo a letezesehez, egesz addig amig nem szolnak ervek mellette. Lehet, csak minek? Lehet szemenkent csomagolni a makot is, csak nincs ertelme.
-
válasz
urandom0
#34693
üzenetére
Lehet csurni-csavarni, az elso 13 pont kozul egyik sem indokolja a binaris logot, meg csak utba sem esik. Egyenesen logikai bukfenc, hogy ezeknek a megvalositasahoz minek kellett binarissa tenni a formatumot, de ha teged ennyire nem zavar a felesleges konvertalas oda-vissza, akkor nem akarlak lebeszelni rola.
Szerintem KISS, if it ain't broke, don't fix it es don't overengineer, ezek alapjan pedig semmi letjogosultsaga nincs a binaris logoknak, tehat nem is hasznalom oket es megis valahogy kepes vagyok a letezesre ennek ellenere.
-
válasz
urandom0
#34691
üzenetére
1. Egyszeru fajlrendszer jogosultsaggal meg lehet ugrani
2. Plain text formatumban is lehet szabvanyositani
3. TZ-t tartalmazo timestampet is lehet plain textben
4. Megint csak szabvanyositas kerdese
5. Plain text indexelheto
6. Szabvanyositas
7. Jogosultsag
8. Jogosultsag
9. Szabvanyositas
10. A rotacio megoldott problema
11. Megoldott problema
12. Megoldott problema: tar pigz
13. Megoldott problema
14. Nem igazan jut eszembe, hogy mi haszna volna binaris fajlokkal teleszemetelni a logokat, ez egy ettol teljesen fuggetlen problemanak tunik, de megadom ezt az egy pontot, csak hogy ugy tunjon hogy egyetlen egy szempontbol van ertelme a binaris logolasnak. -
válasz
urandom0
#34687
üzenetére
14 pontban ossze van foglalva hogy (szerintuk) mitol jobb a journalctl mint a syslog, nem pedig az, hogy mi haszna a binaris logoknak. Es ahogy nezem a felhozott 14 pont java is vitathato, vagy eleve nemletezo problema. Tipikusan "igeny nem volt ra, csak unalmaban hozzanyult" csak mert nem hallott meg az "if it ain't broke, don't fix it" elvrol.
De ahogy nezem tenyleg nagy vendor lock-in rajongo lehet, ha mar kepes volt google doc-kent megosztani valami szabad, fuggetlen formatum helyett (html, md, plain text).
-
vargalex
félisten
válasz
urandom0
#34687
üzenetére
A felsoroltakból a 4-es pont a kedvencem:
"Portable: journal files should be usable across the full range of Linux systems, regardless which CPU or endianess is used. Journal files generated on an embedded ARM system should be viewable on an x86 desktop, as if it had been generated locally."Mert ez a plain text logra nem igaz??? Ugyanis csak akkor lenne előny.
-
bambano
titán
válasz
urandom0
#34670
üzenetére
jaja, logszerver... múltkor is kaszálnom kellett, mert logszerverek nőttek a réten és zavarták a kilátást.
De mondok neked egy relatíve egyszerű dolgot:
debian trixie, van egy bekonfigurált drbd-m. ezt fel kell moutolni a home-ba, és ha sikerült, akkor engedni, hogy elinduljon a lightdm.ez rc.localban pár sor. lássuk a te systemd-s megoldásodat. ez egy ilyen történet, amire én gondoltam, a csomagkarbantartók meg nem. de a második fordulóra van ennél jóval cifrább is.
-
válasz
urandom0
#34670
üzenetére
"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."
Visszautalnek bambano mondandojara: miert kell elbaltazni valamit, ami jol mukodik?
"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."
Ha nem systemd service, akkor se induljon el - ha mar ugyis rakkent terjedt szet a systemd.
"É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."
Mas meg screent es igen, lelovi a tavoli processt - semmi koze a lokalis systemdnek ahhoz, hogy a tavoli rendszeren mennyi eroforrast zabal a process, lehet, hogy az a dolga (csak a teljesseg igenye nelkul: DB reorg, sha checksumok stb.).
"Itt nem tudom, mire gondolsz, én a dmidecode és a biosdecode programokat ismerem, de azoknak semmi köze a systemdhez."
https://github.com/systemd/systemd/issues/2402
Ezen felul persze azt is tudta a systemd (nem tudom, hogy ez igy van-e meg): ha a userneved szammal kezdodott, akkor root jogosultsagot kaptal, maga Poettering is kihasznalta ezt a bugot.
-
válasz
urandom0
#34670
üzenetére
Tehat a logoknak ket fontos szerepe van, az egyik a debugolas a masik pedig az archivalas. Mindketto plain text formatumban tortenik hogy ember altal olvashato legyen. A systemd pedig binaris formatumban tarolja oket, mert ____________.
a) hulye
b) igy garantalja a rendszeres korrumpalodast
c) igy plusz eroforrast kepes pazarolni
d) a fentiek mindegyike -
válasz
urandom0
#34666
üzenetére
Pl. azert akarhatsz logokat olvasni 10 ev mulva, mert torveny irja elo. A text logot 10 ev mulva az akkori okoshajcsaton is el fogom tudni olvasni, a binarist meg nem, mert ahhoz kell egy futo systemd, meg az, hogy ne korruptalodjon a binarist log addig - ami nem erossege a journalnek.
De ha mar systemd: lehetne, hogy ne huzza fel a halozatot, ha valamiert nem sikerul betolteni a tuzfal konfigot? Vagy ha mar mindenaron felhuzza, akkor szoljon a sysadminnak, hogy szaros a palacsinta? Lehetne, hogy a screenben inditott tavoli processeket ne loje le? Lehetne, hogy egy printer install miatt ne baszodjon el a tuzfal konfig? Lehetne, hogy az alaplap EFI ertekei ne valtozokba toltodjenek be, hanem konstansokba?
Hja, Poettering azota elment fejlesztonek a Microsofthoz - roluk azert mult penteken feltettem a kerdet, hogy minek irnak egyaltalan programokat: a marciusi javitocsomag 57 biztonsagi hibajabol 44 magas, vagy kritikus besorolasu a CVSS 3 szerint...
szoval igen, osszenott, ami osszetartozik. -
bambano
titán
válasz
urandom0
#34662
üzenetére
Ha hibás a dns konfig, akkor hibásnak *KELL* lenni a hálózatnak, különben sosem derül ki, hogy hibás a konfig. Annak is célnak kell lenni, hogy kitakarítod a hibákat a rendszerből.
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.
Elhiszem, hogy a doksiban el tudtad olvasni, hogy tud dependelni. A valóságban nem működik rendesen.
A szöveges logokat is lehet szűrni grep-pel. Nem találjuk fel újra a kereket.
"biztos lehetek benne, hogy" a szolgáltatásod vagy elindul, vagy nem.
Azokat a beállításokat, amiket a journald-nek meg lehet adni, csak bináris naplózással lehet megadni? Van biztosíték arra, hogy azokat a bináris naplókat 10 év múlva is fogod tudni olvasni bármivel?
Azt akarom, hogy ha más a feladat, és svr4 initben pikk-pakk össze lehet rakni, akkor systemd-ben még kevesebb meló legyen összerakni, különben nincs okom váltani. 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.
-
vargalex
félisten
válasz
urandom0
#34662
üzenetére
Azért a network-wait-online-val kapcsolatban lenne negatív tapasztalatom. Nagyon nem úgy működik, ahogy elvárná az ember. Van saját fejlesztésünk egy ügyfélnél, hogy-hogy nem, éppen RHEL-en, ami egy Oracle szerverhez kapcsolódik. A service file-ja dependel a
network-online.target-re. Mivel az ügyfélnek van RHEL support-ja, így felvette velük a kapcsolatot. A vége az lett, hogy kezeljük az alkalmazásban... Meg is tettük.
Simán tudtuk egy netcat-el reprodukálni és prezentálni nekik. -
bambano
titán
válasz
urandom0
#34659
üzenetére
"Ez jelen pillanatban úgy működik": és itt a hangsúly a jelen pillanaton van.
Szerintem ha rossz a dns konfig, akkor működjön rosszul (vagyis ne működjön). A hiba elmaszkolása azt okozhatja, hogy a hiba oka nem kerül kijavításra.
Egyébként ezt az egész systemd alapgondolatot nem értem. Azt mondják, akik szeretik, hogy azért is jó a systemd, mert menedzseli a processzeket, újraindítja, ha elszálltak, stb. De miért is száll el egy processz, amire fontos feladatokat akartak bízni? Ha egy processz elszáll, akkor nem az a megoldás, hogy körbepakoljuk mindenféle szeméttel, ami újraindítja (és maga is bughalmaz), hanem az, hogy kijavítjuk a programot és akkor nem fog elszállni.
Egyébként amíg out of the box használom a debiant, nekem sem szokott semmi bajom lenni, még a systemd-vel sem. De abban a pillanatban, ahogy valami mást akarok, mint a csomag-karbantartók, rögtön falakba ütközöm.
-
bambano
titán
válasz
urandom0
#34644
üzenetére
Az első és legfontosabb probléma a systemd-vel, hogy Pöttering elvtárs sokszor és alaposan eljátszotta a bizalmat. 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. Lásd még fallback google dns-re. És akkor még nem beszéltünk arról, hogy pulseaudio téren is futott már ámokot az elvtárs.
A második probléma, hogy a systemd nem működik. Amennyiben olyat szeretnél vele csinálni, ami nem az alap, akkor nem működik.
Harmadik, hogy a unix az sor alapú szöveges dolgokra van optimalizálva. Az, hogy a sima txt logokról áttért binárisra, az lehet egy jó választás, ha windowsod van, de unixon nem csinálunk ilyet.
Negyedik, hogy ki a franc ez a pöttering, hogy rákényszerít engem és másokat is olyan plusz munkára, ami nem térül meg soha? Az eredeti sysv init tudott mindent, amire valóban szükség van, ha kellett syslog, ntpd, felraktad, oszt jónapot. Abnormális kiadásokra kényszerít. És ne csak arra gondolj, hogy otthon van egy linuxod, amit néha bekapcsolsz két windowsos játék között, hanem arra is, hogy vannak, akik linux üzemeltetésből keresik a kenyerüket.
Mondjuk Pöttering pont annál a redhat-nél dolgozott sokáig, akik hamisítottak már gcc-t is, mit csodálkozunk. Azóta meg összenőtt, ami összetartozik.
Tőle függetlenül én azt egy beteges dolognak gondolom, hogy egyes programozók akkor is programoznak, amikor nincs mit értelmesen programozni. Tölthetnék hibakereséssel is az idejüket, csak az büdös.
KISS: Keep it stupid and simple. Ami nem ilyen, az nem unix. Csináljon csilivili processz managementet windowsra, az oda való, minket (pláne a mi munkaeszközeinket) meg hagyjon békén.
-
-
válasz
urandom0
#34542
üzenetére
Bocs, de ez most nyafi-nyafi.
Igenis baj, hogy mindent is felzabal a systemd, de ha mar ezt teszi, akkor meg igenis elvarhato, hogy meg tudja kulonboztetni a lokalis filesystemet a remote-tol.
A peldaddal (es a man oldallal) szembeallitva bennem megint felmerul, miert nincs egy sajat adatbazisa az eldonthetetlen mountokrol, valoszinuleg ebbol nincs sok, ahogy maga a man is referal ra.
De vegul is mindegy, legfeljebb ujabb fekete pont a systemd bizonyitvanyaba. Reszemrol a tema lezarva, ha meg jon valasz, persze szivesen elolvasom. -
-
Vasti74
senior tag
válasz
urandom0
#34480
üzenetére
Nem félek olyan nagyon ;-) , igazából valószínűleg parancssorban már nem sok mindent bogarászok, a grafikus felületen dolgozva meg a KDE nagyjából mindenhol KDE, sok különbséget nem fogok látni.
Azon már túl vagyunk, hogy a a hardveres gyorsítás működik, a böngészőkben is, meg a videólejátszókban is, ennek ellenére ha nem 100 vagy 200%-ra van skálázva a munkaasztal, akkor MATE és Cinnamon alatt legalábbis az idegesítő és a használhatatlan között van valahol a dolog.
Úgy néz ki, a KDE legalább tünetileg kezeli a dolgot, mert mint kiderült valamiért hardveres gyorsítás ott sem lesz pl. 150 vagy 175%-ra skálázott asztal mellett, de legalább a szoftver jobban megoldja a megoldandót: a KDE Neon egyelőre USB-ről futtatva ilyen "nem egészre" skálázva is akadozás nélkül játszik Youtube-ról és és a NAS-ról a 4k videókat.
Most már csak a megfelelő disztribúciót keresem: a Neon tetszett, de le lettem beszélve ;-) , a Kubuntu-ról is gyakorlatilag, úgyhogy kipróbálom virtuális gépen - live rendszerként a Fedora-t és az EndeavourOS-t, aztán majd kiderül, melyik lesz.
Közben lett valamelyik kernelfrissítés óta egy olyan problémám a Mint Cinnamon-al, hogy az USB-s FX-Audio DAC-X6 kütyüm naponta többször elfelejt működni, illetve hang helyett fehér zajt ad ki magából... Csak az USB kábel kihúzása-visszadugása segít. 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 ;-)
-
kovaax
őstag
válasz
urandom0
#34482
üzenetére
De láttam Tumbleweed-et, használtam is egy rövid ideig. Csak az egy rolling disztró, más kategória.
Meg nem mondom neked, hogy mivel lehet nézni a lemez írását, na azt megnéztem frissítés után, hogy hol tart, majd kikapcsoltam a gépet. Aztán egy hét múlva bekapcsoltam, és lefrissítettem, és meglett, hogy mennyit írta a lemezt a frissítés. Aztán használtam addig, míg nem lettek új frissítések, és frissítés előtt megnéztem, hogy normál használattal mennyit íródott a lemez. Nem pontos értékek, természetesen, de meglepő lett az eredmény.
"Élesben" csak stabil Debiant használok.
-
kovaax
őstag
válasz
urandom0
#34480
üzenetére
A Fedora előnye és hátránya, hogy nagyon újak benne a szoftverek. Újabb vasakat is támogat, viszont temérdek frissítés jön ki szinte minden héten. Anno amikor ezt a laptopot vettem, amiről írok, azt raktam rá, de aztán kiderült, hogy többet írom az ssd-t a frissítésekkel, mint a konkrét használattal, úgyhogy gyorsan lecseréltem Debian testing-re (a stabil nem támogatott mindent még rajta)...
-
bviktor93
tag
válasz
urandom0
#34348
üzenetére
Ja, hogy bare-metal-ra gondoltatok a VM helyett... Mert még sosem csináltam olyat, és elég kezdő vagyok GNS-be
és csak pár nem túl hw. igényes image-el szeretnék gyakorolni.
De egyébként köszi a tippet, megpróbálom bare metal. Találtam is hozzá egy elég jónak tűnő leírást, nem tűnik túl bonyolultnak... -
bviktor93
tag
válasz
urandom0
#34343
üzenetére
Hogy érted? Most is a Linux-os verziót használom. Arra utaltam, hogy más disztóval is ki fogom próbálni még, most a 24.04 LTS Ubuntu van a gépen. Valószínűleg egy Debiannal is megpróbálom még.
Igazából, hogy min fut maga a GNS3 program nem is annyira lényeg. A VM használ sok erőforrást, meg annak kell ez hardware-es VT-x virtualizáció. A GUI-s programot futtathatnám akár Windows-on is, és a remote szerverként be lehet állítani a VM-et a saját IP címével. Ezzel nem szokott gond lenni. Windows-on viszont még sosem csináltam ilyen nested virtualizációt, azt sem tudom mit kell ott még engedélyezni. Linux-on már használtam korábban (igaz más OS, más verziót), és ott nem volt gond.
#34344 kpityu2: az a baj, hogy én sem nagyon ismerem.
de megnézem majd milyen service-ek futnak.
Lehet amúgy, hogy valami hardware-es gond van? Mikor fut a VM akkor ilyenek történnek pár percenként állandóan, és a VM leállítása után is:Sep 10 21:10:38 ubuntubox kernel: NMI backtrace for cpu 3 skipped: idling at intel_idle+0x72/0xe0Sep 10 21:10:38 ubuntubox kernel: Sending NMI from CPU 7 to CPUs 3:Sep 10 21:10:38 ubuntubox kernel: rcu: blocking rcu_node structures (internal RCU debug):Sep 10 21:10:38 ubuntubox kernel: rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 3-...D } 11415673 jiffies s: 2149 root: 0x8/
A gép amúgy egy elég erős laptop (ráadásul nem is az enyém), valami újabb generációs i7-tel, meg 16GB RAM-mal. -
bviktor93
tag
válasz
urandom0
#34338
üzenetére
Valószínűleg igen, akkor már a VM is szét kellene hogy essen futás közben, mikor csúcson használja a RAM-ot, de semmi ilyen nincs, teljesen stabil, egyébként 8GB-ot állítottam csak be neki VMware-ben. És a VM leállítása után is teljesen stabil, reszponzív az egész rendszer, 1-5-2 GB körül használja csak a RAM-ot.
Ami némileg ellent mond ennek azok a magas load avg. értékek, mindhárom 1-5-15-ös érték ilyen 6-7 körül mozog, VM leállítása után is, úgy hogy teljesen idle az egész rendszer.htop-pal figyelem, és nem látok semmi olyat ami ezt indokolja.
De legidgesítőbb dolog ez a leállítás/újraindítás amit írtam is.
Egyébként már próbáltam VirtualBox-ban is ugyanezt a GNS 3 VM-et futtatni, na ott 5-10 percenként szétcrashelte magát az egész, így jutottam el a Vmware-ig. Na ezt most stabil, csak itt meg a rendszert nem tudom rendesen leállítani.
-
Ablakos
őstag
válasz
urandom0
#34310
üzenetére
Ha terminálban "egyszerűen" mountolok, akkor csak egy megosztásom lesz. Lehet, hogy a /etc/fstab bejegyzés nem egészen jó?
//192.168.200.3/java /media/java/ cifs rw,vers=3.0,credentials=/root/.userCredentials,gid=1000,dir_mode=0775,file_mode=0664,x-systemd.automount,nofail -
-
-
CPT.Pirk
Jómunkásember
válasz
urandom0
#34228
üzenetére
Van egy b. drága célprogramunk, ami kezelne SVN szervert fájlban és akkor az is mehetne OneDrive-on, ahogy a GIT-et is használjuk, de a mi verziónkban ez bugos, nem lehet használni. Viszont helyi hálón meg kezeli az SVN-t, így azzal dolgozunk. Sajnos bazi drága lenne új verzióra frissíteni a proginkból...
Mondjuk az OneDrive önmagában is egy csoda. Csoda, hogy működik...
-
#34226
lionhearted
őstag
urandom0
#34225
válasz
urandom0
#34225
üzenetére
Nem, ilyen célokra, ha nincs meg a méretgazdaságosság miatti saját üzemeltetésre a pénz, akkor a felhőből kell venni, as a service. Git hub/lab támogat privát repokat, OneDrive/M365 meg véd ransomware ellen alapból. Aztán mindegy milyen linuxot futtatnak ott.
Amúgy 10 év ESM van. Live kernel patching mellett is elhasal a boot az új kernellel, de a korábbit futtatva se leszel "lyukas"... Ha emiatt volt az új kiadás egyáltalán. Nekem évek óta így futnak a 7/24 home serverek.
-
UHHH
őstag
válasz
urandom0
#34216
üzenetére
Félreértesz: Arra céloztam a hozzászólásommal, hogy fizikailag tiltani kell azt, hogy bárki és a szerver között létrejöjjön az SSH kapcsolat. Éljen a tűzfalszabály. Ne engedjünk be bárkit az utcáról, hogy hátha be tud lépni.
Igen, a LoginGraceTime 0-ra állításával van workaround, aki nem tud frissíteni. S csak egy "szűk részét" érinti az openssh verzióknak. -
Edorn
senior tag
válasz
urandom0
#34177
üzenetére
Igen, pont ezt szeretném valahogy belőni, hogy egyáltalán honnan indul a probléma. ss-t néztem, de ott kb pont el kellene kapni egy próbálkozást ráadásul a sok egyébként okés kapcsolódás rengetegében. De lsof-al és netstat-al is ugyanez lenne. De ha mondjuk óránként egyszer történik, akkor elég esélytelen. Ezért reménykedtem valami log-ban vagy egyéb megoldásban.
Két példa log, amit kaptam mint panasz:
2024-05-16 06:54:09
Url: ho###ff.ir/wp-content/themes/blossom-spa/wp-config-sample.php
Remote connection: xxx.xxx.xxx.xxx:39158
Headers: {
"Host": "ho###ff.ir",
"Connection": "Upgrade, HTTP2-Settings",
"Upgrade": "h2c",
"HTTP2-Settings": "AAEAAQAAAAIAAAAAAAMAAAPoAAQAYAAAAAYABAAA",
"Cookie": "[hidden]",
"sec-ch-ua": ""Chromium";v="110", "Not A(Brand";v="24", "Google Chrome";v="110"",
"sec-ch-ua-mobile": "?0",
"sec-ch-ua-platform": ""Windows"",
"Upgrade-Insecure-Requests": "1",
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.#.#.0 Safari/537.36",
"Accept": "*/*",
"Sec-Fetch-Site": "none",
"Sec-Fetch-Mode": "navigate",
"Sec-Fetch-User": "?1",
"Sec-Fetch-Dest": "document",
"Accept-Encoding": "gzip,deflate",
"Accept-Language": "eo;q=0.8,en-US;q=0.6,en;q=0.4",
"Accept-Charset": "ISO-8859-1,utf-8;q=0.7,*;q=0.3",
"Content-Length": "28",
"Content-Type": "application/x-www-form-urlencoded"
}
Post data: {
"IU": "die(pi()*42);"
}Másik:
2024-05-28 06:32:07
Url: www.hardcoretooling.com/wp-content/plugins/booking-package/lib/Sitehook.php
Remote connection: xxx.xxx.xxx.xxx:52530
Headers: {
"Host": "www.hardcoretooling.com",
"sec-ch-ua": ""Not_A Brand";v="8", "Chromium";v="120", "Google Chrome";v="120"",
"sec-ch-ua-mobile": "?0",
"sec-ch-ua-platform": ""macOS"",
"upgrade-insecure-requests": "1",
"user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
"accept": "*/*",
"sec-fetch-site": "none",
"sec-fetch-mode": "navigate",
"sec-fetch-user": "?1",
"sec-fetch-dest": "document",
"accept-encoding": "gzip,deflate",
"accept-language": "eo;q=0.8,en-US;q=0.6,en;q=0.4",
"accept-charset": "ISO-8859-1,utf-8;q=0.7,*;q=0.3",
"content-length": "28",
"content-type": "application/x-www-form-urlencoded",
"host": "www.hardcoretooling.com",
"cookie": "[hidden]",
"BN-Frontend": "captcha-https",
"X-Forwarded-Port": "443",
"X-Forwarded-Proto": "https",
"BN-Client-Port": "52006",
"X-Forwarded-For": "xxx.xxx.xxx.xxx"
}
Post data: {
"Rv": "die(pi()*42);"
}
xxx.xxx.xxx.xxx a szerverem ip-je... -
bambano
titán
válasz
urandom0
#34153
üzenetére
ha rootként van bent, akkor ami azon a gépen van, az kuka, a komplett gép kompromittálódott.
nyilván hozzáfér az adott gépen levő privát kulcsodhoz is, ahogy leírtam az előző hsz-emben.ha nem követted el azt az orbitális hibát, hogy másolgatod a kulcsaidat mindenféle gépre, akkor ez nem olyan nagy probléma. ha ugyanazt a kulcspárt használtad egy rakás gépről, akkor bajban vagy
-
-
#78522999
törölt tag
válasz
urandom0
#34149
üzenetére
Folyamatosan online szokott lenni.
Igazából ~3éve használom és összesen ~50%-ban üzemelt megszakításokkal, de valahogy mostanában elmérgesedni látom a támadásokat és volt egy furcsaság is a Debian esetében, amikor egyik reggelre annyira megadta magát a gép, hogy még az nginx sem volt elérhető és az ssh sem.
Valami számomra nem értelmezhető hibát kaptam konzollal belépés után az sshd systemd status-ról. De sajnos akkor annyira pánikoltam, hogy nem mentettem semmit, hanem töröltem.
Most hagyom kicsit szenvedni a rendszert és pár nap után mentek minden log-ot és infót aztán átnézem őket. Lehet tanulságos lesz a későbbiekre vonatkozóan. -
bambano
titán
válasz
urandom0
#34148
üzenetére
vajon hogyan lopja el a privát kulcsodat, ha azt soha, semmilyen körülmények között sem adod ki a kezedből? oké, a feltört rendszeren levő kulcsaidat ellophatja, de itt arról van szó, hogy aki távolról be akar jelentkezni a feltört gépre, azzal lesz baj. ha be akarsz jelentkezni a feltört gépre, akkor sem adod ki a sajátodról a saját privát kulcsodat.
-
bambano
titán
válasz
urandom0
#34143
üzenetére
ez így a nemlétező esemény. hogy sebezhetőség van az openssh szerverben, azt ki tudta lőni, de a 22-es portra nem tud rábindelni, annak nulla az esélye. a credentials lopásnak meg azért nincs értelme ebben az elképzelt felállásban, mert ha a jogosult user tudja, hogy nem a 22-es portra tette az ssh-t, akkor nem fog a 22-es porton próbálkozni, tehát nem fog legális azonosító adatokat kapni ott, aki meg a 22-es porton próbálkozik, az fake.
ha elköltöztetted az ssh-t a 22-es portról, akkor egy rakás cpu-t megspórolsz, amit a fail2ban elhasználna.
-
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.
-
-
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).
-
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".
-
-
#34021
lionhearted
őstag
urandom0
#34006
-
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.
-
Vladi
nagyúr
válasz
urandom0
#33996
üzenetére
nincs 3 életem, így is csomó hülyét kerülgetek.
Valamint az aktuális életfilozófiám: mivel én elmaradott faszi vagyok, csak azt hiszem el, amit a vaksi szememmel látok, süket fülemmel hallok és tompa agyammal gondolok. Akkor is ha ez nem ér fel a nagy céljaik igazságához.
-
bambano
titán
válasz
urandom0
#33980
üzenetére
az xz egy annyira fontos szoftver, hogy egyáltalán nem az, még egy debian is elgurul nélküle.
Az pedig továbbra is hiba, hogy systemd jellegű óriás bináris blobok vannak a mostani disztrókban, és ész nélkül használják is azt. Jól láthatóan az alapelvtől való eltérés lényegesen elősegítette a kendácsolást.
-
Vladi
nagyúr
válasz
urandom0
#33970
üzenetére
ugye, ugye..! mire nem jó a transzparencia. rémlik, hogy valaki anno írt erről blogot, hogy a linux nem elsősorban azért biztonságos, mert kevesen használják.
egyébként az egyetlen valamirevaló disztró ami még sysvinitet használ az az antix, lehet arra fogok átállni.
-
bambano
titán
válasz
urandom0
#33974
üzenetére
A unix úgy született, hogy megpróbáltak komplex operációs rendszert írni, de nem sikerült. Ekkor lett az alapelve, hogy keep it stupid and simple.
A systemd teljesen egyértelműen szembemegy ezzel az alapelvvel, nagy hiba volt integrálni a disztrókba.
Minél több szemetet integrálsz az oprendszerbe, annál több támadási vektort hagysz benne.
szoval igen, osszenott, ami osszetartozik.
és csak pár nem túl hw. igényes image-el szeretnék gyakorolni.
de megnézem majd milyen service-ek futnak. 
Nginx logokban nincs semmi? Nem aludt el a gép? (Bár nem tudom, eg VPS mennyire csinál ilyet.)
Új hozzászólás Aktív témák
Hirdetés
- Everest / AIDA64 topik
- sh4d0w: Csak a profit - emberélet nem számít
- Szeged és környéke adok-veszek-beszélgetek
- AMD Navi Radeon™ RX 9xxx sorozat
- Linux kezdőknek
- Formula-1
- Kazy Computers - Fehérvár - Megbízható?
- Renault, Dacia topik
- Bemutatkozott a Poco X7 és X7 Pro
- Álláskeresés, interjú, önéletrajz
- További aktív témák...
- Gyermek PC játékok
- 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.
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- iKing.Hu - Motorola Edge 50 Ultra - Nordic Wood - Használt, karcmentes
- Huawei P20 Lite 64GB, Kártyafüggetlen, 1 Év Garanciával
- Samsung Galaxy S25 Ultra 1TB, Kártyafüggetlen, 1 Év Garanciával
- LG 27GS60QC-B - 27" Ívelt - 2560x1440 - 180Hz 1ms - AMD FreeSync - Bontatlan - 2 Év Gyári Garancia
- Telefon felvásárlás! Samsung Galaxy A15, Samsung Galaxy A25, Samsung Galaxy A35, Samsung Galaxy A55
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged