Le istruzioni che nominano una specifica release di OpenVPN di solito codificano una funzionalità, e il numero di versione ne è solo un sostituto. Quando le leggi, la distribuzione può fornire qualcosa di più recente della versione indicata e mancare comunque dell'integrazione che ti serve, oppure fornire qualcosa di più vecchio che copre già il requisito. Trattare il numero come obiettivo produce modifiche ai repository che non risolvono nulla. Trattarlo come sintomo di un requisito produce una decisione molto più piccola.

Tre domande separano i due casi: quale implementazione, quale release di base e chi gestisce gli aggiornamenti.

Un numero di versione non è un requisito di funzionalità

Chiediti di cosa ha bisogno la connessione prima di chiedere quale pacchetto lo fornisce. Un profilo può richiedere un cifrario, una modalità TLS, un plugin di autenticazione o un'interfaccia di gestione, e ognuno di questi può mancare in una build che dichiara una stringa di versione soddisfacente. Viceversa, una build leggermente più vecchia può implementare tutto ciò che il profilo usa. La stringa di versione è un riassunto scritto da chi impacchetta, non un elenco di funzionalità.

Chiarisci se l'istruzione significa 'questa funzionalità o una successiva' oppure 'questa build esatta è stata testata'. Le due risposte portano a repository diversi.

Il nome in codice deve corrispondere alla release di base

I repository sono indicizzati per nome in codice della distribuzione, e il nome della release di una derivata non è il nome in codice della sua base. Leggi /etc/os-release per VERSION_CODENAME e ID_LIKE, e verifica quale release di base segue la derivata. Una risposta vecchia che associava una release desktop a un nome in codice Ubuntu non dice nulla su quella successiva. Indovinare il nome in codice è il modo in cui un sistema finisce per scaricare pacchetti compilati contro una libreria C diversa.

Controlla ciò che il gestore dei pacchetti offre già con apt-cache policy openvpn prima di aggiungere qualsiasi cosa. Se il candidato installato soddisfa il requisito, la questione del repository sparisce.

A cosa si lega davvero un repository upstream

Un canale upstream pubblica build per release di base specifiche, e le sue istruzioni abbinano una riga di repository a una chiave di firma e a un nome in codice supportato. Quelle parti non sono segnaposto da sostituire con il nome in codice che ti capita di conoscere. Le dipendenze vengono risolte rispetto alla release a cui mirava la build, quindi un pacchetto che si installa senza errori può comunque rompere software non correlato che condivide una libreria.

Leggi la guida del repository per l'implementazione che hai scelto e segui la sua tabella di compatibilità attuale invece della copia che ne fa un blog più vecchio.

Installare non è integrare

Sostituire il binario openvpn non aggiunge un plugin NetworkManager mancante, una finestra di importazione o un editor desktop. Questi vivono in pacchetti separati come network-manager-openvpn e la sua controparte desktop, e hanno un proprio rapporto di versione con la libreria client. OpenVPN 3 Linux è un'altra implementazione ancora, con il proprio modello di sessione e di configurazione, quindi i suoi pacchetti non sono sostituti diretti per un flusso di lavoro con profilo 2.x.

Decidi quale componente possiede il tunnel in esecuzione prima di installare qualsiasi cosa. Due gestori su un solo host producono la stessa confusione da tunnel duplicato di due client.

Annota le tre decisioni

Registra l'implementazione, la release di base e il responsabile degli aggiornamenti, e annota quale di essi dovrebbe cambiare. Quel documento è ciò che un aggiornamento futuro legge quando la riga del repository smette di funzionare dopo una release della distribuzione. Senza di esso, la persona successiva ripete l'indovinello del nome in codice con un numero più recente.

Se il canale che ti serve non supporta più la release di base, la risposta è una migrazione di piattaforma, non un repository di tre release fa.

Articoli correlati