#1 Le 19/08/2017, à 09:25
- thierry_b
conteneur lxc avec ubuntu mate depuis un template ubuntu 16.04
Bonjour,
Je suis en train de tester Proxmox (Proxmox VE 5 sur une debian stretch en host) sur un nuc de test et mon but était d'avoir un container lxc avec ubuntu mate (qui remplacera mon host actuel sous ubuntu sur mon nuc d'utilisation qui tourne avec kvm + libvirt), mais comme tous les template de base sont construit avec une image minimale text,
je me suis dit que ça serait pas bien compliqué d'installer le package qui va bien ensuite, mais malheureusement, ça ne fonctionne pas.
apt-get install ubuntu-mate-desktop
me donne ces erreurs de dépendances.
Aug 18 10:28:30 ubuntu systemd[1]: bluetooth.service: Failed with result 'exit-code'.
dpkg: error processing package bluez (--configure):
subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of indicator-bluetooth:
indicator-bluetooth depends on bluez (>= 5); however:
Package bluez is not configured yet.
dpkg: error processing package indicator-bluetooth (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of unity-control-center:
unity-control-center depends on indicator-bluetooth; however:
Package indicator-bluetooth is not configured yet.
dpkg: error processing package unity-control-center (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of unity-control-center-signon:
unity-control-center-signon depends on unity-control-center; however:
Package unity-control-center is not configured yet.
dpkg: error processing package unity-control-center-signon (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of pulseaudio-module-bluetooth:
pulseaudio-module-bluetooth depends on bluez (>= 5.23); however:
Package bluez is not configured yet.
dpkg: error processing package pulseaudio-module-bluetooth (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of gnome-bluetooth:
gnome-bluetooth depends on bluez (>= 5.5); however:
Package bluez is not configured yet.
dpkg: error processing package gnome-bluetooth (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of ubuntu-mate-desktop:
ubuntu-mate-desktop depends on pulseaudio-module-bluetooth; however:
Package pulseaudio-module-bluetooth is not configured yet.
dpkg: error processing package ubuntu-mate-desktop (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of blueman:
blueman depends on bluez (>= 4.61); however:
Package bluez is not configured yet.
dpkg: error processing package blueman (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of ubuntu-mate-core:
ubuntu-mate-core depends on pulseaudio-module-bluetooth; however:
Package pulseaudio-module-bluetooth is not configured yet.
dpkg: error processing package ubuntu-mate-core (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of gnome-user-share:
gnome-user-share depends on gnome-bluetooth (>= 3.9.3); however:
Package gnome-bluetooth is not configured yet.
dpkg: error processing package gnome-user-share (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
bluez
indicator-bluetooth
unity-control-center
unity-control-center-signon
pulseaudio-module-bluetooth
gnome-bluetooth
ubuntu-mate-desktop
blueman
ubuntu-mate-core
gnome-user-share
Et même avec
apt-get -f install
ou
dpkg --configure -a
, impossible de résoudre cela.
Avez-vous une piste?
Merci.
Hors ligne
#2 Le 19/08/2017, à 12:50
- outcast
Re : conteneur lxc avec ubuntu mate depuis un template ubuntu 16.04
Je ne sais pas si t'es conscient de ce que tu veux faire : faire tourner un serveur X dans un container qui échangera des données (clavier, souris, affichage, etc...) avec le serveur X de l’hôte. Une sorte de 2 serveurs X en mode Maitre-Maitre Actif-Actif.
Mais le problème de compréhension conceptuel des containers n'est pas la.
T'essaies de faire avec un container ce qui est l'apanage d'une machine virtuelle.
Et c'est pas parce que t'as un container "ubuntu 16.04" que t'as une VM ubuntu 16.04 avec son serveur X etc..., ça n'a aucun rapport.
Pour revenir à ce que tu veux faire, t'as 2 possibilités :
- T'oublies les containers, t'installes une VM ubuntu 16.04
- Tu gardes le container mais t'y accèdes via une connexion VNC. Ainsi le serveur X reste confiné dans le container et tu passes par VNC pour y accéder. Je ne connais pas LXC mais je connais Docker.
Regarde comment ça marche avec Docker
https://github.com/dockerfile/ubuntu-desktop
Un conseil, renseigne toi sur les fondamentaux des containers et des VMs, ça t'évitera des confusions et surtout d'utiliser un container en lieu et place d'une VM et vice versa, erreur très très commune.
Hors ligne
#3 Le 19/08/2017, à 13:01
- thierry_b
Re : conteneur lxc avec ubuntu mate depuis un template ubuntu 16.04
Je ne sais pas si t'es conscient de ce que tu veux faire : faire tourner un serveur X dans un container qui échangera des données (clavier, souris, affichage, etc...) avec le serveur X de l’hôte. Une sorte de 2 serveurs X en mode Maitre-Maitre Actif-Actif.
Mais le problème de compréhension conceptuel des containers n'est pas la.
T'essaies de faire avec un container ce qui est l'apanage d'une machine virtuelle.
Et c'est pas parce que t'as un container "ubuntu 16.04" que t'as une VM ubuntu 16.04 avec son serveur X etc..., ça n'a aucun rapport.Pour revenir à ce que tu veux faire, t'as 2 possibilités :
- T'oublies les containers, t'installes une VM ubuntu 16.04
- Tu gardes le container mais t'y accèdes via une connexion VNC. Ainsi le serveur X reste confiné dans le container et tu passes par VNC pour y accéder. Je ne connais pas LXC mais je connais Docker.
Regarde comment ça marche avec Docker
https://github.com/dockerfile/ubuntu-desktopUn conseil, renseigne toi sur les fondamentaux des containers et des VMs, ça t'évitera des confusions et surtout d'utiliser un container en lieu et place d'une VM et vice versa, erreur très très commune.
Désolé, je me suis très mal exprimé, je vais essayer d'être plus complet...car évidemment, je ne cherche pas à me connecter d'un linux sur un autre linux.
Mon ordi principal c'est un Mac en fait.
J'ai actuellement un Intel nuc i5 qui tourne sous Ubuntu Mate 16.04 (utilisation principale pour Plex) et qui contient une VM sous Debian (pour un serveur jeedom) géré par KDM/ libvirt.
- Je me connecte dessus via x2go (x2goserver sur l'intel nuc et x2goclient sur mon mac).
- Je contrôle ma VM sous Debian par ssh, j'ai pas d'interface graphique dessus.
Comme je pensais peut-être changer ma distrib Ubuntu Mate et/ou tester d'autres distribs à la place, je me suis dit "tiens, ça serait peut-être intéressant de le virtualiser aussi " d'où l'idée de Proxmox avec un host "minimal" et des VMs qui tournent derrière.
Pour ne pas casser mon installation actuel, je me suis acheté un second nuc très bon marché à base de Intel Celeron N3050.
Et c'est sur ce nuc là que je fais des tests de ma future solution cad Proxmox en host et par exemple en vm ou container : ubuntu mate et debian.
Mais dans tous les cas, la connexion graphique à distance sur le ubuntu mate, se fera toujours de la même façon via x2go.
Mais effectivement, je voulais avoir un conteneur pour mutualiser les ressources (vu que l'host et les guest sont sous linux) et pour un petit gain de vitesse des disques par rapport à une VM (je crois que niveau cpu c'est presque kif kif) + qui contient une gui parce que j'aime bien pouvoir faire des choses graphiquement à distance.
Le seul problème c'est qu'il n'y a pas de conteneur tout pret pour Ubuntu Mate, y'a juste des templates avec un rootfs minimal et on doit soit même s'installer les paquets et c'est là que ça coince comme je l'ai expliqué plus haut.
Je pense que ce que tu décris avec vnc c'est exactement l'équivalent de ce que je fais actuellement avec x2go du coup.
je vais du coup regarder ton lien pour voir comment ça marche exactement car ce qui m'intéresse c'est de comprendre comment construire cet ubuntu-desktop, pour l'appliquer que ce soit avec Mate ou autre environnement de bureau divers et variés.
PS: Le problème de la solution de la VM c'est que j'aimerais par exemple si je mets une clé sur mon nuc qu'elle soit directement reconnu dans ma VM Ubuntu Mate et je sais pas si ça sera possible du coup, à moins peut-être de mapper tel port bien précisément.
Là aussi c'est l'avantage du conteneur.
Merci.
Dernière modification par thierry_b (Le 19/08/2017, à 13:17)
Hors ligne
#4 Le 19/08/2017, à 19:40
- outcast
Re : conteneur lxc avec ubuntu mate depuis un template ubuntu 16.04
Je comprends ta démarche de vouloir mutualiser les ressources car tous les OS sont sous linux.
Mais encore une fois, les containers ne sont pas conçus pour faire tourner tout un OS dessus, un service ou deux grand max.
Autre point que les gens oublient souvent, la durée de vie d'un container c'est quelques jours, quelques semaines grand max.
Les containers sont des objets jetables.
En revanche, les VMs sont conçus pour avoir une durée de vie de quelques mois à quelques années.
Pour ce qui est de la clé USB, je rappelle qu'un container tout comme une VM sont isolés de l’hôte et qu'il faudra faire dans les 2 cas un mapping.
Pour Plex, nul besoin d'une VM, il y a un container Docker officiel https://hub.docker.com/r/linuxserver/plex/ et ça a un sens de le mettre dans un container au lieu d'une VM.
Ce que je te recommande, c'est de tout mettre à plat, sur ton nuc i5, t'installes Proxmox, puis tu crées tes VMs ubuntu 16.04, debian pour jeedom, container Plex, etc...
Hors ligne
#5 Le 19/08/2017, à 20:02
- thierry_b
Re : conteneur lxc avec ubuntu mate depuis un template ubuntu 16.04
Je comprends ta démarche de vouloir mutualiser les ressources car tous les OS sont sous linux.
Mais encore une fois, les containers ne sont pas conçus pour faire tourner tout un OS dessus, un service ou deux grand max.
Autre point que les gens oublient souvent, la durée de vie d'un container c'est quelques jours, quelques semaines grand max.
Les containers sont des objets jetables.
En revanche, les VMs sont conçus pour avoir une durée de vie de quelques mois à quelques années.Pour ce qui est de la clé USB, je rappelle qu'un container tout comme une VM sont isolés de l’hôte et qu'il faudra faire dans les 2 cas un mapping.
Pour Plex, nul besoin d'une VM, il y a un container Docker officiel https://hub.docker.com/r/linuxserver/plex/ et ça a un sens de le mettre dans un container au lieu d'une VM.Ce que je te recommande, c'est de tout mettre à plat, sur ton nuc i5, t'installes Proxmox, puis tu crées tes VMs ubuntu 16.04, debian pour jeedom, container Plex, etc...
Ok .
Le point négatif par contre dans cette installation, c'est que comme c'est le cas naturellement, je n'ai pas de desktop linux en mode natif, où je peux mettre une clé usb, la voir directement, la lire de suite etc...
En fait, j'avais commencé à installer une première VM spécialement pour Debian et jeedom (qui n'est pas supporté par un autre OS pour le moment).
En gros mes besoins sur la machine sont :
- un bon processeur pour transcoder du Plex
- une debian qui tourne quelque soit sa forme avec jeedom
- une distrib linux en mode desktop où je peux lire, écrire une clé usb
- et éventuellement aussi avoir moyen sans trop de remue ménage de tester d'autres distrib linux en mode desktop sans tout chambouler à mon install existante.
T'en penses quoi par rapport à tout ça, tu restes toujours sur la même idée ou tu me conseillerais autre chose?
Merci encore
Hors ligne
#6 Le 19/08/2017, à 21:09
- outcast
Re : conteneur lxc avec ubuntu mate depuis un template ubuntu 16.04
En fait, tu dois te décider si ton nuc i5 est uniquement serveur ou bien aussi une station de travail.
Si il est uniquement serveur, t'installes Proxmox :
- VM debian pour jeedom
- Container Plex
- VMs pour les autres distribs de test
- Quand tu branches une clé usb dessus, tu passes par l'interface Proxmox pour faire des copies sur le disque hôte.
Si il est station de travail, tu prends ubuntu 16.04, t'installes kvm/qemu
- VM debian pour jeedom
- Plex en natif
- VMs pour les autres distribs de test
- Quand tu branches une clé usb, t’utilises le clavier/souris
C'est un peu bâtard comme installation mais elle est bien optimisée.
Comment choisir ?
Si le nuc est utilisé à 90% en tant que serveur, autant en faire un vrai serveur qui servira de socle pour tous services actuels et à venir (serveur de fichiers, passerelle, firewall, etc...).
Si le nuc sert à tout, autant qu'il soit une station de travail.
Hors ligne
#7 Le 19/08/2017, à 21:21
- thierry_b
Re : conteneur lxc avec ubuntu mate depuis un template ubuntu 16.04
Ouais ok je vois, je pense que c'est la solution 2 et donc l'actuelle qui me convient le mieux.
Et du coup, le nuc moins puissant peut aussi servir, pour tester d'autres distibs (carrément toutes en natives avec choix au boot par exemple) ou d'autres tests, avant de les finaliser sur mon nuc principal puissant (si je veux changer un jour dos pour l'host).
Merci
Hors ligne
#8 Le 19/08/2017, à 21:46
- outcast
Re : conteneur lxc avec ubuntu mate depuis un template ubuntu 16.04
Ton choix est rationnel/pragmatique/économique.
J'ai fait le même chez moi.
Le problème aujourd'hui c'est qu'avec un i5, 16Go de ram, du linux et des VMs, t'as autant de puissance que 5 PCs réels il y a 5 ans.
L'infrastructure à l'époque avec plusieurs machines réelles était justifiée, mais plus aujourd'hui.
Il y a une autre solution aujourd'hui à bases de raspberry pi, ça coûte pas cher, ça consomme rien.
Mais pourquoi multiplier les petites machines alors qu'une seule qui coûte pas trop cher peut tout faire tourner ?
Faut juste prévoir une solution de sauvegarde, par exemple un disque externe de 10To (300 euros) à brancher une fois / semaine.
Avec un disque de 10To à 300 euros, même un NAS n'a plus de sens.
Du coup, tu te retrouves avec un nuc i5, 16Go de ram, disque de 10To puis un disque externe de 10To en sauvegarde, le tout pour moins de 1200 euros. ça consomme rien et pas mal de puissance.
Hors ligne
#9 Le 19/08/2017, à 21:58
- thierry_b
Re : conteneur lxc avec ubuntu mate depuis un template ubuntu 16.04
Tu veux dire qu'avec un raspberry pi tu peux tester toute distrib linux confondue?
Si c'est le cas j'avoue que ta solution est plus économe que mon nuc céléron + 4 Go de ram + dd ssd de 120 Go (cout de 230 euros environ).
En fait, pour la multiplication des machines, c'est juste que changer d'os hote par exemple pour faire pleins de tests de distrib linux c'est pas pratique sur un nuc qui a toujours besoin d'avoir Plex actif comme le mien et jeedom pour la domotique.
Pour la sauvegarde, en fait, j'ai déjà un NAS, 4 disques durs en raid 5 et 12 To d'exploitable sur les 16 théoriques du coup, mais tu n'as pas tort, et avec tes deux disques durs de 10 To, ça équivaut à la plus value du raid 5 que j'ai en pouvant perdre un disque du coup.
Par curiosité, tu as mis en pratique aussi cette solution des 2 disques de 10 To et tu utilises aussi un nuc ou un ordi de bureau du coup?
Dernière modification par thierry_b (Le 19/08/2017, à 22:10)
Hors ligne
#10 Le 19/08/2017, à 22:19
- outcast
Re : conteneur lxc avec ubuntu mate depuis un template ubuntu 16.04
En termes de fonctionnalités et de services rendus, je compare un pc d'il y a 5 ans avec un raspberry.
Certes on peut pas installer n'importe quelle distrib sur un raspberry mais c'est secondaire pour en faire un serveur de fichiers ou un plex (RasPlex).
Perso j'ai un pc portable i3, 16Go de ram, 500Go de disque (tampon pour les VMs) et 2 disques externes de 10To.
Il tourne sur une xubuntu 16.04 très minimaliste (firefox, vlc, éditeur de texte, kvm, ansible).
Tout le reste tourne dans des VMs, j'en ai une cinquantaine (elles tournent pas toutes) et des containers dans des VMs.
Quand je veux expérimenter un truc, je lance une VM provisionnée avec ansible, quand c'est fini, elle est détruite.
L'hôte est toujours propre et il ne bouge jamais, il occupe à peine 4Go sur le disque.
Je me tâte à prendre un raspberry pour isoler la partie dlna, mais c'est vraiment du luxe.
Hors ligne
#11 Le 19/08/2017, à 22:35
- thierry_b
Re : conteneur lxc avec ubuntu mate depuis un template ubuntu 16.04
Ha oui ok, je vois, je te remercie
Hors ligne
#12 Le 20/08/2017, à 10:43
- outcast
Re : conteneur lxc avec ubuntu mate depuis un template ubuntu 16.04
Quand on construit une infrastructure, il y a 2 options : scale up, scale out.
scale up : une seule boite de plus en plus grosse
scale out : plein de boites
Aujourd'hui, pour un particulier, avec un budget de ~1500 euros, quelle est la plus grosse boite qu'il peut avoir ?
i7, 32Go de ram, 2 disques de 10To (dont un pour la sauvegarde).
Sur cette config ou on peut faire tourner une dizaine de VMs simultanément et de quoi stocker des dizaines milliers de documents.
C'est largement plus que suffisant pour n'importe quel foyer de 5 personnes.
Mais il y a une autre solution, on n'a pas d'argent, on fait dans la récup, on fait du scale out.
- Un pc de ~10 ans avec 4Go de ram, 2 disques de 3To (dont un pour la sauvegarde).
Je dis 3To car certaines vieillies cartes mères ne gèrent pas plus, mais si elles savent (mise à jour du bios) faut mettre directement du 10To.
Ce pc sert de serveur de fichiers, dlna, téléchargement, etc... il centralise tous les documents et lance les sauvegardes sur le disque externe.
Si il est un peu plus puissant, il peut servir de station de travail.
Si il a une carte graphique qui décode du 1080p (les nvidia de 2007 savent le faire) autant en faire aussi une station de travail.
Il n'y aura pas de VMs dessus.
- Des pcs en mode client/jetables
Typiquement les vieux pcs portables, ils sont bons pour le surf, écrire des mails, regarder des vidéos etc... mais rien d'important n'est stocké dessus, ils peuvent tomber en panne à n'importe quel moment, il n'y a aucun préjudice
- Des tablettes bas de gamme/jetables (à base de soc mediatek)
C'est parfait pour un usage passif, toutes les vidéos, les mp3 etc... sont sur le serveur, si ça casse, ça part au recyclage, aucun document n'est perdu.
- Dans cette infra, faut oublier tout ce qui est VMs, containers etc... Il n'y a pas assez de puissance
Autres points à voir :
- Faut toujours tenir compte de la consommation électrique
Une machine qui tourne avec un disque de 500Go ou 10To, ça consomme pareil, donc toujours acheter le plus gros disque possible au meilleur prix.
En ce moment c'est du 2To ou du 10To.
Pareil pour les CPUs et la RAM.
Un i7 avec 10 VMs qui tournent consomme quasi autant que sans VM. Alors qu'avoir 10 machines réelles, ben, ça consomme 10 fois plus que le i7 et ses 10 VMs.
- Toute l'infrastructure doit être au service de la sauvegarde
L'acte de sauvegarde doit être le plus simple possible et il faut être capable de vérifier à l'oeil nu que la sauvegarde a été faite.
- Un NAS même en RAID 42 n'est pas une sauvegarde
Ben oui, si j'efface un fichier, il est irrécupérable, pour cela, il faut une sauvegarde.
Un NAS c'est une technique parmi d'autres de faire du scale out de disques durs.
Donc au lieu d'avoir un NAS en RAID 42, vaut mieux avoir un disque interne de 10To et un disque externe de 10To pour la sauvegarde.
- Quand je parle de sauvegarde
Elle doit être incrémentale, c'est à dire que si un fichier de la production est effacé, il existe toujours sur la sauvegarde.
Concrètement, la sauvegarde aura cette structure :
/current/ qui est une copie exacte de la production
/2017-08-12/ tous les fichiers modifiés/supprimés le 2017-08-12
/2017-08-11/ tous les fichiers modifiés/supprimés le 2017-08-11
/2017-08-10/ tous les fichiers modifiés/supprimés le 2017-08-10
etc...
Ainsi, il est très facile de récupérer un vieux fichier.
La taille de la sauvegarde n'est pas extensible, quand il est plein, supprimer les très veilles sauvegardes incrémentales.
- Pourquoi quand on a le budget, préférer le scale up avec des VMs à la place du scale out
Tout simplement parce que les VMs sont très pratiques.
On peut sauvegarder l'image, créer un instantané, faire des bidouilles, si on est pas content, revenir en arrière.
On peut créer des machines sur mesure (CPU, RAM, taille disque, carte réseau, etc...) et les faire évoluer selon les besoins.
On peut créer une config réseau entre VMs qui coûterait cher si il fallait des routeurs/switchs réels.
Je comprends que pour un particulier ça demande beaucoup de savoir faire, mais vaut mieux se renseigner un peu avant de se lancer dans l'achat de NAS à 8 baies ou des i5 en simple station de travail.
Ce qui est sur, c'est que vous aurez pas ce discours chez les vendeurs.
Hors ligne
#13 Le 23/12/2017, à 18:14
- thierry_b
Re : conteneur lxc avec ubuntu mate depuis un template ubuntu 16.04
Salut,
Je voulais te redemander conseil, toi qui a une bonne analyse ^^.
Petit rappel:
Actuellement sur mon intel NUC i5, jeedom tourne sur une VM debian 8 à l'aide de qemu / kvm et libvirt. Le système hôte étant un ubuntu mate 16.04 TLS. En fait, j'avais cet ubuntu avant de m'intéresser à la domotique qui me servait surtout pour faire tourner mon serveur Plex et finalement, j'ai installé jeedom avec la VM par la suite.
Finalement, sur une machine de test, j'ai essayé d'installer debian 9 et j'ai pu par l'installateur lui dire de mettre Mate aussi. Et du coup, j'ai été très surpris, car ces paquets Mate sont même plus récents que ceux d'ubuntu.
Du coup, je me dis que ça vaudrait le coup de tout passer avec une debian + Mate en host qui serait utilisé pour tout : Plex + Jeedom.
En postant sur le forum jeedom, j'ai eu une réponse qu'il vallait mieux laisser jeedom sur un OS seul sans interface graphique, mais je pense que le tout sera quand même plus optimal si je n'ai plus de VM, et que tout tourne sur le host non?
PS: sur ma VM, j'avais une debian nue sans interface graphique.
Merci
Hors ligne
#14 Le 26/12/2017, à 23:19
- outcast
Re : conteneur lxc avec ubuntu mate depuis un template ubuntu 16.04
Ta machine est suffisamment puissante pour faire tourner plusieurs VM.
Faut-il faire tourner l'application sur l’hôte ou utiliser des VMs ?
Les questions que tu dois te poser sont :
Faut-il isoler l'application ?
L'application a-t-elle des besoins autres que l’hôte (version du noyau, des librairies, etc...) ?
L'application a des mises à jours très fréquentes ?
L'application est sujet à bidouilles ?
Est-il nécessaire de revenir en arrière après une mise à jour foireuse ?
Comptes-tu faire tourner l'application sur une autre machine ?
Une heuristique pour décider :
Si ton application est utilisée quotidiennement, autant qu'elle fasse partie intégrante de l’hôte.
Par exemple, une application comme firefox utilisée quotidiennement, autant qu'elle soit installée direct sur l’hôte.
En revanche, si ton trip est de compiler la nightly de firefox pour voir les avancements, autant le faire dans une VM parce qu'il y a une tonne de librairies à installer et que tu ne veux pas polluer ton pc avec tout ça.
Hors ligne
#15 Le 27/12/2017, à 22:17
- thierry_b
Re : conteneur lxc avec ubuntu mate depuis un template ubuntu 16.04
Ha oui je vois.
Je vais y réfléchir, merci.
D'un côté, je lis aussi sur les forum de Jeedom, par exemple, que pour passer de Debian 8 à Debian 9, ils recommandent carrément une nouvelle install from scratch, donc là je me dis tiens, peut-être qu'il vaut mieux que ça reste dans une VM lol.
Mais comme la version de libvirt, est beaucoup plus récente sur debian, je vais peut-être me mettre une Debian Mate avec une VM aussi sous Debian et réinstaller fraichement jeedom dessus, comme ils le conseillent.
Hors ligne