amikor olyan problémára keressük a "systemd-s" megoldás, ami tulajdonképpen nem is létezik.
A probléma (kernel modulok betöltésének felelőssége és a szolgáltatások függőségének kezelése) láthatóan létezik, különben nem beszélgetnénk róla. Te láthatóan átdobnád ezt a felelősséget a szolgáltatásra (hogy legyen annyi kernel modul kezelési megoldás, ahány tűzfal).
Viszont visszatérve a topic indítóra: per pill. a systemd-modules-load (ami kernel modulok korai betöltéséért felelős, hogy a szolgáltatásoknak ne kelljen modprobe-al szórakozniuk... pl. egy CUPS csak azért, mert függ a párhuzamos port modultól, ne akarjon kernel modulokat töltögetni, ő fusson csak a kis saját, privilégiumok nélküli userével) egy a netfilter-persistent-től teljesen független modult nem tudott betölteni - ha _rendesen_ kezeled/dokumentálod az egyes szolgáltatások kernel modul függőségeit, akkor egy CUPS nem tudja a tűzfaladat megborítani - ahogy egy HW szenzor modul sem a CUPS-ot.
A kernel modul ugyanúgy tekinthető dependency-nek, mint egy fájlrendszer. Annál is ugyanígy mondható, hogy dehát ott az fstab, és minden szolgáltatás lesz szíves ellenőrizni, hogy az adatai elérhetőek induláskor. Pl. egy dovecot alá mondhatod, hogy adsz egy külön FS-t a mailboxoknak. Innentől kezdve az az FS a dovecot számára egy szükséges dependency, és a systemd ezt kezeli is - egy sornyi konfig átírásával felveszed függőségként és öröm és boldogság (és egyébként pont egy generátor csinál mount unitokat az fstab fájlból).
Hint: van kernel autoloader, kiadod a netfilter parancsot, a kernel meg magától betölti a modulokat.
Ja, vagyis egy felelősséget (kernel modulok betöltése) áttoltál user space-be (amit egyébként a példában, ha jól nézem a forrást, az iptables meg is csinál, a netfilter-persistent csomag által használt iptables-restore már nem)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)