Ce matin en jetant par hasard un œil dans les logs de smtpd, j'ai vu que beaucoup de messages étaient adressés à un utilisateur dont je me sers uniquement pour les connexions SSH, il n'est pas censé recevoir du courrier. Au début je me suis dit que c'était peut-être le courrier de root, mais non il est déjà redirigé vers un autre.

J'ai donc configuré ce compte dans thunderbird pour pouvoir lire les mails. Et il y en avait 2177 : wtf ? Et finalement c'étaient des rapports d'exécution de tâches cron. Et il faut savoir que j'ai mis une tâche "@hourly" (toutes les heures) pour lancer fetchmail. Donc pour le moment j'ai ajouté un alias de messagerie, pour que cet utilisateur ne reçoive plus rien, et que ce soit un autre qui puisse avoir les rapports.

A terme je pense désactiver ces rapports car ils ne font que mentionner si fetchmail a trouvé du courrier ou non sur les comptes qu'il vérifie... ce n'est pas forcément utile.

Voici une petite présentation de mon serveur de téléchargement autonome accessible par interface web (uniquement depuis le réseau local) qui me sert à télécharger et partager des fichiers sur internet.

Matériel et Logiciel

Le serveur est virtualisé par VMware sur mon ordinateur de bureau, il accède au Core i7 860, et a droit à 256Mo de mémoire vive sur les 8GB disponibles. Le disque virtuel fait 10GB (tout est stocké sur un partage NFS ensuite).

• OS : Debian Squeeze 6.0 amd64
• Client bitorrent / magnet : transmission-daemon
• VPN : OpenVPN + Psilo.fr

Configuration

Stockage

Debian est installé sur le disque virtuel VMware de 10GB, en revanche sur /srv/Torrent j'ai monté un partage nfs, avec l'entrée /etc/fstab suivante :

192.168.10.50:/srv/Torrent/     /srv/Torrent/   nfs     defaults,user,auto,noatime,intr 0 0

Transmission

J'ai modifié les deux paramètres suivants dans /etc/transmission/settings.json :

"download-dir": "/srv/Torrent",
"rpc-whitelist": "127.0.0.1,192.168.10.*,192.168.1.*",

Ceci afin d'autoriser l'accès au WebUI depuis mes deux réseaux, et définir le bon répertoire de stockage des fichiers. Note : vous devez arrêter le daemon transmission avant de faire ces changements, sinon ils seront perdus.

OpenVPN

Il suffit de coller dans /etc/openvpn les fichiers fournis par le prestataire du vpn. Pour ma part j'ai renommé le fichier de configuration en "psilo.conf" pour être certain qu'il soit pris en compte.

Accès à l'interface

Dans un navigateur web, entrez l'IP du serveur suivi du port 9091. Un utilisateur et mot de passe seront demandés : transmission / transmission.

Cliquez sur "Open" pour pouvoir envoyer votre fichier .torrent ou directement coller l'URL. Même procédure avec les magnets. Après quelques secondes le téléchargement devrait débuter.

Astuces

Error: No data found! Au démarrage

Au démarrage du serveur, il se peut que tous les fichiers soient en gris avec l'indication "Error: No data found! Reconnect any disconnected drives, use "Set Location", or restart the torrent to re-download". Il faut aller faire un clic droit sur chaque fichier et sélectionner "Verify Local Data". Mais cela peut être pénible quand il y en a beaucoup, aussi on peut utiliser une commande :

# transmission-remote -n transmission:transmission --torrent all --verify

Cette erreur est probablement due au fait que transmission se lance avant le montage NFS. Il y a probablement des solutions plus propres, je suis preneur ! En attendant, la commande que je donne peut être mise dans un script.

Déconnexion du VPN

Un VPN est tout sauf fiable, il arrive très fréquemment que la connexion soit perdue, ce qui a pour conséquence de faire passer les téléchargements en clair sur internet... et sur transmission il semble impossible de forcer l'utilisation de l'interface tun0. Des manipulations sont sans doute possibles avec SELinux ou Apparmor, mais beaucoup trop complexes pour ce que l'on veut faire.

