A défaut de pouvoir contrôler complètement − en tous les cas sans risque − les logiciels et outils du NAS VHT;
à défaut en particulier de pouvoir ajouter, toujours sans risque pour le fonctionnement prévu du serveur, les programmes qui ne sont pas présents et nous intéressent, on se donne pour objectif ici de réaliser un «serveur d'applications», en s'appuyant sur les containers LXC.

… Merci aux copains du forum, qui m'ont permis … d' «enquêter» … à Epy en fait, et pour son coup de main

☛ Quelques liens LXC:
L'outil LXC.
Blog d'un des créateurs (je crois): Une 10^zaine d'articles pour bien commencer.

☛ Outils tiers:
Scripting lxc - pour voir...
Logiciel Guacamole (cf. plus loin).
Serveur d'affichage X11 Xvfb
Système de fenêtrage FluxBox
MariaDB
…
Un ... «comparatif sans doute un peu rapide» Docker vs LXC

Les cas sont rares (voire inexistant) de programmes disponibles sur les dépôts d'une distribution GNU/Linux et pas sur une autre. Lorsque c'est le cas, on peut en principe s'en sortir à partir des codes sources et en recompilant… ce n'est pas toujours facile ! Dans ce cas, l'installation sur la distribution dont on dispose est au minimum … «problématique».
Par ailleurs, indépendamment des distributions, certaines applications pourraient avoir du mal à cohabiter, par exemple avec des versions différentes d'une même bibliothèque.

L'idéal reste donc d'isoler les applications en les faisant s'exécuter chacune dans leur propre environnement (y compris la distribution), dédié et indépendant de l'application d'à côté, et surtout de la machine hôte sur laquelle elles tournent avec des fonctionnalités éventuellement incompatibles. Pour faire cela, on a au moins trois options:

1. Les machines virtuelles
2. Les containers Docker
3. Les containers Linux (LXC)

