La VM qy.share démarre très bien sous KVM après conversion de l'image disque (au format qcow2 compressé) et correction de l'interface réseau. Je n'ai pas encore "finalisé l'installation".
Il semble que le partage de dossier avec l'hôte s'appuie sur une fonctionnalité de virtualbox, ça ne fonctionnera donc pas sauf à la remplacer (ex: qemu VirtFS). Je n'ai pas vu d'autre lien évident avec virtualbox.
La question: on trouve dans le fichier .ssh/authorized_keys de root et webhost une clef publique ("root@sil1.splitted-desktop.com") sans restriction des commandes autorisées, et dans sshd_config "PermitRootLogin yes". On peut supposer que cette clef est utilisée pour des mises à jour (à lire http://www.qyshare.com/how-does-it-work/ ). Mais pourquoi ne pas restreindre l'accès à un nombre très limité de machines et commandes nécessaires? Ou mieux tirer les mises à jour depuis la VM qy.share plutôt que les pousser depuis un serveur.
[^] # Re: Question
Posté par syntaxerror . En réponse au journal et hop, une nouvelle version de qy.share : multisites !. Évalué à 3.
La VM qy.share démarre très bien sous KVM après conversion de l'image disque (au format qcow2 compressé) et correction de l'interface réseau. Je n'ai pas encore "finalisé l'installation".
Il semble que le partage de dossier avec l'hôte s'appuie sur une fonctionnalité de virtualbox, ça ne fonctionnera donc pas sauf à la remplacer (ex: qemu VirtFS). Je n'ai pas vu d'autre lien évident avec virtualbox.
La question: on trouve dans le fichier .ssh/authorized_keys de root et webhost une clef publique ("root@sil1.splitted-desktop.com") sans restriction des commandes autorisées, et dans sshd_config "PermitRootLogin yes". On peut supposer que cette clef est utilisée pour des mises à jour (à lire http://www.qyshare.com/how-does-it-work/ ). Mais pourquoi ne pas restreindre l'accès à un nombre très limité de machines et commandes nécessaires? Ou mieux tirer les mises à jour depuis la VM qy.share plutôt que les pousser depuis un serveur.