Wafrn több szolgáltatással egy VPS-en: így oldd meg Caddyvel

Egy poszt, több platform

A fediverse egyik nagy előnye, hogy egyetlen bejegyzéssel egyszerre több helyen is jelen lehetsz – Mastodonon, BlueSky-n, Lemmy-n. A Wafrn pontosan erre való: egy központi felület, ahol mindenre egyszerre posztolhatsz. Viszont a telepítése nem mindig egyszerű, ha már fut más szolgáltatás is ugyanazon a szerveren.

A probléma az, hogy a Wafrn alapértelmezett beállítása egy dedikált szervert feltételez. Docker konténer, benne Caddyvel, és kész. De ha már van WordPressed, vagy más alkalmazásod Nginx mögött, ez az „all or nothing” megközelítés könnyen ütközésbe kerül a meglévő rendszerrel.

Miért nem működik az alapértelmezett megoldás

A Wafrn Docker image tartalmazza a Caddy szervert is, ami automatikusan állít ki SSL tanúsítványt Let's Encrypten keresztül. Ez nem csak kényelmi funkció – az ATProto protokoll (ami a BlueSky mögött áll) megköveteli, hogy a szerver valóban birtokolja a domaint. Ezt tanúsítványon keresztül ellenőrzi.

Ha már van egy másik webszervered, ami a 443-as portot figyeli, nem tudsz mellé egy másikat tenni. A portütközés mellett a tanúsítványok kezelése is bonyolulttá válik, ha több szolgáltatás akarja ugyanazt a domaint.

Megoldás: Caddy külön szolgáltatásként

Ahelyett, hogy lecserélnéd a meglévő webszervert, futtathatod a Wafrnt és a Caddyt egy külön, belső rétegben. A külső forgalom a fő proxyhoz (pl. Nginx) érkezik, az pedig továbbítja a Wafrnhez tartozó útvonalakat a belső Caddynek.

Az architektúra így néz ki:

Külső kliensek (BlueSky, Mastodon)
    ↓
Fő proxy (Nginx a 443-as porton)
    ↓
Belső hálózat
    ↓
Caddy + Wafrn (ATProto tanúsítványkezeléssel)

Így a fő proxy továbbra is kezeli az összes forgalmat, a Wafrn pedig megkapja a számára szükséges tanúsítványokat anélkül, hogy konfliktusba kerülne a többi szolgáltatással.

AI segítsége és korlátai

Ha úgy döntesz, hogy az egész rendszert Caddyre állítod át, az Nginx konfiguráció átalakítása viszonylag egyszerű feladat. Az AI eszközök ezt általában jól elvégzik egyetlen menetben.

A Wafrn speciális beállításainál viszont már kevésbé megbízhatóak. Az ATProto tanúsítványkezelése, a proxyhoz kapcsolódó környezeti változók, vagy a federációs hibák debuggolása olyan tudást igényel, amit az AI nem mindig tud helyesen alkalmazni. Érdemes az AI javaslatait kiindulópontnak tekinteni, nem végleges megoldásnak.

Miért érdemes dokumentálni

Ha sikerült beállítanod a Wafrnt ilyen hibrid környezetben, nagy valószínűséggel belefutottál azokba a pontokba, ahol a hivatalos dokumentáció nem ad elég részletet. Ezeket a tapasztalatokat érdemes megosztani – akár egy külön GitHub repositoryban, akár a projekt hivatalos dokumentációjához való hozzájárulással.

A következő fejlesztő így elkerülheti a többórás próbálkozást, és te is lesz egy referenciád a következő projekthez.

Összefoglaló

• Az ATProto federációhoz érvényes tanúsítvány kell a domainhez
• A dedikált szerver egyszerűbb, de nem mindig praktikus
• Caddy-t futtasd külön szolgáltatásként, a fő proxy mögött
• AI-t használj konfiguráció-átalakításhoz, ne új architektúra tervezéséhez
• Oszd meg a megoldásodat – másoknak is segítesz vele

További lehetőségek

Ugyanez a minta más, federációt támogató alkalmazásoknál is működik, ahol tanúsítványkezelésre van szükség. Ha több szolgáltatást futtatsz egy VPS-en, és speciális protokollkövetelményekkel találkozol, érdemes ezt a szeparált proxy-megoldást alkalmazni.

Ha hasonló problémával küzdesz, vagy érdekelnek az önállóan hosztolt alternatívák, szívesen olvasom a tapasztalataidat a hozzászólásokban.