SysAdmin Tips

Si votre serveur possède plusieurs adresses IP et que vous souhaitez utiliser l’une d’elles pour contacter un autre serveur à partir d’un script (lancé depuis le système ou apache), il faut intervenir dans la table de routage afin de créer une route spécifique pour l’adresse IP de destination. La commande est la suivante:

route add -host IPdistante dev eth0:X

où eth0:x représente le numéro d’alias de l’IP, tel que défini dans le fichier /etc/network/interfaces.

Cette astuce vaut pour les software qui ne sont pas bindés sur une IP précise. Bind, Postfix et d’autres ont un paramètre permettant de ne les faire travailler que sur une IP précise.

Système failover, ip, route

Si votre hébergeur vous permet d’avoir plusieurs adresses IP sur la même interface réseau, voici comment les faire reconnaître par votre système. Editez le fichier /etc/networking/interfaces. Ajoutez-y les lignes suivantes:

auto eth0:0
iface eth0:0 inet static
address xxx.xxx.xxx.xxx
netmask 255.255.255.255

Si vous avez plusieurs IP alias, il faut incrémenter le chiffre après les deux points sur les deux premières lignes. Notez que le netmask possède tous ses bits à 1.

Vous pouvez ensuite faire prendre ces changements en compte via la commande /etc/init.d/networking restart

Système alias, failover, ip

Dans les tâches d’administration courantes, certaines tâches peuvent être facilités simplement. Voici une liste de paquets qui sont utiles sur un serveur:

Système paquets

Le logiciel en PHP Gallery permettant de gérer des albums photos est un excellent produit. Cependant, si vous changez la langue d’utilisation dans le menu déroulant approprié et que ce n’est suivi d’aucun effet, voici la marche à suivre pour corriger cela:

apt-get install gettext php-gettext

Vérifie que gettext et son support PHP est installé; l’installe si ce n’est pas le cas.

En tapant locale -a, vous verrez la liste des locales installées sur votre serveur. Vous constaterez qu’il manque le français. Pour l’ajouter, tapez

cat /usr/share/i18n/SUPPORTED  |grep fr_FR>>/var/lib/locales/supported.d/local

Ensuite, regénerez les locales avec la commande locale-gen. Vous pouvez finalement redémarrer apache et constater que ça fonctionne maintenant !

Système gallery, locale, php

Pour faire suite à l’article sur le backup des bases MySQL, voici comment automatiser le transfert des fichiers créés via un script bash mis dans le crontab. Nous utilisons la commande ftp, qui permet, comme vous l’aurez deviné, de se connecter via le protocole FTP au serveur hébergeant les backups.

#!/bin/sh
backup=/home/backup
host=ftp.serveur.com
login=loginftp
mdp=motdepasseftp

cd $backup && /usr/bin/ftp -i -n $host << EOF
quote USER $login
quote PASS $mdp
mput *
bye
EOF

Ici, tous les fichiers présents dans le répertoire désigné par la variable backup seront transférés. Il est tout à fait possible de restreindre à un pattern spécifique en modifiant la ligne « mput ».

Système backup, ftp

Pour faire suite à l’article où je vous expliquais comment transférer des données entre deux serveurs avec scp, voici un autre utilitaire du même genre qui permet de faire un transfert incrémental, ce qui signifie que seul ce qui a été modifié est transféré.

Je vous recommande également pour cette commande de mettre en place une authentification par clé entre les deux serveurs afin d’éviter d’avoir à retaper le mot de passe à chaque transfert.

La syntaxe de la commande est semblable à scp:

rsync -avz -e ssh remoteuser@remoteserveur:/repertoire/distant .

Quelques mots sur les options utilisées:

• -a: mode archive; copie récursive, conserve les liens symbloliques, les permissions, les timestamps des fichiers, les uid et gid originaux
• -v: mode verbeux; les actions réalisées sont envoyées sur stdout
• -z: compresse les données durant le transfert
• -e ssh: force le transfert en utilisant ssh

La commande réalise ici une copie récursive du répertoire /repertoire/distant situé sur remoteserveur vers le répertoire courant.

Système backup, rsync

Aujourd’hui je vais vous exliquer comment transférer des répertoires de manière récursive, en conservant les permissions et les dates des fichiers, et le tout de manière cryptée.  De manière récursive, cela signifie que l’on prend tous les sous répertoires d’un répertoire donné, ainsi que leurs sous répertoires à eux et ainsi de suite.

Une commande sous linux permet de faire cela facilement : scp. Si vous réalisez régulièrement des transferts entre deux serveurs précis, je vous recommande de mettre en place une authentification par clé, afin de ne pas toujours devoir donner les mots de passes, en suivant la procédure expliquée ici.

La syntaxe de base est la suivante:

scp -rp user@serveurdistant.com:/home/user/repertoire .

Les switchs rp permettent respectivement de travailler de manière récursive et de conserver les temps d’accès, de modification ainsi que la valeur du chmod original. Ensuite, nous spécifions l’utilisateur distant utilisé (avant l’@), le nom ou l’ip de la machine distante. Après les deux points, c’est le répertoire de base sur la machine distante. Suit enfin, le répertoire de destination sur la machine locale. Le point indique « ici », mais vous pouvez bien entendu spécifier le répertoire de votre choix.

