Distribuzione FUSS » Server » fuss-server

Una proposta evolutiva qua potrebbe essere il caricamento di un file esterno tramite direttiva include per squid, che carichi eventuali regole custom che non vengono modifiche dalla procedura di ansible. Il fatto che il file principale venga aggiornato e' indispensabile per poter "pushare" verso i serve nuove configurazioni comuni (rendere il file immutabile, a parte dare errore durante l'upgrade, porta a perdere eventuali migliore che arrivano dal pacchetto, comuni per tutti)

D'altra parte, quali cose si vogliono personalizzare o meno, visto che in squid l'ordine di alcune regole (esempio la sequenza di valutazione della ACL) ha un ordine ben preciso, e quindi la posizione della direttiva include e la sua eventuale quantità (nel caso si pensi a piu' file, tipo "pre-standard-rules" o "post-standard-rules")

Un aggiornamento di fuss-server dovrebbe preservare configurazioni preesistenti o quantomeno salvare e notificare al tecnico le modifiche preesistenti da ripristinare dopo il fuss-server upgrade. Questo il comportamento che l'operatore si aspetta. La vedo pertanto come una correttiva di un comportamento non atteso.

Parlavo di evolutiva perche' e' il comportamento che e' sempre stato presente in fuss-server, che e' stato migrato ad ansible cercando di mantenere il comportamento precedente analogo, salvo modifiche richieste in seguito.

La tua proposta e' quindi di notificare che il file e' stato alterato, indicando di andare a recuperare le informazioni dalla copia di backup (sempre che noti il messaggio nell'output di fuss-server), la mia proposta invece era di includere pezzi di configurazione custom e permettere a fuss-server di tenere sempre una copia allineata rispetto al pacchetto. Questo perche' se un nuovo pacchetto fuss-server introduce una correzione critica, e poi l'operatore prende il file di copia e lo rimette al posto del file in uso, la miglioria si perde, in quanto non presente nella versione precedente.

Quale delle due?

Christopher R. Gabriel ha scritto:

Parlavo di evolutiva perche' e' il comportamento che e' sempre stato presente in fuss-server, che e' stato migrato ad ansible cercando di mantenere il comportamento precedente analogo, salvo modifiche richieste in seguito.

La tua proposta e' quindi di notificare che il file e' stato alterato, indicando di andare a recuperare le informazioni dalla copia di backup (sempre che noti il messaggio nell'output di fuss-server), la mia proposta invece era di includere pezzi di configurazione custom e permettere a fuss-server di tenere sempre una copia allineata rispetto al pacchetto. Questo perche' se un nuovo pacchetto fuss-server introduce una correzione critica, e poi l'operatore prende il file di copia e lo rimette al posto del file in uso, la miglioria si perde, in quanto non presente nella versione precedente.

Quale delle due?

Va bene Christopher concordo con la tua proposta.

Ho riesumato questo ticket. Riassumendo: al termine di fuss-server upgrade sarebbe utile avere la lista di tutti i file modificati per permettere al tecnico di ripristinare precedenti configurazioni dai backup, non solo per squid.conf.

Per riconfigurare eventuali servizi non serve avere la lista di tutti i file modificati, casomai solo quelli in /etc. Tracciare tutti i file modificati si può anche fare, ma va usato un wrapper con strace, e mi pare una complicazione di scarsa utilità.

Per trovare quelli in /etc che al termine di fuss-server upgrade si può semplicemente usare find /etc -mmin -10 (dove -10 sta per gli ultimi 10 minuti). Che funziona assumento che nel frattempo nessuno si sia messo a riconfigurare altro sul server.

Inoltre ansible (quindi fuss-serve con l'upgrade come con l'installazione) fa di default una copia del file che modifica (nella forma nomefile.NNNNN.ANNO-ME-GI@OR:MI:SE~) per cui non c'è bisogno di nessun ripristino dal backup.

Si posson cercare quelli modificati nel 2018 con:

find /etc/ -name "*.*.2018-*@*~" 

e si può mettere una data più precisa se si vuole restringere il campo, ad esempio per giugno 2018:

find /etc/ -name "*.*.2018-06*@*~" 

Infine scusami se insisto, se un upgrade modifica un file in genere lo fa perché c'è un motivo per farlo, rimetterci quello vecchio non è una buona politica. Ripeto se ci sono configurazioni locali da preservare è opportuno tenerle in file separati da non toccare.

Simone, mi sono spiegato male. Ovviamente intendevo tutti i file di configurazione.

Concordo con tutto ciò che scrivi e aggiungo che un tecnico fuss nella sua "valigetta" deve avere tutti gli strumenti (da terminale) che servono in circostanze come questa.

Per me il ticket si può comodamente risolvere indicando nella fuss-tech-guide i comandi che tu suggerisci, nella sezione dedicata a fuss-server dove si parla dell'upgrade.

Pertanto sono d'accordo nell'evitare per quanto possibile di complicare inutilmente le implementazioni degli strumenti fuss, traducendo invece in manualistica specifiche e comandi utili.

Documentazione aggiunta, con l'avviso di non ricopiare semplicemente i vecchi file in eterno (e del perché non è il caso di farlo):

https://fuss-tech-guide.readthedocs.io/it/latest/gestione-dei-fuss-server.html#aggiornamenti-dei-file-di-configurazione