71 lines
5.1 KiB
Markdown
Executable file
71 lines
5.1 KiB
Markdown
Executable file
<!-- 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.
|