Comme précisé au début de l’article, le transfert est crypté, réalisé sur base du protocole SSH, à contrario de FTP où toutes les informations (données et mots de passe) circulent en clair sur le réseau, permettant à chacun de se servir allégrement.

Je vous invite à consulter la page de manuel de scp si vous désirez obtenir plus d’informations sur cet utilitaire très utile.

Dans un prochain article, nous verrons comment réaliser des sauvegarders incrémentales.

Système scp, ssh

Le but de cet article est d’arriver à établir une liaison SSH entre deux serveurs sans devoir entrer manuellement de mot de passe à la connexion. L’intérêt est double :

• lors de la réalisation d’un backup lancé en crontab, ou même de simple transfert de fichiers lancés par vous en console;
• lorsque vous passez d’une machine à l’autre régulièrement.

Dans le premier cas cité, il est impossible de rentrer manuellement le mot de passe, l’intérêt du crontab étant précisément de ne pas intervenir. Dans les deux autres, c’est simplement par pur confort.

Se connecter sans mot de passe, c’est bien, mais c’est la porte ouverte à des dérives. Il faut donc un autre moyen de s’identifier pour autoriser l’accès à des données parfois confidentielles. La réponse à se problème est l’utilisation d’un couple de clés, l’une privée et l’autre publique. Le but de l’article n’est pas de faire un cours sur le fonctionnement de la paire de clé, mais pour donner le background nécessaire, je dirai simplement que la clé publique est stockée sur le serveur distant et que vous utilisez la clé privée pour vous y connecter. Un contrôle supplémentaire sur l’adresse IP utilisée peut également facilement être mis en place pour éviter tout problème en cas de vol de votre clé privée.

Pour la suite de l’article, le scénario est le suivant : le serveur A se connecte au serveur B.

Sur le serveur A, connectez-vous au nom de l’utilisateur qui sera utilisé pour se connecter au serveur B. Tapez les commandes qui suivent sur l’invite de commande. Vous devrez répondre à quelques questions. Nous laissons le fichier par défaut pour le fichier dans lequel sauver la clé; nous ne mettons pas de passphrase.

ssh-keygen -t rsa -b 4096
cd ~/.ssh
cat idrsa.pub

S’affichera alors votre clé publique, que vous copiez dans votre presse-papier pour utilisation future.

Sur le serveur B, connectez-vous au nom d’utilisateur qui recevra la connexion du serveur A et tapez-y les commandes suivantes:

mkdir -p ~/.ssh
cd ~/.ssh

Editez ensuite le fichier authorized_keys2 (qui n’existe peut-être pas), et ajoutez-y la ligne suivante, où X représente la clé publique du serveur A se trouvant dans votre presse-papiers.

from="ip du serveur A" X

Vérifiez que la clé publique du serveur A ne contient pas de retours à la ligne. Ensuite, faites en console

chmod -R 600 ~./ssh

afin de donner les bonnes permissions au fichier créé ainsi qu’au répertoire le contenant.

Le serveur A peut maintenant se connecter au serveur B sans devoir entrer de mot de passe. Si vous devez également réaliser une connexion du serveur B vers le serveur A, il est nécessaire de reprendre cette procédure dès le début, en inversant A et B.

Système ssh

Dans un contexte de serveur d’hébergement offert à plusieurs utilisateurs, il est de coutume de leur donner un accès via FTP pour qu’ils puissent mettre en ligne leur site et de limiter leur accès à leur /home (via un chroot).

Si vous utilisez la liste des utilisateurs système pour le FTP, ces utilisateurs ont également par défaut un accès SSH et donc des droits en lecture sur pas mal de fichiers, ce qui est légitime de vouloir restreindre aux utilisateurs de confiance.

La solution est de créer un groupe d’utilisateurs, que nous nommerons par exemple sshallow dans le quel il suffit de placer les utilisateurs qui disposeront d’un droit d’accès à SSH. La création d’un groupe se fait via la commande addgroup sshallow.

Nous ajoutons alors les utilisateurs désirés dans le groupe adduser nom sshallow. N’oubliez pas d’y ajouter l’utilisateur avec lequel vous administrez la machine!!!

Ensuite, nous informons le serveur SSH de l’existence du groupe en éditant le fichier /etc/ssh/sshd_config et en y rajoutant la directive AllowGroups sshallow.

Il ne reste plus qu’à redémarrer le serveur ssh. Avant de fermer la fenêtre, je vous recommande de tester une nouvelle connexion avec l’utilisateur que vous utilisez habituellement pour administrer la machine afin de s’assurer qu’il n’y a aucun blocage.

Système ftp, ssh

Vous avez sûrement déjà constaté qu’une connexion SSH laissée ouverte trop longtemps sans activité fini par se couper au bout d’un certain temps. La raison vient du fait que votre FAI coupe les connexions inactives au bout d’un certain temps.

Pour éviter celà et ne pas devoir vous reconnecter intempestivement, il suffit d’éditer le fichier /etc/ssh/sshd_config, et d’y rajouter la directive ClientAliveInterval 60, sans oublier de redémarrer le serveur SSH.

Avec cette directive, le serveur SSH enverra à votre client un paquet « keep-alive » toutes les 60 secondes pour éviter que la connexion soit déclarée inactive et donc coupée

Système ssh