Bejegyzések

Bejegyzések megjelenítése ebből a hónapból: január, 2019

rsyslog vs syslog-ng - apróság, de gáz...

A routerem logja egy syslog-ng szerveren köt ki. Minap rámjött a hülyeség, regisztráltam az asuscomm.com-ra egy saját nevet és kértem, hogy akkor már egy Let's encrypt tanúsítványt is szerezzen be hozzá a router firmware. Szép, jó, működik. Viszont a syslog-ng által írt logba került pár érdekes sor. :( Ugyanis a tanúsítvány gyártás/törlés készít pár olyan bejegyzést, ami sorvége (^M, \n) karaktert is tartalmaz. Ezt a syslog-ng egy laza mozdulattal beletolja a logba úgy, ahogy van. Emiatt, ha soronként olvasom a logot, mondjuk pythonból vagy akár egy grep-pel, akkor ezek a sorok több sorként jelennek meg, szabálytalan bejegyzésként. Ugyanis az így létrejövő sorok elejéről hiányzik a dátum, időpont, küldő kliens stb. Az rsyslog (debian 9 alatt) normálisan kezeli, az üzenetben lévő sorvég karakterből két karaktert csinál, ha jól láttam: ^M. Megnézem a syslog-ng konfigot, van-e erre valami megoldása, de félek, hogy nincs. (3.x verzió) Update: közben megtaláltam, bár nem töké

Docker - processz limitek - ciki

Ismerkedni kezdtem a docker-rel. Elég fura. Ha nem módosítok a beállításokon, akkor alapjáraton limitek nélkül fut a konténer. Akkor is, ha a host valamennyi userére érvényes limitek vannak beállítva. Emiatt kis híján borítottam a szerverem, mikor elengedtem rajta egy fork-bomb változatot. :D Update: mint közben kiderült , a systemd-t meg én ignoráltam sikeresen, pedig ott kellett volna keresni a választ. Szóval a docker.service fájlban van beállítva, hogy unlimited legyen az nproc értéke. Az oka nem teljesen tiszta. Láttam a githubon egy bugreportot, miszerint a beállított érték túl alacsony, magasabbra lenne szükség, mire ez volt a "javítás", de mobilról néztem, az sem biztos, hogy a hivatalos docker forráshoz tartozó bugok közt szerepelt. Majd előkeresem azt az oldalt, ha nem felejtem el. Újabb update: valóban, a docker.service vonatkozó sorai felett van egy comment, miszerint ha ezeket a paramétereket alapból korlátozzák, az performancia problémákat okozhat, ezért in

squid - X-Forwarded-for

Érdekesség: ha a squid.conf-ban a forwarded_for alapértelmezett, tehát "on" értékű, akkor kívülről láthatóvá válik a kliensek belső címe, emiatt egyes szolgáltatások, ha logolják is, hogy honnan léptem be, csak a LAN-os címet mutatják, ki tudja, miért... Ha off-ra teszem, akkor a lokális cím helyett unknown kerül a fejlécbe. Ha transparent értéket kap, akkor minden happy. Kivéve, hogy a google play áruház megdöglik a mobilomon: nem hajlandó semmit letölteni az így beállított proxyn keresztül.

Másik e-mail, másik történet...

Ugye volt az a kis apróság, hogy tavaly eltűnt egy postafiókomból minden levél, meg a címjegyzék. Kb. pont akkor, mikor a hálózatomon történtek más érdekes dolgok is, szóval nagyon úgy tűnt, hogy valaki hálózaton belül randalírozik illetéktelenül. Aztán szép lassan kiderült, hogy annak az ismerősömnek van igaza, aki szerint az ember túlságosan hajlamos összekötni olyan dolgokat, amiknek semmi közük egymáshoz. Az összes rejtélyes történésre megtaláltam a magyarázatot, egy dologra nem: a kiürült postafiókra. Levelezgettem egy ideig a supporttal, eredmény nélkül, majd egy szép napon megjelent egy vadidegen IP cím a korábbi belépéseim listájában. Olyan szolgáltatótól, amihez utoljára 10+ éve volt közöm. Próbáltam rákérdezni az említett supportnál, hogy erről mit tudnak, de nagyon nem akaródzott érdemi választ küldeniük. Mivel kerülőúton is próbálkoztam, egy "belsős" ismerőssel, hátha onnan több infó jön, még vártam, hátha lesz érdemi magyarázat. Erre ma jön a supporttól egy ol