CentOSLa 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 ».

  1. Installer un système minimal CentOS 7.
  2. Créer un utilisateur initial avec les privilèges d’administrateur.
  3. Installer Git : sudo yum install git
  4. Récupérer le script : git clone https://gitlab.com/kikinovak/centos.git
  5. Changer dans le répertoire nouvellement créé : cd centos
  6. Exécuter le script : sudo ./centos-7.x-setup.sh --setup
  7. Boire un café en attendant que le script gère à peu près tout.
  8. 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.

ImportantLe 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.

 

Catégories : Serveur

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.