Ça fait plusieurs fois que je vois des infos sur cet outil surtout chez LinuxFr.org, il s'agit d'une solution française.
Je comprends l'intérêt mais je pense qu'on peut s'en passer. Ça fait partie de ces outils mal positionnés, Ansible et Puppet vont assurer un suivi de la config même si effectivement ce n'est pas exactement de la conformité comme décrit dans l'article.
Quand je lis : “Le server va compiler un nombre d'informations assez importantes, et notamment les différentes règles et techniques pour définir les ordres à envoyer aux agents. Mieux vaut donc prévoir un serveur relativement costaud. 4Go de RAM me parait un minimum si vous compter gérer plus d'une 20aine de serveur”, je me dis que c'est une blague par rapport à Ansible qui fait 90% de ce qu'on a besoin avec quelques fichiers (playbooks) et sans client (avec SSH). Même les quelques captures d'écran me font penser à une usine à gaz, la conformité des serveurs est assurée mais le sysadmin doit avoir en tête toutes les règles, les définir, les modifier.
Souvent en entreprise les fichiers de config (et autres) sont versionnés avec git et séparés en rôle (FTP, HTTP, IMAP…) puis poussés avec Ansible/Puppet/Salt/Others. Ça reste simple, largement suffisant pour la plupart des entreprises et évite de rajouter une couche supplémentaire notamment via cet outil qui donne plus envie de s'en passer que de s'y mettre.
Tant mieux pour toi si les fichiers de conf sont gérés dans des git… chez nous, hélas, c'est pas le cas malgré que j'ai tenté y quelques temps la mise en place de Rudder et avec ma bande de bidouillers en herbe … impossible, je me suis fait jeter par tout les autres sysadmin….
Il faut aussi des équipes bien matures sur l'IAC et pas des bidouilleurs de fichiers à coup de console interactive…
Avant j'étais (seul) sysadmin dans une PME, j'ai toujours eu la flemme de gérer les fichiers de conf avec git. Il y avait toujours plus urgent/important à faire mais au final c'était un peu hypocrite car clairement c'est ce qu'il y a de mieux pour celui qui reprend le poste derrière.
Dans ton cas un manager ne fait pas correctement son job, il devrait imposer une manière de procéder/travailler.
Je travaille chez un hébergeur web, on est payé pour que les serveurs et leur config soient carrés, normal que ça soit géré correctement.
Pour illustrer notre fonctionnement :
- Une faille assez importante est découverte sur proftpd (https://security-tracker.debian.org/tracker/CVE-2019-12815), on décide de mettre à jour qd le correctif est dispo
- On installe sur qq serveurs (avec le rôle FTP) et en général on attend une journée pour voir si tout se passe bien
- On remarque que les logs “FTP session opened” ne remontent plus, on trouve : “Question: Why are successful logins no longer being logged, after upgrading to ProFTPD 1.3.6, even though I am using the SystemLog directive?
Answer: The default log level was changed from DEBUG to NOTICE in ProFTPD 1.3.6; see Bug#3983. And the "Login successful” log message is logged at the INFO level, which means that it will not be logged by default"
- On ajoute dans le fichier de config “SyslogLevel INFO”
- Le lendemain on installe sur le reste des serveurs
- Dans quelques semaines on fera un git push (sur le dossier/rôle FTP) avec le petit commentaire qui va bien concernant “SyslogLevel INFO”
Ça fait plusieurs fois que je vois des infos sur cet outil surtout chez LinuxFr.org, il s'agit d'une solution française.
Je comprends l'intérêt mais je pense qu'on peut s'en passer. Ça fait partie de ces outils mal positionnés, Ansible et Puppet vont assurer un suivi de la config même si effectivement ce n'est pas exactement de la conformité comme décrit dans l'article.
Quand je lis : “Le server va compiler un nombre d'informations assez importantes, et notamment les différentes règles et techniques pour définir les ordres à envoyer aux agents. Mieux vaut donc prévoir un serveur relativement costaud. 4Go de RAM me parait un minimum si vous compter gérer plus d'une 20aine de serveur”, je me dis que c'est une blague par rapport à Ansible qui fait 90% de ce qu'on a besoin avec quelques fichiers (playbooks) et sans client (avec SSH). Même les quelques captures d'écran me font penser à une usine à gaz, la conformité des serveurs est assurée mais le sysadmin doit avoir en tête toutes les règles, les définir, les modifier.
Souvent en entreprise les fichiers de config (et autres) sont versionnés avec git et séparés en rôle (FTP, HTTP, IMAP…) puis poussés avec Ansible/Puppet/Salt/Others. Ça reste simple, largement suffisant pour la plupart des entreprises et évite de rajouter une couche supplémentaire notamment via cet outil qui donne plus envie de s'en passer que de s'y mettre.
Tcho !
Tant mieux pour toi si les fichiers de conf sont gérés dans des git… chez nous, hélas, c'est pas le cas malgré que j'ai tenté y quelques temps la mise en place de Rudder et avec ma bande de bidouillers en herbe … impossible, je me suis fait jeter par tout les autres sysadmin….
Il faut aussi des équipes bien matures sur l'IAC et pas des bidouilleurs de fichiers à coup de console interactive…
Salute,
Avant j'étais (seul) sysadmin dans une PME, j'ai toujours eu la flemme de gérer les fichiers de conf avec git. Il y avait toujours plus urgent/important à faire mais au final c'était un peu hypocrite car clairement c'est ce qu'il y a de mieux pour celui qui reprend le poste derrière.
Dans ton cas un manager ne fait pas correctement son job, il devrait imposer une manière de procéder/travailler.
Je travaille chez un hébergeur web, on est payé pour que les serveurs et leur config soient carrés, normal que ça soit géré correctement.
Pour illustrer notre fonctionnement :
- Une faille assez importante est découverte sur proftpd (https://security-tracker.debian.org/tracker/CVE-2019-12815), on décide de mettre à jour qd le correctif est dispo
- On installe sur qq serveurs (avec le rôle FTP) et en général on attend une journée pour voir si tout se passe bien
- On remarque que les logs “FTP session opened” ne remontent plus, on trouve : “Question: Why are successful logins no longer being logged, after upgrading to ProFTPD 1.3.6, even though I am using the SystemLog directive? Answer: The default log level was changed from DEBUG to NOTICE in ProFTPD 1.3.6; see Bug#3983. And the "Login successful” log message is logged at the INFO level, which means that it will not be logged by default"
- On ajoute dans le fichier de config “SyslogLevel INFO”
- Le lendemain on installe sur le reste des serveurs
- Dans quelques semaines on fera un git push (sur le dossier/rôle FTP) avec le petit commentaire qui va bien concernant “SyslogLevel INFO”
Tcho !