Vérification des données avec la somme MD5

Une solution simple pour vérifier l’intégrité de fichiers est l’utilisation d’une somme de contrôle. Plusieurs algorithme existe, le plus connu reste la somme MD5. La somme MD5 est une « signature » unique (quoique des collisions existent, c’est pour cela qu’il ne faut plus l’utiliser pour de la cryptographie) d’un fichier. La commande md5sum de linux permet de calculer la somme d’un fichier mais aussi (et c’est un peu moins connu) de vérifier des fichiers en utilisant leurs sommes de contrôle.

Création des sommes de contrôle

Les sommes de contrôle sont calculées avec un groupement d’instructions assez simple :

• un find permet de retrouver tous les fichiers
• un xargs permet d’utiliser les noms de fichiers (en spécifiant \n comme caractère de séparation pour que les noms de fichiers comportant des espaces soient bien pris en compte).
• le calcul de la somme MD5 est réalisé par md5sum.

Le résultat des somme est placé dans un fichier stocké dans le répertoire temporaire (/tmp), il sera automatiquement supprimé par le système. En une ligne (exécutée dans le répertoire source) ça donne :

find . -type f | xargs -d'\n' md5sum > /tmp/chksum.md5

Vérification des fichiers

La commande md5sum permet aussi de vérifier des fichiers à partir d’une liste de sommes de contrôle avec l’option -c. Dans le répertoire des copies, la commande fait tout le travail de vérification :

md5sum -c /tmp/chksum.md5  1>/dev/null

La redirection de la sortie standard vers /dev/null permet de ne garder l’affichage que des erreurs et donc des fichiers non/mal copiés.

Références

• L’idée générale vient de Michael Simons.
• La différence entre l’option exec et xargs est donnée sur : http://www.tuteurs.ens.fr/unix/exercices/solutions/find-sol.html
• Changer le caractère de fin de bloc pour xargs est détaillé sur Stackoverflow

Enregistrer

La grande majorité des opérations se fait en super-utilisateur ; deux conséquences : il est facile de faire des erreurs et si on ne comprend pas ce que l’on fait, on ne le fait pas ! Ceci était dit, passons au travail…

Fichiers de configuration

Avant de faire une bêtise, le fichier /etc/hosts est sauvegardé avec la commande cp /etc/hosts /etc/hosts.backup. En cas de problème, on pourra revenir à la version initiale du fichier avec mv /etc/hosts.backup /etc/hosts

Configuration par défaut du réseau

Le fichier par défaut sera celui utilisé lorsque la machine n’est pas sur le réseau de la maison. Une copie du fichier hosts initial est faite pour cela cp /etc/hosts /etc.hosts.default

Configuration du réseau pour la maison

Le fichier de configuration pour la maison est construit à partir du fichier par défaut, on fait donc une copie avec cp /etc/hosts /etc/hosts.home. Il est ensuite édité (par exemple avec vim /etc/hosts.home) pour ajouter les résolutions locales :

127.0.0.1	localhost
127.0.1.1	linux

192.168.5.3	serveur1.chezmoi.local
192.168.5.3	serveur2.chezmoi.local
192.168.5.3	serveur3.chezmoi.local

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Les trois sites webs pointent vers le même serveur, c’est Nginx qui gère la résolution des différents sites.

Gestion des événements de NetworkManager

La gestion des cartes réseaux est assurée par NetworkManager sous la très grande majorité des systèmes Linux (en tout cas ça marche sur mon Linux Mint !). Une des qualités de NetworkManager est de proposer de gérer les événements associés aux changements d’états des cartes réseaux de manière très simple.

Les scripts traitant les événements doivent être placés dans le répertoire /etc/NetworkManager/dispatcher.d. Le script peut être sauvegardé avec n’importe quel nom (pour respecter la notation générale, je l’ai sauvegardé sous le nom 02home) mais il doit avoir les droits d’exécution pour tous les utilisateurs et doit être la propriété de root (mais comme il faut être super utilisateur pour pouvoir écrire dans ce répertoire ça se fait tout seul…).

Les scripts de changement d’états de NetworkManager doivent traiter deux paramètres lors de l’appel qui sont le nom de la carte réseau concernée et le statut (arrêt, démarrage,…). La carte wifi de mon ordinateur est repérée par wlp1s0 et l’événement qui nous intéresse est la mise en marche de la carte (événement up).

Le script est ensuite assez simple à écrire :

#!/bin/bash -e
IF=$1
STATUS=$2

if [[ $IF = "wlp1s0" ]] && [[ $STATUS = "up" ]]
then
	wifi=`iwlist wlp1s0 scan | grep SSID`
	if [[ $wifi == *"MonWifi"* ]]
	then

	cp /etc/hosts.home /etc/hosts
	fi
else
	#Use the normal host file
	cp /etc/hosts.default /etc/hosts
fi

Le nom du réseau WiFi est obtenu avec la commande iwlist et un grep. On vérifie ensuite que le nom du réseau local (MonWifi) est présent dans la chaîne. Dans ce cas, on copie le fichier de configuration pour la maison dans le fichier /etc/hosts.

Si un autre événement (arrêt, …) se produit sur la carte, le fichier de configuration par défaut est recopié sur /etc/hosts pour tout remettre à la configuration par défaut.

