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
L'idée qu'on garde en tête le long de ce «tuto» est de ne pas toucher − tant que faire se peut − à la configuration native du serveur VHS, y compris en matière de réseau et de règles sur le pare-feu.
En dehors du fait qu'elles seront perdues à chaque installation ou mise à jour du firmware, de telles modifications pourraient introduire des comportements indésirables et/ou des failles de sécurité (pas assez calé pour en juger) …
Les opérations proposées ici sont réalisées sur un VHS avec firmware en version de 6.1.3
☛ Quelques liens LXC:
L'outil LXC.
Blog d'un des créateurs (je crois): Une 10zaine 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:
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:
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:
nginx
/ php
/ mariadb
; on va pouvoir y «déposer» phpMyAdmin, sonerezh ou nextcloud;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:
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. 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:
ssh
(port 22 par défaut) ou http
(port 80) d'un container soient ouverts sur le réseau (en 192.168.x.y) ?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:
Attention les manipulations proposées ici seront réalisées, si vous vous lancez, à vos «risques et périls».
Le risque − relatif − parait plus grand pour vos données si votre NAS est en DMZ.
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:
lxc-ubuntu
est «une grosse vache» avec un certain nombre de paquets dont on n'a pas forcément besoin (serveur ssh par exemple)lxc-debian
est plus léger… voir creux !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:
snap
codé), on a une option -P /mon/chemin/containers
dans toutes les commandes lxc-xxx
qu'on va exploiter;
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…
Et pensez à désactiver l'indexation de votre dossier VM-LXC
…
… sinon, le FileTrackingSystem (FTS pour les intimes), é bé l'a pas fini de ramer à indexer la foultitude de fichiers système du premier container venu !
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:
#LXC_DHCP_CONFILE=/etc/lxc/dnsmasq.conf
.#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) :
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$
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$
lxc-<ce-que-c-est>_creat.sh
chmod +x lxc-<ce-que-c-est>_creat.sh
sudo -E ./lxc-<ce-que-c-est>_creat.sh <ARGS> <password>
-E
permet que le script voit nos variables d'environnement en LXC_*
Ci-joint - et afin d'éviter les boulettes éventuelles - un script qui fait tout çà, à savoir:
../partages/VM-LXC
destiner à recevoirdnsmasq.conf
que le script créé../prive/scripts-lxc
pour les travaux de définitions des containers
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
Bon, on doit pas être trop mal… Allez … Go !!
On prévoit de construire 3 types de containers
lxc-mariadb
lxc-pma
lxc-sonerezh
lxc-nextcloud
lxc-x11vnc
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.
Il faut en effet préciser un point important: les dernières versions utilisent l’outil systemd
. Or, LXC sur Ubuntu Trutsy (système du NAS en v6.x) ne supporte pas cela dans les containers. Il existe une solution apparemment : il faut installer lxcfs
sur le NAS … donc on laisse tomber (cf. https://newspaint.wordpress.com/2016/04/25/adding-an-ubuntu-16-04-xenial-lxc-container-to-ubuntu-14-04-trusty/)
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:
#!/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:
#!/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
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$ _
admin@sesame:~/prive/scripts-lxc/lxc-mariadb$ chmod +x lxc-mariadb-creat.sh
finalize_mariadb.sh
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:
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….
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: ...
root
de MariaDB :
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.
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$
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$
-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 NGinxconfig.inc.php
: la configuration de PhpMyAdminLes 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:
lxc-mariadb
doit être installé; il peut ne pas tourner, le script le lanceralxc-pma
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:
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:
lxc-x11vnc
avec «à-l'intérieur-dedans»: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
Faites attention: Ce container s'appuie sur le template lxc-download
: Assurer vous que la ligne 374 correspond bien à un chemin sur les disques et pas sur la clé système:
# Setup the cache if [ "$DOWNLOAD_TARGET" = "system" ]; then #LXC_CACHE_BASE="$LOCALSTATEDIR/cache/lxc/" LXC_CACHE_BASE="/mnt/data/data/users/admin/partages/VM-LXC/cache/" else LXC_CACHE_BASE="$HOME/.cache/lxc/" fi
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:
lxc-JDownloader_creat_v1.1.sh
de création du container et de sa «préparation» (cf. plus loin)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
).
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$
chmod +x lxc-JDownloader_creat_v1.1.sh
admin@sesame:~/prive/scripts-lxc/lxc-JDownloader$ ./lxc-JDownloader_creat_v1.1.sh
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:
lxc-download
et la distribution Debian Wheezy (peut-être rapide si déjà présente en cache);sudo
)
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é
cd ~
./JD2SilentSetup_x64.sh
Ç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
)
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 !
admin@moka:~$ sudo lxc-info -n ubuntu01 Name: ubuntu01 State: STOPPED admin@moka:~$
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 containerfstab
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:~$
-d
):admin@moka:~$ sudo lxc-start -n ubuntu01 -d
admin@moka:~$ sudo lxc-ls -f NAME STATE IPV4 IPV6 AUTOSTART ---------------------------------------------- ubuntu01 RUNNING 10.0.3.179 - NO admin@moka:~$
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:/#
root@ubuntu01:/# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty
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
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
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)
root@ubuntu01:/# exit exit admin@moka:~$
ssh
(mot de passe ubuntu
comme indiqué).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.
L'idée est de ne pas toucher - tant que faire se peut - à la configuration de l'hôte, y compris en matière de réseau. Sur le NAS, ces modifications éventuelles risquent peut-être d'introduire des failles de sécurité (pas assez calé pour en juger), et seront perdues aux prochaines livraisons de Ve-Hotech…
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 :
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:
Attention les manipulations proposées ici seront réalisées,
si vous vous lancez, à vos «risques et périls»
C'est fait …
ssh admin@sesame
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:~$
sudo lxc-info -n lxcubuntu00 Name: lxcubuntu00 State: STOPPED admin@sesame:~$
sudo lxc-start -n lxcubuntu00 -d
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)
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:
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
Et là, on se heurte au pare-feu du VHS:
on ne sort pas !
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 :
lxc.cgroup.memory.limit_in_bytes = 256M
lxc.cgroup.memory.memsw.limit_in_bytes = 1G
lxc.cgroup.cpuset.cpus = 0-1,3
lxc.cgroup.cpu.shares = 512
, et ici on donne deux fois moins de CPU à ce conteneur qu’aux autres