Archives par mot-clé : installation

Créer des serveurs virtuels Debian 7 Wheezy avec LXC sur un dédié OVH Kimsufi

(Dernière mise à jour : 19 février 2015)

Présentation de LXC

Tout comme Linux-VServer et OpenVZ, LXC est une solution de virtualisation de type isolateur. Cette solution permet la virtualisation par container au niveau du noyau. LXC est très récent et remplace Linux-VServer et OpenVZ. Aussi, LXC est dès à présent intégré au noyau, ce qui n’a jamais été le cas des deux solutions citées précédemment.

L’isolateur tire avantage de la possibilité, unique sous UNIX et Linux, de partager le noyau avec d’autres processus du système. Cette virtualisation à noyau partagé utilise une fonctionnalité nommée chroot. Cette fonctionnalité modifie le système de fichiers racine d’un processus pour l’isoler de manière à fournir une certaine sécurité. On parle alors de « prison » chroot.

Un programme, ensemble de programmes ou système dans le cas de virtualisation à noyau partagé fonctionnant dans un environnement chroot est protégé en faisant croire au système emprisonné qu’il fonctionne sur une machine réelle avec son propre système de fichiers.
Le mécanisme de chroot a été amélioré pour mimer un système de fichiers entier, de sorte qu’un système entier peut fonctionner dans un chroot, ce qui constitue une machine virtuelle.

Cette solution est très performante du fait du peu d’overhead puisque les environnements virtualisés se partagent le code du noyau.

Le schéma ci-dessous représente la technologie de virtualisation par isolation :
Linux Containers

Notes

  • La totalité des opérations décrites ne devrait pas vous prendre plus de 30 minutes (en dehors des temps nécessaires aux compilations qui peut avoisiner 45 minutes en fonction des performances de votre machine)
  • Si une partie d’une ligne de commande est surlignée comme ceci, cela signifie qu’elle peut ou doit être adaptée avec vos paramètres ou préférences
  • Je pars du principe que vous avez déjà installé une distribution sur votre serveur
  • Ce guide a été écrit et testé pour une Debian Wheezy 64 bits, il devrait cependant fonctionner avec ses dérivés (Ubuntu, Xandros, etc.)

Compilation du nouveau noyau Linux

Les noyaux par défaut installés sur les serveurs Kimsufi ont été privés de certaines options malheureusement indispensables au fonctionnement de LXC (Pid namespace, User namespace, Multiple /dev/pts instances, Cgroup namespace, Cgroup sched, Cgroup memory controller, Veth pair device, Macvlan). Pour cette raison, nous allons devoir en compiler un nouveau en activant les options nécessaires.

Avant d’entamer de nombreuses manipulations sur un serveur, j’ai pour habitude de lancer un screen. Cela permet, en cas de coupure de la connexion, de ne pas stopper la tâche en cours (une compilation par exemple) ; vous pourrez donc vous y rattacher et ainsi reprendre là où vous en étiez.

Si screen n’est pas déjà installé :

apt-get install screen

On créé la session screen :

screen -S compil
En cas de déconnexion, vous pourrez reprendre votre session comme ceci :

screen -x compil

Il est même possible de se rattacher à la session depuis plusieurs machines, cela vous permet par exemple de partager votre terminal avec une autre personne qui pourra voir en temps réel ce qu’il s’y passe.

Nous allons commencer par reconfigurer les locales avec le jeu de paramètres régionaux français :

dpkg-reconfigure locales

On décoche les locales suivantes avec la barre d’espace :

  • en_GB ISO-8859-1
  • en_GB.ISO-8859-15 ISO-8859-15
  • en_GB.UTF-8 UTF-8

On coche celles-ci :

  • fr_FR ISO-8859-1
  • fr_FR.UTF-8 UTF-8
  • fr_FR.UTF-8@euro
  • fr_FR@euro ISO-8859-15

On valide, puis dans la fenêtre de dialogue qui suit on sélectionne fr_FR.UTF-8.

Enfin, on précise au système quelle langue utiliser :