Docker parait bien convenir pour des applications (même s'il est quand même orienté vers les développeurs en intégrant des outils de build et de déploiement). Il est très à la mode à l'heure de ces lignes; par conséquent il existe une foultitude d'aides, de tutoriels, d'images Docker disponibles sur la toile. Mais il n'est pas installé sur le VHS… donc risque !

Les Machines Virtuelles sont bien sûr possibles: elles existent pour les serveurs dont le processeur supporte les instructions nécessaires (donc pas tous). Mais les VM émulent complètement une machine − matériel et OS − et elles consomment ainsi pas mal de ressources.

Enfin, les LXC (Linux Containers), semblent un bon compromis entre Docker (qui en hérite dans ses principes d'isolation) et les VM. LXC est moins lourd que ces dernières, car il partage d'avantage de ressources de son hôte, en particulier le noyau Linux. Du fait même de ce partage, les containers LXC sont nécessairement du Linux, contrairement aux VM (Windows par exemple).

Le gros avantage, c'est que LXC est nativement installé sur le NAS VHT ! Et que donc même les serveurs sans support des VM pourraient le faire tourner … En théorie du moins !!

La version LXC installée est la 1.0.7 donnée par la commande suivante en ssh:

admin@sesame:~$ dpkg-query -l | grep lxc
ii liblxc1       1.0.7-0ubuntu0.1 amd64 Linux Containers userspace tools (library)
ii lxc           1.0.7-0ubuntu0.1 amd64 Linux Containers userspace tools
ii lxc-templates 1.0.7-0ubuntu0.1 amd64 Linux Containers userspace tools (templates)
ii python3-lxc   1.0.7-0ubuntu0.1 amd64 Linux Containers userspace tools (Python 3.x bindings)
admin@sesame:~$ 

Sachant qu'a priori, la dernière version stable semble être la 1.0.9 pour la distribution Ubuntu Trusty du VHS…

Z'ont vu loin chez Ve-Hotech, même si apparemment ils ne sont pas allés au bout… et/ou n'ont pas communiqué…

On va donc tenter ici de faire s'exécuter des applications dans des containers LXC sur le VHS… Donc, par le principe même du fonctionnement, sans risque pour lui.

Mais, prudents, on va se faire les dents d'abord dans une VM (on «empile» les virtualisations, çà le fait ): ☛ cf. les annexes.

Faisons un peu de …heu … «d'architecture applicative» … pffff !

Les services qu'on veut proposer et positionner dans des containers LXC pourront être de toutes natures:

• de simples applications serveur pilotées en lignes de commandes (des scripts de sauvegarde par exemple),
• des services en mode web qui ne sont pas déployables simplement sur le VHS − avec des contraintes diverses sur le NAS: versions PHP ou MySQL insuffisantes, configuration Apache incompatible, etc…
• ou bien encore des applications plus lourdes, en mode bureau avec IHM graphique.

La façon d'atteindre ces services «containérisés» sur le VHS est nécessairement distante depuis un client connecté au réseau: ordinateur, tablette, mobile…

L'outil Guacamole pourrait bien être idéal pour servir d'intermédiaire de présentation de nos services sur un client «banalisé»: depuis un simple navigateur.

Guacamole est positionné comme suit:

Ainsi, nos services en containers LXC sont exposés sur le réseau dans un protocole (VNC, RDP, SSH etc…) et sont «restitués» dans un navigateur en HTML 5 sur les clients via Guacamole: … simple !

Cerise sur le gâteaux: Guacamole tourne évidemment dans un container !

Pour les services web, Guacamole n'est pas indispensable, pas plus que pour l'accès à un container serveur en ssh. On le propose ici surtout pour les accès aux services graphiques dans les containers sur le VHS, aussi bien que pour atteindre par exemple des postes du réseau, des Raspberry sous Raspbian ou même les VM hébergées sur le NAS… Point d'accès unique et mutualisé quoi !

On se propose donc dans la suite de couvrir la réalisation des containers LXC suivants:

• Des piles applicatives «service web» avec nginx / php / mariadb; on va pouvoir y «déposer» phpMyAdmin, sonerezh ou nextcloud;
• une «distribution fenêtrée» avec les applications de bureau ;
• et guacamole donc.

… et on aura alors − a priori − balayer et illustrer pas mal de cas d'usage …

Avant de commencer la mise en œuvre de nos containers, ci-dessous quelques point d'attention et de configuration.

☛ Les containers LXC sont prévus pour fonctionner avec aussi une «isolation réseau» (en plus de celle des processus): il existe un pont qui définit un sous-réseau dédié aux containers (en 10.0.3.* sur le VHS). Un dispositif serveur DNS/DHCP (avec dnsmasq) est fourni avec LXC, permettant d'attribuer noms et adresses IP aux containers sur ce sous-réseau. Or, il faut bien exposer les services des containers sur le réseau pour pouvoir y accéder !

La structure du réseau dans le cadre des containers LXC correspond au schéma suivant:

• Les services exposés le sont «publiquement» sur le réseau LAN - et donc au-delà possiblement
• Les services isolés ne sont visibles que sur leur sous-réseau LXC
• Les services exposés et isolés se «connaissent» entre eux via le bridge des containers
• Par exemples:
  • le service #1 fait tourner Guacamole et expose le seul port 8080 (c'est du Tomcat) vis à vis des navigateurs web sur le LAN; en revanche il accède aux services #2 et #5, via le bridge, sur les ports VNC ou RDP que ces services ouvrent.
  • Pareil pour le service #3 (Ngnix / Php) qui expose HTTP / HTTPS (80 et 443)sur le LAN et peut accéder à service #4, container MariaDB qui n'expose que le port 3306 sur 10.0.3.x…

Donc on a deux écueils:

1. Comment faire en sorte par exemple que les services ssh (port 22 par défaut) ou http (port 80) d'un container soient ouverts sur le réseau (en 192.168.x.y) ?
2. Comment laisser passer les flux associés depuis et vers le container sur le VHS, et son pare-feu justement «sévère», sur lequel les flux LXC ne paraissent pas considérés ?

Il ne parait pas pertinent de modifier les règles du pare-feu − d'autant qu'on va perdre les changements à chaque livraison du firmware.

Première option:on prend le parti de «court-circuiter» le sous-réseau LXC : on «raccroche» les containers à l'interface réseau du VHS br0 et du coup, comme pour les machines virtuelles du NAS ou n'importe quelle machine sur le réseau local, le container va cherche son adresse sur la box / le routeur… Les containers sont alors des machines comme les autres, exposées et atteignables comme les autres.

Seconde option:on expose les seuls services qui en ont besoin sur le réseau local comme sur le schéma, via une commande iptables; on perdra la configuration à chaque livraison, mais c'est scriptable et re-jouable sans problème et le «risque» est quand même moindre.

On prendra cette seconde option ici.

☛ Il existe deux types de containers: les privileged et les unprivileged. C'est encore un peu velu pour moi, mais, en gros, dans un container privileged, un pirate qui s'y introduirait pourrait avoir accès à une ressource de l'hôte, via des processus système du container, et pourrait ainsi potentiellement échapper au container et passer pour root sur l'hôte…
Il est possible depuis la version 1.0 de LXC, de faire démarrer un unprivileged container complètement en tant qu'utilisateur (et non pas root) grâce à la gestion des espaces de noms utilisateurs. Dans un tel container, les droits d'un éventuel pirate seraient au maximum ceux de l'utilisateur, il resterait ainsi «confiné» dans le container.
Dans la mesure où il peut y avoir de tout et n'importe quoi comme application dans les containers, le mode unprivileged est naturellement à … privilégier.

Dans nos manipulations ici − pour l'instant et jusqu'à plus ample informé sur l'appréciation du risque, la création des containers unprivileged et l'exploitation de la notion de «capabilities» sur les containers − on court-circuite ce niveaux d'isolation.

Ainsi et en l'état, la mise en garde s'impose selon la formule consacrée:

Un container exploite le noyau Linux de son hôte; il s'appuie quand même sur une distribution GNU/Linux lorsqu'on le construit. On peut avoir une distribution Debian, Ubuntu, Arch-Linux, etc… dans une de ses versions / variantes compatibles avec le noyau de l'hôte. Le choix de la distribution est fait lors de la création du container, en indiquant le modèle ou template utilisé (ici choix d'une Debian):

  sudo lxc-create -n MonContainer -t debian

Les templates (localisés dans /usr/share/lxc/templates/) définissent la configuration et les paquets installés par défaut de la distribution choisie. Ces templates ont été installés sur le NAS avec l'installation du produit LXC (donc, ça date…). C'est pourquoi il existe un template download qui propose des templates téléchargés depuis un serveur linuxcontainer sur le web, a priori plus actualisés et le choix parait plus riche.

Lors de la création d'un premier container avec un template donné, la procédure permet de se connecter aux dépôts de la distribution pour récupérer les dernières modifications; les créations suivantes qui s'appuient sur le même template sont plus rapides par l'exploitation d'un cache du template stocké sur l'hôte cf. ci-dessous les répertoires).

Dans nos manipulations ici, on propose aussi bien de l'Ubuntu que du debian en template locaux et download, selon les cas:

• Le template lxc-ubuntu est «une grosse vache» avec un certain nombre de paquets dont on n'a pas forcément besoin (serveur ssh par exemple)
• Le template lxc-debian est plus léger… voir creux !
• Le template lx-download semble être un compromis

Il faudrait pointer exactement les contenus de chacun…

LXC manipule et «vit» dans des répertoires localisés par défaut sur la partition système du NAS − i.e. la clé système − qui ne dispose pas d'un espace important ni n'aime beaucoup les lectures / écritures fréquentes. Au moins deux de ces dossiers sont concernés, dont il va falloir qu'on les fasse pointer vers une zone de stockage plus appropriée sur le NAS.

Les répertoires utilisés souvent par LXC et où il stocke ses fichiers:

• /var/lib/lxc: emplacement par défaut pour les containers
• /var/lib/lxcsnap: emplacement par défaut pour les instantanés (snapshots)
• /var/cache/lxc: emplacement par défaut du cache des modèles (template vu plus haut)

Pour … plus tard et pour information (mais ces chemins-là ne devraient pas poser de souci, le $HOME des comptes du VHS étant définis selon: /mnt/data/data/users/<compte>):

• $HOME/.local/share/lxc: emplacement par défaut pour les containers non privilégiés (unprivileged)
• $HOME/.local/share/lxcsnap: emplacement par défaut pour les instantanés non privilégiés (unprivileged snapshots)
• $HOME/.cache/lxc: emplacement par défaut pour le cache de modèle non privilégié (unprivileged template cache)

Définissons-nous un emplacement dédié avec droits d'exécution sur le serveur pour accueillir tout çà (sous partages par exemple) et surtout pour ne pas pourrir la clé système (on a un script plus loin qui va le faire) :

ssh admin@sesame
# On créé le dossier dédié  
admin@sesame:~$ sudo mkdir partages/VM-LXC
 
# On y copie le cache et les modèles:
admin@sesame:~$ sudo cp -pR /var/cache/lxc partages/VM-LXC/cache
admin@sesame:~$ sudo cp -pR /usr/share/lxc/templates partages/VM-LXC/templates
 
# On donne les droits qui vont bien
admin@sesame:~$ sudo chmod +x -R partages/VM-LXC

«Et pourquoi les templates ?» − «Parce qu'on va les modifier …».
peut-être pas très élégant, mais pas de souci, on a toujours les originaux…

En effet:

• Pour l'emplacement des containers, et de leurs instantanés (ajout de snap codé), on a une option -P /mon/chemin/containers dans toutes les commandes lxc-xxx qu'on va exploiter;
• L'emplacement du cache est codé en dur semble-t-il…
• Donc, dans la mesure où on souhaite éviter les liens symboliques depuis l'arborescence du système, qu'à priori le cache est surtout exploité lors de la création des containers via les scripts des templates, et qu'enfin, le chemin complet du template peut être fourni à la commande de création des containers… et bien disons qu'on peut se le permettre!

Exemple avec le template lxc-debian:
Remplacer (lignes #282 et #397 du template lxc-debian):

cache="$LOCALSTATEDIR/cache/lxc/debian"

Par:

cache="/mnt/data/data/users/admin/partages/VM-LXC/cache/debian"

Exemple avec le template lxc-ubuntu:
Remplacer (ligne #383 du template lxc-ubuntu):

cache="$LOCALSTATEDIR/cache/lxc/$release"

Par:

cache="/mnt/data/data/users/admin/partages/VM-LXC/cache/$release"

Pour l'utilisation, ci-dessous un exemple de commande de création d'un container:

sudo lxc-create -n lxc-ubuntu-base \
 -t /mnt/data/data/users/admin/partages/VM-LXC/templates/lxc-ubuntu \
 -P /mnt/data/data/users/admin/partages/VM-LXC

Et notre dossier cache est bien alimenté:

admin@sesame:~/partages/VM-LXC$ sudo ls -aln cache/
total 12
drwx--S--- 3 0   0 4096 Feb 26 20:48 .
drwxrwsr-x 6 0 100 4096 Feb 26 20:48 ..
drwxr-sr-x 3 0   0 4096 Feb 26 13:59 trusty
admin@sesame:~/partages/VM-LXC$ 

A vous de trouver les modifications pour les autres template que vous souhaiterez utiliser…

Pour répondre au schéma proposé plus haut avec les services exposés et pas, on propose une configuration du serveur DNS/DHCP dnsmasq intégré avec LXC.

A l'instar d'un routeur ou d'une box, lorsqu'un container est démarré, une adresse lui est attribuée dynamiquement par ce serveur dnsmasq. Et comme un routeur également, on peut fixer l'adresse de façon systématique. D'autre part, on peut donner un nom a chaque container, pour pouvoir les adresser de cette façon plutôt que par une adresse IP qu'on mémorise moins bien… enfin, pour ce qui me concerne !

Le fichier de configuration est là: /etc/defaut/lxc-net. Deux lignes sont à adapter:

• La première consiste à donner un chemin vers un fichier de configuration des noms et adresses des containers: #LXC_DHCP_CONFILE=/etc/lxc/dnsmasq.conf.
• La seconde permet d'activer le domaine «lxc»: #LXC_DOMAIN=“lxc”

Le scripts ci-dessous définit le fichier de configuration dans l'espace utilisateur du NAS (par défaut, il est sur la clé ) et dé-commente ces deux lignes «qui vont bien».

Vous pouvez bien sûr faire cela à la main et en dehors du script. Un arrêt / relance du service est nécessaire à chaque modification de ce fichier, ou de la configuration sur laquelle il pointe:

sudo service lxc-net stop
sudo service lxc-net start

NB: la commande restart ne semble pas définie et/ou fonctionnelle…

… ne nuit pas ! Ci-dessous, des idées d' «organisation» d'un environnement LXC, qu'on exploite dans la suite.

Un script qui met en œuvre les items des § 3.x est proposé ci-dessous …

Pour éviter de mémoriser les «chemins à rallonges» dans l'utilisation des commandes LXC, vous pouvez ajouter, via la commande suivante, les variables d'environnement qui-vont-bien (adaptez si nécessaire), exploitables avec le mécanisme de complétion:

nano ~/.profile
...  
# 2017.03.01 - Ajout chemins LXC et templates
export LXC_PATH=$HOME/partages/VM-LXC
export LXC_TEMPLATE=$LXC_PATH/templates

La commande en exemple précédente s'écrit alors:

sudo lxc-create -n lxc-ubuntu-base -P $LXC_PATH -t $LXC_TEMPLATE/lxc-ubuntu

Proposition: La création des containers LXC se fait depuis un connexion ssh avec le compte admin sur VHS. On va tenter ici de «scripter» la mise en œuvre des containers. En conséquence on propose – meilleures suggestions bienvenues – l'organisation suivante (sesame est ici le nom du VHS) :

• Création d'un répertoire de scripts dans lequel on définit un dossier par container
  

ssh admin@sesame
admin@sesame:~$ pwd
/mnt/data/data/users/admin
admin@sesame:~$ mkdir -p prive/scripts-lxc
admin@sesame:~$ cd prive/scripts-lxc/
admin@sesame:~/prive/scripts-lxc$ 

• Un répertoire par container de la forme lxc-xxx

admin@sesame:~/prive/scripts-lxc$ mkdir lxc-sonerezh
admin@sesame:~/prive/scripts-lxc$ mkdir lxc-mariadb
....
admin@sesame:~/prive/scripts-lxc$ ls -l
total 8
drwxr-sr-x 2 admin users 4096 Mar  8 20:44 lxc-mariadb
drwxr-sr-x 2 admin users 4096 Mar  8 20:44 lxc-sonerezh
....
admin@sesame:~/prive/scripts-lxc$ 

• des «règles»:
  • Les scripts sont nommés lxc-<ce-que-c-est>_creat.sh
  • Quand on les a créé / copié sur le NAS, il faut les rendre exécutables via chmod +x lxc-<ce-que-c-est>_creat.sh
  • On les lance, par convention/construction avec sudo -E ./lxc-<ce-que-c-est>_creat.sh <ARGS> <password>
    • l'option -E permet que le script voit nos variables d'environnement en LXC_*
    • <ARGS>: arguements du script, on aura a priori au minimum la définition d'un compte sur le containers: -u <user> -p <password> .

Ci-joint - et afin d'éviter les boulettes éventuelles - un script qui fait tout çà, à savoir:

• Création d'un répertoire ../partages/VM-LXC destiner à recevoir
  • un dossier pour le cache
  • un dossier pour les templates qui y sont recopiés et adaptés (pour ubuntu et debian seulement…)
  • il contient également le fichier de configuration dnsmasq.conf que le script créé
  • il recevra un répertoire par container créé
• Création d'un répertoire ../prive/scripts-lxc pour les travaux de définitions des containers
• Définition de la configuration réseau des containers (avec arrête / relance du service associé)
• Définition des variables d'environnement pour simplifier la vie: il faut se déloger pour prise en compte.

Ce script est prévu pour le compte admin du NAS. Il faut l'y copier et le rendre exécutable (chmod +x lxc-set_env.sh)

Il est là: lxc-set_env.sh.zip

On prévoit de construire 3 types de containers

• Environnement / distribution de base en vue de faire tourner des traitements et/ou des scripts, éventuellement planifiés (des sauvegardes par exemple); ou des logiciels qui tournent en tâche de fond comme un moteur de base de données: lxc-mariadb
• pour remplir les fonctionnalités associées à un serveur web:
  • un serveur web Ngnix / Php-fpm avec phpMyAdmin pour gérer notre MariaDB (ou +…): lxc-pma
  • Le logicel Sonerezh: une «boîte à musique» dans un container - inspiré de son image Docker…: lxc-sonerezh
  • Le logiciel NextCloud: lxc-nextcloud
• On passera ensuite aux containers avec environnements graphiques et fenêtrés:
  • Une container «de base» avec des composants au minimum pour la gestion graphique: lxc-x11vnc
  • un ou plusieurs containers - qui «hériterons» du précédent et «dédiés»: Un environnement de développement, un autre de téléchargement, etc…
  • Guacamole pour y accéder en mode navigateur web… même si des clients VNC ou même X2GO (si on met un x2goServer dans les containers) peuvent suffire depuis un PC.

Ce serait bien de prendre les dernières versions des logiciels; ce serait bien de faire çà aussi pour la distribution: Ubuntu Xenial par exemple depuis le template download. Mais il faut tenir compte des contraintes sur le NAS et son noyau Linux (c'est lui qui tourne dans les containers) et de son système.

On s'appuiera ici sur Ubuntu Trusty (comme le VHS) ou Debian Wheezy… par regardé les Arch-linux et autre Centos disponibles aussi

Commençons par MariaDB. Le site suivant fournit un moyen simple de définir le dépôt et les commandes d'installation associées en fonction de choix (distribution, version, etc…): https://downloads.mariadb.org/mariadb/repositories. Dans le script plus loin, le choix correspond à l'écran ci-dessous:

La création du container lxc-mariadb s'appuie donc sur les deux scripts ci-dessous, qu'on va déposer tous les deux sur le NAS et selon nos conventions, là: /mnt/data/data/users/admin/prive/scripts-lxc/lxc-mariadb. La mise en œuvre est décrite ensuite:

lxc-mariadb-creat.sh

#!/bin/bash
# A lancer avec "sudo -E ./lxc-mariadb-creat.sh <user> <password>"
 
# On créé le container avec un nom un peu parlant:
echo -e "==> Création du container ..."
lxc-create -n lxc-mariadb -t $LXC_TEMPLATE/lxc-ubuntu -P $LXC_PATH
 
echo -e "\n==> Mise à niveau comptes ...usr $1 - pwd: $2"
# Créer le compte <user> avec son répertoire ''home/<user>''
chroot $LXC_PATH/lxc-mariadb/rootfs useradd --create-home -s /bin/bash $1
# Lui donner un mot de passe
echo "$1:$2" | chroot $LXC_PATH/lxc-mariadb/rootfs chpasswd
# l'affecter au groupe ''sudo''
chroot $LXC_PATH/lxc-mariadb/rootfs adduser $1 sudo
# Supprimer le compte de contruction
chroot $LXC_PATH/lxc-mariadb/rootfs userdel -r ubuntu
 
# Modifier la config réseau par défaut: interface NAS plutôt que bridge dnsmasq
# Adaptation bridge = Interface réseau du NAS à la place de celle de LXC
#sed -i "s/lxc.network.link = lxcbr0/lxc.network.link = br0/g" $LXC_PATH/lxc-mariadb/config
 
echo -e "\n==> Préparation installations ..."
# Installation mariadb; Demande / définition du mot de passe root en cours de route
chroot $LXC_PATH/lxc-mariadb/rootfs apt-get update
chroot $LXC_PATH/lxc-mariadb/rootfs apt-get install -y software-properties-common nano
chroot $LXC_PATH/lxc-mariadb/rootfs apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943db
chroot $LXC_PATH/lxc-mariadb/rootfs add-apt-repository 'deb http://ftp.igh.cnrs.fr/pub/mariadb/repo/10.1/ubuntu trusty main'
chroot $LXC_PATH/lxc-mariadb/rootfs apt-get update
#chroot $LXC_PATH/lxc-mariadb/rootfs apt-get install mariadb-server
 
# Pas trouvé pourquoi l'installation de MariaDB n'est opérationnelle qu'à l'interieur du container
# Donc copie d'un script de finalisation et lancement / login
cp finalize_mariadb.sh $LXC_PATH/lxc-mariadb/rootfs/home/cram28/finalize_mariadb.sh
chroot $LXC_PATH/lxc-mariadb/rootfs sudo chmod +x /home/cram28/finalize_mariadb.sh
 
# Démarrer Mariadb en tâche de fond...
lxc-start -n lxc-mariadb -P $LXC_PATH -d
 
# Connexion au container
echo -e "\n==> On bascule dans le container: login avec $1 / $2 ..."
echo -e "\n... Dans le container, après le login, taper <<sudo -E ./finalize_mariadb.sh>>"
lxc-attach -n lxc-mariadb -P $LXC_PATH login

Et le second, destiné au container lui-même pour finaliser l'installation:

finalize_mariadb.sh

#!/bin/bash
# A lancer avec "sudo -E ./finalize_mariadb
 
apt-get install mariadb-server -y
 
# Permettre les connexion à mariadb depuis le réseau
#sed -i -r 's/bind-address.*$/bind-address = 0.0.0.0/' $LXC_PATH/lxc-mariadb/rootfs/etc/mysql/my.cnf
sed -i 's/^\(bind-address\s.*\)/# \1/' /etc/mysql/my.cnf
# On redémarre pour prise en compte
service mysql restart
 
echo -e "\n==>Mot de passe root de l'installation MariaDB - Création d'un utilisateur <<de travaille>>..."
# On se crée un utilisateur «pour travailler» et ayant des droits réseaux (''%'')
# adpater le fichier en entrée si changements ... Souvenez-vous de mot de passe ''root'' de l'installation...
mysql -u root -p << EOF
GRANT ALL privileges ON *.* TO 'remoteAdmin'@'%' IDENTIFIED BY 'remoteAdmin' WITH GRANT OPTION;
FLUSH privileges;
EOF
 
echo -e "\n==> Terminé. Container lxc-mariadb créé avec un compte de travail..."
exit

• On se positionne dans notre répertoire et on crée un dossier lxc-mariadb:

admin@sesame:~$ cd prive/scripts-lxc/
admin@sesame:~/prive/scripts-lxc$ mkdir lxc-mariadb
admin@sesame:~/prive/scripts-lxc$ cd lxc-mariadb
admin@sesame:~/prive/scripts-lxc/lxc-mariadb$ _

• On dépose les deux scripts ci-dessus, via un moyen à notre convenance: filezilla, explorateur, etc…

• On rend le script de création exécutable s'il ne l'est pas déjà:

admin@sesame:~/prive/scripts-lxc/lxc-mariadb$ chmod +x lxc-mariadb-creat.sh

• On peut ajuster le contenu du second script qui défini un utilisateur sur MariaDB (ici usr: remoteAdmin - pwd: remoteAdmin) en adaptant la ligne 16 dans finalize_mariadb.sh

• On exécute avec la commande ci-dessous.
  Deux paramètres : le compte et son mot de passe du container lxc-mariadb.
  

admin@sesame:~/prive/scripts-lxc/lxc-mariadb$ sudo -E ./lxc-mariadb-creat.sh <user> <password>

Le script mouline − c'est le premier, les suivants vont utiliser le cache − pas mal en allant chercher des mises à jours et en installant quelques paquets dans notre container. Il faut surveiller quand-même: on se connecte directement dans le container via un login… qui attend 60 secondes et sort…

.....
Fetched 8,793 B in 42s (207 B/s)
Reading package lists... Done

==> On bascule dans le container: login avec <user> / <password> ...
... Dans le container, après le login, taper <<sudo -E ./finalize_mariadb.sh>>
lxc-mariadb login: 

• Lorsque vous avez cet écran, taper les <user> puis <password> qui sont rappelés.
  

Une fois dans le container, l'installation proprement dite de MariaDB est lancée pas trouvé pourquoi çà marche pas depuis l'extérieur, sombre histoire de socket il me semble….

• Si vous avez raté le coche, vous êtes revenu sur le NAS. Il suffit de s'y re-loguer, et d'exécuter la commande indiquée:

Login timed out after 60 seconds.
admin@sesame:~/prive/scripts-lxc/lxc-mariadb$ sudo lxc-attach -n lxc-mariadb -P $LXC_PATH login
[sudo] password for admin: ===> çà c'est l'admin du VHS
lxc-mariadb login: ===> le login du container <user>
Password: ===> le mot de passe du container <password>
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.16.0-31-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

cram28@lxc-mariadb:~$ sudo ./finalize_mariadb.sh
[sudo] password for <user>: ===> <password> du container, puisque <user> à des droits sudo
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
...

• En cours d'installation, il faudra saisir − deux fois − un mot de passe pour l'utilisateur root de MariaDB :

• L'installation se termine enfin par la définition d'un utilisateur «de travail» avec des droits réseau. Pour le faire, on a à nouveau besoin du mot de passe root de MariaDB défini juste au-dessus:

Setting up mariadb-server (10.1.21+maria-1~trusty) ...
Processing triggers for libc-bin (2.19-0ubuntu6.9) ...
 * Stopping MariaDB database server mysqld                          [ OK ] 
 * Starting MariaDB database server mysqld                          [ OK ] 
 * Checking for corrupt, not cleanly closed and upgrade needing tables.

==>Mot de passe root de l'installation MariaDB - Création d'un utilisateur <<de travaille>>...
Enter password: 

==> Terminé. Container lxc-mariadb créé avec un compte de travail...
cram28@lxc-mariadb:~$ 

Ouf… Le script ne sort tout seul du container: tapez exit pour sortir du container, sans l'arrêter.

• Liste des containers:

admin@sesame:~/prive/scripts-lxc/lxc-mariadb$ sudo lxc-ls -f -P $LXC_PATH 
[sudo] password for admin: 
NAME         STATE    IPV4       IPV6  AUTOSTART  
------------------------------------------------
lxc-mariadb  RUNNING  10.0.3.2  -     NO         
admin@sesame:~/prive/scripts-lxc/lxc-mariadb$ 

• Des infos:

admin@sesame:~/prive/scripts-lxc/lxc-mariadb$ sudo lxc-info -n lxc-mariadb -P $LXC_PATH
Name:           lxc-mariadb
State:          RUNNING
PID:            21670
IP:             10.0.3.37
CPU use:        9.04 seconds
Memory use:     460.74 MiB
KMem use:       0 bytes
Link:           vethSFD1LO
 TX bytes:      321.42 KiB
 RX bytes:      22.80 MiB
 Total bytes:   23.11 MiB
admin@sesame:~/prive/scripts-lxc/lxc-mariadb$ 

• L'arrêter, le (re)lancer − -d important, sinon autre terminal pour l’arrêter − s'y connecter:

sudo lxc-stop -n lxc-mariadb -P $LXC_PATH 
sudo lxc-start -n lxc-mariadb -P $LXC_PATH -d
sudo lxc-attach -n lxc-mariadb -P $LXC_PATH login
lxc-mariadb login: 

On se servira de ce container plus loin… Mais depuis l'intérieur du container çà le fait déjà, en se connectant au moteur MariaDB avec le compte de travail défini ici : u et mot de passe p en remoteAdmin:

admin@sesame:~/prive/scripts-lxc/lxc-mariadb$ sudo lxc-attach -n lxc-mariadb -P $LXC_PATH login cram28
Password: 
Last login: Fri Mar 24 20:18:32 CET 2017 on UNKNOWN
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.16.0-31-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

cram28@lxc-mariadb:~$ mysql -uremoteAdmin -premoteAdmin
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 33
Server version: 10.1.22-MariaDB-1~trusty mariadb.org binary distribution

Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
+--------------------+
3 rows in set (0.00 sec)

MariaDB [(none)]> quit
Bye
cram28@lxc-mariadb:~$ logout
admin@sesame:~/prive/scripts-lxc/lxc-mariadb$

Pour la localisation des tables de données de MariaDB, on pourrait envisager de les stockées directement dans un répertoire du NAS plutôt que dans le container: à la réflexion, quel est l'intérêt, le système de fichiers du container est déjà sur le serveur …?

On propose ici deux containers qui embarquent un serveur http.

Allez, un p'tit package pour une installation «sans y penser»: lxc-pma.zip

A vous de potasser le contenu… un peu commenté. Il y a trois fichiers:

• lxc-pma_creat.sh: Le script de création; il sera plus rapide, en exploitant le cache construit pour le container précédent et dans $LXC_PATH/cache.
• default est le fichier de configuration pour le serveur http NGinx
• config.inc.php: la configuration de PhpMyAdmin

Les deux derniers fichiers sont copiés dans le container par le script de création.

Les 3 fichiers (après décompression) sont donc à placer sous /mnt/data/data/users/admin/prive/scripts-lxc/lxc-phpmyadmin sur le VHS, via un moyen à votre convenance.

En principe la caractéristique “exécutable” du script de création doit être conservée. Si ce n'était pas le cas, appliquez la commande suivante, depuis le dossier cible:

admin@sesame:~/prive/scripts-lxc/lxc-pma$ chmod +x lxc-pma_creat.sh 

Comme indiqué si vous lancez le script sans paramètre, il y a des pré-requis:

• L'environnement LXC doit avoir été défini
• Le container lxc-mariadb doit être installé; il peut ne pas tourner, le script le lancera
• L'aide du script indique les paramètres nécessaires:
  • <user> et <password> su container lxc-pma
  • <compte> et <mot de passe> de l'«utilisateur de travail» de lxc-mariadb

Si tout se passe bien à l'issue, vous avez vos deux container lxc-mariadb et lxc-pma qui sont opérationnels et tournent … mais qui sont isolés. On est ici dans le cas du schéma réseau du § 3.1:

• Le service#2 est MariaDB et il est isolé
• Le service#1 est phpMyAdmin et pour l'instant il est encore isolé

En attendant de définir un script un peu plus … «chiadé», la commande suivante va permettre d'exposer un port du container lxc-pma sur le LAN:

sudo iptables -t nat -A PREROUTING -p tcp -i <interfaceNAS> --dport <portExposé> -j DNAT --to-destination <adresseServiceAExposer>:<PortDuService>

avec:
<interfaceNAS>           : c'est ''br0'' sur le VHS
<portExposé>             : un port libre du VHS
<adresseServiceAExposer> : adresse du container en 10.0.3.x
<PortDuService>          : port sur service; ici service web du PhpMyAdmin en ''80''

L'adresse du container lxc-pma est donnée par la commande sudo lxc-ls -f -P $LXC_PATH Par exemple, ici:

NAME         STATE    IPV4       IPV6  AUTOSTART  
------------------------------------------------
lxc-mariadb  RUNNING  10.0.3.2   -     NO         
lxc-pma      RUNNING  10.0.3.59  -     NO         

Notre commande d'exposition pourrait ainsi être la suivante:

sudo iptables -t nat -A PREROUTING -p tcp -i br0 --dport 60080 -j DNAT --to-destination 10.0.3.59:80

Pour stopper l'exposition (D comme delete remplace A comme append):

sudo iptables -t nat -D PREROUTING -p tcp -i br0 --dport 60080 -j DNAT --to-destination 10.0.3.59:80

Et là, tadam… (login avec le compte de travail remoteAdmin)

Et quelque notes qui surlignent les versions installées:

Sonerezh est un player audio web permettant de jouer sa discothèque via une présentation sympa. Il restitue le son, à partir de pistes aux formats MP3/OGG, mais aussi AAC ou FLAC qu'il converti en MP3/OGG via la librairie libav-tools. Le FLAC en 24 bits n'est cependant pas supporté, hélas !
ou je n'ai pas trouvé…

Sonerezh se présente sous la forme d'un site web qui fonctionne sous apache/nginx-php avec un SGBD comme MySQL ou MariaDB (qu'on a déjà, soit sur le NAS pour MySQL, soit dans le container précédent qu'on va donc utiliser ici).

On va s'installer Sonerezh dans un container LXC en s'inspirant – très beaucoup – de son image Docker proposée par les développeurs du logiciel. On pourra ainsi comparer…

Ce paragraphe concerne les containers avec environnement de bureau.

Le paquet joint lxc-x11vnc.zip contient deux scripts:

• un pour construire un container lxc-x11vnc avec «à-l'intérieur-dedans»:
  • une distribution minimale: Debian Wheezy
  • un système X graphique léger: Xvfb
  • un gestionnaire de fenêtres poids plume: fluxbox
  • un serveur VNC pour atteindre notre container via le réseau: x11vnc
• un autre script, destiné au container lui-même, pour lancer tout ce petit monde au démarrage de lxc-x11vnc.

Ces scripts sont commentés pour en comprendre l'objet et le procédé. Là encore, c'est une proposition, il est certain qu'on peut faire mieux !

Dézippez le package sur votre PC et déposez-le dans un dossier sur le répertoire qui va bien sur le VHS: /mnt/data/data/users/admin/prive/scripts-lxc selon les «conventions» proposées.

Positionnez-vous dans le répertoire et rendez le premier script de création exécutable:

admin@sesame:~/prive/scripts-lxc/lxc-x11vnc$ chmod +x lxc-x11vnc_creat.sh

Le script se lance avec des privilèges et des paramètres. La commande

admin@sesame:~/prive/scripts-lxc/lxc-x11vnc$ ./lxc-x11vnc_creat.sh

vous dira tout…

Par exemple, une suite de commandes pour rendre le tout opérationnel:

sudo -E ./lxc-x11vnc_creat.sh -u toto -p motdepassedetoto

Quand la création du container est achevée, il n'y a qu'à appliquer :

☛ Fin du script de création

....
....
Processing triggers for menu ...
Adding user `cram28' to group `sudo' ...
Adding user cram28 to group sudo
Done.
********************************************************************
*** Configurations & mise en oeuvre dans lxc-x11vnc ...       ***
********************************************************************
update-rc.d: using dependency based boot sequencing
********************************************************************
Création Terminée
lxc-x11vnc est atteignable via un client VNC (pas de mot de passe).

Utiliser la commande suivante pour en autoriser l'accès sur votre réseau:
	 sudo iptables -t nat -A PREROUTING -p tcp -i br0 --dport xxxxx -j DNAT --to-destination 10.0.3.yyy:5900 

Utiliser la commande suivante pour en interdire l'accès sur votre réseau:
	 sudo iptables -t nat -D PREROUTING -p tcp -i br0 --dport xxxxx -j DNAT --to-destination 10.0.3.yyy:5900 

xxxxx: port exposé sur l'hôte (ex. 55900) - yyy: morceau final de l'adresse du container (obtenu avec 'sudo lxc-ls -f -P $LXC_PATH)'.
NB: l'interface réseau br0' est propre au NAS; si le container tourne dans une VM par exemple, placer 'eth0'.

☛ Donc on lance le container

$ sudo lxc-start -n lxc-x11vnc -P $LXC_PATH -d

☛ On exécute la commande suivante (l'adresse ne vient pas tout de suite)

$ sudo lxc-ls -f -P $LXC_PATH 
NAME          STATE    IPV4       IPV6  AUTOSTART  
-------------------------------------------------
lxc-mariadb   RUNNING  10.0.3.2   -     NO         
lxc-pma       RUNNING  10.0.3.59  -     NO         
lxc-sonerezh  RUNNING  10.0.3.55  -     NO         
lxc-x11vnc    RUNNING  -          -     NO         

☛ Re… jusqu'à obtenir une adresse

$ sudo lxc-ls -f -P $LXC_PATH 
NAME          STATE    IPV4       IPV6  AUTOSTART  
-------------------------------------------------
lxc-mariadb   RUNNING  10.0.3.2   -     NO         
lxc-pma       RUNNING  10.0.3.59  -     NO         
lxc-sonerezh  RUNNING  10.0.3.55  -     NO         
lxc-x11vnc    RUNNING  10.0.3.66  -     NO         

☛ On ouvre les accès réseau

$ sudo iptables -t nat -A PREROUTING -p tcp -i br0 --dport 55900 -j DNAT --to-destination 10.0.3.66:5900

☛ On vérifie que c'est bon

$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A PREROUTING -i br0 -p tcp -m tcp --dport 60080 -j DNAT --to-destination 10.0.3.59:80
-A PREROUTING -i br0 -p tcp -m tcp --dport 55900 -j DNAT --to-destination 10.0.3.66:5900
-A POSTROUTING -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
-A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE

$ 

On a un container, exposé sur le LAN, qui écoute sur le port 5900 (serveur VNC). En attendant ce que donnera Guacamole, on peut utiliser un client VNC, ici Remmina qu'il faut donc configurer en VNC sur le VHS et le port exposé:

Et là, magie:

On peut même s'amuser à installer un logiciel via la commande sudo apt-get install <paquet> dans un terminal click droit, “Application / Terminal Emulators / XTerm” (on peut le faire, l'utilisateur a des privilèges via sudo); Gedit ici est installé (sudo apt-get install gedit):

Vue le nombre de librairies installées pour ce simple éditeur de texte Gedit on peut se rejouir: Notre container est vraiment léger …

Ce container n'est pas vraiment destiné à servir ici: il constitue une base pour de futures utilisations, on va plutôt le cloner plus loin…

Le container proposé ici est destiné à faire tourner le logiciel JDownloader, outil de téléchargement assez … «doué». Outre cet aspect, l'intérêt de faire tourner un tel outil sur le serveur VHS est essentiellement de l'avoir en permanence à disposition - en particulier quand le serveur VHS fonctionne tout le temps et qu'on a des soucis de quota sur internet …

Mais l'inconvénient majeur: JDownloader – la jvm plutôt – consomme mémoire et CPU …

Le paquet joint lxc-jdownloader.zip est à extraire dans prive/scripts-lxc/ du compte admin sur le VHS. Il contient:

• le script lxc-JDownloader_creat_v1.1.sh de création du container et de sa «préparation» (cf. plus loin)
• le script service-JDownloader qu'on positionne de façon telle qu'il est exécuté au démarrage du container.

Il faut commencer par télécharger deux outils indispensables au fonctionnement:

☛ JDownloader est écrit en Java: il faut donc disposer d'un «Java Runtime Environnement» (JRE). Mais le script d'installation ci-dessous embarque ce qu'il faut …

☛ Le script d'installation de JDownloader qu'on trouve derrière ce lien: http://installer.jdownloader.org/JD2SilentSetup_x64.sh.

Positionnez ce fichier téléchargé – JD2SilentSetup_x64.sh – dans le même répertoire que les scripts (le chemin absolu sur le NAS est /mnt/data/data/users/admin/prive/scripts-lxc/lxc-JDownloader).

• Loguez-vous en ssh et positionnez-vous dans ce même répertoire. Vérifiez la présence des fichiers :

admin@sesame:~/prive/scripts-lxc/lxc-JDownloader$ ls -l
total 102848
-rwxr-xr-x 1 admin users 50621986 Apr 17 12:05 JD2SilentSetup_x64.sh
-rwxrwxrwx 1 admin users     8451 Apr 17 12:04 lxc-JDownloader_creat_v1.1.sh
-rwxrwxrwx 1 admin users      933 Apr 17 12:04 service-JDownloader
admin@sesame:~/prive/scripts-lxc/lxc-JDownloader$ 

• Si le script de création n'est pas exécutable, rendez-le tel via la commande :

chmod +x lxc-JDownloader_creat_v1.1.sh 

• Lancez le script de création/préparation du container, sans paramètre pour obtenir un p'tit baratin explicatif :

admin@sesame:~/prive/scripts-lxc/lxc-JDownloader$ ./lxc-JDownloader_creat_v1.1.sh

• Et donc lancez un truc qui va bien, genre:

sudo -E ./lxc-JDownloader_creat_v1.1.sh -u cram28 -p pwd_cram28 -e 10001

qui permet la création du container lxc-JDownloader avec le compte avec privilège cram28 , et qui va lancer le container et «nater» sont port VNC 5900 sur le port 10001 de son hôte.

☛ Le script va donc mouliner pas mal:

• Création du container LXC, sur la base du template lxc-download et la distribution Debian Wheezy (peut-être rapide si déjà présente en cache);
• Installation de l'environnement graphique et réseau
• Création du compte passé en paramètre, avec privilèges (sudo)
• Copie des scripts d'installation de JDownloder et d'initialisation des services au démarrage
• Au cours de ces traitements, il vous sera demandé de définir fuseau horaire et langue(s) - 2 écrans chaque fois (ici choix de langues):

• Update, Upgrade de la distribution du container
• Installation en mode silencieux et hors de l'IHM graphique pas réussie/trouvée… En conséquence, l'installation proprement dite de JDownloder va se faire dans le container lui-même, via une connexion réseau en VNC (en attendant Guacamole…)
• Pour ce faire, le script de création va lancer le container, récupérer l'adresse IP qui lui est attribuée par dnsmasq en 10.0.3.xxx et ouvrir l'accès VNC du container sur le réseau de son hôte; ainsi, lorsque le script se termine, la connexion au container pour «finir le boulot» est facilitée via votre client VNC préféré
• Une fois connecté, le script vous a dit quoi faire:
  • ouvrir un terminal (clic droit souris pour ouvrir le menu contextuel)

• se positionner dans le répertoire maison de notre utilisateur: cd ~
• lancer le script d'installation de JDownloader: ./JD2SilentSetup_x64.sh

• les étapes (de gauche à droite): Sur la 4ième, ne pas changer le chemin, il est utiliser dans la définition du service – ou alors, adaptez…

Ça fonctionne tout pareil que sur votre poste en local…

Ci-dessous, quelques rubriques: Informations et manip. … faites avant/pendant pour tests…

Le but du jeu est de voir si on peut reproduire, dans une VM, la configuration de containers LXC présente apparemment sur le VHS, afin de voir si on peut l'utiliser sur la VM afin de voir si on pourrait faire de même sur le VHS … afin de voir quoi ! ……

Ce serait bien en effet…

Pour ces manipulations, on a donc une VM moka - qu'on a déjà créée là : une Ubuntu trusty 14.04.5 (le VHS étant, lui en version 14.04.2 avec le firmware 6.1.3…).

Basique …

admin@moka:~$ sudo apt-get install lxc

On reboot la VM pour prise en compte. L'installation - au moins sous Ubuntu - intègre un serveur DNS/DHCP afin de gérer les adresses IP des containers ainsi créés.

A la prochaine connexion, on a une définition réseau supplémentaire lxcbr0: 10.0.3.1 (ici, on a aussi une définition pour Docker, car il est installé sur la VM):

cram28@paprika ~ $ ssh admin@moka
...
...
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 4.4.0-62-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Sat Feb 18 09:10:02 CET 2017

  System load:  0.23               Users logged in:        0
  Usage of /:   11.2% of 97.32GB   IP address for eth0:    192.168.1.4
  Memory usage: 6%                 >>>> IP address for lxcbr0:  10.0.3.1 <<<<
  Swap usage:   0%                 IP address for docker0: 172.17.0.1
  Processes:    149
...
...

admin@moka:~$ 

On est donc - a priori - dans la même situation que le VHS…

Sur le VHS sesame, le process DNS/DHCP (basé sur l'outil dnsmasq qu'on retrouve sur plein de routeurs d'ailleurs) à la commande suivante:

admin@sesame:~$ sudo ps -aux | grep lxc
lxc-dns+  1658  0.0  0.0  28212  2288 ?        S    Feb12   0:00 dnsmasq -u lxc-dnsmasq --strict-order --bind-interfaces --pid-file=/run/lxc/dnsmasq.pid --conf-file= --listen-address 10.0.3.1 --dhcp-range 10.0.3.2,10.0.3.254 --dhcp-lease-max=253 --dhcp-no-override --except-interface=lo --interface=lxcbr0 --dhcp-leasefile=/var/lib/misc/dnsmasq.lxcbr0.leases --dhcp-authoritative
admin@sesame:~$ 

Sur la VM moka:

admin@moka:~$ sudo ps -aux | grep lxc
lxc-dns+  1427  0.0  0.1  28208  2184 ?        S    09:09   0:00 dnsmasq -u lxc-dnsmasq --strict-order --bind-interfaces --pid-file=/run/lxc/dnsmasq.pid --conf-file= --listen-address 10.0.3.1 --dhcp-range 10.0.3.2,10.0.3.254 --dhcp-lease-max=253 --dhcp-no-override --except-interface=lo --interface=lxcbr0 --dhcp-leasefile=/var/lib/misc/dnsmasq.lxcbr0.leases --dhcp-authoritative
admin@moka:~$ 

Donc tout pareil, c'est bon signe

On va - toujours sur la VM - créer un premier container qui s'appuie sur le «modèle» ubuntu (-t pour template)

• On le créé (en l'appelant ubuntu01):

admin@moka:~$ sudo lxc-create -n ubuntu01 -t ubuntu 
Checking cache download in /var/cache/lxc/trusty/rootfs-amd64 ... 
Installing packages in template: ssh,vim,language-pack-en
Downloading ubuntu trusty minimal ...
I: Retrieving Release 
I: Retrieving Release.gpg 
...
...
 >>> il bosse <<<
...
Copy /var/cache/lxc/trusty/rootfs-amd64 to /var/lib/lxc/ubuntu01/rootfs ... 
Copying rootfs to /var/lib/lxc/ubuntu01/rootfs ...
Generating locales...
  en_US.UTF-8... up-to-date
Generation complete.
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
Creating SSH2 ECDSA key; this may take some time ...
Creating SSH2 ED25519 key; this may take some time ...
update-rc.d: warning: default stop runlevel arguments (0 1 6) do not match ssh Default-Stop values (none)
invoke-rc.d: policy-rc.d denied execution of start.

Current default time zone: 'Europe/Paris'
Local time is now:      Sat Feb 18 18:27:48 CET 2017.
Universal Time is now:  Sat Feb 18 17:27:48 UTC 2017.


##
# The default user is 'ubuntu' with password 'ubuntu'!
# Use the 'sudo' command to run tasks as root in the container.
##

admin@moka:~$ 

D'accord, faudra changer le mot de passe ubuntu … un peu «facile» il est vrai !

• Dans quel état qu'il est le container ?

admin@moka:~$ sudo lxc-info -n ubuntu01
Name:           ubuntu01
State:          STOPPED
admin@moka:~$ 

• Et qu'est-ce donc qu'il a créé ?

admin@moka:~$ sudo ls -aln /var/lib/lxc/ubuntu01
total 16
drwxrwx---  3 0 0 4096 Feb 18 18:27 .
drwx------  4 0 0 4096 Feb 18 18:09 ..
-rw-r--r--  1 0 0  559 Feb 18 18:27 config
-rw-r--r--  1 0 0    0 Feb 18 18:27 fstab
drwxr-xr-x 21 0 0 4096 Feb 18 18:33 rootfs
admin@moka:~$ 

• config est le fichier de configuration du container
• fstab bah, l'est vide… Il est destiné à recevoir les définitions des montages depuis le container vers son hôte.
• rootfs est un répertoire; c'est le système de fichier du container:

admin@moka:~$ sudo ls -aln /var/lib/lxc/ubuntu01/rootfs
total 84
drwxr-xr-x 21 0 0 4096 Feb 18 18:21 .
drwxrwx---  3 0 0 4096 Feb 18 18:27 ..
drwxr-xr-x  2 0 0 4096 Feb 18 18:27 bin
drwxr-xr-x  2 0 0 4096 Apr 11  2014 boot
drwxr-xr-x  3 0 0 4096 Feb 18 18:19 dev
drwxr-xr-x 64 0 0 4096 Feb 18 18:27 etc
drwxr-xr-x  3 0 0 4096 Feb 18 18:27 home
drwxr-xr-x 12 0 0 4096 Feb 18 18:26 lib
drwxr-xr-x  2 0 0 4096 Feb 18 18:25 lib64
drwxr-xr-x  2 0 0 4096 Feb 18 18:17 media
drwxr-xr-x  2 0 0 4096 Apr 11  2014 mnt
drwxr-xr-x  2 0 0 4096 Feb 18 18:17 opt
drwxr-xr-x  2 0 0 4096 Apr 11  2014 proc
drwx------  2 0 0 4096 Feb 18 18:17 root
drwxr-xr-x  7 0 0 4096 Feb 18 18:20 run
drwxr-xr-x  2 0 0 4096 Feb 18 18:27 sbin
drwxr-xr-x  2 0 0 4096 Feb 18 18:17 srv
drwxr-xr-x  2 0 0 4096 Mar 13  2014 sys
drwxrwxrwt  2 0 0 4096 Feb 18 18:25 tmp
drwxr-xr-x 10 0 0 4096 Feb 18 18:17 usr
drwxr-xr-x 11 0 0 4096 Feb 18 18:17 var
admin@moka:~$ 

• On lance le container (en tache de fond: -d):

admin@moka:~$ sudo lxc-start -n ubuntu01 -d

• On vérifie qu'il tourne (il a même une adresse, dis-donc !):

admin@moka:~$ sudo lxc-ls -f
NAME      STATE    IPV4        IPV6  AUTOSTART  
----------------------------------------------
ubuntu01  RUNNING  10.0.3.179  -     NO         
admin@moka:~$ 

• On s'y connecte:

admin@moka:~$ sudo lxc-attach -n ubuntu01
root@ubuntu01:/# ls -aln
total 72
drwxr-xr-x  21 0 0 4096 Feb 18 18:33 .
drwxr-xr-x  21 0 0 4096 Feb 18 18:33 ..
drwxr-xr-x   2 0 0 4096 Feb 18 18:27 bin
drwxr-xr-x   2 0 0 4096 Apr 11  2014 boot
drwxr-xr-x   4 0 0 4096 Feb 18 18:33 dev
drwxr-xr-x  64 0 0 4096 Feb 18 18:33 etc
drwxr-xr-x   3 0 0 4096 Feb 18 18:27 home
drwxr-xr-x  12 0 0 4096 Feb 18 18:26 lib
drwxr-xr-x   2 0 0 4096 Feb 18 18:25 lib64
drwxr-xr-x   2 0 0 4096 Feb 18 18:17 media
drwxr-xr-x   2 0 0 4096 Apr 11  2014 mnt
drwxr-xr-x   2 0 0 4096 Feb 18 18:17 opt
dr-xr-xr-x 175 0 0    0 Feb 18 18:33 proc
drwx------   2 0 0 4096 Feb 18 18:17 root
drwxr-xr-x  10 0 0  420 Feb 18 18:33 run
drwxr-xr-x   2 0 0 4096 Feb 18 18:27 sbin
drwxr-xr-x   2 0 0 4096 Feb 18 18:17 srv
dr-xr-xr-x  13 0 0    0 Feb 18 17:25 sys
drwxrwxrwt   2 0 0 4096 Feb 18 18:25 tmp
drwxr-xr-x  10 0 0 4096 Feb 18 18:17 usr
drwxr-xr-x  11 0 0 4096 Feb 18 18:17 var
root@ubuntu01:/# 

• Il a les mêmes versions que son hôte (i.e la VM). Pour la distribution…

root@ubuntu01:/# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04.5 LTS
Release:	14.04
Codename:	trusty

• … et pour le noyau Linux:

root@ubuntu01:/# uname -a
Linux ubuntu01 4.4.0-62-generic #83~14.04.1-Ubuntu SMP Wed Jan 18 18:10:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

• Il a un p'tit nom

root@ubuntu01:/# cat /etc/hostname 
ubuntu01

root@ubuntu01:/# cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   ubuntu01
# 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

• Il a une config réseau (MAC, @IP):

root@ubuntu01:/# ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:16:3e:65:19:30  
          inet addr:10.0.3.179  Bcast:10.0.3.255  Mask:255.255.255.0
          inet6 addr: fe80::216:3eff:fe65:1930/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:60 errors:0 dropped:0 overruns:0 frame:0
          TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:5847 (5.8 KB)  TX bytes:5012 (5.0 KB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

• On peut sortir

root@ubuntu01:/# exit
exit
admin@moka:~$ 

• L'installation embarque un serveur ssh (mot de passe ubuntu comme indiqué).
  Donc, depuis l'hôte :

admin@moka:~$ ssh ubuntu@10.0.3.179
The authenticity of host '10.0.3.179 (10.0.3.179)' can't be established.
ECDSA key fingerprint is xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.3.179' (ECDSA) to the list of known hosts.
ubuntu@10.0.3.179's password: 
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 4.4.0-62-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

ubuntu@ubuntu01:~$ pwd
/home/ubuntu
ubuntu@ubuntu01:~$ logout
Connection to 10.0.3.179 closed.
admin@moka:~$ 

Bon, bien … On va tenter d'aller plus loin.

Le «sous-réseau» en 10.0.3.x que fabrique LXC n'est connu que de l'hôte. Celà signifie que le container ubuntu01 qu'on a crée plus haut et qui a obtenu l'adresse 10.0.3.179 ne peut pas être atteint directement par une autre machine du réseau local: un ping 10.0.3.179 ne répond pas depuis paprika par exemple.

Si l'on défini, sur la box / le routeur, une route statique qui dit: «lorsque tu vois une adresse en 10.0.3.*, tu l’envoies vers la machine qui saura quoi en faire», alors çà marche.

Sur un routeur équipé du firmware Tomato ici, on lui dit d'ajouter une route statique du genre :

• Réseau de destination : 10.0.3.0/24
• Passerelle : @IP de l'hôte

A partir de là, on peut atteindre notre container LXC depuis n'importe quelle machine du réseau local.

Ici, depuis un terminal (ou PuTTY):

cram28@paprika ~ $ ssh ubuntu@10.0.3.179
The authenticity of host '10.0.3.179 (10.0.3.179)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxx
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.3.179' (ECDSA) to the list of known hosts.
ubuntu@10.0.3.179's password: 
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 4.4.0-62-generic x86_64)

 * Documentation:  https://help.ubuntu.com/
Last login: Sat Feb 18 21:20:29 2017 from 10.0.3.1
ubuntu@ubuntu01:~$ 

On sait que la distribution ubuntu est «livrée» avec un serveur ssh et un serveur sftp ( openssh-sftp-server x.x ). Donc cela fonctionne aussi depuis l'explorateur d'un poste du réseau (qui supporte sftp, bien sûr):

Cool…

Glupss.. Bon, au pire en fait un reboot non destructif… Au pire du pire, réinstallation complète depuis la clé USB externe avec la v 6.0.0 dessus …

Allez, courage …

Selon la formule consacrée:

C'est fait …

• On se connecte au serveur VHS

ssh admin@sesame

• Création du container, base ubuntu:

sudo lxc-create -n lxcubuntu00 -t ubuntu

...

Generation complete.
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
Creating SSH2 ECDSA key; this may take some time ...
Creating SSH2 ED25519 key; this may take some time ...
update-rc.d: warning: default stop runlevel arguments (0 1 6) do not match ssh Default-Stop values (none)
invoke-rc.d: policy-rc.d denied execution of start.

Current default time zone: 'Europe/Paris'
Local time is now:      Sun Feb 19 10:15:25 CET 2017.
Universal Time is now:  Sun Feb 19 09:15:25 UTC 2017.


##
# The default user is 'ubuntu' with password 'ubuntu'!
# Use the 'sudo' command to run tasks as root in the container.
##

admin@sesame:~$ 

• Infos dessus:

sudo lxc-info -n lxcubuntu00
Name:           lxcubuntu00
State:          STOPPED
admin@sesame:~$ 

• Démarrage en tâche de fond:

sudo lxc-start -n lxcubuntu00 -d

• Etat et @IP attribuée:

sudo lxc-ls -f
NAME         STATE    IPV4       IPV6  AUTOSTART  
------------------------------------------------
lxcubuntu00  RUNNING  10.0.3.79  -     NO         
admin@sesame:~$ 

On s'en va changer la route statique sur le Tomato: La cible est désormais le NAS.
(faudra changer sur la VM la config. du DHCP avec plage d'adresse en 10.0.4.* par exemple. Mais là, on peut bien faire c'qu'on veut s'en risque)

• Connexion ssh

ssh ubuntu@10.0.3.79

Et patatra ! Marche pô ! Heuuu Crotte alors !

Même les ping et ssh en local sur le serveur sont sans résultat: pare-feu et/ou iptable sur le NAS lui-même interdisent (ou n'autorisent pas) l'accès à cette adresse ?

Une piste ? un pro du réseau ?

Commençons par mariadb. On liste ci-dessous une série de commandes d'installation et de configuration.

On créé notre container, et quand la distribution sur laquelle il s'appuie est dans le cache, çà va très vite (simple copie):

admin@sesame:~$ cd $LXC_PATH
admin@sesame:~/partages/VM-LXC$ sudo lxc-create -n mariadb -t $LXC_TEMPLATE/lxc-ubuntu -P $LXC_PATH  

Checking cache download in /mnt/data/data/users/admin/partages/VM-LXC/cache/trusty/rootfs-amd64 ...   
Copy /mnt/data/data/users/admin/partages/VM-LXC/cache/trusty/rootfs-amd64 to /mnt/data/data/users/admin/partages/VM-LXC/mariadb/  rootfs ... 
Copying rootfs to /mnt/data/data/users/admin/partages/VM-LXC/mariadb/rootfs ...
Generating locales...
  en_US.UTF-8... up-to-date
Generation complete.
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
Creating SSH2 ECDSA key; this may take some time ...
Creating SSH2 ED25519 key; this may take some time ...
update-rc.d: warning: default stop runlevel arguments (0 1 6) do not match ssh Default-Stop values (none)
invoke-rc.d: policy-rc.d denied execution of start.

Current default time zone: 'Europe/Paris'
Local time is now:      Mon Feb 27 21:05:36 CET 2017.
Universal Time is now:  Mon Feb 27 20:05:36 UTC 2017.


##
# The default user is 'ubuntu' with password 'ubuntu'!
# Use the 'sudo' command to run tasks as root in the container.
##

admin@sesame:~/partages/VM-LXC$ 

Le nouveau container mariadb est bien là:

admin@sesame:~/partages/VM-LXC$ sudo lxc-ls -f -P $LXC_PATH
NAME     STATE    IPV4  IPV6  AUTOSTART  
---------------------------------------
mariadb  STOPPED  -     -     NO         
admin@sesame:~/partages/VM-LXC$ 

On s'empresse de s'ajouter un compte à nous; on supprimera le compte par défaut depuis l'intérieur du container. On a en effet deux moyens d'intervenir sur le container:

1. Le container fonctionne, on s'y logue et on réalise nos manip. de façon classique comme sur une «vraie» machine
2. On utilise la commande chroot (le container est éteint)

Création d'un compte avec droits (i.e. appartient au groupe sudo). Remplacez les mentions entre <> par vos données:

# Créer le compte <user> avec son répertoire ''home/<user>''
sudo chroot $LXC_PATH/mariadb/rootfs useradd --create-home -s /bin/bash <user>

# Lui donner un mot de passe
echo "<user>:<password>" | sudo chroot $LXC_PATH/mariadb/rootfs chpasswd

# l'affecter au groupe ''sudo''
sudo chroot $LXC_PATH/mariadb/rootfs adduser <user> sudo

On démarre le container, on s'y connecte et on y installe la version 10.1 de mariadb:

# Démarrage du container (en tâche de fond / mode démon: ''-d'' ):
sudo lxc-start -n mariadb -P $LXC_PATH -d

# On vérifie qu'il tourne
sudo lxc-ls -f -P $LXC_PATH

# On se connecte (en root)
sudo lxc-attach -n mariadb -P $LXC_PATH
root@mariadb:/#

# Ou bien avec un compte
sudo lxc-attach -n mariadb -P $LXC_PATH login
mariadb login: <user>
Password: 
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.16.0-31-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

<user>@mariadb:~$ 

Premières choses:

# on va s'empresser de supprimer le compte «de construction»
sudo userdel -r ubuntu
userdel: ubuntu mail spool (/var/mail/ubuntu) not found

# et de mettre à jour la distribution
sudo apt-get update

Une «solution de contournement» − en attendant mieux éventuellement − consiste à utiliser l'interface réseau du NAS plutôt que le bridge-pont dnsmasq mis en œuvre par défaut sur LCX dans un souci d'isolation réseau des containers (cf. le § sécurité).

Donc, on sort du container et on l'arrête avant de faire cette modification:

<user>@mariadb:~$ logout
admin@sesame:~/partages/VM-LXC$ sudo lxc-stop -n mariadb -P $LXC_PATH 

Éditons le fichier de configuration de notre container mariadb:

admin@sesame:~/partages/VM-LXC$ sudo nano mariadb/config
...  
# Network configuration
lxc.network.type = veth
lxc.network.flags = up

# Modif. 2017.02.28 - Utiliser l'interface réseau du VHS, plutôt que celle de LXC par défaut
#lxc.network.link = lxcbr0
lxc.network.link = br0
...

Après quoi, on relance notre container, on se re-logue, et … miracle:

admin@sesame:~/partages/VM-LXC$ sudo lxc-start -n mariadb -P $LXC_PATH -d

# On vérifie qu'il tourne ... avec une adresse sur notre réseau local maintenant
# (regarder les devise sur votre routeur: mariadb et @IP sont définis)
admin@sesame:~/partages/VM-LXC$ sudo lxc-ls -f -P $LXC_PATH

# On se connecte 
sudo lxc-attach -n mariadb -P $LXC_PATH login

# et on reprend...
sudo apt-get update

# et on s'installe l'éditeur ''nano'' (+simple que vi...)
sudo apt-get install nano

Maintenant, passons à l'installation de mariadb avec la série de commandes suivante:

sudo apt-get install software-properties-common
sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943db
sudo add-apt-repository 'deb http://ftp.igh.cnrs.fr/pub/mariadb/repo/10.1/ubuntu trusty main'    
sudo apt-get update
sudo apt-get install mariadb-server

En cours d'installation, il faudra saisir − deux fois − le mot de passe du compte root de mariadb:

L'installation se termine sur le lancement du démon mariadb − qui s'appelle mysql: c'est historique, on sera pas dépaysé…:

...
  * Starting MariaDB database server mysqld                                                       [ OK ] 
  * Checking for corrupt, not cleanly closed and upgrade needing tables.
Processing triggers for ureadahead (0.100.0-16) ...
Setting up mariadb-server (10.1.21+maria-1~trusty) ...
Processing triggers for libc-bin (2.19-0ubuntu6.9) ...
<user>@mariadb:~$ 

Et donc, on se connecte à mariadb, avec le root/password défini à l'installation:

<user>@mariadb:~$ mysql -u root -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 45
Server version: 10.1.21-MariaDB-1~trusty mariadb.org binary distribution

Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> 

On se crée un utilisateur «pour travailler» et ayant des droits réseaux (%) en tapant les deux commande SQL suivantes:

GRANT ALL privileges ON *.* TO 'remoteAdmin'@'%' IDENTIFIED BY 'remoteAdmin' WITH GRANT OPTION;
FLUSH privileges;
 

On vérifie qu'on peut utiliser ce nouveau compte: on quitte et on se reconnecte:

MariaDB [(none)]> quit
Bye
cram28@mariadb:~$ mysql -u remoteAdmin -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 46
Server version: 10.1.21-MariaDB-1~trusty mariadb.org binary distribution

Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> quit 

Et enfin, un dernier changement afin d'ouvrir le serveur mariadb aux requêtes en provenance du réseau (la ligne à modifier est autour de la #47):

sudo nano /etc/mysql/my.cnf

# Modif Cram28 - 2017.02.28 - Ligne commentée pour autoriser à traiter tous les flux réseaux
#bind-address           = 127.0.0.1

Un arrêt/relance du serveur de base de données est nécessaire pour prise en compte:

sudo service mysql restart

 * Stopping MariaDB database server mysqld                            [ OK ] 
 * Starting MariaDB database server mysqld                            [ OK ] 
 * Checking for corrupt, not cleanly closed and upgrade needing tables.

Pour la localisation des tables de données de mariadb, on pourrait envisager de les stockées directement dans un répertoire du NAS plutôt que dans le container: à la réflexion, quel est l'intérêt, le système de fichiers du container est déjà sur le serveur …?

Récupéré sur le net… A adapter …

#!/bin/bash

MIRROR=${MIRROR:-"http://192.168.42.2:3142/ftp.fr.debian.org/debian"}
TEMPLATE=$(dirname $0)/lxc-debian.sh

# lvm
VGNAME=rootvg
FSTYPE=ext4

# network
GATEWAY="192.168.42.1"
NETMASK="24"
MACBASE="00:FF"
BRIDGE="brlxc0"

test -e /etc/default/lxc-philpep && . /etc/default/lxc-philpep

if [ ! -x "$TEMPLATE" ]; then
    echo "$TEMPLATE doesn't exist or isn't executable"
    exit 1
fi

arch=$(dpkg --print-architecture)

usage() {
     echo "$0 -h|--help -n <name> -i <ip> -s <fssize (default 2G)> -a <arch (default $arch)>"
    exit 64
}

options=$(getopt hn:i:s: "$@")

eval set -- "$options"

while true
do
    case "$1" in
        -h) usage && exit 0;;
        -n) name=$2; shift 2;;
        -i) ip=$2; shift 2;;
        -s) fssize=$2; shift 2;;
        -a) arch=$2; shift 2;;
        *) break;;
    esac
done

test -z "$name" && usage
test -z "$ip" && usage
test -z "$fssize" && fssize=2G

mac=$MACBASE$(printf ':%02X' ${ip//./ }; echo)
lxc_path=/var/lib/lxc/$name
rootdev=/dev/$VGNAME/$name
rootfs=$lxc_path/rootfs

cleanup() {
    umount $rootfs
    lvremove -f $rootdev
}

trap cleanup HUP INT TERM

lvcreate -L $fssize -n $name $VGNAME || exit 1
udevadm settle
mkfs -t $FSTYPE $rootdev || exit 1
mkdir -p $rootfs
mount -t $FSTYPE $rootdev $rootfs

MIRROR=$MIRROR $TEMPLATE --path=$lxc_path --name=$name

if [ $? -ne 0 ]; then
    echo "$0: failed to execute template"
    cleanup
fi

cat >> $lxc_path/config << EOF
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = $BRIDGE
lxc.network.hwaddr = $mac
lxc.network.ipv4 = $ip/$NETMASK
lxc.network.veth.pair = lxc-$name
lxc.network.ipv4.gateway = $GATEWAY

# drop capabilities
lxc.cap.drop = audit_control audit_write fsetid ipc_lock ipc_owner lease linux_immutable mac_admin mac_override mac_admin mknod   setfcap setpcap sys_admin sys_boot sys_module sys_nice sys_pacct sys_ptrace sys_rawio sys_resource sys_time sys_tty_config   net_admin syslog  
EOF  

cat <<EOF > $rootfs/etc/network/interfaces
auto lo
iface lo inet loopback
EOF

# random password
root_password="$(dd if=/dev/urandom bs=32 count=1 2> /dev/null | base64)"
echo "root:$root_password" | chroot $rootfs chpasswd

# put your ssh keys here, otherwise leave mines :)
mkdir -p $rootfs/root/.ssh
cat > $rootfs/root/.ssh/authorized_keys << EOF
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuV9mpjaE2wAA+MqrkxNrSM93Lfw2n/wTHICi6YQpVv9A+d4MSWPO2uw8I0j6jf7PdXiwSirPYtZS59+7rzPbS/  l6t0fftBdYE0nR5kMtPOWn0Gt6Me4gLHJAAW5ZGZOkJuFVFjkOEA16zXjGG8X6KWe3Uv7KdFhEpcNokNZVk6uzqBSVemBKVpmDPjBOUQbR/  xICdHqvNy4OYyXBxGb9UxlR9142O2yqXHR7gJtRJEKbR5lkiqZiWNtAhxTqUcgODe6EIA9fSyrAqOzGG4okMyt/4IXRgkRYkpu/  VV9ZZ4x6DuHTt6XOwTv0rJiLWJe0HoIEfHhjLKnRrYvhLUZ0Iw==  
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA44/kafwOzHQDN8hs  Vqxsdoo24z9aGTsBWdiqPj8cDlIC49DusBowZEcd+f2GVy8  Op0KSy7ETEvazTfwWHi4KgcHmZRJplUoO  5jfZ1BwbCQTrABkOAdX/5PYRepG9dQam4DnHKs7EDb1Fz/ggs6aZ  CamFvFu6P3hJ74/BsT0Pew2phevRRSieJQM0ORSgATCeNi6  2uYXnham/A3eODv/h5D/  vDsZDJIcs5QzhWZYUY4iIIk63wimOje5pZX4MaGdvyRZfPPXCKnn  29Y+ZdNJQbhYga5FFooqURX6CXrr6CQjOpZpeG/0YJWupNd  6QX/CIC0MEuVpI/gjhHo  ZvzVnoUQ==
EOF  

#http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg01266.html
sed -i 's/$ModLoad imklog/#$ModLoad imklog/' $rootfs/etc/rsyslog.conf

# Configure timezone
echo "Europe/Paris" > $rootfs/etc/timezone
chroot $rootfs dpkg-reconfigure -f noninteractive tzdata

# TODO lxc can mount the fs when starting container
echo "$rootdev $rootfs $FSTYPE defaults 0 0" >> /etc/fstab

echo "$name" created

Il est possible de limiter l’utilisation de tout et n’importe quoi concernant les conteneurs, et ça peut se faire via fichier de config: lxc.cgroup.<cgroup-name> = <value>

Pour limiter la consommation des conteneurs :

• mémoire: lxc.cgroup.memory.limit_in_bytes = 256M
• swap: lxc.cgroup.memory.memsw.limit_in_bytes = 1G
• pour assigner des cœurs CPU: lxc.cgroup.cpuset.cpus = 0-1,3
• pour donner plus ou moins de CPU (chacun a 1024 de base) il s’agit de lxc.cgroup.cpu.shares = 512, et ici on donne deux fois moins de CPU à ce conteneur qu’aux autres