Bilan

Pour l’instant aucun problème ! Je suis toujours surpris par le côté « bien pensé » de Linux et la puissance de petits scripts tout simples…

Bibliographie

• La différence entre les opérateurs [ ] et [[ ]] en bash
• Un exemple de script
• L’idée générale

• Dans le /etc/apache2/mods-available/userdir.conf on commente la ligne AllowOverride FileInfo AuthConfig Limit Indexes et on la remplace par AllowOverride All.
• Ensuite dans /etc/apache2/mods-available/php5.conf on commente toute la fin :

#
# 
# php_admin_flag engine Off
# 
#

• Et on redémarre Apache sudo service apache2 restart

Pour vérifier on créée un fichier index.php dans ~/public_html :

 <?php phpinfo(); ?>

Ce petit script permet de vérifier la version de PHP installée ainsi que les modules installés (ici PHP Version 5.5.9-1ubuntu4.7).

Et voilà !

1. Décharger le module usbhid
2. Attendre 5 secondes pour que tout se stabilise
3. Recharger le module

sudo modprobe -r usbhid && sleep 5 && sudo modprobe usbhid

Installation et configuration de cntlm

Informations nécessaires

Avant de commencer, il faut connaitre son nom d’utilisateur, son mot de passe et le domaine dans lequel on travail. Dans la suite de cette explication ils seront remplacés par name, password et domain.

Évidement il faudra aussi connaitre l’adresse IP de la passerelle utilisée par le système, sous Windows on l’obtient avec la commande ipconfig.

Installation de cntlm

Sous Ubuntu (et les descendants comme Mint,…) cntlm est dans les dépôts :

sudo apt-get install cntlm

Dès l’installation le service cntlm est lancé, la configuration n’étant pas faite, il faut commencer par arrêter le service (sudo service cntlm stop). Il reste à configurer les principaux éléments en éditant le fichier /etc/cntlm.conf en superutilisateur  (par exemple sudo gedit /etc/cntlm.conf &). Les éléments importants du fichier sont les suivants :

#
# Cntlm Authentication Proxy Configuration
#
# NOTE: all values are parsed literally, do NOT escape spaces,
# do not quote. Use 0600 perms if you use plaintext password.
#

Username    name
Domain      domain
Auth       
PassNT     

Proxy       192.168.1.5:8080
NoProxy     localhost, 127.0.0.*, 10.*, 192.168.*

Listen      3128

Les différents champs sont assez explicites. Pour l’instant les champs Auth et PassNT sont laissés vierges.

Le champ Listen correspond au port qui sera utilisé par cntml, sauf si vous utilisez déjà ce port, ne le changez pas.

Il reste à remplir le mot de passe avec son condensé (hash). La solution la plus simple (qui permet en même temps de tester le reste de la configuration) et d’utiliser cntlm en ligne de commande :

sudo cntlm -v -I -M http://www.google.fr

Le mot de passe doit être saisit ensuite et le résultat doit contenir les lignes suivantes (bien entendu les valeurs de condensés (hash) ne seront pas les mêmes) :

Config profile  1/4... Connection closed
Config profile  2/4... OK (HTTP code: 200)
----------------------------[ Profile  1 ]------
Auth            NTLM
PassNT          FF72C0DFC1C0D237CCEA5F7D53A17557
PassLM          48AC20D4C99F6423D42DDF2A2C6D325A
------------------------------------------------

On ferme tous les terminaux et on relance dans un nouveau terminal (sudo cntlm -v pour voir ce qui passe par le proxy).Sous Mint (sous les autres interfaces on retrouvera les mêmes principes) on utilise l’applet réseaux pour configurer un serveur mandataire pour tout le système en http://127.0.0.1:3128.

Il est aussi possible de relancer le service mais dans ce cas, rien ne sera visible en cas de problème (sudo service cntlm start).

Utilisation

Si le service est lancé au démarrage, rien à faire. Sinon le lancer dans un terminal qui restera ouvert comme ci-dessous.

Références

• http://www.howtoforge.com/linux-ntlm-authentication-proxy-isa-server-with-cntlm
• http://www.leslamas.net/index.php?post/2012/08/20/Cntlm-Authentication-Proxy

VBoxManage clonevdi src.vdi dest.vdi

permet de copier le disque src.vdi vers le disque dest.vdi en lui associant un nouveau numéro.

J’ai trouvé la copie plus longue qu’avec un simple cp. De toutes façons, la commande :

VBoxManage internalcommands sethduuid dest.vdi

peut être utilisée pour changer le numéro d’une copie déjà faite.

GAFFitter

Une version gratuite du logiciel est disponible pour Linux. Elle est limitée à des circuits double couches de 100*150 mm maxi. L’installation a failli se dérouler sans problème mais j’ai eu le message d’erreur suivant :

/tmp/eagle-setup.24273/eagle-6.3.0/bin/eagle: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

Après quelques minutes de recherches, j’ai trouvé la cause de mon problème. Mon système est un 64 bits et EAGLE à besoin de la version 32 bits de la librairie. J’ai simplement dû installer la version 32 bits de la librairie avec la commande :

sudo apt-get install libssl1.0.0:i386

Ensuite, l’installation se déroule sans problème.