1. Nem szeretném 1000 felhasználó konfigurációját beolvasztani az nginx konfig fájlokba. Egy ilyen megoldásnak már a support költsége is több lenne, mint a .htaccess overhead.
Egyik megkozelites ez.
En a masik oldalrol kozelitem meg: jo otletnek tartod, hogy a felhasznaloknak legyen befolyasuk a webszervered konfiguraciojara?
En ezt nem igazan tartom jo otletnek. Egy egyetemi-kozepiskolai kornyezetben, pedig kifejezetten ellenjavallottnak talalom, ahol nem egyszeru banki adminisztrator mancikak lesznek a felhasznaloid, de sokkal nagyobb az eselye, hogy a felhasznaloid kozott olyan is akad, akik a reseket fogjak keresni az egesz rendszeren.
2. Nem teljesen oldható meg, ugyanis más-más hibát kell kiszolgálni ha nem létezik felhasználó, vagy ha csak nincs weboldala.
Nem tudom milyen adatbazisban tartod a felhasznaloidat, de ilyen esetben en inkabb egy include-olt fajl generalnek valamilyen template alapjan.
template lehet akar valami jinja.
passwd / ldap / egyeb valtozas alapjan lehet triggerelni.
de akar az is lehet modszer, hogy 5 percenkent lefut egy script, ami a legutolso exportalt sorba-rendezett felhasznalolistat osszeveti az aktualissal. ha elteres van, ujrageneralja az include fajlt, majd reload az nginx-nek.
A php-fpm nagyon jó, de egyrészt ~1200 poolt nem szeretnék futtatni, illetve nem szeretném ha poolok újrakonfigurálódnának minden egyes felhasználó törlésekor/hozzáadásakor. Ilyenkor csak a suphp marad.
Miert tartod problemasnak 1200 pool futtatasat?
En sokkal kevesbe erzem biztonsagosnak, hogy fut egyazon uid alatti processzel valami, ami aztan at-suzhat masra, mint ha eleve minden pool kulon, mar eleve dropped cap-ekel inditott processzekbol all.
+ reload is letezik, ha hozzaadsz / elveszel pool-t.
Rendszergazdakent par scriptet osszerakni, ami cronbol (vagy mas triggerre) lefut, es templete alapjan ujrageneral fajlt / fajlokat nem kellene nagy ordongosseg legyen.
Szerintem.