Alors, avec mon ami Etenil, nous avons concocté un petit bidouillage sous forme de script :

#!/bin/sh

if [ ! -e /sys/devices/virtual/net/tun0 ]
then
        transmission-remote -n transmission:transmission --torrent all --stop
        mail -s "VPN down" xavier@domaine.org
fi

Grossomodo, le script vérifie la présence du fichier tun0, qui est là si le VPN est connecté. Si ce n'est pas le cas, il arrête tous les téléchargements, et envoie une alerte par mail. Ce script est à placer en tâche cron afin qu'il s'exécute régulièrement. Personnellement je lui demande de se lancer toutes les minutes... mais attention, si votre VPN est déconnecté pendant 1 heure, toutes les minutes le script enverra un mail... vous vous retrouverez donc avec 60 mails !

La aussi une solution plus propre est sans doute possible.

Récupérer les fichiers téléchargés

Vous pouvez le faire en installant openssh-server, et en vous connectant en sftp via nautilus, dolphin, filezilla ou autre. Vous pouvez aussi vous amuser à configurer un partage samba ou un accès ftp. Les possibilités sont nombreuses.

Voici un petit schéma réalisé rapidement sur Visio, afin de présenter le réseau que j'ai mis en place chez moi. Alors oui, il manque des choses, notamment un DNS (qui s'avère pratique quand on commence à avoir beaucoup de serveurs) ou un vrai routeur. Mais par souci d'économie (matériel ou énergie) j'ai tout simplifié, et cela fonctionne plutôt bien actuellement.

Partie publique (en rouge)

C'est là où se situe mon serveur mail/jabber, il y a donc des redirections de port sur le routeur, et il doit fonctionner 24h/24.

• Geode : C'est un ordinateur Alix, en mini-ITX, qui consomme moins de 10 watts et fonctionne sur OpenBSD.

Partie privée isolée

Un autre sous réseau, derrière du NAT, avec aucune redirection de port. Il n'est donc pas ouvert sur internet. L'intégralité des serveurs est réservé à mon usage, et ne fonctionne d'ailleurs pas 24h/24, mais ponctuellement.

