Comment mettre à niveau le logiciel installé à partir de la source?


10

J'installe NGinx à partir des sources car les packages du référentiel ubuntu sont assez anciens. Je me demandais quelle est la meilleure méthode pour mettre à niveau ces types d'installations?

Mon flux de travail actuel implique.

  • Téléchargement de la nouvelle source
  • Installez le logiciel avec les mêmes chemins.
  • Redémarrage du logiciel.

Quelque chose me dit que ce n'est pas le meilleur itinéraire.

Suggestions?

Réponses:


9

Vous avez raison de penser que ce n'est pas le meilleur itinéraire. Cette route nécessite de nombreuses étapes manuelles, est très sujette aux erreurs et ne s'adapte pas bien.

Lorsque vous travaillez avec des distributions Linux, vous devez vous en tenir autant que possible à la gestion des packages.

Les avantages de l'utilisation de la gestion des packages:

  • Prise en charge des dépendances
  • Installation / retrait facile
  • Inventaire logiciel
  • Support de mise à niveau / rétrogradation, y compris la gestion des fichiers de configuration
  • Le package source documente essentiellement votre processus de génération et l'a automatisé pour vous une fois qu'il est écrit.
  • Signature du package
  • et plus.

Lorsque vous commencez à travailler uniquement à partir des sources, vous perdez toutes ces excellentes fonctionnalités, et les choses commencent à devenir désordonnées assez rapidement.

Afin de résoudre votre problème spécifique, vous devriez vérifier le référentiel de backports ubuntu , peut-être qu'ils ont une version mise à jour pour NGinx que vous pouvez utiliser.

S'ils n'ont pas de version appropriée, la meilleure solution serait de créer vous-même un paquet ubuntu rétroporté. Ce n'est vraiment pas si difficile, et c'est moins de travail que de le compiler manuellement à partir de la source à chaque fois. Le rétroportage nécessite, fondamentalement, de prendre le paquet source d'ubuntu, de remplacer l'ancien fichier tar.gz upsteam par le dernier que vous voulez, et de reconstruire le paquet.

Vous pouvez utiliser ce guide pour vous aider à rétroporter le package.


8

J'ai trouvé assez pratique d'installer une version différente dans des emplacements séparés et de simplement créer un lien symbolique vers la version que vous souhaitez utiliser, comme:

lrwxr-xr-x  1 root  wheel     7B Jun  7 18:26 /usr/local/foo -> foo-1.0
drwxr-xr-x  2 root  wheel   512B Jun  7 18:26 /usr/local/foo-1.0
drwxr-xr-x  2 root  wheel   512B Jun  7 18:26 /usr/local/foo-1.1

Les avantages sont les suivants:

  • temps d'arrêt du service minimisé lors d'une mise à niveau
  • restauration facile
  • vous pouvez toujours utiliser le même chemin o, comme /usr/local/foo/bin/bar

Bien sûr, vous devez toujours réappliquer toutes les modifications de configuration que vous avez apportées à la version précédente, mais pour cela, vous pouvez utiliser un système de gestion des versions (RCS / SVN / GIT) ou un outil de gestion de configuration comme Bcfg2 .

Et, bien sûr, cela ne convient qu'à une poignée ou moins d'hôtes.


C'est ce que je fais dans les quelques cas où la construction de packages n'est pas une réponse appropriée, sauf que j'utilise généralement / opt au lieu de / usr / local.
freiheit

2

La prochaine fois ... que diriez-vous de le compiler en * .rpm ou * .deb?


1

Si vous allez installer cela sur une seule machine, le faire à partir de la source à chaque fois est le meilleur moyen. Si vous allez installer ceci sur plusieurs machines et que vous voulez vous assurer qu'il est cohérent, cela vaut probablement la peine d'apprendre à créer des paquets Debian. Vous pourriez probablement utiliser l'emballage d'Ubuntu comme base.


1

Il n'y a pas de bonne façon. La raison pour laquelle une gestion efficace des packages a été créée était de résoudre ce problème. La mise à niveau et la désinstallation des éléments compilés à la source sont difficiles.

Je suis d'accord avec Tom et David.

S'il s'agit d'un cas unique, alors la recompilation à partir de la source est probablement votre meilleur pari. S'il s'agit d'un ensemble de machines, il est définitivement temps de passer à la gestion des packages prise en charge.


0

j'ai peur que ce soit le seul moyen. si vous avez plus de serveurs à entretenir - pensez à avoir un environnement de test séparé où vous compilez et éventuellement empaquetez le résultat de votre compilation.

cela normalisera légèrement vos configurations et facilitera le déploiement sur de nombreux serveurs. vous n'aurez pas non plus besoin de gcc sur les machines de production [que beaucoup considéreront comme un avantage de sécurité].

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.