Quin paquet d'OpenVPN pot suportar realment una versió de Linux

Les instruccions que anomenen una versió concreta d'OpenVPN solen codificar una funció, i el número de versió només n'és un indici. Quan les llegeixes, la distribució pot servir alguna cosa més nova que la versió esmentada i encara no tenir la integració que necessites, o servir alguna cosa més antiga que ja cobreix el requisit. Si tractes el número com a objectiu, obtens canvis al repositori que no resolen res. Si el tractes com a símptoma d'un requisit, obtens una decisió molt més petita.

Tres preguntes separen les dues coses: quina implementació, quina versió base i qui és responsable de les actualitzacions.

Un número de versió no és un requisit de funció

Pregunta què necessita la connexió abans de preguntar quin paquet ho proporciona. Un perfil pot requerir un xifratge, un mode TLS, un connector d'autenticació o una interfície de gestió, i qualsevol d'aquests pot faltar en una compilació que declara una cadena de versió satisfactòria. A l'inrevés, una compilació una mica més antiga pot implementar tot el que utilitza el perfil. La cadena de versió és un resum escrit per qui empaqueta, no una llista de funcions.

Aclareix si la instrucció vol dir «aquesta funció o posterior» o «aquesta compilació exacta s'ha provat». Les dues respostes porten a repositoris diferents.

El nom en clau ha de coincidir amb la versió base

Els repositoris es clauen pel nom en clau de la distribució, i el nom de versió d'una derivada no és el nom en clau de la seva base. Llegeix /etc/os-release per obtenir VERSION_CODENAME i ID_LIKE, i confirma quina versió base segueix la derivada. Una resposta antiga que assignava una versió d'escriptori a un nom en clau d'Ubuntu no diu res sobre la següent. Endevinar el nom en clau és com un sistema acaba baixant paquets construïts contra una biblioteca C diferent.

Comprova què ja ofereix el gestor de paquets amb apt-cache policy openvpn abans d'afegir res. Si el candidat instal·lat satisfà el requisit, la pregunta del repositori desapareix.

A què s'uneix realment un repositori upstream

Un canal upstream publica compilacions per a versions base concretes, i les seves instruccions aparellen una línia de repositori amb una clau de signatura i un nom en clau suportat. Aquestes parts no són marcadors de posició per substituir pel nom en clau que coneguis. Les dependències es resolen contra la versió a què apuntava la compilació, així que un paquet que s'instal·la net pot trencar igualment programari no relacionat que comparteix una biblioteca.

Llegeix la guia del repositori de la implementació que has triat i segueix la seva taula de compatibilitat actual en lloc de la còpia d'un blog antic.

Instal·lar no és integrar

Substituir el binari openvpn no afegeix un connector de NetworkManager que falta, un diàleg d'importació ni un editor d'escriptori. Aquests viuen en paquets separats com network-manager-openvpn i la seva contrapart d'escriptori, i tenen la seva pròpia relació de versions amb la biblioteca client. OpenVPN 3 Linux és encara una altra implementació, amb el seu propi model de sessió i configuració, així que els seus paquets no són substituts directes per a un flux de treball amb perfil 2.x.

Decideix quin component és propietari del túnel en marxa abans d'instal·lar res. Dos gestors en un sol amfitrió produeixen la mateixa confusió de túnel duplicat que dos clients.

Anota les tres decisions

Registra la implementació, la versió base i el responsable de les actualitzacions, i anota quina d'elles s'espera que canviï. Aquest registre és el que llegeix una futura actualització quan la línia del repositori deixa de funcionar després d'una versió de la distribució. Sense això, la següent persona repeteix l'endevinalla del nom en clau amb un número més nou.

Si el canal que necessites ja no dóna suport a la versió base, la resposta és una migració de plataforma, no un repositori de fa tres versions.