Project

General

Profile

Segnalazione #427

squid.conf resttata ad ogni Fuss-Server upgrade

Added by Markus Pfeifer about 2 years ago. Updated 9 months ago.

Status:
Risolto
Priority:
Normale
Start date:
09/26/2017
Due date:
% Done:

0%


Description

Ogni volta che c'é un'aggiornamento di FUSS-SERVER che necessita dell'esecuzione del commando "fuss-server upgrade" le impostazione individuali per squid vengono risettate. Siccome devono passare anche client non-Linux attraverso SQUID per accedere ad internet è importantissimo che queste impostazioni vengono mantenute anche dopo di che si effettua un'aggiornamento delle componenti.

Saluti
Markus.


Related issues

Related to fuss-server - Segnalazione #372: accesso internet non consentito a client non-LINUX Chiuso 08/04/2017

History

#1 Updated by Christopher R. Gabriel about 2 years ago

  • Related to Segnalazione #372: accesso internet non consentito a client non-LINUX added

#2 Updated by Christopher R. Gabriel about 2 years ago

  • Status changed from Nuovo to Commenti
  • Assignee changed from TRUELITE to Paolo Dongilli

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")

#3 Updated by Paolo Dongilli about 2 years ago

  • Assignee changed from Paolo Dongilli to Christopher R. Gabriel

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.

#4 Updated by Elena Grandi about 2 years ago

Segnalo per informazione che la vecchia versione di /etc/squid3/squid.conf viene già salvata in caso di modifiche (però non c'è notifica esplicita all'operatore, oltre a quella che probabilmente scompare in mezzo a tutto il resto che dice che il file è stato modififcato)

#5 Updated by Christopher R. Gabriel about 2 years ago

  • Assignee changed from Christopher R. Gabriel to Paolo Dongilli

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?

#6 Updated by Paolo Dongilli about 2 years ago

  • Assignee changed from Paolo Dongilli to Christopher R. Gabriel

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.

#7 Updated by Paolo Dongilli about 1 year ago

  • Assignee changed from Christopher R. Gabriel to Simone Piccardi

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.

#8 Updated by Simone Piccardi about 1 year ago

  • Assignee changed from Simone Piccardi to Paolo Dongilli

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.

#9 Updated by Paolo Dongilli about 1 year ago

  • Assignee changed from Paolo Dongilli to Simone Piccardi

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.

#10 Updated by Elena Grandi 11 months ago

  • Assignee changed from Simone Piccardi to Paolo Dongilli

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

#11 Updated by Elena Grandi 11 months ago

Ho uploadato la versione 8.0.37 del fuss-server che aggiunge dei file per le configurazioni aggiuntive, non sovrascritte dal fuss-server, di:

  • bind
  • dhcp
  • squid

Con fuss-server upgrade vengono creati i file vuoti relativi, documentati su https://fuss-tech-guide.readthedocs.io/it/latest/gestione-dei-fuss-server.html#i-principali-file-di-configurazione

#12 Updated by Paolo Dongilli 9 months ago

  • Status changed from Commenti to Risolto

Also available in: Atom PDF