Admin sys et bonne pratiques

De l'art d'administrer un systême

a marqué ce sujet comme résolu.
Auteur du sujet

Bonjour à tous,

cela fait quelques temps que je déploie des services, les miens ou ceux des autres sur des serveurs Linux.

Je me pose beaucoup de questions vis à vis des bonne pratiques, en voici quelques unes:

  • à chaque nouveau service de production que je crée sur mon serveur, je crée un nouvel utilisateur avec un /home et les permissions qui vont bien, du coup difficile de différencier les utilisateurs "humains" et ceux "services". Comment gérez vous la multiplicité des services ? vous collez tout dans /var/www avec différents dossier ? vous faites comme moi ? cela m’intéresse…
  • toute les configurations sont placés dans /root, ainsi un ls /root/conf permet de lister toutes les confs d’usage courant (iptables, supervisor ect…) je documente les besoins de chaque service "metier" dans un fichier de doc afin qu’un nouveau dev puisse à tout moment revoir la conf sans avoir galérer pendant des heures.
  • quel outil utilisez vous pour gérer vos logs ? je suis lassé de configurer mail et sendmail qui selon les distibs sont long à configurer (cela fait plusieurs fois que j’y parviens mais je ne m’y fait pas, je prend toujours un temps fou…) J’aimerais trouver un outil simple à configurer pour un service minimum…

Je pense passer à Ansible pour que tout cela se fasse naturellement, mais en attendant que pensez vous de ces pratiques ? en avez vous à me suggérer pour que tout soit le plus naturel possible et que n’importe qui puisse reprendre le serveur ?

Voila, j’ai conscience que ces interrogations peuvent paraître vagues mais je n’ai jamais appris l’admin sys et j’aimerais m’améliorer. Vos conseils et commentaire sont les bienvenus.

Édité par Nogs

+0 -0

Hello,

  • Si tu rajoutes/enlèves souvent des services, passer sur des conteneurs (lxc, docker) sera bien plus pratique pour toi, même si ça amène d’autres problèmes. Tu peux aussi faire du conteneur contrôlé par du ansible si tu veux facilement pouvoir redéployer. Si tes services sont plus ou moins fixes, ta méthode marche relativement bien, mais tu peux mettre les homes dans /home/services/{stuff} plutôt que /home/{stuff}.

  • Le problème en AdminSys c’est que souvent les installations ne sont pas vraiment trop documenté ou tenu à jour. Si tu l’as fait c’est parfait. Forcer le passage à Ansible permet justement d’être certain d’avoir un minimum de documentation correspondant à l’état du serveur.

  • Pour les logs, tu peux utiliser des outils comme une pile ELK, du graylog, etc. Pour mail et sendmail il faut voir comment installer un serveur postfix pour ça, ou désigner le serveur postfix à utiliser. C’est douloureux mais assez compréhensible après la première fois.

Je suis dans une association de réseau étudiant et globalement on améliore beaucoup la qualité des services/déploiement en automatisant avec des scripts documentés et utilisés en CI. Si tu as la possibilité de faire ça c’est toujours un plus, mais ça dépend de tes besoins.

On a aussi eu tendance à faire des trucs stupides comme formatter le serial de bien en AAAAMMJJII, parrce que les tutoriels sur internet disent de faire ça, prendre un regard critique sur chaque «technique» comme ça te permettra de t’améliorer.

Édité par unidan

+1 -0

Salut,

  • à chaque nouveau service de production que je crée sur mon serveur, je crée un nouvel utilisateur avec un /homme et les permissions qui vont bien, du coup difficile de différencier les utilisateurs "humains" et ceux "services". Comment gérez vous la multiplicité des services ? vous collez tout dans /var/www avec différents dossier ? vous faites comme moi ? cela m’intéresse…
Nogs

Côté OpenBSD, les noms de service sont préfixés par un underscore, ce qui permet de savoir directement (à quelques exceptions près, genre « nobody » ou « www-data ») si l’utilisateur est un « vrai » utilisateur ou non.

  • toute les configurations sont placés dans /root, ainsi un ls /root/conf permet de lister toutes les confs d’usage courant (iptables, supervisor ect…) je documente les besoins de chaque service "metier" dans un fichier de doc afin qu’un nouveau dev puisse à tout moment revoir la conf sans avoir galérer pendant des heures.
Nogs

Du moment qu’une personne qui doit te remplacer s’y retrouve, c’est l’essentiel. En général, un admin regardera d’abord dans /etc après des fichiers de configs, mais du moment qu’il sait où chercher c’est bon.

  • quel outil utilisez vous pour gérer vos logs ? je suis lassé de configurer mail et sendmail qui selon les distibs sont long à configurer (cela fait plusieurs fois que j’y parviens mais je ne m’y fait pas, je prend toujours un temps fou…) J’aimerais trouver un outil simple à configurer pour un service minimum…
Nogs

Qu’entends-tu exactement par « gérer vos logs » : traitement, stockage, délai de rétention,… ? Par ailleurs, quand tu parles de mail et sendmail, tu veux dire que tu configures le serveur pour qu’il t’envoie des courriels en cas de problèmes ?

+0 -0
Auteur du sujet

Merci pour vos réponses, c’est instructif. Effectivement, pour les logs je suis à la recherche d’outils tels que unidan les as décrits (j’utilisais Monit auparavant), ceux que tu présentent semblent bien plus ergonomiques. L’idée du préfixe par un underscore pour les utilisateurs liés à un service n’est pas mal non plus, bref, je vous remmercie de vos réponses. Je crois que j’ai déjà matière à optimiser mes pratiques.

+0 -0

Pour les services, je passe systématiquement par le gestionnaire de paquets, quitte à créer le paquet. Le répertoire utilisateur est donc /var/lib/service/, ce qui est généralement le cas des services dans les dépôts officiels.

La conf va systématiquement dans /etc/, de préférence dans /etc/service/.

J’ai l’habitude de commenter mes confs, et de maintenir un wiki avec la documentation.

Pour les logs, rsyslog ou journald font le taf. Pour les alertes, scripts customs ou monit.

Breizh eo ma bro, hag ihuel eo ma c’halon geti. Da viken. — L’oiseau imaginaire : ZzxŷxzZ

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte