====== Sysadmin, ou comment les geeks s'occupent de faire fonctionner internet... ======
===== Quelques règles de base =====
==== Documenter ====
Documenter ce que l'on s'apprête à faire, ce que l'on fait réellement et ce qui se passe est le meilleur moyen pour que les choses se passent bien. Ainsi, la chose est déjà préparée, on aura eu plus tendance à penser à des détails auxquels on n'aurait pas nécessairement pensé de prime abord, et en cas de souci on peut se faire aider plus facilement, quelqu'un d'autre peut même reprendre le souci si on n'arrive pas soi-même à le résoudre, etc.


==== Communiquer ! ====
Si on n'est pas la seule à travailler sur un système, que ce soit de manière générale ou à un instant T, il est vital de communiquer afin de savoir qui fait quoi, où, comment, et a priori pour combien de temps.
Imaginez le nombre de choses qui peuvent mal tourner quand plusieurs personnes administrent une même machine... 

Par exemple, on est en-train d'éditer un fichier de configuration d'un vhost de nginx. On vérifie la syntaxe avex ''nginx -t'', et il y a une erreur. On cherche, parfois avec acharnement, où peut bien se situer l'erreur dans notre modification. Le souci réel c'est qu'en fait un autre administrateur a édité un autre fichier de configuration de nginx en y introduisant au moins une erreur. Premier souci potentiel.
Ensuite, il se peut que l'autre administrateur ne soit pas aussi consciencieux que nous et veuille relancer nginx sans vérifier la syntaxe de sa configuration : *boum* le serveur ne se relance plus !
Maintenant imaginez la même chose avec ''sshd''...

<WRAP center round info 60%>
Sur Khaganat, les sysadmin ont une section dédiée sur le forum, justement destinée à votre "log" des actions du moment. N'y laissez pas traîner les mots de passe, bien sûr...
</WRAP>

==== Vérifier la syntaxe ====
Lors d'une modification, toujours faire un maximum de vérifications avant de valider. Par exemple, procéder systématiquement à une vérification de la syntaxe quand c'est possible, avant de relancer / recharger la configuration d'un démon :

  nginx -t
  sshd -t
  php-fpm -t

Dans le même esprit, toujours utiliser un éditeur de texte qui procède automatiquement à cette vérification syntaxique. Cela est valable au moins pour les fichiers/commandes suivantes :
  crontab -e
  vipw
  vipw -s
  vigr
  vigr -s
  visudo

==== Plan B ====
Quelle que soit la modification que l'on apporte à un système, penser à un plan B (voire un plan C, D, etc.) bref un plan de secours au cas où les choses ne se passeraient pas comme on l'aurait espéré.
Cela commence par le fait de faire une copie du fichier que l'on s'apprête à modifier (fichiers de configuration notamment).
Cela peut aussi prendre la forme d'un snapshot/freeze du système de fichier sur lequel on veut travailler, voire de la machine virtuelle complète si c'en est une.

Bref, vous avez compris l'idée.


===== Reboot =====
Quoi que l'on fasse comme modification sur un système, il faut toujours veiller à ce qu'après un redémarrage la machine se retrouve dans un état identique à celui dans lequel elle était avant ce redémarrage.

Par exemple, quand on ajoute une route sur la CLI, bien veiller à ce que la route soit aussi configurée "en dur". Dans le cas de Debian, on peut mettre la commande dans par exemple ''/etc/network/interfaces'' en ajoutant ''up ''  devant la commande qu'on a exécuté.

  CLI :
  route add -host ftp.fr.debian.org gw 192.168.100.253

  /etc/network/interfaces :
  iface eth0 inet static
      address [...]
  up route add -host ftp.fr.debian.org gw 192.168.100.253
  down route del -host ftp.fr.debian.org gw 192.168.100.253

Attention à la seconde ligne avec ''down'', ce n'est pas ''route add'' mais ''route del'', pour supprimer la route lors de l'extinction ou du redémarrage.

Cela n'est qu'un exemple. À chaque modification il faut se poser la question : "Est-ce que ma modification est «reboot-proof» ?"


===== sudo =====
:!: Soyez très prudents avec ''sudo'', si on ne sait pas exactement ce que l'on fait cela peut avoir des répercussions graves sur la sécurité du système.

Généralement on considère que ''sudo'' permet de donner les pleins droits à un utilisateur. Certes, mais ''sudo'' est bien plus que cela : il permet une gestion assez fine des droits à octroyer à un utilisateur ou à un groupe. Par exemple, on peut limiter les droits root à une seule commande (dans l'exemple l'utilisateur s'appelle "bofh") :

  /etc/sudoers (à éditer avec la commande "visudo", pour éviter les erreurs de syntaxe !)
  bofh ALL=NOPASSWD:/bin/ls

Ici, ''bofh'' aura le droit d'exécuter la commande ''/bin/ls'' avec les droits root, mais c'est tout.


On peut aussi limiter à un sous-ensemble de quelques commandes seulement (et pas uniquement une seule), à l'aide de la directive ''Cmnd_Alias'' :

  /etc/sudoers
  Cmnd_Alias MESCOMMANDES = /bin/ls, \
                            /usr/bin/id, \
                            /bin/pwd
  
  bofh ALL=NOPASSWD:MESCOMMANDES

Lorsque l'on définit les commandes autorisées, il faut faire attention à bien définir le périmètre dans lequel la commande peut agir. Par exemple, on ne mettra jamais de chemin contenant un "wildcard" comme ''*'', ou alors avec un complément :

  Cmnd_Alias MESCOMMANDES = /bin/more /var/log/*.log, \
                            !/bin/more /var/log/*../*

Parfois on essaye de lancer une de ces commandes via ''sudo'', mais ça ne fonctionne pas. Il est possible que l'on tente d'exécuter la mauvaise commande, ou du moins de la mauvaise manière. En effet -- et c'est une bonne pratique -- les commandes sont spécifiées avec leur chemin absolu dans ''/etc/sudoers'', et il faut les lancer avec leur chemin absolu. Le plus simple moyen de savoir quelles commandes on a le droit d'exécuter via sudo est de lancer la commande suivante, sachant que cela montrera les commandes ''sudo'' que l'utilisateur **actuel** a le droit d'exécuter :

  sudo -l

Si les commandes ne sont pas spécifiées avec leur chemin absolu, c'est une faille potentielle de sécurité. En effet si au lieu de ''/bin/ls'' on n'a que ''ls'', il suffit à l'utilisateur de placer un exécutable malicieux (disons, un shell) nommé ''ls'' dans son dossier personnel (dans son ''$PATH'' en fait) pour qu'il s'exécute en priorité sur ''/bin/ls''.

Il y a aussi quelques commandes avec lesquelles il faut être prudent, avec ''sudo'', quand bien même on interdit explicitement ''*../*'' dans le chemin. Quelques exemples :

  vi (ou tout autre éditeur, en fait)
  less

En effet, ces commandes permettent d'écrire n'importe où dans l'arborescence, ou d'ouvrir n'importe quel fichier (pensez par exemple à ''/etc/shadow'' ou ''/root/.my.cnf'').

Une règle générale à ce propos pourrait être de n'avoir dans ''/etc/sudoers'' que des commandes qui ne peuvent rien écrire sur le disque (oui, ''less'' peut écrire dans un fichier, se référer à la documentation pour les détails).

Il existe souvent des moyens de contourner ces risques, mais pas toujours.


===== find =====
Pour supprimer des fichiers de manière automatisée on pourrait être tenté d'exécuter ce genre de commande :

  rm -rf `find /var/tmp/ -type d -name .svn`

Cette commande cherche tous les dossiers nommés ''.svn'' dans /var/tmp/ de manière récursive, puis passe le résultat à la commande ''rm -rf''. Le problème qui peut se poser est si dans cette liste de dossiers, l'un d'eux contient une espace dans son chemin, la commande va échouer et donc ce dossier ne sera pas supprimé.

Pour bien faire les choses, autant dire directement à la commande ''find'' de supprimer les dossiers trouvés, via l'option ''-exec'' :

  find /var/tmp/ -type d -name .svn -exec rm -rf {} \;

L'exemple ci-dessus est donné à titre de comparaison avec la première commande ''rm -rf'' qui prend le résultat de ''find'' en paramètre. Une version encore plus propre serait :

  find /var/tmp/ -type d -name .svn -delete

L'option ''-delete'' active automatiquement l'option ''-depth'', qui traite d'abord les sous-répertoires avant le répertoire lui-même.


À noter que l'on peut aussi afficher les fichiers supprimés en ajoutant l'option ''-print''.


===== Problèmes bizarres et solution =====
==== Espace insécable ====
Il ne vous est jamais arrivé d'avoir l'erreur étrange suivante ?

  $ echo 123 | grep 2
  bash:  grep : commande introuvable

Moi si, régulièrement. Et j'ai cherché à comprendre ce qui n'allait pas et ai finalement trouvé, après pas mal de recherche. Et l'explication est des plus simples (encore une victime du rasoir d'Occam...) ; lorsqu'on tape (trop) vite au clavier il arrive qu'en voulant taper une espace, notamment après avoir fait une pipe ''|'', on a encore le doigt sur la touche ''AltGr''. ''AltGr + [espace]'', cela donne une espace insécable, indiscernable à l'œil nu d'une espace "classique". Le shell en revanche, lui, fait la différence et considère que '' grep'' ("[espace insécable]grep") est la commande à exécuter. À moins d'avoir une commande de ce nom dans son chemin (''$PATH''), le shell vous retournera une erreur. Certains shells sont plus explicites quant à l'erreur affichée :

  bash: $'\302\240grep': commande introuvable

Je dis "indiscernable à l'œil nu", ce n'est pas tout à fait vrai : en faisant attention on voit bien qu'il y a deux espaces après ''bash:''. Cela dit, ça ne saute pas forcément aux yeux.

{{tag>sysadmin serveur}}