Forum Linux.général administrer à plusieurs un serveur

Posté par  .
Étiquettes : aucune
0
14
sept.
2006
bonjour,

Nous 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.

  • # Bein ...

    Posté par  . Évalué à 3.

    CVS ?

  • # sudo

    Posté par  . Évalué à 2.

    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  . É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

      • [^] # Re: sudo

        Posté par  (site web personnel) . É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.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: sudo

          Posté par  . É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é ?

          • [^] # non

            Posté par  (site web personnel) . É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. ».

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

            • [^] # Re: non

              Posté par  (site web personnel) . É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).

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Journal de log

    Posté par  (site web personnel) . Évalué à 1.

    Une solution simple sile besoin n'est pas trop important : utiliser la commande 'logger' pour enregistrer des commandes et éventuellement des commentaires dans un fichier journal.

  • # Télédistribution

    Posté par  . Évalué à 2.

    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

    Posté par  . Évalué à 2.

    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+

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.