echo "LC_ALL=fr_FR.UTF-8" >> /etc/environment
echo "LANG=fr_FR.UTF-8" >> /etc/environment
echo "LANGUAGE=fr_FR.UTF-8" >> /etc/environment

On met à jour le système au cas où :

apt-get update
apt-get upgrade

Pour compiler notre noyau, nous allons avoir besoin d’installer plusieurs outils :

apt-get install make gcc libncurses5-dev lzma dpkg-dev wget

On se créé un répertoire de travail :

mkdir /root/noyau
cd /root/noyau

On récupère la dernière version stable du noyau sur https://www.kernel.org/.

Actuellement la dernière version est la 3.19 :

wget -P /root/noyau -c --no-check-certificate https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.19.tar.xz

On décompresse l’archive et on se place dans le répertoire :

tar -Jxvf linux-3.19.tar.xz
cd /root/noyau/linux-3.19

Par curiosité, on peut regarder quelle est la version du noyau actuellement utilisée :

uname -r

Pour que le noyau que nous allons compiler soit compatible avec la machine, nous allons devoir récupérer la dernière version du fichier de configuration du noyau d’OVH. Ces fichiers sont hébergés ici : ftp://ftp.ovh.net/made-in-ovh/bzImage

On récupère la dernière configuration (actuellement la 3.19.0) :

wget -P /root/noyau/linux-3.19 -c ftp://ftp.ovh.net/made-in-ovh/bzImage/3.19/config-3.19.0-xxxx-std-ipv6-64

Dans l’utilitaire de configuration des options du noyau menuconfig, le nom par défaut du fichier de configuration est « .config », nous allons donc renommer celui que nous venons de télécharger :

mv config-3.19.0-xxxx-std-ipv6-64 .config

On lance l’utilitaire de configuration :

make menuconfig

Si vous n’êtes pas familier avec menuconfig, voici le minimum à savoir :

  • On se déplace avec les flèches haut, bas, gauche et droite
  • On coche une option avec la barre espace ([*] signifie que l’option est activée, [ ] signifie que l’option n’est pas activée)
  • ---> signifie que l’option dispose d’un sous-menu
  • On se rend dans un sous-menu avec la touche entrée

La première étape est de charger le fichier de configuration. Pour cela, on se rend dans <Load> et on valide <Ok> avec la touche entrée.

Ensuite, il faut activer les options suivantes :

