Retourner aux forums || Retourner au forum Linux.general
Linux.general : administrer à plusieurs un serveur
Posté par Ludovic Gasc (Jabber id, ) le 14 septembre 2006Nous sommes plusieurs admins systèmes sur plusieurs serveurs, je me demandais quel est la meilleure façon pour stocker les modifs qu'on a fait afin de ne pas perdre le fil.
J'exclue les solutions web, car vu que ce sont des serveurs web, il vaudrait mieux que ça fonctionne sans, au cas où il y ait une panne.
Je pensais mettre un fichier README dans chaque dossier de conf où l'on fait des modifs et un fichier dans /root pour stocker les modifs autres que fichiers (par exemple dans la base de données).
Avez-vous de meilleures méthodes ?
Merci pour vos réponses.
> Lire le message (11 commentaires, moyenne: 2).
Bein ...
-
[^]Re: Bein ...
Posté par Krunch (Jabber id, page perso, ) le 14/09/2006 à 17:15. (lien). Évalué à 2.Ou SVK http://lists.debian.org/debian-devel/2005/02/msg00495.html
Ou Bazaar http://bazaar-vcs.org/VersioningEtc
Ou ...--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
sudo
Il peut etre interessant de passer systematiquement par sudo quand on administre un serveur à plusieurs. Ca permet d'une part de ne pas avoir à partager le mot de passe root entre plusieurs personnes (il peut meme etre fixé automatiquement et aléatoirement) et il suffit de demander à sudo de logger les actions pour savoir qui a touché à quoi à quel moment. Après dans chaque fichier modifier, on peut tenir à la main un historique des modifications et garder l'ancien fichier en sauvegarde
-
[^]Re: sudo
Posté par NeoX () le 14/09/2006 à 20:07. (lien). Évalué à 1.ca me semble une bonne idée.
à cela on rajoutera le fait de "commenter" la source.
comme en programmation
perso quand je modifie un fichier, pour moi meme ou pour les autres, je note au debut du fichier :
#Numero de la modif : utilisateur : date et heure
# raison de la modif et explication de cette modif
ensuite dans le code ou le fichier je met
#debut Numero de la modif
code que j'ai modifié
#fin Numero de la modif--
Apprendre par les autres, c'est bien.
Apprendre par soi-meme (RTFM, man, et notre ami google) c'est mieux-
[^]Re: sudo
Posté par Krunch (Jabber id, page perso, ) le 14/09/2006 à 20:46. (lien). Évalué à 2.L'utilisation de sudo me semble évidente mais l'ajout du commentaire dans le fichier l'est moins. Je pense que ce commentaire indiquant la nature de la modification devrait plutôt être fait au niveau du commit log du gestionnaire de versions. Ca permet en plus de regrouper la modification de plusieurs fichiers pour la même raison sous la même appellation.
--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: sudo
Posté par NeoX () le 14/09/2006 à 20:57. (lien). Évalué à 2.encore faut-il disposer d'un systeme d'historisation de version...
et si tu le montes sur la machine qui fait serveur, cela en vaut-il la peine ?
un commentaire dans le code n'est-il pas à la base d'un code lisible et renseigné ?--
Apprendre par les autres, c'est bien.
Apprendre par soi-meme (RTFM, man, et notre ami google) c'est mieux-
[^]non
Posté par Krunch (Jabber id, page perso, ) le 14/09/2006 à 21:59. (lien). Évalué à 3.encore faut-il disposer d'un systeme d'historisation de version...
Si on veut se passer d'un cvs/svn/bzr/... on peut toujours effectuer une journalisation « externe » : le serveur de versions est distinct du serveur réel et on commit les changement sur les deux. L'intérêt d'une journalisation externe au fichier est de garder un historique complet sans allourdir le contenu du fichier (et donc sans nuire à sa lisibilité). En général quand on lit/modifie le fichier, l'historique n'est d'absolument aucune utilité et le maintenir manuellement est particulièrement pénible et sujet à erreurs. Quand a besoin de l'historique d'un fichier, on va le demander au gestionnaire de versions. On va même plutôt lui demander directement l'information qui nous intéresse (« Quel est le crétin qui a modifié cette ligne et quand ? Qu'est-ce qu'il a pété d'autre sur ce commit ? ... »). Au final c'est bien plus efficace que de garder toutes ces méta informations dans le fichier même.un commentaire dans le code n'est-il pas à la base d'un code lisible et renseigné ?
C'est hors sujet mais non. La base d'un code lisible est un style clair et cohérent. Si le code sans commentaire est incompréhensible, les commentaires n'aideront pas beaucoup. Voire http://www.clifford.at/style.html pour de plus amples explications.
Par ailleurs, rien à voir mais dans le cas des fichiers de configuration, je trouve que redire en commentaire quelque chose qui est dit dans la documentation nuit plus à la lisibilité qu'autre chose (ou alors des trucs du genre "# 0 = off, 1 = on, 2 = auto" quand la syntaxe est mal foutue puisqu'elle n'est pas explicite). C'est d'ailleurs un des trucs qui est dit dans le lien plus haut : « Never explain the programming language or API in your code. ».--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: non
Posté par Krunch (Jabber id, page perso, ) le 14/09/2006 à 22:02. (lien). Évalué à 2.Ha oui et si on est vraiment allergique aux gestionnaires de versions, une journalisation externe simple peut se faire avec une bête mailing list (avec ou sans diff en pièce jointe).
--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
-
-
-
-
Télédistribution
Une solution (extrèmement) propre consiste à appliquer les modifications sous forme de packages. Une fois les modifications testées sur un environnement de test, tu les déploie en production par télédistribution.
Un outil de télédistribution: http://ocsinventory.sourceforge.net/
Avantage: tout le monde voit l'historique des déploiements de packages.
Pour le suivi des travaux sur ton parc de machine, un outil de gestion de tickets peut suffire: GLPI qui exploite l'inventaire d'OCS ou alors RequestTracker par exemple
sudo et rsync
pour la gestion : sudo (comme cité plus haut)
pour la gestion des modifications : rsync sur chaque logout dans un répertoire du type : /rsync/modif-user-date.
a+
Revenir en haut de page || Retourner aux forums || Retourner au forum Linux.general
Cette page a été générée par Templeet en 0.072s (dont 0.0073 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.