Forum Linux.débutant Bonne pratique administration système

Posté par  .
Étiquettes : aucune
1
24
août
2011

Bonjour,

Dans un désire de m'améliorer et d'apprendre et profiter de vos expériences, je cherche des bonnes pratique/outils sur l'administration système. Je me considère comme débutant donc bon je pars sur la base, si mon poste peux en aider d'autre, même si je dois passer pour le neuneu de service ;)

  • Dans la fréquence des mises a jour ? comment vérifier si une mise à jour va faire cracher votre serveur en production ...

  • Fréquence d'analyse d'état de santé des disques durs ?

  • Outils d'administration à distance ? (mise à jour de configuration, voir mise a jour des sytèmes etc ...)

  • La configuration minimal en sécurité (Firewall, Ssh, rootkit ...)

Bon avec un peu de chance sa partira pas en troll baveux (déjà y a pas kde ni gnome :p)

Merci de vos retour dans tous les cas.

Totoroavi

  • # une recherche avec ces memes questions

    Posté par  . Évalué à 7.

    te donneras deja pas mal de chose à lire, et tu gagneras du temps par rapport à lire un forum.
    je mets neanmoins mes reponses ci-dessous :
    - frequence de mise à jour : c'est toi qui voit, si tu es ou non dans un secteur critique ou pas

    • comment verifier si une mise à jour va faire planter un serveur en prod : simplement en ayant un maquette identique à la prod sur laquelle tu vas appliquer la mise à jour et voir si ca plante

    • analyse santé disque dur ? bah y a des outils de monitoring pour surveiller ca en quasi temps reels

    • administration à distance : ssh principalement, mais si le parc est tres grand, il y a des outils comme puppet, cfengine

    • config mini en securité : rien ne rentre sauf ce que tu autorises (donc firewall), ne pas laisser de service inutile qui tourne si ce n'est pas necessaire (ex : apache si ce n'est pas un serveur web)

    • [^] # Re: une recherche avec ces memes questions

      Posté par  . Évalué à 1.

      Bonjour,

      J'ai fais des recherche déjà sur google. Mais j'aimerais avoir des retours de se qui se fais plus dans la pratique.

      Mais merci de ton retour.

      • [^] # Re: une recherche avec ces memes questions

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

        ça dépend de ce que tu recherches, de ton infrastructure, des moyens dont tu disposes...

        Système - Réseau - Sécurité Open Source

        • [^] # Re: une recherche avec ces memes questions

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

          plus spécifiquement :

          • nombre de postes à administrer (pas forcément les mêmes solutions pour une dizaine ou une centaine...)
          • types de postes : serveurs d'applications, serveurs d'infrastructures, postes clients, postes nomades voire
          • diversité des OS : windows (même si je pense que ceux-là mériteraient leur infra à part tellement c'est compliqué pour bien le faire...), unix (AIX, les Slowlaris même si en voie de disparition..., Linux selon la ou les distros... autres ?)
          • niveau de maturité des projets (cycle de développement avec environnements dédiés développement, qualification/recette/préproduction, production ?)

          bon, yaurait plus à dire, ça dépendra de tes réponses ;-)

          • [^] # Re: une recherche avec ces memes questions

            Posté par  . Évalué à -1.

            Bonjour,

            Dans mon cas, une vingtaine de serveur, malheureusement pas tous avec la même configuration.
            Les serveurs sont sous Debian, en version varier :(
            Au niveau des projets le plus "exotique" est openswan. (noter les " ;) ) c'est d'ailleurs celui qui nous a poser le plus de problème lors de mise à jour.

            Vue que je suis dans une petite structure... pour tout se qui est teste avant mise a jour etc... pas forcément évident.

            Dans tous les cas j'apprécie vos différent retour.

            à Bientôt

            Totoroavi

            • [^] # Re: une recherche avec ces memes questions

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

              bin autant « capitaliser » sur le problème rencontré, tant techniquement que pour tenter d'obtenir d'avoir au minimum une pré-production, à l'identique de la prod', histoire d'éviter que ça se reproduise... Quand je dis capitaliser c'est aussi en profiter pour identifier combien a coûté le souci rencontré :

              • temps d'indisponibilité, ce que ça a empêché de faire... (et ce que ça a généré comme coût)
              • différence de chiffrage du temps évalué à y passer avant et temps que cela a effectivement pris
              • nombre de fois où il est acceptable que ce genre de souci se reproduise...

              Si on te répond que doubler l'infra pour des environnements qui ne serviront qu'une fois par an voire mois, bin indiquer les points notés ci-dessus :-) Garder comme autres arguments sous le coude que :

              • l'environnement en double pourrait servir de fail-over ou de remplacement si problème sur le serveur principal (les disques ça pète régulièrement, une carte réseau peut griller...)
              • dans le cas idéal, ce n'est pas un environnement supplémentaire qu'il faudrait mais un pour le "développement" (s'il y en a), un pour la qualification technique, un pour la qualification fonctionnelle (pour une appli), un pour la recette utilisateur, un pour les benchmarks, un pour la maintenance, un autre pour les montées de version, bon je dois en oublier :-) Il est possible de mutualiser pour optimiser un peu... mais bon généralement c'est tout de même 3 environnements au mini - en comptant la prod' - qui sont recommandés.
              • évaluer ce que la virtualisation peut apporter (pour pouvoir créer des environnements à la volée, sans avoir à acheter trop de matériel à chaque fois...), prévoir plus de place disque ça aide, doubler ou tripler le volume envisagé initialement (il y a toujours besoin de plus :/).

              Dans l'admin, il y a le volet technique effectivement, mais il y a aussi tous les argumentaires pour justifier de pouvoir bosser correctement et dans de bonnes conditions plutôt qu'avec des bouts de ficelle.

              Pour ta vingtaine de serveurs, puppet pour gérer les déploiements peut sembler overkill, mais bon ça permet aussi de scripter une mise en production et de la répéter sur un environnement amont à la prod' sans rien casser, sachant qu'il restera toujours un cas de plus non prévu (sinon spa drôle).

              Sinon, comment ça des versions variées de debian ? Tout n'est pas en Squeeze ?

    • [^] # Re: une recherche avec ces memes questions

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

      En complément de cfengine, tout versionner via subversion ou équivalent...

      Pour les mises à jour, je les fais régulièrement sans trop me poser de question mais je suis devant les machines. Je le fais par paquet de 40 machines environs avec clusterssh. Pour les serveurs (virtualisé dans Xen), j'ai toujours deux backups ! Un backup de la nuit sur un autre dom0 que je suis prèt à lancer en cas de grosse merde. Cela n'arrive quasiment jamais pour être honnête sans lors d'un upgrade de système. En plus, j'ai un backup via backuppc de tous les serveurs.

      Sachant que les serveurs sont des installations minimales de debian et que cfengine s'occupe de tout le reste, la ré-installation d'un serveur est pas si long que cela (le problème sont toujours les données et non le système).

  • # rootkit

    Posté par  . Évalué à 2.

    La configuration minimal en sécurité (Firewall, Ssh, rootkit ...)

    Pas un rootkit hein ! Éventuellement chkrootkit pour vérifier qu'il n'y en a pas ;)

    • [^] # Re: rootkit

      Posté par  . Évalué à 2.

      Salut,

      Ha je sais pas ça me semblais pas mal un ptit rootkit ;)

      Mais oui chkrootkit ;)

  • # Outils

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

    Perso moi je voterais aussi pour l'install d'outils de monitoring genre
    Munin, Nagios / shinken ou autre qui permettent de te notifier de problèmes et de voir les différents états et évolutions.

    Après des outils comme puppet & co c'est sympa mais p-e trop gros pr ton infra...un truc genre etckeeper peut-être pratique si tu connais un peu les DVCS...

    • [^] # Re: Outils

      Posté par  . Évalué à 1.

      Oui tout à fait c'est un très bon complément aux taches classique d'administration, pour anticiper les problèmes.

  • # bha dison pour faire simple

    Posté par  . Évalué à 1.

    • Dans la fréquence des mises a jour ? comment vérifier si une mise à jour va faire cracher votre serveur en production ...

    La fréquence est moins importante que la qualité de la mise à jour, et chaque fois que c'est possible on prend tjrs la mise à jour connue stable mais jamais la dernière chronologique, au cas où des problèmes non-découverts existeraient...
    Accessoirement lorsque c'est possible, on maquette une copie ISO-prod et on test dessus d'abord, plusieurs jours, et on teste en particulier la possibilité de retour arrière.

    • Fréquence d'analyse d'état de santé des disques durs ?

    Chaque down-time programmé, on doit en profiter pour le faire, et si on en a pas de down-time prévu, on en fait 1 au minimum lors d'un reboot programmé, pour mise à jour ou pour le reboot annuel minimal nécessaire (même si en général on ne le fait jamais on devrait ).

    • La config minimal en sécurité ?

    Bha là ça dépend de la structure, mais de façon général aucun accès possible hors ssh par clef, aucune connections par password hormis localement. Chaque machine à son démon de blacklist, de surveillance rootkits etc... toute salle informatique doit avoir son firewall hardware, avec jumper qui interdit électriquement la mise à jour du firmware. et bien sur en entrée on a 4 firewall redondés 2 à 2, à la suite. Une fois par an au moins, une campagne de type nessus ou tiger d'analyse des risques et d'estimation des mises à jours de sécurités à faire doit être pratiqué (_là pareil on le fait plus quand on a le temps que de façon planifié, genre l'été _)

Suivre le flux des commentaires

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