General setup --->
    [*] Control Group support --->
        [*] Example debug cgroup subsystem
        [*] Freezer cgroup subsystem
        [*] Device controller for cgroups
        [*] Cpuset support
        [*]  Include legacy /proc/<pid>/cpuset file
        [*] Simple CPU accounting cgroup subsystem
        [*] Resource counters
        [*]  Memory Resource Controller for Control Groups
        [*]   Memory Resource Controller Swap Extension
        [*]    Memory Resource Controller Swap Extension enabled[...]
        [*]   Memory Resource Controller Kernel Memory accountin[...]
        [*] Enable perf_event per-cpu per-container group (cgrou[...]
        [*] Group CPU scheduler --->
            [*] Group scheduling for SCHED_OTHER (NEW)
            [*]  CPU bandwidth provisioning for FAIR_GROUP_SCHED
            [*] Group scheduling for SCHED_RR/FIFO
        [*] Block IO controller
        [*]  Enable Block IO controller debugging
    -*-  Namespaces support --->
        [*] UTS namespace
        [*] IPC namespace
        [*] User namespace
        [*] PID Namespaces
        [*] Network namespace
[*] Enable loadable module support
Networking support --->
    Networking options --->
        <*> 802.1d Ethernet Bridging
        [*]  IGMP/MLD snooping
        [*]  VLAN filtering
        <*> 802.1Q/802.1ad VLAN Support
        [*]  GVRP (GARP VLAN Registration Protocol) support
Device Drivers --->
    [*] Network device support --->
        <*> MAC-VLAN support
        <*>  MAC-VLAN based tap driver
        <*> Virtual ethernet pair device
    Character devices --->
        -*- Unix98 PTY support
        [*]  Support multiple instances of devpts

Une fois la configuration terminée, ne pas oublier d’enregistrer les modifications : <Save> puis <Ok>.

Nous pouvons à présent quitter menuconfig : <Exit> et compiler notre nouveau noyau.

La commande suivante redirige la sortie standard vers le fichier compil.log, cela vous permettra d’en savoir un peu plus en cas de problème ; aussi, pour que la compilation soit plus rapide, vous pouvez adapter l’argument 4 de l’option --jobs en fonction du nombre de threads que peut exécuter votre machine simultanément :

make KDEB_PKGVERSION=3.19.0.cgroups.1.0 deb-pkg --jobs 4 | tee -a compil.log

La compilation devrait durer une bonne demi-heure, voir plus, selon la configuration de votre serveur.

Si tout se passe bien, vous devriez trouver votre nouveau noyau dans /root/noyau : linux-image-3.19.0-xxxx-std-ipv6-64_3.19.0.cgroups.1.0_amd64.deb

LXC repose sur les fonctionnalités des Control Groups qui permettent de limiter, compter, et isoler l’utilisation des ressources processeur, mémoire, ou espace disque ; nous devons donc les monter automatiquement au démarrage de la machine, pour cela, il suffit de les ajouter dans /etc/fstab :

echo "cgroup /sys/fs/cgroup cgroup defaults 0 0" >> /etc/fstab
mkdir -p /sys/fs/cgroup
mount /sys/fs/cgroup

On déplace le noyau actuel :

mv /boot/bzImage-3.14.32-xxxx-grs-ipv6-64 /tmp
mv /boot/System.map-3.14.32-xxxx-grs-ipv6-64 /tmp
mv /etc/grub.d/06_OVHkernel /tmp

Nous pouvons à présent installer le noyau que nous venons de compiler :

dpkg -i /root/noyau/linux-image-3.19.0-xxxx-std-ipv6-64_3.19.0.cgroups.1.0_amd64.deb

Si l’installation s’est bien déroulée, on redémarre le serveur :

reboot

On pense à recréer une session screen :

screen -S compil

On s’assure que nous sommes à présent sur le nouveau noyau :

uname -r

Vous devriez obtenir la valeur suivante : 3.19.0-xxxx-std-ipv6-64

Maintenant que la compilation et l’installation du nouveau noyau Linux sont terminées, nous pouvons passer à l’installation de LXC.

Installation de LXC

LXC est présent dans les dépôts, mais dans une ancienne version, qui de plus, peut poser quelques problèmes. Le projet évoluant assez vite, nous allons récupérer la dernière version directement depuis git et la compiler nous-mêmes.

Pour cela, nous avons besoin de quelques outils :

apt-get install git automake libcap-dev pkg-config docbook2x python3-dev

On récupère le projet complet :

cd /root
git clone https://github.com/lxc/lxc.git

On se place dans le répertoire contenant le projet et on lance le script de génération du makefile :

cd /root/lxc
./autogen.sh

On démarre la compilation en lançant les commandes suivantes une par une :

./configure --enable-doc --enable-python --prefix=/usr | tee -a config.log
make -j4 | tee -a compil.log
make check

On installe LXC :

make install

Un peu de nettoyage :

make distclean

Maintenant que nous avons un noyau compilé spécialement pour l’occasion, et que nous avons installé LXC dans sa version la plus récente, il convient de s’assurer que la configuration du noyau est correcte :

lxc-checkconfig

Tout devrait être à « enable ».

En lançant la commande lxc-checkconfig, vous pouvez voir que le contrôleur memory est activé ce qui n’est pas tout à fait exact ; le terme adéquat serait “supporté” car en réalité, par défaut, il est désactivé. Ce contrôleur permet de limiter l’utilisation de la mémoire (plus d’infos ici et ). Nous allons donc devoir l’activer en remplaçant la ligne GRUB_CMDLINE_LINUX="" du fichier /etc/default/grub par GRUB_CMDLINE_LINUX="cgroup_enable=memory". La commande sed suivante vous épargnera l’édition manuelle du fichier :

sed -i -e "s/GRUB_CMDLINE_LINUX=\"\"/GRUB_CMDLINE_LINUX=\"cgroup_enable=memory\"/g" /etc/default/grub

On applique les modifications puis on redémarre la machine pour la dernière fois :

update-grub
reboot

LXC est à présent prêt à fonctionner, cependant, avant de pouvoir créer des serveurs virtuels, il va nous falloir effectuer une petite modification.

Par défaut, les containers sont stockés dans le répertoire /usr/var/lib/lxc. Or sur un serveur Kimsufi PS 4G de 1To, la partition / ne fait que 20 Go, contre 898 Go pour la partition /home. Nous allons donc déplacer l’emplacement par défaut vers /home/containers.

On créé le répertoire /home/containers :

mkdir /home/containers

On créé un lien symbolique de /usr/var/lib/lxc vers /home/containers :

rm -r /usr/var/lib/lxc
ln -s /home/containers/ /usr/var/lib/lxc

Création d’un serveur virtuel sous Debian Wheezy

On installe les paquets nécessaires à la création du pont et du rootfs :

apt-get install bridge-utils debootstrap

Les templates de création de containers fournis avec LXC sont stockés dans /usr/share/lxc/templates.

Ces templates automatisent l’installation des distributions. Je vous propose de personnaliser le template de création d’un container Debian en modifiant les paramètres de langues et en ajoutant quelques paquets.

On met de côté le template original :

cp /usr/share/lxc/templates/lxc-debian /usr/share/lxc/templates/lxc-debian.bak

De base, les paramètres de langues sont définis en anglais, nous allons éditer deux lignes pour les mettre en français :

  • chroot $rootfs locale-gen en_US.UTF-8 UTF-8 devient chroot $rootfs locale-gen fr_FR.UTF-8
  • chroot $rootfs update-locale LANG=en_US.UTF-8 devient chroot $rootfs update-locale LANG=fr_FR.UTF-8

Les commandes sed suivantes vous épargneront l’édition manuelle du fichier :

sed -i -e "s/locale-gen en_US.UTF-8 UTF-8/locale-gen fr_FR.UTF-8/g" /usr/share/lxc/templates/lxc-debian
sed -i -e "s/update-locale LANG=en_US.UTF-8/update-locale LANG=fr_FR.UTF-8/g" /usr/share/lxc/templates/lxc-debian

Nous allons également ajouter deux paquets : l’éditeur de texte vim et l’utilitaire iputils-ping qui permet de tester l’accessibilité d’une autre machine à travers un réseau IP :
La commande sed suivante vous épargnera l’édition manuelle du fichier :

sed -i -e "s/openssh-server/openssh-server,\\\\\\niputils-ping,\\\\\\nvim/g" /usr/share/lxc/templates/lxc-debian

Nous sommes à présent prêts à créer notre premier container sous Debian Wheezy.
Pour cela rien de plus simple :

  • on créé un nouveau container : lxc-create
  • on lui donne un nom : -n vm1
  • on indique quel template utiliser : -t debian

Ce qui nous donne :

lxc-create -n vm1 -t debian

Comme vous avez pu le constater, l’installation a duré quelques minutes, rassurez-vous, la création de nouveaux containers ne prendra que quelques secondes, car les paquets nécessaires ont été mis en cache.

Nous venons de créer notre premier container, avant de le démarrer, nous allons configurer le réseau pour qu’il ait accès à internet.

Configuration du réseau

Configuration du container

Nous allons commencer par configurer l’interface de notre serveur virtuel en lui attribuant une adresse privée. Pour cela, on édite son fichier interfaces comme suit :

vim /home/containers/vm1/rootfs/etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
		address 192.168.1.2
		netmask 255.255.255.0
		broadcast 192.168.1.255
		gateway 192.168.1.1

Pour finir, on édite le fichier de configuration de notre serveur virtuel en ajoutant les éléments suivants à la fin du fichier :

vim /home/containers/vm1/config
# Network
lxc.utsname = vm1
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth0
lxc.network.ipv4 = 192.168.1.2/24
lxc.network.ipv4.gateway = 192.168.1.1
lxc.network.veth.pair = veth-vm1

Configuration de l’hôte

Nous allons à présent configurer l’hôte en autorisant le système à rediriger les paquets IP. Pour cela, il suffit d’éditer le fichier /etc/network/interfaces et d’ajouter la ligne suivante pour l’interface eth0 :

vim /etc/network/interfaces
post-up echo 1 > /proc/sys/net/ipv4/ip_forward

Comme nos containers auront chacun une adresse réseau privée, nous allons créer une nouvelle interface qui aura pour rôle de faire un pont entre l’ensemble des adresses privées de nos containers et l’interface physique eth0. Pour cela, on ajoute la configuration suivante à la suite du fichier /etc/network/interfaces :

auto br0
iface br0 inet static
		address 192.168.1.1
		netmask 255.255.255.0
		bridge_ports none
		bridge_stp off
		bridge_fd 0
		bridge_maxwait 5

Pour que l’ensemble de nos containers puisse accéder à internet, nous allons devoir ajouter une règle iptables pour activer le SNAT et la mascarade. Pour cela, on ajoute la ligne suivante pour l’interface eth0 :

post-up iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

Le fichier de configuration du réseau de votre hôte devrait maintenant ressembler à ceci :

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
	address 5.39.88.234
	netmask 255.255.255.0
	network 5.39.88.0
	broadcast 5.39.88.255
	gateway 5.39.88.254
	post-up echo 1 > /proc/sys/net/ipv4/ip_forward
	post-up iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

auto br0
iface br0 inet static
	address 192.168.1.1
	netmask 255.255.255.0
	bridge_ports none
	bridge_stp off
	bridge_fd 0
	bridge_maxwait 5

iface eth0 inet6 static
	address 2001:41D0:8:9Aea::1
	netmask 128
	post-up /sbin/ip -f inet6 route add 2001:41D0:8:9Aff:ff:ff:ff:ff dev eth0
	post-up /sbin/ip -f inet6 route add default via 2001:41D0:8:9Aff:ff:ff:ff:ff
	pre-down /sbin/ip -f inet6 route del default via 2001:41D0:8:9Aff:ff:ff:ff:ff
	pre-down /sbin/ip -f inet6 route del 2001:41D0:8:9Aff:ff:ff:ff:ff dev eth0

La configuration est à présent terminée, il ne vous reste plus qu’à redémarrer vos interfaces réseau pour enfin profiter des avantages des containers :

service networking restart

Informations utiles

Commandes LXC :

  • Démarrer un container : lxc-start -n vm1
  • Démarrer un container en arrière-plan : lxc-start -n vm1 -d
  • Rentrer dans un container démarré en arrière-plan (pour en sortir faire ctrl+a puis q) : lxc-console -n vm1
  • Arrêter un container (si possible privilégier l’arrêt depuis le container qui est moins brutal): lxc-stop -n vm1
  • Mettre en pause un container : lxc-freeze -n vm1
  • Sortir de pause un container : lxc-unfreeze -n vm1
  • Créer un container : lxc-create -n vm2 -t debian
  • Détruire un container : lxc-destroy -n vm1
  • Afficher la liste des containers : lxc-ls
  • Afficher l’état (démarré/arrêté/en pause) et l’IP de tous les containers : lxc-ls --fancy
  • Afficher des informations sur un container : lxc-info -n vm1
  • Purger le cache d’une image : /usr/share/lxc/templates/lxc-debian --clean

Je vous invite à consulter le manuel pour plus d’informations : man lxc

Quelques règles iptables :

Si vous souhaitez que des services installés sur vos containers soient accessibles depuis l’extérieur, vous devez rediriger les connexions vers les adresses et ports des containers. Pour cela, nous allons utiliser le DNAT.

Si votre container dont l’adresse IP est 192.168.1.2 héberge un serveur HTTP, nous utiliserons la règle suivante pour transférer les connexions entrantes sur le port 80 de l’hôte vers notre container écoutant sur le port 80 :

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.2:80

Si vous ne souhaitez pas donner l’accès à internet à l’ensemble de vos containers, mais plutôt au cas par cas, vous pouvez vous inspirer de la règle suivante en lieu et place de celle que nous avons utilisée dans la partie “Configuration de l’hôte” :

iptables -t nat -A POSTROUTING -s 192.168.1.2 -o eth0 -j MASQUERADE

Démarrer des containers automatiquement :

Avec la version 0.8.0-rc1 de LXC, il était possible de démarrer automatiquement des containers lors du démarrage de l’hôte en effectuant un simple lien symbolique : ln -s /var/lib/lxc/vm1/config /etc/lxc/auto/vm1. Mais cette fonctionnalité était en fait offerte par les distributions et non par LXC, cela ne fonctionne donc plus avec la version actuelle.

J’ai pris contact avec le développeur principal de LXC qui m’a dit travailler à l’implémentation de l’auto-start en natif.

En attendant, mon ami Arnaud Valensi a créé un script qui pallie ce manque ; je vous propose de l’utiliser.

On récupère le script dans /etc/inid.d :

wget -P /etc/init.d https://raw.github.com/ArnaudValensi/lxc-ovh/master/files/init.d/lxc

On lui donne les bons droits :

chmod 755 /etc/init.d/lxc

Pour finir, on active le service :

update-rc.d lxc defaults

Pour activer le démarrage automatique d’un container au lancement de l’hôte, il suffira d’écrire la valeur 1 dans un fichier nommé autostart contenu dans le répertoire principal du container :

echo "1" > /home/containers/vm1/autostart

Créer une seedbox avec qBittorrent sous Debian Wheezy

(Dernière mise à jour : 12 mai 2014)

Présentation de qBittorrent

qBittorrent est un client bittorrent très léger développé en C++ avec la bibliothèque Qt4. Il est libre, multiplateforme et dispose d’une interface web en Ajax, il peut donc fonctionner sans serveur X. Nous allons voir comment l’installer en ligne de commande sur un serveur ne disposant pas d’interface graphique.
Ce guide fonctionne pour Debian, Ubuntu et ses dérivés.

qBittorrent
Capture d’écran de l’interface web de qBittorrent

Installation des dépendances

La compilation de qBittorrent nécessite l’installation de plusieurs dépendances.

On installe les outils de base :

apt-get install build-essential libtool automake autoconf subversion git wget pkg-config python

Les librairies SSL et Boost :

apt-get install libboost-date-time-dev libboost-dev libboost-filesystem-dev \
libboost-iostreams-dev libboost-program-options-dev libboost-regex-dev \
libboost-serialization-dev libboost-signals-dev libboost-test-dev \
libboost-thread-dev libssl-dev

La librairie Qt4 :

apt-get install libqt4-dev

Compilation de Libtorrent

qBittorrent utilise la librairie libtorrent, il est donc nécessaire de la compiler et de l’installer avant de pouvoir faire de même avec qBittorrent.

Nous allons donc commencer par récupérer la dernière version de la librairie depuis le svn :

mkdir -p qBittorrent_compiling
cd qBittorrent_compiling
svn co https://svn.code.sf.net/p/libtorrent/code/branches/RC_0_16 libtorrent

Vous devriez à présent disposer de la dernière branche svn de libtorrent dans le répertoire du même nom. Comme le fichier de configuration n’est pas fourni, nous allons le créer nous-mêmes :

cd libtorrent
./autotool.sh

Nous pouvons à présent compiler la librairie :

./configure --disable-debug --prefix=/usr && make clean && make

Il ne nous reste plus qu’à l’installer :

make uninstall
make install-strip

Compilation de qBittorrent

On récupère la dernière version de qBittorrent depuis git :

cd ..
git clone https://github.com/qbittorrent/qBittorrent.git

On la compile en désactivant l’interface graphique :

cd qBittorrent
./configure --prefix=/usr --disable-gui
make

On installe qBittorrent :

make install

Lancer qBittorrent au démarrage du serveur

Donner les droits root à une application de ce type étant une très mauvaise idée, nous allons créer un utilisateur spécifique :

adduser qbittorrent

Un utilisateur de qBittorrent (Jesper Smith) a créé un script d’initialisation. Nous allons donc le récupérer :

wget -P /etc/init.d http://blaisethirard.fr/partage/blog/qbittorrent-nox-daemon

(Si vous n’avez pas nommé le nouvel utilisateur “qbittorrent”, pensez à remplacer “qbittorrent” à la ligne 25 du script /etc/init.d/qbittorrent-nox-daemon par le nom de l’utilisateur que vous avez créé.)

On lui donne les bons droits :

chmod 755 /etc/init.d/qbittorrent-nox-daemon

On exécute le script d’initialisation au démarrage du système :

update-rc.d qbittorrent-nox-daemon defaults

Au premier démarrage de qBittorrent, un message d’avertissement s’affiche et vous demande de taper “y” afin de pouvoir continuer. Pour cette raison, nous allons nous connecter avec l’utilisateur qbittorrent et lancer le programme manuellement :

su qbittorrent
qbittorrent-nox
******** Informations ********
 Pour contrôler qBittorrent, accéder à l'interface Web via http://localhost:8080
 Le nom d'utilisateur de l'administrateur de l'interface Web est : admin
 Le mot de passe de l'administrateur de l'interface Web est toujours celui par défaut : adminadmin
 Ceci peut être dangereux, veuillez penser à changer votre mot de passe dans les options.
 15/09/2013 04:59:57 - L'interface Web est associée au port 8080

Au prochain démarrage de votre serveur, le service qbittorrent-nox sera automatiquement lancé en arrière-plan.

Un peu de ménage :

rm -r ~/qBittorrent_compiling

L’installation est terminée, pensez à changer l’utilisateur et le mot de passe par défaut de qBittorent : Outils > Options… > Interface Web > Authentification

Installation de Linux-VServer sur Debian GNU/Linux 7.0 (Wheezy)

Comme vous le savez sans doute si vous n’êtes pas tombé sur cet article par hasard, avec cette dernière version de Debian, Linux-VServer devient obsolète. Cela signifie qu’il va bientôt falloir migrer vers une autre solution de virtualisation (KVM, Linux Container ou Xen). Cependant, vous avez peut-être besoin de poursuivre avec Linux-VServer quelque temps sans pour autant vous priver de la dernière version stable de Debian.
Si vous êtes conscients que le projet Debian arrête le suivi en sécurité de Linux-VServer et qu’il n’y aura plus de support de ce composant, suivez le guide. Sinon, je vous invite à passer à LXC.

Notes :

  • Je pars du principe que vous avez déjà installé Debian Wheezy
  • Si une partie d’une ligne de commande est surlignée comme ceci, cela signifie qu’elle peut ou doit être adaptée avec vos paramètres ou préférences
  • Ce guide est conçu pour que dans la plupart des cas, vous puissiez vous contenter de faire des copier / coller

Dans le fichier /etc/apt/sources.list, on commente la ligne relative au cd-rom :

sed -i "s/^\(deb cdrom.*\)/#\1$/g" /etc/apt/sources.list

On met à jour le système :

apt-get update
apt-get upgrade

On installe les outils de base et ceux qui seront nécessaires à la compilation :

apt-get install \
wget \
build-essential \
kernel-package \
initramfs-tools \
module-init-tools \
libncurses5-dev \
e2fslibs-dev \
dietlibc-dev \
pkg-config \
vlan \
libnss3 \
libnss3-dev \
debootstrap

On récupère la dernière version du patch Linux-VServer depuis le site http://vserver.13thfloor.at/Experimental/ :

wget -P /usr/src http://vserver.13thfloor.at/Experimental/patch-3.9.5-vs2.3.6.5.diff

On récupère le kernel correspondant depuis le site https://www.kernel.org/pub/linux/kernel/ ou https://www.kernel.org/ :

wget -P /usr/src https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.9.5.tar.gz

On se place dans /etc/src et on décompresse le kernel :

cd /usr/src
tar xvfz linux-3.9.5.tar.gz

On créé le lien symbolique /usr/src/linux qui pointe vers les sources du noyau :

ln -s linux-3.9.5 linux

On récupère la configuration du noyau actuellement en service puis on la copie dans celle du nouveau noyau :

cp /boot/config-3.2.0-4-686-pae /usr/src/linux/.config

Il est également possible de récupérer cette configuration dans le système de fichier procfs, si l’optionKernel .config support du noyau était activée pour le noyau en service :

zcat /proc/config.gz > /usr/src/linux/.config

ou encore dans le répertoire kernel du noyau actuellement en service :

cp /usr/src/linux-3.9.5/.config /usr/src/linux/

On se place dans /usr/src/linux et on applique le patch :

cd /usr/src/linux
patch -p1 < ../patch-3.9.5-vs2.3.6.5.diff

On lance menuconfig :

make menuconfig

et on active les options suivantes :

  • « Enable loadable module support »
  • « Linux VServer »
    • « Automatically Assign Loopback IP »
    • « Enable COW Immutable Link Breaking »
    • « Enable Proc Security »
    • « VServer Warnings »
    • « VServer DevPTS Warnings »

Pensez à enregistrer vos modifications avant de quitter menuconfig : < Save >

On efface tous les fichiers créés dans le répertoire des sources du noyau par la cible build :

make-kpkg clean

On lance la compilation du kernel (l’argument « 4 » de l’option « --jobs » est à adapter en fonction du nombre de threads que peut exécuter votre machine simultanément) :

make-kpkg --initrd --append-to-version vserver --revision 1 kernel-image --jobs 4

Si la compilation s’est bien déroulée, un paquet .deb a été créé dans /usr/src.
On installe le nouveau kernel :

dpkg -i /usr/src/linux-image-3.9.5-vs2.3.6.5vserver_1_amd64.deb

Si vous êtes sur une machine distante à laquelle vous n’avez pas d’accès physique, je vous recommande très fortement de prendre la précaution détaillée dans mon article précédent avant de redémarrer la machine : https://blog.blaisethirard.com/grub-precaution-a-prendre-apres-la-compilation-d-un-nouveau-kernel-sur-un-serveur-distant/

On redémarre la machine :

reboot

Une fois la machine redémarrée, on vérifie que le noyau utilisé est bien celui que nous venons d’installer :

uname -r

Maintenant que nous sommes sur le noyau patché, il ne nous reste plus qu’à installer util-vserver. Pour cela, on télécharge la dernière version à cette adresse : http://people.linux-vserver.org/~dhozac/t/uv-testing :

wget -P /usr/src http://people.linux-vserver.org/~dhozac/t/uv-testing/util-vserver-0.30.216-pre3038.tar.bz2

On se place dans /etc/src et on décompresse l’archive :

cd /usr/src
tar jxvf util-vserver-0.30.216-pre3038.tar.bz2

On se place dans /etc/src/util-vserver-0.30.216-pre3038/ et on lance le script de configuration :

cd util-vserver-0.30.216-pre3038/
./configure --prefix=/usr --enable-release --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc --enable-dietlibc --localstatedir=/var --with-vrootdir=/home/srv

On compile util-vserver :

make
make install
make install-distribution

Le script vshelper est utilisé pour arrêter et redémarrer correctement les serveurs virtuels. Nous allons donc indiquer au noyau où il se trouve :

echo /usr/lib/util-vserver/vshelper >| /proc/sys/kernel/vshelper
echo kernel.vshelper = /usr/lib/util-vserver/vshelper >> /etc/sysctl.conf

On démarre util-vserver :

service util-vserver start

Pour finir, on configure le démarrage automatique des services :

update-rc.d vprocunhide defaults
update-rc.d util-vserver defaults
update-rc.d vservers-default defaults

Linux-VServer est à présent installé et fonctionnel sur votre Debian Wheezy !