Új hozzászólás Aktív témák

• #34675 bambano titán urandom0 #34670

  Új Válasz 2025-03-18 23:21:43 #34675

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bambano

  titán

  LOGOUT blog

  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.

• #34672 sh4d0w félisten urandom0 #34670

  Új Válasz 2025-03-18 23:15:38 #34672

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sh4d0w

  félisten

  LOGOUT blog

  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.

• #34671 Rhino666 addikt urandom0 #34670

  Új Válasz 2025-03-18 23:15:18 #34671

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Rhino666

  addikt

  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

Új hozzászólás Aktív témák