1 votes

Quelle est la manière recommandée d'utiliser/installer des webapps sur Arch Linux?

Je suis en train d'essayer de trouver la meilleure façon de configurer de manière robuste des webapps sur mon serveur Arch Linux + nginx. La façon dont je le faisais avant était de télécharger et de décompresser par exemple la dernière version de dokuwiki/wordpress dans /srv/http/, puis de le configurer manuellement en éditant les fichiers de configuration à cet emplacement, après avoir changé la propriété du répertoire à l'utilisateur nginx. À chaque nouvelle version d'une webapp (sans mécanisme de mise à jour intégré) qui sortait, je répétais la procédure, tout en déplaçant les fichiers de configuration/données existants de l'ancien emplacement au nouvel emplacement.

Cependant, il doit sûrement y avoir une meilleure façon de maintenir (installer, mettre à jour, sauvegarder) ces webapps, surtout en considérant que pacman en a beaucoup dans ses dépôts.

J'ai quelques préoccupations avec cette approche, cependant, et quelques questions concernant les bonnes pratiques pour la maintenance des webapps sur un serveur :

  • les fichiers installés à partir de paquets dans Arch ont tendance à aller dans /usr/share/webapps/. Et que faire des fichiers de données / de configuration ? Est-ce que je les mets là-dedans aussi ? Ou est-ce que je les lie symboliquement d'une certaine manière ? Est-ce que je copie automatiquement les applications de là vers /srv/http après chaque mise à jour ?
  • en supposant que je lie symboliquement ces répertoires ou configure nginx pour lire directement à partir de ceux-ci, que se passe-t-il avec les autorisations ? Devrai-je exécuter manuellement chown -R root:nginx /usr/share/webapps/new_webapp après chaque mise à jour/installation ? Ou leurs propriétés sont-elles automatiquement définies sur un groupe www ?
  • enfin, que faire des fichiers de configuration de ces webapps lorsque leurs paquets sont mis à jour ? Ne seront-ils pas écrasés (dans le pire des cas) par pacman ou des tonnes de fichiers .pacnew seront-ils créés (dans le meilleur des cas) ?

Comment les webmasters résolvent-ils normalement ce problème ? Quelles ressources existent pour décrire les bonnes pratiques en la matière ? J'utilise déjà puppet pour gérer la configuration de divers paquets, mais une façon "propre" et facile à entretenir d'installer des webapps me semble encore échapper.

1voto

James Mertz Points 390

Pour les applications installées manuellement, envisagez de télécharger le dépôt Git ou Hg s'il en existe un. Vous pourrez mettre à jour la dernière version (stable ou de développement) avec une seule commande et suivre vos propres modifications de code si vous en faites. (Et si quelqu'un trouve un moyen de polluer vos fichiers avec des logiciels malveillants, cela prend aussi quelques instants pour nettoyer.)

Cela a accéléré la mise à jour de nos deux installations Moodle de 30 à 60 minutes (téléchargement; extraction; sauvegarde; réajout de modules; réapplication de correctifs locaux) à seulement 1 à 3 minutes (git pull).

Alternativement, vous pourriez créer vos propres paquets pour pacman, qui se chargeront ensuite de supprimer les anciens fichiers et d'extraire les nouveaux au bon endroit.


Les paquets incluent également toujours les informations de propriété, donc ce n'est généralement pas un problème.

Les mises à jour manuelles signifient que la propriété doit généralement être réinitialisée, bien que cela puisse être automatisé dans une certaine mesure : avec des mises à jour sur place (par ex. Git/Hg ou rsync ou similaire), vous pouvez définir le mode "setgid" sur les répertoires de données de l'application web en utilisant chmod g+s, et le groupe (la partie :nginx) sera automatiquement appliqué à tous les nouveaux fichiers à l'intérieur.

Cependant, lorsque vous extrayez un nouveau tarball, vous devrez toujours corriger les fichiers manuellement.


Pour l'emplacement principal, /usr/share/webapps est bien. Vous n'avez pas toujours besoin de liens symboliques, il est souvent plus pratique de configurer l'emplacement directement dans httpd.conf; par exemple:

Alias /myapp /usr/share/webapps/MyApp/public

Pour la configuration, cela dépend de votre méthode de téléchargement. Les applications web empaquetées par le système ont généralement leurs fichiers de configuration liés symboliquement à /etc, principalement pour mieux se conformer à la hiérarchie des fichiers Linux.

Lors de l'installation à partir d'un tarball, un lien symbolique est également plus pratique chaque fois que vous devez effectuer une mise à niveau.

Avec les mises à jour basées sur Git/Hg, vos modifications sont de toute façon conservées, c'est donc principalement une question de préférence.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X