bonjour la planète, Je m'excuse d'avance car c'est peut-etre un sujet redondant.je suis à la recherche d'un système de gestion de mises à jour Linux (mainly des Ubuntu...) de façon auto avec un reporting en mode web (ou autre).En gros, un système à la Landscape ou Puppet mais avec un modèle économique un peu moins étouffant si possible.J'ai déjà lorgné du coté de spacewalk mais redhat only, du coté de Foreman mais cela me paraissait pas faire l'affaire....ce qui me paraissait à peu près faire l'affaire était rundeck mais pas de vrai interface de reporting centralisé... J'ai aussi vu des produits mais qui partait de templating, alors que moi mes machines existent déjà, sont toutes différentes et n'ont aucun lien entre elle... mon besoin:* accrocher mes machines Linux (toutes indépendantes)* déployer les mises à jour de sécurités * reporting de situation * pas de service en ligne / cloud je pense que je cherche mal au niveau de l'existant, je n'arrive pas à déméler le sac de noeud des différents produits.C'est pourquoi je me permets de me tourner vers la communauté. par avance, merci beaucoup et bonne journée, Toni
Le 18/08/2015 10:03, Toni Verdasco a écrit :
bonjour la planète,
Je m'excuse d'avance car c'est peut-etre un sujet redondant. je suis à la recherche d'un système de gestion de mises à jour Linux (mainly des Ubuntu...) de façon auto avec un reporting en mode web (ou autre). En gros, un système à la Landscape ou Puppet mais avec un modèle économique un peu moins étouffant si possible. J'ai déjà lorgné du coté de spacewalk mais redhat only, du coté de Foreman mais cela me paraissait pas faire l'affaire.... ce qui me paraissait à peu près faire l'affaire était rundeck mais pas de vrai interface de reporting centralisé... J'ai aussi vu des produits mais qui partait de templating, alors que moi mes machines existent déjà, sont toutes différentes et n'ont aucun lien entre elle...
mon besoin:
- accrocher mes machines Linux (toutes indépendantes)
- déployer les mises à jour de sécurités
- reporting de situation
- pas de service en ligne / cloud
je pense que je cherche mal au niveau de l'existant, je n'arrive pas à déméler le sac de noeud des différents produits. C'est pourquoi je me permets de me tourner vers la communauté.
par avance, merci beaucoup et bonne journée,
Bonjour Toni,
As tu regardé Rudder ? ( http://www.rudder-project.org ) Il semble correspondre à ta liste de besoin: - ca gère Ubuntu/Debian/RedHat/Centos/SLES - une interface graphique de reporting et de configuration - par nécessaire de se baser sur des templates, tu construits les règles sur des groupes de noeuds (qui peuvent ne contenir qu'un noeud si c'est vraiment spécifique) - c'est un outil de gestion de conf, donc tu peux aller plus loin que du deploiement de maj de sécurité - et c'est open source (sisi, même l'interface graphique)
Nicolas
Toni
Bonjour Toni,
Si ce n'est pas indiscret, quel était le problème de The Foreman ?
Tu cites Puppet plus haut dans ton post, Foreman est un orchestrateur de PuppetMasters qui retourne à l'utilisateur des graphiques de compliance des différents déploiement effectués. Il peut aussi aller jusqu'à créer ta VM/ton OS avec un PXE, à la sauce Cobbler. Tu y gères directement tes modules puppet.
Je n'ai pas encore pris la main sur sa configuration, mais j'ai cru comprendre qu'il était possible de gérer les mises à jour dans puppet avec des choses comme :
package { "screen": ensure => "latest" }
Concernant Rudder mes collègues et moi avons trouvé l'interface assez rebutante/contre nature... :)
Cordialement,
-- Youenn Piolet piolet.y@gmail.com
Le 18 août 2015 10:18, Nicolas Charles nicolas.charles@normation.com a écrit :
Le 18/08/2015 10:03, Toni Verdasco a écrit :
bonjour la planète,
Je m'excuse d'avance car c'est peut-etre un sujet redondant. je suis à la recherche d'un système de gestion de mises à jour Linux (mainly des Ubuntu...) de façon auto avec un reporting en mode web (ou autre). En gros, un système à la Landscape ou Puppet mais avec un modèle économique un peu moins étouffant si possible. J'ai déjà lorgné du coté de spacewalk mais redhat only, du coté de Foreman mais cela me paraissait pas faire l'affaire.... ce qui me paraissait à peu près faire l'affaire était rundeck mais pas de vrai interface de reporting centralisé... J'ai aussi vu des produits mais qui partait de templating, alors que moi mes machines existent déjà, sont toutes différentes et n'ont aucun lien entre elle...
mon besoin:
- accrocher mes machines Linux (toutes indépendantes)
- déployer les mises à jour de sécurités
- reporting de situation
- pas de service en ligne / cloud
je pense que je cherche mal au niveau de l'existant, je n'arrive pas à déméler le sac de noeud des différents produits. C'est pourquoi je me permets de me tourner vers la communauté.
par avance, merci beaucoup et bonne journée,
Bonjour Toni,
As tu regardé Rudder ? ( http://www.rudder-project.org ) Il semble correspondre à ta liste de besoin:
- ca gère Ubuntu/Debian/RedHat/Centos/SLES
- une interface graphique de reporting et de configuration
- par nécessaire de se baser sur des templates, tu construits les règles
sur des groupes de noeuds (qui peuvent ne contenir qu'un noeud si c'est vraiment spécifique)
- c'est un outil de gestion de conf, donc tu peux aller plus loin que du
deploiement de maj de sécurité
- et c'est open source (sisi, même l'interface graphique)
Nicolas
Toni
Liste de diffusion du FRsAG http://www.frsag.org/
Le 18/08/2015 17:44, Youenn PIOLET a écrit :
Bonjour Toni,
Bonjour Youenn,
Si ce n'est pas indiscret, quel était le problème de The Foreman ?
Tu cites Puppet plus haut dans ton post, Foreman est un orchestrateur de PuppetMasters qui retourne à l'utilisateur des graphiques de compliance des différents déploiement effectués. Il peut aussi aller jusqu'à créer ta VM/ton OS avec un PXE, à la sauce Cobbler. Tu y gères directement tes modules puppet.
Je me trompe peut être, mais The Foreman ne supporte pas encore Puppet 4 (cf http://projects.theforeman.org/issues/8447 ) et d'ailleurs, aucune des interfaces graphiques existantes n'ont pu être portées vers Puppet 4 pour l'instant
Je n'ai pas encore pris la main sur sa configuration, mais j'ai cru comprendre qu'il était possible de gérer les mises à jour dans puppet avec des choses comme : |package { "screen": ensure => "latest" }| Concernant Rudder mes collègues et moi avons trouvé l'interface assez rebutante/contre nature... :)
Je réagis sur ce point. Qu'as tu trouvé de rebutant ou contre nature dans l'interface ? Était-ce sur une version récente (3.0 ou 3.1) ou une plus ancienne ? On a fait pas mal d'efforts sur l'amélioration de l'ergonomie, et on est preneur de tous retours pouvant nous aider à améliorer encore.
Merci ! Nicolas
Cordialement,
-- Youenn Piolet piolet.y@gmail.com mailto:piolet.y@gmail.com / /
Le 18 août 2015 10:18, Nicolas Charles <nicolas.charles@normation.com mailto:nicolas.charles@normation.com> a écrit :
Le 18/08/2015 10:03, Toni Verdasco a écrit :bonjour la planète, Je m'excuse d'avance car c'est peut-etre un sujet redondant. je suis à la recherche d'un système de gestion de mises à jour Linux (mainly des Ubuntu...) de façon auto avec un reporting en mode web (ou autre). En gros, un système à la Landscape ou Puppet mais avec un modèle économique un peu moins étouffant si possible. J'ai déjà lorgné du coté de spacewalk mais redhat only, du coté de Foreman mais cela me paraissait pas faire l'affaire.... ce qui me paraissait à peu près faire l'affaire était rundeck mais pas de vrai interface de reporting centralisé... J'ai aussi vu des produits mais qui partait de templating, alors que moi mes machines existent déjà, sont toutes différentes et n'ont aucun lien entre elle... mon besoin: * accrocher mes machines Linux (toutes indépendantes) * déployer les mises à jour de sécurités * reporting de situation * pas de service en ligne / cloud je pense que je cherche mal au niveau de l'existant, je n'arrive pas à déméler le sac de noeud des différents produits. C'est pourquoi je me permets de me tourner vers la communauté. par avance, merci beaucoup et bonne journée,Bonjour Toni, As tu regardé Rudder ? ( http://www.rudder-project.org ) Il semble correspondre à ta liste de besoin: - ca gère Ubuntu/Debian/RedHat/Centos/SLES - une interface graphique de reporting et de configuration - par nécessaire de se baser sur des templates, tu construits les règles sur des groupes de noeuds (qui peuvent ne contenir qu'un noeud si c'est vraiment spécifique) - c'est un outil de gestion de conf, donc tu peux aller plus loin que du deploiement de maj de sécurité - et c'est open source (sisi, même l'interface graphique) NicolasToni_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Hello Toni,
On Tue, Aug 18, 2015 at 10:03 AM Toni Verdasco tverdasco@outlook.com wrote:
bonjour la planète,
Je m'excuse d'avance car c'est peut-etre un sujet redondant. je suis à la recherche d'un système de gestion de mises à jour Linux (mainly des Ubuntu...) de façon auto avec un reporting en mode web (ou autre). En gros, un système à la Landscape ou Puppet mais avec un modèle économique un peu moins étouffant si possible. J'ai déjà lorgné du coté de spacewalk mais redhat only, du coté de Foreman mais cela me paraissait pas faire l'affaire.... ce qui me paraissait à peu près faire l'affaire était rundeck mais pas de vrai interface de reporting centralisé... J'ai aussi vu des produits mais qui partait de templating, alors que moi mes machines existent déjà, sont toutes différentes et n'ont aucun lien entre elle...
mon besoin:
- accrocher mes machines Linux (toutes indépendantes)
- déployer les mises à jour de sécurités
- reporting de situation
- pas de service en ligne / cloud
je pense que je cherche mal au niveau de l'existant, je n'arrive pas à déméler le sac de noeud des différents produits. C'est pourquoi je me permets de me tourner vers la communauté.
par avance, merci beaucoup et bonne journée,
Toni _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Personnellement je suis un grand fan d'Ansible qui a une très petite learning curve et ne nécessite aucune installation d'agents sur les serveurs.
Pour ce qui est reporting & co, tu as Ansible Tower, par contre c'est loin d'être gratuit (contrairement à Ansible tout court qui est libre).
Mais bon, si tu veux juste du reporting sur les mises à jour, peut-être qu'Ansible plus un peu d'huile de coude ça peut bien se passer :)
Le 18/08/2015 18:36, Rémy Sanchez a écrit :
Hello Toni,
On Tue, Aug 18, 2015 at 10:03 AM Toni Verdasco <tverdasco@outlook.com mailto:tverdasco@outlook.com> wrote:
bonjour la planète, Je m'excuse d'avance car c'est peut-etre un sujet redondant. je suis à la recherche d'un système de gestion de mises à jour Linux (mainly des Ubuntu...) de façon auto avec un reporting en mode web (ou autre). En gros, un système à la Landscape ou Puppet mais avec un modèle économique un peu moins étouffant si possible. J'ai déjà lorgné du coté de spacewalk mais redhat only, du coté de Foreman mais cela me paraissait pas faire l'affaire.... ce qui me paraissait à peu près faire l'affaire était rundeck mais pas de vrai interface de reporting centralisé... J'ai aussi vu des produits mais qui partait de templating, alors que moi mes machines existent déjà, sont toutes différentes et n'ont aucun lien entre elle... mon besoin: * accrocher mes machines Linux (toutes indépendantes) * déployer les mises à jour de sécurités * reporting de situation * pas de service en ligne / cloud je pense que je cherche mal au niveau de l'existant, je n'arrive pas à déméler le sac de noeud des différents produits. C'est pourquoi je me permets de me tourner vers la communauté. par avance, merci beaucoup et bonne journée, Toni _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/Personnellement je suis un grand fan d'Ansible qui a une très petite learning curve et ne nécessite aucune installation d'agents sur les serveurs.
Pour ce qui est reporting & co, tu as Ansible Tower, par contre c'est loin d'être gratuit (contrairement à Ansible tout court qui est libre).
Mais bon, si tu veux juste du reporting sur les mises à jour, peut-être qu'Ansible plus un peu d'huile de coude ça peut bien se passer :) -- *Rémy Sanchez* http://hyperthese.net/
Liste de diffusion du FRsAG http://www.frsag.org/
+1 pour Ansible... que l'on pousse bcp en ce moment là où on est Il existe une alternative très partielle à Ansible Tower, c'est ansible-semaphore (non testé) Sinon en front-end je me pencherais plus sur Rundeck (non testé) qui semble s'interfacer avec bcp de choses du moment que c'est du script si j'ai bien capté (et donc pas dépendant de chef/ansible/salt/puppet/etc....)
Cdlt,
JYL
Le 18/08/2015 19:40, Jean-Yves LENHOF a écrit :
+1 pour Ansible... que l'on pousse bcp en ce moment là où on est Il existe une alternative très partielle à Ansible Tower, c'est ansible-semaphore (non testé) Sinon en front-end je me pencherais plus sur Rundeck (non testé) qui semble s'interfacer avec bcp de choses du moment que c'est du script si j'ai bien capté (et donc pas dépendant de chef/ansible/salt/puppet/etc....)
Intéressant ansible semaphore j'avais pas trouvé mais je cherche pas encore d'interface à Ansible.
Question de débutant sur Ansible, j'ai beau lire des docs dans tous les sens, je vois plus souvent des playbooks sur le déploiement de logiciels systèmes (serveur web, db, services en tout genre) mais j'ai trouvé qu'un seul élément http://debops.org/ pour le déploiement des configurations de base et des packages à installer par défaut.
Du coup je me demande si des gens utilisent Ansible pour postconfiguré une fresh installation? Si vous avez des ressources à me recommander ça m'intéresse.
On Wed, Aug 19, 2015 at 10:42 AM Wallace wallace@morkitu.org wrote:
Question de débutant sur Ansible, j'ai beau lire des docs dans tous les sens, je vois plus souvent des playbooks sur le déploiement de logiciels systèmes (serveur web, db, services en tout genre) mais j'ai trouvé qu'un seul élément http://debops.org/ pour le déploiement des configurations de base et des packages à installer par défaut.
Du coup je me demande si des gens utilisent Ansible pour postconfiguré une fresh installation?
C'est ce que je fais, à l'aide principalement de :
- http://docs.ansible.com/ansible/apt_module.html pour installer des paquets - http://docs.ansible.com/ansible/lineinfile_module.html pour éditer des fichiers de conf - http://docs.ansible.com/ansible/template_module.html pour générer des fichiers de conf plus complexes (BDD, vhost, ...)
Ça répond à la question ?
Le 19/08/2015 10:59, Rémy Sanchez a écrit :
On Wed, Aug 19, 2015 at 10:42 AM Wallace <wallace@morkitu.org mailto:wallace@morkitu.org> wrote:
Question de débutant sur Ansible, j'ai beau lire des docs dans tous les sens, je vois plus souvent des playbooks sur le déploiement de logiciels systèmes (serveur web, db, services en tout genre) mais j'ai trouvé qu'un seul élément http://debops.org/ pour le déploiement des configurations de base et des packages à installer par défaut. Du coup je me demande si des gens utilisent Ansible pour postconfiguré une fresh installation?C'est ce que je fais, à l'aide principalement de :
- http://docs.ansible.com/ansible/apt_module.html pour installer des paquets
- http://docs.ansible.com/ansible/lineinfile_module.html pour éditer des fichiers de conf
- http://docs.ansible.com/ansible/template_module.html pour générer des fichiers de conf plus complexes (BDD, vhost, ...)
En fait y a les deux extrêmes, d'un côté on voit les docs qui disent faut factoriser à fond pour pouvoir réutiliser au maximum en changeant juste quelques variables et d'un autre la doc officielle qui montre en exemple un simple listing d'actions à faire sans prendre en compte différentes versions de Debian ou les adaptations nécessaires vis à vis d'Ubuntu. Les exemples de la doc sont effectivement simple et permettent de rapidement mettre en place des actions mais est ce le bon exemple, je n'en suis pas convaincu quand je vois le travail de debops qui là à mon goût est peu flexible si je veux changer une façon de faire sans forker leur git.
On Wed, Aug 19, 2015 at 12:08 PM Wallace wallace@morkitu.org wrote:
En fait y a les deux extrêmes, d'un côté on voit les docs qui disent faut factoriser à fond pour pouvoir réutiliser au maximum en changeant juste quelques variables et d'un autre la doc officielle qui montre en exemple un simple listing d'actions à faire sans prendre en compte différentes versions de Debian ou les adaptations nécessaires vis à vis d'Ubuntu. Les exemples de la doc sont effectivement simple et permettent de rapidement mettre en place des actions mais est ce le bon exemple, je n'en suis pas convaincu quand je vois le travail de debops qui là à mon goût est peu flexible si je veux changer une façon de faire sans forker leur git.
Pour moi la stratégie est la suivante : faire le script pour la/les machines cibles, et quand de nouvelles machines avec des distros/versions différentes apparaissent, je rajoute des conditions pour faire des actions appropriées en fonction de.
Idem pour la factorisation, à part certains trucs que tu sais qu'il faut ranger dans des variables (comptes user/mot de passe, tokens/endpoints d'API externes, ...), il vaut mieux rajouter des variables au fur et à mesure de l'émergeance d'un besoin de généricité. Le script parfaitement générique n'existe pas :)
Le 2015-08-19 13:59, Rémy Sanchez a écrit :
On Wed, Aug 19, 2015 at 12:08 PM Wallace wallace@morkitu.org wrote:
En fait y a les deux extrêmes, d'un côté on voit les docs qui disent faut factoriser à fond pour pouvoir réutiliser au maximum en changeant juste quelques variables et d'un autre la doc officielle qui montre en exemple un simple listing d'actions à faire sans prendre en compte différentes versions de Debian ou les adaptations nécessaires vis à vis d'Ubuntu. Les exemples de la doc sont effectivement simple et permettent de rapidement mettre en place des actions mais est ce le bon exemple, je n'en suis pas convaincu quand je vois le travail de debops qui là à mon goût est peu flexible si je veux changer une façon de faire sans forker leur git.
Pour moi la stratégie est la suivante : faire le script pour la/les machines cibles, et quand de nouvelles machines avec des distros/versions différentes apparaissent, je rajoute des conditions pour faire des actions appropriées en fonction de.
En fait je vais un poil plus loin encore... Mes premières lignes d'un rôle testent la distribution et si personne n'a encore testé ce rôle sur cette distribution dans la version précisée je sors en failed avec un message du genre vas modifier le rôle pour autoriser cette version et du coup jeter un oeil s'il n'y aurait pas de lignes spécifiques à la version du genre un apt ou un yum avec un repository spécifique à une version.
Si vous avez d'autres bonnes pratiques à partager n'hésitez pas, pour ma part, en voici deux :
- je préfixe toutes les variables d'un rôle par le nom du rôle pour éviter les surcharges par un autre rôle...
- une variable ne comprend pas de tiret ni de point, et donc par rapport à la règle juste au-dessus les rôles n'ont donc pas non plus de tiret et de point dans leur nom (Le tiret et le point ont des significations spécifiques en python et donc en ninja2 & ansible... cette connerie m'a fait perdre une bonne demi-journée)
Cdlt,
JYL
Salut!
Je recommande saltstack ( https://github.com/saltstack/salt )
Pour ce qui est de l'interface graphique pour salt (jamais utilise perso mais merite un coup d'oeil), il y a halite ( https://github.com/saltstack/halite )
J'utilise Salt depuis un moment et ca marche plutot bien !
Val
Feron Valentin valferon@gmail.com 0474 225 521
Le 19 août 2015 23:43, Jean-Yves LENHOF jean-yves@lenhof.eu.org a écrit :
Le 2015-08-19 13:59, Rémy Sanchez a écrit :
On Wed, Aug 19, 2015 at 12:08 PM Wallace wallace@morkitu.org wrote:
En fait y a les deux extrêmes, d'un côté on voit les docs qui
disent faut factoriser à fond pour pouvoir réutiliser au maximum en changeant juste quelques variables et d'un autre la doc officielle qui montre en exemple un simple listing d'actions à faire sans prendre en compte différentes versions de Debian ou les adaptations nécessaires vis à vis d'Ubuntu. Les exemples de la doc sont effectivement simple et permettent de rapidement mettre en place des actions mais est ce le bon exemple, je n'en suis pas convaincu quand je vois le travail de debops qui là à mon goût est peu flexible si je veux changer une façon de faire sans forker leur git.
Pour moi la stratégie est la suivante : faire le script pour la/les machines cibles, et quand de nouvelles machines avec des distros/versions différentes apparaissent, je rajoute des conditions pour faire des actions appropriées en fonction de.
En fait je vais un poil plus loin encore... Mes premières lignes d'un rôle testent la distribution et si personne n'a encore testé ce rôle sur cette distribution dans la version précisée je sors en failed avec un message du genre vas modifier le rôle pour autoriser cette version et du coup jeter un oeil s'il n'y aurait pas de lignes spécifiques à la version du genre un apt ou un yum avec un repository spécifique à une version.
Si vous avez d'autres bonnes pratiques à partager n'hésitez pas, pour ma part, en voici deux :
- je préfixe toutes les variables d'un rôle par le nom du rôle pour éviter
les surcharges par un autre rôle...
- une variable ne comprend pas de tiret ni de point, et donc par rapport à
la règle juste au-dessus les rôles n'ont donc pas non plus de tiret et de point dans leur nom (Le tiret et le point ont des significations spécifiques en python et donc en ninja2 & ansible... cette connerie m'a fait perdre une bonne demi-journée)
Cdlt,
JYL
Liste de diffusion du FRsAG http://www.frsag.org/
20 août 2015 03:47 "Valentin FERON" valferon@gmail.com a écrit:
Pour ce qui est de l'interface graphique pour salt (jamais utilise perso mais merite un coup d'oeil), il y a halite ( https://github.com/saltstack/halite )
Sauf que c'est "deprecated" ; que le projet est abandonné ('retired')
Dans le message indiquant l'arrêt du projet, il est mentionné une voire deux alternatives : https://groups.google.com/forum/#!msg/salt-users/rmMWLSaw0RY/N5PGRqDkwQgJ
Mes 2 cents,
Nicolas
Le 20 août 2015 03:45, Valentin FERON valferon@gmail.com a écrit :
Salut!
Je recommande saltstack ( https://github.com/saltstack/salt )
Pour ce qui est de l'interface graphique pour salt (jamais utilise perso mais merite un coup d'oeil), il y a halite ( https://github.com/saltstack/halite )
J'utilise Salt depuis un moment et ca marche plutot bien !
+1 pour SaltStack. C'est très simple à mettre en place (paquets Debian/Ubuntu, puis conf YAML) et plutôt light. D'énormes progrès ont été faits au niveau de perfs sur les dernières versions.
La communauté est très sympa, les devs sont toujours présents sur GitHub pour répondre aux tickets et acceptent bien volontiers les patchs.
Bonjour, merci à tous pour vos réponses (in et off liste). Pour répondre à Youenn Piolet concernant Foreman, mon problème n°1 c'était peut-etre mes mouffles :) :)le problème n°2 c'est justement que cela finissait toujours par prendre la tournure qu'a pris ce post: c'est à dire déploiement, factorisation, templating...alors que moi je cherche (dans la mesure du possible) un outil simple (pas une usine à gaz) qui me dirait "ok t'as tant ou de mise à jour de secu sur telle ou telle machines", je pourrai le gérer comme le disait certains à l'huile de coude avec un simple unattended-upgrade et un chti dev de traitement du mail envoyé par unattended-upgrades. Mais parfois pourquoi réinventer la roue ? Rudder me plait beaucoup, je l'ai monté et testé de base, l'esprit est là et l'API disponible m'intéresse aussi. J'ai mis un gars dessus, si je comprends toutefois la logique des directives et ses moultes possibilités, j'ai juste du mal à comprendre comment obtenir mon but , c'est à dire reporting & déploiement des mises à jour de sécurité. Il a contacté la mailinglist de Rudder pour obtenir plus d'infos, un truc tout bete nous échappe surement...
Mais je ne renie pas les autres produits que j'avais déjà survolé et qui sont tous plus intéressants les uns que les autres... Excellente journée à tous, Toni
Le Fri, Aug 21, 2015 at 07:35:40AM +0000, Toni Verdasco [tverdasco@outlook.com] a écrit: [...]
[...] alors que moi je cherche (dans la mesure du possible) un outil simple (pas une usine à gaz) qui me dirait "ok t'as tant ou de mise à jour de secu sur telle ou telle machines",
Y'a pas de reporting en soit, mais en mode juste tu vois quelles sont les serveurs avec des màj et pouvoir lui demander de les faire, nous, on utilise apt-dater (interface Curses, configuration dans un fichier XML).
Le 21 août 2015 09:35, Toni Verdasco tverdasco@outlook.com a écrit :
le problème n°2 c'est justement que cela finissait toujours par prendre la tournure qu'a pris ce post: c'est à dire déploiement, factorisation, templating... alors que moi je cherche (dans la mesure du possible) un outil simple (pas une usine à gaz) qui me dirait "ok t'as tant ou de mise à jour de secu sur telle ou telle machines"
Dans ce cas je crois que http://distrodash.ovh.ca/ fait exactement ce que tu veux. C'est ouvert à tous (pas besoin d'être client OVH), mais les sources du serveur ne sont pas dispo.
Vraiment dommage qu’OVH n’ait pas publié çà sur Github.
Ca aurait par exemple permis d’élargir les OS supportés.
Gaëtan
Le vendredi 21 août 2015 à 11:25, Jonathan Leroy a écrit :
Le 21 août 2015 09:35, Toni Verdasco <tverdasco@outlook.com (mailto:tverdasco@outlook.com)> a écrit :
le problème n°2 c'est justement que cela finissait toujours par prendre la tournure qu'a pris ce post: c'est à dire déploiement, factorisation, templating... alors que moi je cherche (dans la mesure du possible) un outil simple (pas une usine à gaz) qui me dirait "ok t'as tant ou de mise à jour de secu sur telle ou telle machines"
Dans ce cas je crois que http://distrodash.ovh.ca/ fait exactement ce que tu veux. C'est ouvert à tous (pas besoin d'être client OVH), mais les sources du serveur ne sont pas dispo.
-- Jonathan Leroy. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Hello,
Vraiment dommage qu’OVH n’ait pas publié çà sur Github.
Ca aurait par exemple permis d’élargir les OS supportés.
OVH ne publie rien sur github, en général ils ne publient pas grand chose en opensource. Il y avais même^H^H^H^Htroll sur le net vis a vis de la position de Octave vis a vis de ses employés et github...
C'est assez dommage hélas...
Xavier
On 21/08/2015 12:17, Xavier Beaudouin wrote:
Il y avais même^H^H^H^Htroll sur le net vis a vis de la position de Octave vis a vis de ses employés et github...
Vis-à-vis de tout ce qui n'est pas hosté en interne, notamment les emails corporate.
Enfin faut quand même avoir pas confiance en ses équipes infra si on est hébergeur de mail (entre autres) et qu'on utilise pas l'infra vendue pour les mails corpo (ou tout du moins une partie de l'infra)...
Après je peux comprendre le truc 'on a pas que ça à faire dans certaines boites'... mais quand même...
Xavier
On 21/08/2015 13:40, Xavier Beaudouin wrote:
On 21/08/2015 12:17, Xavier Beaudouin wrote:
Il y avais même^H^H^H^Htroll sur le net vis a vis de la position de Octave vis a vis de ses employés et github...
Vis-à-vis de tout ce qui n'est pas hosté en interne, notamment les emails corporate.
Enfin faut quand même avoir pas confiance en ses équipes infra si on est hébergeur de mail (entre autres) et qu'on utilise pas l'infra vendue pour les mails corpo (ou tout du moins une partie de l'infra)...
C'était plutôt dans le sens : si tu forwardes tes mails pro vers ton Gmail perso, tu perds des doigts...
En pratique, c'est pas quelque chose qui me choque.
J'ai pu en discuter sur #frsag hier, mais on tourne ici sur le sujet des accords de confidentialités et du devoir de réserve. Il est bien souvent difficile d'avoir une vision de ce que tu peut et ce que tu ne peut pas dire sur ton boulot. Au moins avec ce genre de structure tu sait clairement où t’arrêter que ça soit niveau comm verbale ou utilisation des services numérique de ta boite.
C'est une protection pour l'employeur et le salarié à mon sens. Dans un autre domaine je ne saurais que trop vous rappeler l'affaire Alten
Alexis PS : on est pas mal en train de dévier du sujet initial, peut être devrions nous changer le titre du topic
Le 21 août 2015 15:01, Simon Morvan garphy@zone84.net a écrit :
On 21/08/2015 13:40, Xavier Beaudouin wrote:
On 21/08/2015 12:17, Xavier Beaudouin wrote:
Il y avais même^H^H^H^Htroll sur le net vis a vis de la position de
Octave vis a
vis de ses employés et github...
Vis-à-vis de tout ce qui n'est pas hosté en interne, notamment les emails corporate.
Enfin faut quand même avoir pas confiance en ses équipes infra si on est
hébergeur de mail (entre autres) et qu'on utilise pas l'infra vendue pour les mails corpo (ou tout du moins une partie de l'infra)... C'était plutôt dans le sens : si tu forwardes tes mails pro vers ton Gmail perso, tu perds des doigts...
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour à tous,
Effectivement la discussion part dans toutes les directions qui devraient converger mais qui ne le font pas.
Reprenons dans l'ordre. Pour commencer à connaître l'état de machines il faut connaître les machines. Je n'ai pas encore trouvé d'outil simple d'inventaire dynamique qui me permette de connaître les machines et de pondre un inventory ansible en fonction de mes besoins. Collins semble faire le job mais c'est un outil Java qui consomme 800M de Ram à vide, ce qui est inacceptable pour un outil d'inventaire qui ne devrait pas, pour 1000 machines, gérer plus de 2 ou 3M de données texte.
Ensuite les mises à jour. J'ai testé Landscape et c'est à peu près exactement ce qu'il faudrait sans le crap marketing Canonical. Un contournement pourrait être : - Mes serveurs n'ont qu'une seule entrée sources.list (ou équivalent yum/...) vers un repo que j'héberge. - Une MAJ est détectée, je spawne mes environnements de prod en test, je MAJ, je run tous mes tests unitaires, fonctionnels, ... Si ça passe, je met à jour mon repo de prod. - En cron ou manuellement, tous mes serveurs de prod peuvent upgrade car c'est testé. Ainsi si c'est bien fait, j'enlève même l'intervention humaine des mises à jour de mon parc de prod :)
Pour le pilotage des serveurs, rundeck m'a vendu du rêve. Faire du libre-service de scripts est une très bonne idée. Je peux écrire des scripts et en donner accès aux devs, qui les exécutent en un clic sur leurs envs. Enfin sur le papier, car j'utilise Ansible et c'est pas encore très sec, il faut wrapper ansible dans des scripts shell et utiliser l'inventaire issu de Collins. Rundeck est en Java et consomme quasiment 1G de ram à vide. Encore une fois inacceptable.
Le sujet du déploiement d'une stack from scratch est intéressant. Je connais des admins par exemple qui utilisent ansible pour installer et conf puppet-agent sur leurs machines fraîches :) J'utilise Vagrant pour mes VM de test et de plus en plus de prod (Digital ocean, AWS). Il n'a pas de plugin pour déployer en Bare Metal, mais peut-être qu'en passant par un intermédiaire qui fasse du PXE/... unifié derrière une API ça marcherait (je vais tester MAAS de Canonical qui, encore une fois sur le papier, vend du rêve :) )
Très interessé par vos réponses !
++
2015-08-21 15:06 GMT+02:00 Alexis Lameire alexis.lameire@gmail.com:
En pratique, c'est pas quelque chose qui me choque.
J'ai pu en discuter sur #frsag hier, mais on tourne ici sur le sujet des accords de confidentialités et du devoir de réserve. Il est bien souvent difficile d'avoir une vision de ce que tu peut et ce que tu ne peut pas dire sur ton boulot. Au moins avec ce genre de structure tu sait clairement où t’arrêter que ça soit niveau comm verbale ou utilisation des services numérique de ta boite.
C'est une protection pour l'employeur et le salarié à mon sens. Dans un autre domaine je ne saurais que trop vous rappeler l'affaire Alten
Alexis PS : on est pas mal en train de dévier du sujet initial, peut être devrions nous changer le titre du topic
Le 21 août 2015 15:01, Simon Morvan garphy@zone84.net a écrit :
On 21/08/2015 13:40, Xavier Beaudouin wrote:
On 21/08/2015 12:17, Xavier Beaudouin wrote:
> Il y avais même^H^H^H^Htroll sur le net vis a vis de la position
de Octave vis a
> vis de ses employés et github...
Vis-à-vis de tout ce qui n'est pas hosté en interne, notamment les emails corporate.
Enfin faut quand même avoir pas confiance en ses équipes infra si on
est hébergeur de mail (entre autres) et qu'on utilise pas l'infra vendue pour les mails corpo (ou tout du moins une partie de l'infra)... C'était plutôt dans le sens : si tu forwardes tes mails pro vers ton Gmail perso, tu perds des doigts...
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 26/08/2015 15:26, Damien MICHAUDET a écrit :
Bonjour à tous,
Effectivement la discussion part dans toutes les directions qui devraient converger mais qui ne le font pas.
Reprenons dans l'ordre. Pour commencer à connaître l'état de machines il faut connaître les machines. Je n'ai pas encore trouvé d'outil simple d'inventaire dynamique qui me permette de connaître les machines et de pondre un inventory ansible en fonction de mes besoins. Collins semble faire le job mais c'est un outil Java qui consomme 800M de Ram à vide, ce qui est inacceptable pour un outil d'inventaire qui ne devrait pas, pour 1000 machines, gérer plus de 2 ou 3M de données texte.
Bonjour,
De notre côté on a décidé que la supervision serait l'élément qui référence les serveurs. Du coup tout est branché dessus y compris le fait de se connecter en ssh. Si le serveur n'est pas supervisé alors on ne peut rien faire dessus, rien déployer. Ca évite d'un coup l'oubli de supervision d'une machine. Bon c'est old school comme technique de nos jours quand le déploiement auto pourrait ajouter le serveur à la supervision mais comme je fais cette technique depuis 15 ans quand le déploiement auto n'existait pas ...
Bref du coup on a fait des scripts qui sortent le listing des hosts de la supervision avec le type de machine (serveur, sw, ...), l'OS, le fqdn, ... Et tout cela peut être soit passé en dynamique à Ansible (on s'y met tranquillement), soit on cron la récupération et la mise en forme d'un fichier static pour Ansible (on va privilégier cette partie là au cas où la supervision ne soit pas joignable en cas de gros crash).
J'ai vu des exemples où Ansible peut se brancher sur un vcenter ESXI pour récupérer les hosts présents. Donc on peut lui faire manger à peu près n'importe quelle source pour le fichier host.
++
On Wed, Aug 26, 2015 at 4:07 PM Wallace wallace@morkitu.org wrote:
J'ai vu des exemples où Ansible peut se brancher sur un vcenter ESXI pour récupérer les hosts présents. Donc on peut lui faire manger à peu près n'importe quelle source pour le fichier host.
En fait, Ansible appelle un script qui lui retourne l'inventaire en JSON. Donc tu peux utiliser tout ce que tu veux du moment que tu peux en faire un script. J'ai même eu fait une source d'inventaire pour de l'IoT découvert avec un broadcast UDP maison :)
http://docs.ansible.com/ansible/developing_inventory.html
Le 2015-08-26 15:26, Damien MICHAUDET a écrit :
Bonjour à tous,
Effectivement la discussion part dans toutes les directions qui devraient converger mais qui ne le font pas.
Reprenons dans l'ordre. Pour commencer à connaître l'état de machines il faut connaître les machines. Je n'ai pas encore trouvé d'outil simple d'inventaire dynamique qui me permette de connaître les machines et de pondre un inventory ansible en fonction de mes besoins. Collins semble faire le job mais c'est un outil Java qui consomme 800M de Ram à vide, ce qui est inacceptable pour un outil d'inventaire qui ne devrait pas, pour 1000 machines, gérer plus de 2 ou 3M de données texte.
As-tu essayé itop ? Tu peux sortir une liste dynamique assez facilement... https://github.com/jaimevalero78/itop-utilities
JYL
Je ne connaissais pas Itop, ça a l'air un peu comme TheForeman mais supporté par une boîte markéteuse. La solution a l'air un peu trop complète pour être pertinente mais mérite de s'y attarder un peu. Le lien que tu donnes me semble super intéressant et du coup pas franchement besoin que ce soit Itop qui alimente la cmdb ;)
2015-08-26 16:13 GMT+02:00 Jean-Yves LENHOF jean-yves@lenhof.eu.org:
Le 2015-08-26 15:26, Damien MICHAUDET a écrit :
Bonjour à tous,
Effectivement la discussion part dans toutes les directions qui devraient converger mais qui ne le font pas.
Reprenons dans l'ordre. Pour commencer à connaître l'état de machines il faut connaître les machines. Je n'ai pas encore trouvé d'outil simple d'inventaire dynamique qui me permette de connaître les machines et de pondre un inventory ansible en fonction de mes besoins. Collins semble faire le job mais c'est un outil Java qui consomme 800M de Ram à vide, ce qui est inacceptable pour un outil d'inventaire qui ne devrait pas, pour 1000 machines, gérer plus de 2 ou 3M de données texte.
As-tu essayé itop ? Tu peux sortir une liste dynamique assez facilement... https://github.com/jaimevalero78/itop-utilities
JYL
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
Le 26 août 2015 à 17:05, Damien MICHAUDET <d.michaudet@gmail.commailto:d.michaudet@gmail.com> a écrit :
Je ne connaissais pas Itop, ça a l'air un peu comme TheForeman mais supporté par une boîte markéteuse.
Ca n’a pas grand chose à voir, TheForeman va te permettre de deployer sur différentes infra (baremetal, vmware, aws, etc) et de gérer le cycle de vie de tes VMs en étant un ENC Puppet (classifieur de noeud).
iTop va être un réferentiel CMDB, (+ ticketing, etc, à la sauce ITIL) ou tu vas pouvoir documenter tes infra et solutions applicatives.
C’est plutôt pratique, ca permet d’auto documenter tes infras, d’y attacher des contacts, des contrats, du support, etc. Les modèles sont extensibles et tu peux tout modéliser. La partie IPAM est plutot bien fichue aussi.
Nous commençons l’écriture de custom facts que nous remonte l’agent Puppet, que l’on pourrait importer dans I-Top pour étoffer l’inventaire des CI.
Le côté sympa c’est aussi Rundeck couplé à TheForeman, qui te permet d’exécuter des tâches sur des groupes de machines qui répondent directement à un fact particulier (version de l’OS, version d’un paquet, maj en attente, etc). Comme mcollective mais avec la délégation et l’UI pour les non adminsys.
De notre côté, on commence vraiment à utiliser TheForeman+Puppet+Rundeck (+GitLab+Jenkins pour l’écriture de modules Puppet) pour l’opérationnel et I-Top pour l’organisationnel.
Ca demande quand même pas mal de temps pour mettre le tout en ordre de marche et convaincre ses collègues du bien fondé de la chose.
La solution a l'air un peu trop complète pour être pertinente mais mérite de s'y attarder un peu. Le lien que tu donnes me semble super intéressant et du coup pas franchement besoin que ce soit Itop qui alimente la cmdb ;)
2015-08-26 16:13 GMT+02:00 Jean-Yves LENHOF <jean-yves@lenhof.eu.orgmailto:jean-yves@lenhof.eu.org>: Le 2015-08-26 15:26, Damien MICHAUDET a écrit : Bonjour à tous,
Effectivement la discussion part dans toutes les directions qui devraient converger mais qui ne le font pas.
Reprenons dans l'ordre. Pour commencer à connaître l'état de machines il faut connaître les machines. Je n'ai pas encore trouvé d'outil simple d'inventaire dynamique qui me permette de connaître les machines et de pondre un inventory ansible en fonction de mes besoins. Collins semble faire le job mais c'est un outil Java qui consomme 800M de Ram à vide, ce qui est inacceptable pour un outil d'inventaire qui ne devrait pas, pour 1000 machines, gérer plus de 2 ou 3M de données texte.
As-tu essayé itop ? Tu peux sortir une liste dynamique assez facilement... https://github.com/jaimevalero78/itop-utilities
JYL
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- // Damien Michaudet # Libre systems engineer @ inovia.frhttp://inovia.fr/ | 42.mghttp://42.mg/ // +33 (0)6 76 74 46 50 _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
— Vincent Hurtevent Direction du Système d’Information Université Claude Bernard Lyon 1
-
Alexis Lameire -
Damien MICHAUDET -
Dominique Rousseau -
Gaëtan Allart -
HURTEVENT VINCENT -
Jean-Yves LENHOF -
Jonathan Leroy -
Nicolas Charles -
Nicolas Steinmetz -
Rémy Sanchez -
Simon Morvan -
Toni Verdasco -
Valentin FERON -
Wallace -
Xavier Beaudouin -
Youenn PIOLET