La semaine dernière, j’ai publié un script de configuration automatique pour les postes de travail OpenSUSE que j’installe dans mon quotidien professionnel. Je me suis dit que je pourrais peut-être faire la même chose pour mes installations de serveurs tournant sous CentOS, qu’il s’agisse d’une machine locale ou d’un serveur dédié avec une ouverture frontale sur Internet. Là aussi, la configuration post-installation d’une machine comporte toute une série d’opérations potentiellement chronophages.
- Peaufiner le shell Bash et l’éditeur Vim
- Rendre la console plus lisible
- Configurer les dépôts de paquets officiels et tiers
- Installer un jeu complet d’outils en ligne de commande
- Supprimer une poignée de paquets inutiles
- Rendre les logs système accessibles à l’utilisateur initial
- Désactiver l’IPv6 si l’on ne l’utilise pas
- Rendre le mot de passe persistant pour
sudo
- Etc.
Pour les impatients
Voici ce qu’il faut faire pour disposer d’un serveur CentOS 7 « aux petits oignons ».
- Installer un système minimal CentOS 7.
- Créer un utilisateur initial avec les privilèges d’administrateur.
- Installer Git :
sudo yum install git
- Récupérer le script :
git clone https://gitlab.com/kikinovak/centos.git
- Changer dans le répertoire nouvellement créé :
cd centos
- Exécuter le script :
sudo ./centos-7.x-setup.sh --setup
- Boire un café en attendant que le script gère à peu près tout.
- Redémarrer.
Détails techniques
Le script centos-7.x-setup.sh
fournit une série d’options dont voici les détails.
Configurer Bash et Vim et rendre la console plus lisible :
# ./centos-7.x-setup.sh --shell
Configurer les dépôts de paquets officiels et tiers :
# ./centos-7.x-setup.sh --repos
Activer DeltaRPM et mettre à jour le système :
# ./centos-7.x-setup.sh --fresh
Installer les groupes de paquets Core
et Base
et quelques outils supplémentaires :
# ./centos-7.x-setup.sh --extra
Supprimer une poignée de paquets inutiles :
# ./centos-7.x-setup.sh --strip
Rendre les logs système accessibles à l’utilisateur initial :
# ./centos-7.x-setup.sh --logs
Désactiver l’IPv6 et reconfigurer les services de base ;
# ./centos-7.x-setup.sh --ipv4
Rendre le mot de passe persistant pour sudo
:
# ./centos-7.x-setup.sh --sudo
Exécuter toutes ces opérations de A à Z :
# ./centos-7.x-setup.sh --setup
Élaguer le système pour ne garder que le système de base amélioré :
# ./centos-7.x-setup.sh --reset
Afficher l’aide sur les options :
# ./centos-7.x-setup.sh --help
Si vous êtes curieux de savoir ce qui se passe exactement sous le capot, vous pouvez très bien ouvrir un deuxième terminal et afficher les logs à chaud.
$ tail -f /tmp/centos-7.x-setup.log
La procédure a été dûment testée sur une série de machines. Si vous l’utilisez sur vos serveurs et que vous rencontrez des problèmes, n’hésitez pas à m’en faire part dans les commentaires à cet article.
Le script centos-7.x-setup.sh
est prévu pour une installation minimale de CentOS 7. Il ne vous servira pas à grand-chose sur un poste de travail. Et il ne fonctionnera pas sous CentOS 8.
La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.
8 commentaires
Nico · 9 mars 2020 à 14 h 56 min
Vous devriez vraiment regarder du coté de Ansible pour voir comment on configure un serveur en 2020 🙂
kikinovak · 9 mars 2020 à 16 h 46 min
C’est vrai que c’est très à la mode d’enfoncer les clous avec un marteau-piqueur.
Nico · 10 mars 2020 à 9 h 26 min
Pourtant, quand je regarde comment on configure un repo yum sur ansible (https://docs.ansible.com/ansible/latest/modules/yum_repository_module.html), et ce qui se passe dans votre script, j’ai plutôt l’impression que c’est le script le marteau-piqueur.
+ encore, votre script lui ne peut configurer que une target à la fois. Enfin bon si ça marche pour vous. Tant mieux !
kikinovak · 10 mars 2020 à 9 h 39 min
La question Ansible vs. scripts Bash est abordée dans l’excellent Unix & Linux System Administration Handbook. Pour les parcs importants, Ansible est certainement la solution. Mais pour les configurations modestes, c’est un peu du overkill. Quoi qu’il en soit, merci pour la remarque et la suggestion.
TED · 10 mars 2020 à 18 h 54 min
Je rejoins l’avis de Nico, ansible local est niquel y compris pour ce cas de figure. Plus facile à maintenir, à déployer (ansible galaxy n’a besoin que de dépôts git), plus sécurisé (vu que c’est des arguments qu’on passe et pas du shell, la base du code, le moteur, étant communautaire). Il sera plus facile d’y ajouter de nouveau cas d’usage (la liste des modules est gigantesque), et si un jour la machine se retrouve être un serveur distant, ou comme tu dis un parc, il le gérera aussi bien. Bref c’est très souple.
kikinovak · 10 mars 2020 à 19 h 05 min
OK. Je note tout ça dans un coin de ma tête, et je regarderai ça de plus près dès que j’ai un moment. Merci pour le tuyau, et un gentil bonjour de la garrigue.
Madko · 11 mars 2020 à 10 h 18 min
Tiens d’ailleurs pour ex j’avais commencer un squelette pour ça justement. J’ai repris quelques ex de ton script pour que tu vois comment ça marche. C’est assez simple, et quand on le lance on a une sortie déjà très propre. Tu verras que le nombre de ligne tapées par rapport à ton script est assez faible.
C’est ici https://github.com/Madko/perso
Ildrit · 2 juin 2020 à 16 h 00 min
Bonjour,
J’ai beaucoup aimé vos deux livres et ce script est assez utile ! Merci de la mise à disposition ! 🙂
Les commentaires sont fermés.