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 NeoX . É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 totoroavi . É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 nono14 (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 - Ouvert à de nouvelles opportunités
[^] # Re: une recherche avec ces memes questions
Posté par BAud (site web personnel) . Évalué à 3.
plus spécifiquement :
bon, yaurait plus à dire, ça dépendra de tes réponses ;-)
[^] # Re: une recherche avec ces memes questions
Posté par totoroavi . É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 BAud (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é :
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 :
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 Sytoka Modon (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 Marotte ⛧ . Évalué à 2.
Pas un rootkit hein ! Éventuellement chkrootkit pour vérifier qu'il n'y en a pas ;)
[^] # Re: rootkit
Posté par totoroavi . Évalué à 2.
Salut,
Ha je sais pas ça me semblais pas mal un ptit rootkit ;)
Mais oui chkrootkit ;)
# Outils
Posté par eMerzh (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 kuroineko . É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 kuroineko . Évalué à 1.
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.
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 ).
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.