You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
blog/posts/2013/2013-06-28-sysadmin-1.md

72 lines
5.1 KiB
Markdown

<!-- title: Ma vie de sysadmin en semi-pro (1) -->
<!-- category: GNU/Linux -->
<!-- tag: planet -->
Par goût personnel et par nécessité professionnelle, je rajoute progressivement le rôle
d'administrateur système à mon métier de base qui est le développement de logiciels.<!-- more --> Doté de
bonnes bases UNIX et réseau, je découvre petit à petit les bon outils et les bonnes pratiques
pour faire le job, le simplifier voire l'automatiser. Et parfois j'enverrais volontiers une
caisse de bières à l'auteur d'un outil qui m'a sauvé plusieurs heures fastidieuses :-)
Dans cette série d'articles *ma vie de sysadmin en semi-pro* je parlerais épisodiquement de mes
avancées et de mes découvertes dans le domaine de l'administration système.
Tout d'abord la console est ta seule amie. Sur ton PC de bureau, la console est un choix. Dans
le monde des serveurs c'est un passage obligé car ils sont rarement installés avec une interface
graphique et on les accède généralement par SSH. Les outils de base sont connus mais il faut
apprendre à les maîtriser.
Ce qui propulse la console c'est un shell UNIX compatible Bourne Shell. Il y a plusieurs variantes :
le Bourne Shell d'origine (sh), le Bourne Again Shell (bash), Korn Shell (ksh), Z Shell (zsh). Des
experts sont capables de discuter de tel avantage de zsh par rapport à ksh. A mon niveau, maîtriser
**sh** et **Bash** qui est le choix par défaut d'un grand nombre de systèmes GNU/Linux est le choix
de la raison. On trouve beaucoup de littérature sur le sujet (le Bourne Shell existe depuis 1978 et
le Bourne Again Shell depuis 1989 ), ma référence est le guide **Advanced Bash-Scripting Guide** sur
[le site du Linux Document Project](http://www.tldp.org/guides.html). Ensuite il est bien sûr
important de connaître les programmes en ligne de commande nécessaires pour les tâches de tous les
jours : grep, find, locate, chmod, chown, cp, mv, mkdir, rm, rmdir, touch, top, kill, ps ... la
liste est loin d'être exhaustive.
Un autre élément important est éditeur de texte en mode console. Il doit être polyvalent, léger,
capable de traiter des fichiers de centaines de milliers de lignes. Deux candidats se détachent du
peloton : **Vim** et **Emacs**. Les deux sont beaucoup plus que de simples éditeurs de texte. Ayant
des rudiments de **Vi** depuis 20 ans, je me suis lancé à corps perdu dans l'apprentissage des
fonctions avancées de **Vim** Que du bonheur ! Voici quelques liens :
* [Vim FAQ](https://github.com/chrisbra/vim_faq)
* [Vimcasts - Vim podcasts](http://vimcasts.org)
* [Vundle - Vim Plugin manager](https://github.com/gmarik/vundle)
Quand on passe beaucoup de temps sur la console, on est à l'affut des manières de la rendre plus
attractive et plus puissante
* Le prompt du shell par défaut est minimaliste. Pourquoi ne pas l'enrichir avec des informations
utiles comme la charge processeur ou les infos de gestion de version (SVN, GIT) du répertoire
courant ? C'est ce que propose [le projet
LiquidPrompt](https://github.com/nojhan/liquidprompt).
* Le choix des couleurs est important quand on passe beaucoup d'heures devant une console. Je ne
parle pas de choisir une palette *cool* mais bien de préserver sa vue. J'ai fait le choix [du
schéma de couleur Solarized](https://github.com/altercation/solarized). Ca peut sembler un peu
pâlot au début mais je me suis vité habitué et je l'utilise dans chaque programme où c'est
possible. Dans le même registre, j'utilise [le projet RedShift](https://launchpad.net/redshift)
pour gérer la température des couleurs en fonction de l'heure de la journée et de votre
emplacement géographique. Les deux premiers jours, on a l'impression que la luminosité est trop
basse, ensuite on trouve cela normal. Et on se sent agressé quand on utilise une autre machine
que la sienne.
* On se retrouve vite à ouvrir quantité de terminaux et à jongler entre eux. J'ai utilisé
[Terminator](https://terminator-gtk3.readthedocs.io) un temps puis j'ai pris confiance et j'ai
eu besoin de multiplier les terminaux depuis une même session SSH et de lancer des traitements
qui tournent en tâche de fond. Du coup, j'ai pris le temps d'apprendre
[Tmux](http://tmux.sourceforge.net) et c'est un très bon investissement ! Un bon article pour
démarrer est [accessible
ici](http://blog.hawkhost.com/2010/06/28/tmux-the-terminal-multiplexer).
* Quand on *provisionne* des serveurs régulièrement, il est intéressant de déployer sa
configuration du shell, de l'éditeur de texte, ses outils afin de retrouver son environnement et
ses habitudes. On peut installer ses fichiers manuellement depuis un point central [comme son
GitHub](https://github.com/kianby/dotfiles), ou mieux on peut carrément automatiser cette partie
en utilisant un outil comme [Fabric](https://github.com/fabric/fabric).
Le choix des outils présentés dans cet articles est personnel. Ce qui est intéressant, c'est la
puissance de la console dans une utilisation quotidienne, la pléthore d'outils et le sentiment de
maîtrise de ce qu'on fait.