Utilisation de df

df est un utilitaire permettant de connaître l’organisation du système de fichier ainsi que l’espace disponible sur les disques et différents points de montage :

# df
Sys. de fichiers      1K-blocs   Utilisé    Dispo. Uti% Monté sur
/dev/sda2            959661608   7537172 903376400   1% /
tmpfs                  4093604         0   4093604   0% /lib/init/rw
udev                   4088520        92   4088428   1% /dev
tmpfs                  4093604         4   4093600   1% /dev/shm
/dev/sda1               194442     23491    160912  13% /boot

Ce résultat est un peu difficile à lire.
On peut utiliser l’option -h (human readable sizes) pour avoir un affichage lisible des tailles :

# df -h
Sys. de fichiers    Taille  Uti. Disp. Uti% Monté sur
/dev/sda2             916G  7,2G  862G   1% /
tmpfs                 4,0G     0  4,0G   0% /lib/init/rw
udev                  3,9G   92K  3,9G   1% /dev
tmpfs                 4,0G  4,0K  4,0G   1% /dev/shm
/dev/sda1             190M   23M  158M  13% /boot

C’est déjà mieux. Ensuite en fonction de vos goûts il est possible de connaître le système de fichier utilisé avec l’option -T :

# df -hT
Sys. fich.    Type  Taille  Uti. Disp. Uti% Monté sur
/dev/sda2     ext4    916G  7,2G  862G   1% /
tmpfs        tmpfs    4,0G     0  4,0G   0% /lib/init/rw
udev         tmpfs    3,9G   92K  3,9G   1% /dev
tmpfs        tmpfs    4,0G  4,0K  4,0G   1% /dev/shm
/dev/sda1     ext4    190M   23M  158M  13% /boot

Enfin, pour n’avoir que les partitions concernant les disques, on peut ne pas afficher certains types de fichiers avec l’option -x :

# df -hT -x tmpfs -x devtmpfs -x rootfs
Sys. fich.    Type  Taille  Uti. Disp. Uti% Monté sur
/dev/sda2     ext4    916G  7,2G  862G   1% /
/dev/sda1     ext4    190M   23M  158M  13% /boot

Cela permet de gagner en lisibilité !

Bien sur, pour faciliter les choses il est conseillé de créer des alias en ajoutant ces lignes dans votre .baschrc :

alias df='df -hT'
alias dh='df -hT -x tmpfs -x devtmpfs -x rootfs'

Ainsi la commande df est étendue et affiche toutes les partitions alors que la nouvelle commande dh n’affiche que les partitions des disques.

Se connecter en ssh avec une clé publique

L’utilisation d’une clé publique permet d’éviter de devoir saisir son mot de passe à chaque connexion.
Cet article détaille l’utilisation d’une clé publique pour se connecter à un serveur à partir d’un ordinateur utilisant linux (Ubuntu pour être précis). Si vous utilisez Windows, il est donc possible que ce tutoriel ne fonctionne pas (en particulier la dernière partie avec l’agent ssh).

Le principe

On génère en local une clé publique et une clé privée. En suite, on envoie la clé publique sur le serveur qui pourra alors nous reconnaître grâce à notre clé privée.

Générer les clés

Sur votre ordinateur local, saisir la commande :

$ ssh-keygen -t rsa -b 4096

-t rsa permet de choisir la méthode de chiffrement RSA (la plus utilisée actuellement). -b 4096 spécifie la taille de la clé (4096 est un minimum actuellement, vous pouvez aller jusqu’à 8192).

Generating public/private rsa key pair.
Enter file in which to save the key (/home/login/.ssh/id_rsa):

Appuyez sur entrée afin de garder l’emplacement par défaut.

Enter passphrase (empty for no passphrase):

Entrez ici une passphrase de façon à consolider votre clé. Ainsi même une personne en possession de votre clé privée ne pourra pas se connecter au serveur.

Enter same passphrase again:

Entrez à nouveau votre passphrase.
Il s’affiche alors la confirmation de la création de vos clés :

Your identification has been saved in /home/login/.ssh/id_rsa.
Your public key has been saved in /home/login/.ssh/id_rsa.pub.
The key fingerprint is:
9f:d5:6f:2b:d7:5b:f8:ce:83:c5:31:4c:97:1a:2a:57 login@monordi
The key's randomart image is:
+--[ RSA 4096]----+
|                .|
|             E o.|
|            o = .|
|         . o o + |
|        S o . o o|
|         . o   = |
|          o   + =|
|             o *+|
|              o+*|
+-----------------+

Vous avez bien généré vos clés. Il faut maintenant envoyer la clé publique sur le serveur.

Envoyer la clé sur le serveur

Toujours en local, on envoie la clé publique sur le serveur :

$ ssh-copy-id -i ~/.ssh/id_rsa.pub toto@monserveur.fr

(attention à éventuellement rajouter le port pour ssh si vous l’avez changé)

Rentrez votre mot de passe pour la dernière fois.

Maintenant on vous demandera votre passphrase pour vous connecter à votre serveur. Pour éviter de la saisir à chaque connexion il faut l’ajouter à l’agent ssh.

Ajouter la passphrase à l’agent ssh

Pour ajouter la passphrase à l’agent ssh sous ubuntu, il suffit de lancer la commande :

$ ssh-add

et de saisir la passphrase.

