L’avís d’OpenVPN sobre diversos scripts --up: només se n’executa un

L’avís de diversos scripts sona com una queixa de planificació, així que la solució òbvia és reordenar les línies fins que desaparegui. No és una queixa de planificació. Una definició posterior de --up substitueix l’ordre que ja estava desada per a aquella etapa, i l’analitzador ho diu, cosa que significa que dels vostres dos scripts mai només se n’ha executat un de sol. L’altre no fa cua darrere seu; ha desaparegut.

Per això l’avís mereix atenció encara que no sigui fatal: el que prediu és una actualització de DNS o un canvi de ruta que va deixar de passar en silenci.

L’avís no va d’ordenació

OpenVPN desa una única ordre d’script d’usuari per a l’etapa up. Quan l’analitzador troba una altra definició, del perfil, d’un fitxer inclòs o de la línia d’ordres, substitueix el que ja tenia i emet l’avís. No es concatena res, res no s’executa dues vegades i no existeix cap qüestió d’ordre. L’ordre que sobreviu és la que l’analitzador va veure més tard, i per això moure una línia pot canviar el guanyador mentre l’altre script queda mort.

El mateix patró val per a les altres etapes d’script: una ordre cadascuna. Si dues feines s’han de fer totes dues, necessiten un sol punt d’entrada, no dues directives que semblin una llista.

Trobeu les dues definicions a l’arrencada real

Comenceu per allò que el dimoni ha rebut realment, no pel perfil que heu editat. ps -ef i ExecStart de la unitat mostren la línia d’ordres, que pot afegir --up des d’un punt d’entrada de contenidor o un embolcall; el fitxer init d’una distribució pot fer el mateix. systemctl cat openvpn-server@server revela què aporta el servei mateix, i un grep recursiu pel directori de configuració troba les definicions a nivell de fitxer. Els duplicats solen venir de capes diferents, i és exactament per això que editar un sol fitxer no canvia res.

Copiar un script a un altre directori o reanomenar-lo tampoc no elimina una directiva. L’analitzador compta definicions, no fitxers.

Que un sol hook es faci càrrec de la feina

La solució duradora és un sol despatxador que executi les dues accions en un ordre deliberat. Un script de shell curt amb set -eu que crida la integració necessària i després l’acció local, passant "$@" perquè els límits dels arguments sobrevisquin, manté el comportament en un lloc auditable. Passar arguments només els preserva; no demostra que els dos auxiliars esperin la mateixa interfície, així que llegiu el contracte de cadascun. Decidiu què ha de fer un fallada i si els canvis parcials s’han de revertir.

Si l’arrencador ofereix un hook d’extensió compatible, preferiu-lo a l’encadenament fet a mà. Una imatge de contenidor o un paquet de proveïdor sovint té un lloc documentat per a feina addicional, i fer-lo servir evita que una actualització sobreescrigui el vostre despatxador.

La neteja pertany a l’etapa down corresponent. Una acció up que reescriu DNS o afegeix rutes necessita una reversió documentada, i un despatxador que només gestiona l’arrencada és mig disseny.

Confirmeu la integració, no només el silenci

Treure l’avís de duplicat és la part fàcil; la integració encara ha de funcionar. Comproveu l’estat del resolutor després de connectar amb resolvectl status o llegint /etc/resolv.conf, i confirmeu les rutes amb ip route. Després desconnecteu i torneu a connectar, perquè un hook encadenat amb presses sol deixar alguna cosa de la sessió anterior. journalctl -u openvpn-server@server -b mostra si el vostre despatxador s’ha executat i què ha imprès.

Mantingueu els privilegis del hook on pertanyen. Elevar script-security o executar el dimoni amb més drets no és una solució per a un hook substituït; amplia què pot fer cada script futur, inclòs un que un atacant arribi a nomenar.

La prova que la solució és real no és el silenci al registre. És la resposta DNS, l’entrada de ruta i la neteja funcionant després de dues reconnexions.