Bonsoir,
J'infogère pour le compte des mes clients quelques dizaines de serveurs, en quasi-totalité sous Debian Wheezy + SaltStack. Je recherche un outil, idéalement open source, qui me permette d'avertir mes clients en "bulk" lors de la réalisation d'interventions.
Un exemple concret : mise à jour de tous les serveurs disposants de PHP 5.5 vers sa dernière version (5.5.18). Dans l'outil en question, je recherche tous les serveurs sur lesquels PHP 5.5 est installé, et envoi aux clients concernés un email les informants de la mise à jour.
En fait, il me faudrait une sorte de intercom.io mais orienté admin sys :)
Des pistes ?
Merci,
On 29/10/2014 19:59, Jonathan Leroy wrote:
Bonsoir,
Un exemple concret : mise à jour de tous les serveurs disposants de PHP 5.5 vers sa dernière version (5.5.18). Dans l'outil en question, je recherche tous les serveurs sur lesquels PHP 5.5 est installé, et envoi aux clients concernés un email les informants de la mise à jour.
En fait, il me faudrait une sorte de intercom.io mais orienté admin sys :)
Hello Jonathan,
Je dirai que ça dépend un peu de ton inventaire actuel. Mais si tu as moyen d'avoir un export sauce YAML de tes associations client/serveur (ou encore plus simple, un fichier par host avec une variable pointant sur l'email du client), avec Ansible c'est plié rapidement.
Exemple, imaginons que pour chaque host, tu aies une variable 'email_client', et que les serveurs utilisent Apt, tu peux faire quelque chose dans ce genre là :
- name: Recupère la version du package voulu shell: "dpkg -s {{ package }} 2> /dev/null | grep 'Version' | cut -f2 -d' '" register: version
- name: Prévient les clients si une mise à jour est nécessaire local_action: mail host='smtp.server' port=25 subject="Mise à jour imminente" body="Version {{ version }} obsolete - màj en vue" from="jonathan@unsigned.inikup.com" to="{{ email_client }}" when: version_cible not in version.stdout and not do_it
- name: Effectue la mise à jour si demandé apt: name={{ package }} state=latest update_cache=yes when: do_it
Avec, coté ligne de commande :
# pour prévenir ansible-playbook upgrade.yml -e 'package=php5 version_cible=5.5.18 do_it=false'
# pour mettre à jour ansible-playbook upgrade.yml -e 'package=php5 version_cible=5.5.18 do_it=true'
Après, si tu veux juste prévenir le client après la mise à jour vers la dernière version, c'est encore plus simple :
- name: Effectue la mise à jour apt: name=php5 state=latest update_cache=yes notify: Prévenir client
(le handler de notification 'Prévenir client' étant globalement équivalent à l'envoi du mail ci-dessus).
et :
ansible-playbook upgrade.yml -e 'package=php5'
Bon, c'est fait à l'arrache sur un coin de nappe, et il y a plein de manière que ça foire, donc YMMV, mais tu vois l'idée.
A+
M
Le 29 octobre 2014 21:36, Michel Blanc mb@mbnet.fr a écrit :
Hello Jonathan,
Bonjour Michel,
Désolé pour la réponse tardive, j'étais passé à côté...
Je dirai que ça dépend un peu de ton inventaire actuel. Mais si tu as moyen d'avoir un export sauce YAML de tes associations client/serveur (ou encore plus simple, un fichier par host avec une variable pointant sur l'email du client), avec Ansible c'est plié rapidement.
Exemple, imaginons que pour chaque host, tu aies une variable 'email_client', et que les serveurs utilisent Apt, tu peux faire quelque chose dans ce genre là : [...]
En fait je voulais surtout vérifier qu'aucune solution "clé en main" n'existe avant de me lancer dans du dev. Entre temps, j'ai découvert cette solution proposée par OVH, qui ne correspond pas totalement à mes besoins mais qui est ce qui s'en rapproche le plus : http://distrodash.ovh.ca/
Je pense que je vais développer un petit script chargé de remonter depuis chaque serveur la liste des paquets à mettre à jours, que je pourrais ensuite afficher dans l'espace client de mes clients, puis éventuellement les alerter par email.
Le 18 janvier 2015 22:22, Jonathan Leroy jonathan@unsigned.inikup.com a écrit :
En fait je voulais surtout vérifier qu'aucune solution "clé en main" n'existe avant de me lancer dans du dev. Entre temps, j'ai découvert cette solution proposée par OVH, qui ne correspond pas totalement à mes besoins mais qui est ce qui s'en rapproche le plus : http://distrodash.ovh.ca/
Je pense que je vais développer un petit script chargé de remonter depuis chaque serveur la liste des paquets à mettre à jours, que je pourrais ensuite afficher dans l'espace client de mes clients, puis éventuellement les alerter par email.
Smile chez qui certains des sites de la société sont hébergés a implémenté cela dans Redmine ; on reçoit de temps en temps des tickets avec pour chaque vm la liste des paquets mis à jour.
Si qqn connait qqn de cette équipe ou s'ils sont sur la liste, ils peuvent peut être partager ça ?
Mes 2 cents du lundi matin, Nicolas
Le 19 janv. 2015 à 09:54, Nicolas Steinmetz nsteinmetz@gmail.com a écrit :
Le 18 janvier 2015 22:22, Jonathan Leroy <jonathan@unsigned.inikup.com mailto:jonathan@unsigned.inikup.com> a écrit :
En fait je voulais surtout vérifier qu'aucune solution "clé en main" n'existe avant de me lancer dans du dev. Entre temps, j'ai découvert cette solution proposée par OVH, qui ne correspond pas totalement à mes besoins mais qui est ce qui s'en rapproche le plus : http://distrodash.ovh.ca/ http://distrodash.ovh.ca/
Je pense que je vais développer un petit script chargé de remonter depuis chaque serveur la liste des paquets à mettre à jours, que je pourrais ensuite afficher dans l'espace client de mes clients, puis éventuellement les alerter par email.
Smile chez qui certains des sites de la société sont hébergés a implémenté cela dans Redmine ; on reçoit de temps en temps des tickets avec pour chaque vm la liste des paquets mis à jour.
Si qqn connait qqn de cette équipe ou s'ils sont sur la liste, ils peuvent peut être partager ça ?
Mes 2 cents du lundi matin, Nicolas _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Salut,
Tu as un script qui fait ça sous debian. Il faut installer le package update-noitifer-common. Il faut ensuite utiliser le script apt-check.
Sinon tu peux le faire « avec ta bite et ton couteau » ça fonctionne aussi: https://github.com/DjinnS/Debian-security-check https://github.com/DjinnS/Debian-security-check
Tu as ensuite toute la liberté de remonter les informations dans ton extranet client.
A+
— Guillaume
-
DjinnS -
Jonathan Leroy -
Michel Blanc -
Nicolas Steinmetz