Voilà, maintenant vous pouvez vous connecter à votre serveur sans saisir de mot de passe.

Si vous voulez ni saisir votre passphrase à chaque connexion ni utiliser l’agent ssh, ne donnez pas de passphrase lors de la création des clés. La connexion sera alors moins sécurisée mais elle sera immédiatement automatique.

Sources

tuteurs.ens.fr – ssh
prendreuncafe.com – Installer sa clé SSH sur un serveur distant

.htaccess : comment ne plus l’utiliser sur son serveur dédié

On prend souvent l’habitude d’utiliser les fichiers .htaccess sur les serveurs mutualisés. Or il n’y a plus aucune raison de les utiliser sur un dédié. En effet, les fichiers .htaccess n’existent que pour permettre aux utilisateurs qui ne sont pas administrateur du serveur de faire des changements de configuration. Donc lorsqu’on a son dédié, plus besoin de .htaccess ! Il faut remplacer tous les .htaccess par des directives dans les fichiers de configuration d’Apache.

Pourquoi ?

Quel est l’intérêt de s’en passer puisque ça marche très bien avec ? Il y a trois raisons :

La rapidité. Pour prendre en compte les fichiers .htaccess, le serveur doit avoir l’option AllowOverride d’activée. Il va donc chercher à chaque chargement de fichier les fichiers .htaccess dans toute l’arborescence. Cela prend du temps. De plus le fichier .htaccess est chargé à chaque fois ce qui fait également perdre du temps.

La sécurité. La directive AllowOverride All permet à l’aide d’un fichier .htaccess de modifier localement la configuration du serveur. Si on peut éviter cette souplesse de configuration la sécurité n’en sera que meilleure.

La maintenance. En supprimant tous les fichiers .htaccess, on peut regrouper toutes les directives dans un même fichier de conf. Cela simplifie grandement la maintenance des règles de ré-écriture par exemple.

Comment ?

Il faut remplacer un à un les fichiers .htaccess par une section Directory dans un fichier de conf de apache (/etc/apache2/apache2.conf par exemple, ou le fichier de conf du virtualHost).
Si par exemple on a un fichier .htaccess dans le répertoire /var/www/monsite.fr qui contient les directives suivantes :

RewriteCond %{HTTP_HOST} ^monsite\.fr [NC]
RewriteRule (.*) http://www.monsite.fr/$1 [QSA,R=301,L]

Il suffit de supprimer ce fichier .htaccess et de rajouter ce bloc dans un fichier de conf d’Apache :

‹Directory /var/www/monsite.fr›
   RewriteCond %{HTTP_HOST} ^monsite\.fr [NC]
   RewriteRule (.*) http://www.monsite.fr/$1 [QSA,R=301,L]
‹/Directory›

Lorsqu’on a remplacé tous les fichiers .htaccess, on peut ajouter la directive :

AllowOverride None

dans une section Directory. Cette directive est par défaut à All. Par exemple, si j’ai remplacé tous les fichiers .htaccess de monsite.fr, je rajoute la directive comme ceci :

‹Directory /var/www/monsite.fr›
   AllowOverride None
   ...
‹/Directory›

Comme ça, Apache ne perdra plus de temps à aller chercher les fichiers .htaccess. De plus la configuration est chargée une seule fois au démarrage d’Apache et plus à chaque requête sur un fichier.

Sources

Apache.org – Utilisation du .htaccess

Installer curl pour php

curl (abréviation de Client URL Request Library) est un programme et une bibliothèque pour php qui permet d’utiliser simplement des protocoles réseaux (http, ftp…). Elle n’est pas installée par défaut, on a besoin de deux paquets supplémentaires :

# apt-get install curl php5-curl

Avec ceci, curl devrait fonctionner sans problème.

À la réception du serveur

Réception du serveur

Quand on reçoit son serveur, tout ce qu’on peut faire c’est de se connecter en ssh avec le nom d’utilisateur fourni à l’hébergeur et avec un mot de passe temporaire (si vous vous connectez directement en root, passez directement au changement du mot de passe root). La première chose à faire est donc de changer son mot de passe :

$ passwd

On vous demande de re-saisir l’ancien et de taper deux fois le nouveau. Choisissez un mot de passe solide (lettres majuscule et minuscule, symboles et chiffres, au moins 10 caractères) car ssh est la principale porte d’accès à votre serveur.

Ensuite, on se connecte en root pour pouvoir agir sur la machine :

$ su

Il faut maintenant saisir le mot de passe root temporaire que vous avez fourni à l’hébergeur.

Ensuite, on change le mot de passe root :

# passwd

Encore une fois, il faut re-saisir l’ancien et de taper deux fois le nouveau. Il faut trouver un nouveau mot de passe différent de celui de l’utilisateur et tout aussi solide.

Il est possible que vous n’ayez pas d’utilisateur autre que root sur votre machine. Dans ce cas, changez le mot de passe root et créez un autre utilisateur toto :

# adduser toto

Puis on donne comme répertoire à l’utilisateur toto, celui où on mettra les sites (/var/www):

# usermod -d /var/www toto -m

Enfin, on installe vim pour pouvoir éditer plus facilement les fichiers :

# apt-get install vim

Je n’arrivais pas à utiliser correctement vi, sans doute à cause de l’encodage des caractères. Avec vim tout marche pour le mieux.