• SRVNAS : Il dispose d'un disque de 1TB et me sert à stocker toutes mes données. De plus, je fais mes sauvegardes dessus (boites mail, site Maniatux...). Plusieurs accès sont possibles : FTP, Samba (partages Windows), NFS, SFTP.
• Pegasus : C'est mon ordinateur de bureau, qui me sert pour les jeux vidéos. Équipé d'un Core i7 860 et de 8GB de ram, je lui ai installé VMware Workstation afin de pouvoir le transformer en serveur.
• SRVNAS-REP : Relié à un disque dur physique de 1TB dans l'hôte Pegasus, il me sert à répliquer le contenu de SRVNAS. Il n'y a pas d'automatisation, je lance des rsync régulièrement.
• SRVTORRENT : Mis en place récemment, il fait tourner un daemon transmission administrable depuis une interface web. Il fonctionne à travers un VPN afin de garantir la discrétion des données qui transitent. Un script vérifie régulièrement que le VPN n'est pas tombé, et peut stopper les torrent si c'est le cas (suivi de l'envoi d'un mail pour m'avertir). Les données sont enregistrées sur SRVNAS via un partage NFS.

Bien qu'OpenSMTPD soit développé pour OpenBSD, il existe une version portable qui peut être compilée sur d'autres systèmes tels que Linux. Voici un petit howto pour mettre en place OpenSMTPD sur Debian 6.0 Squeeze par compilation.

Dépendances

# apt-get install build-essential bison automake libtool libdb-dev libssl-dev libevent-dev

Récupération et compilation

# cd /root
# wget http://chl.be/opensmtpd/opensmtpd-latest.tar.gz
# tar -xvf opensmtpd-latest.tar.gz
# cd opensmtpd
# ./bootstrap
# ./configure
# make
# make install
# useradd -c "SMTP Daemon" -d /var/empty -s /sbin/nologin _smtpd
# mkdir /var/empty

OpenSMTPD a été installé dans /usr/local c'est là que vous y trouverez ses binaires. Cependant, les fichiers de configuration seront dans /etc/mail. Le répertoire /var/empty doit être créé car OpenSMTPD sera chrooté dedans. Tous ces chemins peuvent être modifiés en passant le bon paramètre à configure. Pour voir la liste, entrez ./configure --help.

Configuration

Il faut commencer par désactiver le MTA par défaut de Debian qui est exim4. On pourrait aussi simplement le désinstaller, mais comme OpenSMTPD ne fait pas partie "officiellement" du système (il n'est pas listé comme package), certaines applications réclamant un MTA risquent de le remettre.

# service exim4 stop
# update-rc.d exim4 disable

Créez ensuite le fichier de configuration pour opensmtpd, il doit se situer dans /etc/mail/smtpd.conf

# Interfaces
listen on lo
listen on eth0

# Generic Parameters
hostname "smtpd.my.domain"

# ACL
accept for local deliver to mbox
accept for all relay

Comme vous vous en doutez, nous venons de faire une configuration strictement minimale. Pas d'alias, pas de communication avec l'extérieur... pour le reste, à vous de vous débrouiller. Vous pouvez vous inspirer de cet article.

Pour lancer OpenSMTPD, utilisez la commande :

# smtpd

Pour avoir des logs, deux solutions : ajouter -v à la commande smtpd, ou alors consulter le fichier /var/log/mail.log.

Note : Si vous utilisez la commande mail depuis le serveur, c'est exim4 qui sera utilisé. Il est probablement possible de remédier à cela avec des alias.

Proxmox VE - Virtual Environment - est une solution de virtualisation bare metal orientée entreprise prête à l'emploi, basée sur l'hyperviseur Linux-KVM et les containers OpenVZ. Sa particularité est de proposer une console graphique en web pour administrer le tout. La version 2 est actuellement en beta, mais sa sortie finale est prévue d'ici le mois de Mars (2012 Q1 d'après la roadmap).

Caractéristiques

L'entreprise Proxmox qui développe Proxmox VE met son produit à disposition gratuitement sous licence libre. Parallèlement à cela ils proposent du support payant (forums, assistance, requêtes aux développeurs...) et une solution de sécurisation de messagerie (mail gateway) payante, même si il existe une version free avec moins de fonctionnalités.

Proxmox VE permet de faire simplement un cluster avec plusieurs serveurs physiques, et depuis la version 2.0 la HA, High Availability (haute disponibilité) est possible. Il est donc envisageable d'assurer la continuité de service même en cas de panne matérielle. L'entreprise Proxmox dispose de certifications avec plusieurs constructeurs (la liste est visible dans leurs brochures commerciales).

Proxmox VE se base sur Debian 6.0 Squeeze amd64, avec un kernel "based on RHEL6x" et lui ajoute un dépôt permettant d'avoir l'interface web de configuration mais aussi une version de qemu à jour. Le fonctionnement en cluster fait appel au système de fichiers pmxcfs (Proxmox Cluster file system).

Installation

Vous devez commencer par télécharger l'ISO d'installation à cette adresse. Le processus est simple et ne demande que d'entrer un mot de passe root et de spécifier une adresse IP fixe. Le disque dur entier est automatiquement utilisé et formaté pour recevoir Proxmox. Après avoir démarré le système, vous pouvez lancer une mise à jour pour être certain d'avoir les dernières versions des composants. Vous pouvez le faire sur la machine même, ou par accès SSH de la manière suivante :

# apt-get update
# apt-get dist-upgrade

Découverte de l'interface

L'adresse IP de votre serveur Proxmox s'affiche lorsque celui-ci a fini de booter. Il y a également l'adresse de l'interface d'administration, elle est de la forme https et contient le FQDN ou l'adresse IP suivie du port 8006. Par exemple : https://10.40.1.17:8006

Cette vue affiche les principales informations de votre infrastructure : serveurs, authentification, configuration. Tout comme sur vSphere, le cadre du bas affiche les logs à la volée ce qui vous permet de connaître précisément les résultats de vos opérations sur l'hyperviseur. Dans le menu "storage" (stockage) vous pouvez voir vos différents périphériques : disque local, partage NFS, iSCSI. Stocker ses VM sur un support réseau permet de mettre en place la High Availability. La liste des serveurs à gauche permet d'accéder à une configuration individuelle : paramètres IP, nom d'hôte, etc.

Pour découvrir l'interface plus en détail et apprendre à mettre en place une machine virtuelle, Proxmox a créé une chaîne Youtube avec des tutoriels video. Voir les vidéos.

Virtualisation KVM vs container OpenVZ

Pour connaître le fonctionnement théorique de la virtualisation et des containers, je vous renvoie à cet ancien article dans lequel j'explique les différences entre les deux à l'aide de schémas.

OpenVZ est la solution la plus performante, puisqu'il n'y a aucune couche d'émulation et un seul kernel pour tous les systèmes invités. Il n'y a en pratique aucune perte de performance ou elle s'élève à seulement 2 ou 3%. Il faut cependant que le système invité soit de type Linux, puisqu'il sera dépourvu de kernel et utilisera celui de l'hôte. Pour cela, Proxmox VE utilise des templates (modèles). Il y a par exemple un template pour Debian Squeeze, qui va juste demander à l'utilisateur d'entrer un mot de passe root, les paramètres IP et l'installation se fera ensuite automatiquement. Le boot est presque instantané.

KVM va au contraire émuler un ordinateur complet afin de rendre le système indépendant de l'hôte. Cette virtualisation est assurée par le processeur de l'hôte (grâce aux instructions Intel VT-x ou AMD-V) et par Qemu pour la création des périphériques complémentaires. Il est ainsi possible d'installer des systèmes non modifiés tels que Windows, et d'utiliser des périphériques VirtIO (qui ne sont pas réellement émulés mais partagés avec l'hôte). Par contre SPICE, solution de virtualisation desktop développée par RedHat, ne semble pas encore disponible mais prévu.

Installation d'un Windows Server 2008 virtualisé

Je dispose d'un exemplaire de Windows Server 2008 en image iso (msdnaa). La première chose à faire est de l'envoyer sur le serveur. Pour cela, cliquez sur l'espace de stockage de votre choix dans la colonne de gauche. Dans l'onglet "content" vous verrez un bouton upload vous permettant d'envoyer votre iso. Il est aussi possible de le faire par SSH. Voir le tutoriel vidéo.

L'étape suivante consiste à créer une nouvelle machine virtuelle et à entrer les paramètres adéquats. Il est judicieux de sélectionner VirtIO pour le stockage et la carte réseau. Vous aurez cependant besoin de récupérer le CDROM de pilotes pour Windows. Vous pouvez suivre le tutoriel vidéo à cette adresse.

Attention, pour que la console fonctionne, vous devez avoir le plugin Java installé dans votre navigateur.

Une fois Windows 2008 installé, vous devrez aller dans le gestionnaire de périphérique pour installer les pilotes de la carte réseau (ils sont sur le CDROM VirtIO). Votre serveur virtualisé est maintenant prêt à l'emploi !

Conclusion

KVM, Linux, OpenVZ, sont des produits libres très puissants que l'on apprécie de voir fonctionner ensemble une fois leur configuration réalisée. Proxmox VE fournit un système où tout est déjà intégré, prêt à l'emploi. L'interface de configuration rend accessible à tous les administrateurs la mise en place de cluster de virtualisation, et rend ainsi cette solution compétitive avec celles du monde propriétaire.

Alors que Virt-Manager, développé par RedHat, est limité à Linux et tend à crasher très souvent, l'interface Web de Proxmox est universelle, stable, et bien plus complète.

Proxmox VE 2.0 est très bon !