Bonjour, Le 13/11/20 à 23h44, Marmotte <garamotte(a)gmail.com> a écrit : Je connaissais pas, je vais regarder, mais tu n'as pas les même pbs qu'avec lxc3 : - devoir mettre du nested = 1 dans la conf du conteneur sur le host - devoir rester en legacy cgroup hierarchy - devoir définir pleins d'overrides systemd dans les conteneurs pour que les services tournent normalement (en gros faire sauter toutes les limitations systemd, du genre mettre à false PrivateDevices / PrivateTmp / ProtectControlGroups / ProtectKernelModules / ProtectSystem / …) - devoir revoir les conf apparmor Tout ça est pénible mais va surtout à l'encontre des principes d'isolation recherchés. C'est ça qui me pousse à passer à kvm.

Plus simple ? J'avoue avoir un doute, car ce que j'avais avec lxc2 était vraiment simplissime, mais je vais regarder ;-)

J'utilise btrfs seulement sur le serveur de backup, pas en prod car j'ai eu trop de misères (ça freeze de manière imprédictible et pour une durée indéterminée après certaines manip sur les subvolumes, surtout les delete, c'est tolérable sur le backup mais pas sur la prod). Mais dupliquer un lv reste assez simple. C'est plutôt de devoir gérer du dhcp qui m'embête ;-) J'ai déjà un resolver unbound par host sur le lan, ils gèrent ma zone statique (toutes les ip du lan) à partir d'une simple liste nom ip (avec un script qui déploie les modifs et reload les resolvers après chaque modif de la liste). Du coup pour créer un fichier de conf lxc j'avais juste un script qui récupère l'ip d'après le nom dans le dns et la met dans le fichier de conf.

systemd-networkd, j'avoue que c'est le premier truc que je vire, passé pas mal d'heures à essayer d'y répliquer ce qui marchait avec /etc/network/interfaces sans succès, je suis revenu au legacy.

Ok, une alternative à lxc, je vais regarder ça de plus près, merci pour cette piste.

proxmox vient de sortir une nouvelle solution de backup (proxmox backup server = pbs) https://pbs.proxmox.com/wiki/index.php/Main_Page nouveauté, les incrementales pour qemu (sans snapshots disques, ca track un bitmap dans le process qemu directement, donc ca marche avec n'importe quel stockage), et lxc également. c'est vraiment bien foutu, un seul backup full, et des incrementales à vies. (ensuite, dans pbs, il  a un systeme de tracking de block, de  purge automatique, checkum des backups, etc...)

Bonjour, Merci à ceux qui se sont penchés sur le pb, résultat des courses pour ceux que ça intéresse. Le 13/11/20 à 19h15, Daniel Caillibaud <ml(a)lairdutemps.org> a écrit : Ça c'est visiblement pas possible en kvm, on file pas un filesystem à la vm mais un disque, et elle a son bootloader et sa table de partitions. Y'a des moyens de contournement (libguestfs), mais c'est pas simple. Ce serait possible avec xen. Ça c'est possible mais toujours assez compliqué, faut définir ça dans la VM (pas moyen de fixer nic/ip depuis le host dans les specs de la vm), c'est probablement pour ça que tout le monde passe par du dhcp. Cf 1) Cf 2) Donc kvm n'est pas adapté à ce que je voulais faire. xen pourrait faire le job, mais j'ai pas assez creusé car en testant proxmox6 + kvm, j'ai testé aussi proxmox6 + lxc, et ça marche mieux que ce que je faisais manuellement auparavant. Ça me permet aussi de garder une infra plus homogène (encore des hosts en stretch + lxc2), et de conserver ma batterie de scripts (pour le backup surtout, avec gestion de la rotation des snapshots, où on peut accéder à n'importe quel fichier de n'importe quel snapshot directement sur le filesystem). Je vais donc pouvoir rester encore un peu avec lxc ;-) Pour info, les pbs que j'ai eu avec systemd dans les conteneurs (avec ma gestion manuelle des conteneurs lxc) pour - host stretch/lxc2 + conteneur buster - host buster/lxc3 + conteneur buster concernaient tous des pbs de sytetmd avec les cgroup, qu'il faut régler au cas par cas en faisant sauter des restrictions systemd, pour notamment ces services (à chaque fois faut un /etc/systemd/system/xxx.service.d/override.conf) Il y a pas mal de monde a avoir des pbs, sur pleins de services, du genre https://forum.proxmox.com/threads/upgrade-lxc-16-04-to-18-04-problems-cgrou… et la réponse est souvent de passer les conteneurs en mode privilégiés avec du nested = 1 (ce qui revient +/- à rompre l'isolation) 1) logrotate # logrotate.service: Failed to set up mount namespacing: Permission denied # logrotate.service: Failed at step NAMESPACE spawning /usr/sbin/logrotate: Permission denied # cf https://forum.proxmox.com/threads/logrotate-issue-in-buster-lxc.56726/ [Service] PrivateDevices=false PrivateTmp=false ProtectControlGroups=false ProtectKernelModules=false # lui ne devrait pas coincer (ça passe en ro /usr /boot /efi /etc), mais # sans ça il veut pas… ProtectSystem=false 2) munin-node # Cf https://github.com/munin-monitoring/munin/issues/1278 [Service] PrivateTmp=false ProtectHome=false ProtectSystem=false 3) varnishncsa [Service] # vu qu'on tourne dans lxc sans les CAP_SYS_ADMIN, si on veut éviter de mettre dans la conf du conteneur du # lxc.apparmor.profile = unconfined # faut ajouter ça # pour ProtectSystem, yes passe /usr et /boot en read-only, full ajoute /etc et strict ajoute /dev /proc et /sys # pourquoi faut du no ? (en tout cas même avec yes ça démarre pas pour un pb de namespace) ProtectSystem=no ProtectHome=false PrivateTmp=false PrivateDevices=false # ça limite la sécurité dans la VM mais l'augmente vis-à-vis du host # (si varnish est troué il pourrait mettre plus de bazar dans la vm mais ne pourra pas accéder au host) # ça marchait sans cette option, mais y'avait régulièrement des alertes systemd (le notify ci-dessus) avec du # Failed to set up mount namespacing # on essaie ça pour voir si ça va mieux NoNewPrivileges=yes J'ai d'abord eu l'impression qu'avec proxmox6 j'avais moins de pbs, mais ça semble pas tellement le cas, je vais faire un autre thread pour ça. -- Daniel Ce qui manque aux orateurs en profondeur, ils vous le donnent en longueur. Montesquieu _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

Bonjour, Merci à ceux qui se sont penchés sur le pb, résultat des courses pour ceux que ça intéresse. Le 13/11/20 à 19h15, Daniel Caillibaud <ml(a)lairdutemps.org> a écrit : Ça c'est visiblement pas possible en kvm, on file pas un filesystem à la vm mais un disque, et elle a son bootloader et sa table de partitions. Y'a des moyens de contournement (libguestfs), mais c'est pas simple. Ce serait possible avec xen. Ça c'est possible mais toujours assez compliqué, faut définir ça dans la VM (pas moyen de fixer nic/ip depuis le host dans les specs de la vm), c'est probablement pour ça que tout le monde passe par du dhcp.

Cf 1) Cf 2) Donc kvm n'est pas adapté à ce que je voulais faire. xen pourrait faire le job, mais j'ai pas assez creusé car en testant proxmox6 + kvm, j'ai testé aussi proxmox6 + lxc, et ça marche mieux que ce que je faisais manuellement auparavant. Ça me permet aussi de garder une infra plus homogène (encore des hosts en stretch + lxc2), et de conserver ma batterie de scripts (pour le backup surtout, avec gestion de la rotation des snapshots, où on peut accéder à n'importe quel fichier de n'importe quel snapshot directement sur le filesystem). Je vais donc pouvoir rester encore un peu avec lxc ;-) Pour info, les pbs que j'ai eu avec systemd dans les conteneurs (avec ma gestion manuelle des conteneurs lxc) pour - host stretch/lxc2 + conteneur buster - host buster/lxc3 + conteneur buster concernaient tous des pbs de sytetmd avec les cgroup, qu'il faut régler au cas par cas en faisant sauter des restrictions systemd, pour notamment ces services (à chaque fois faut un /etc/systemd/system/xxx.service.d/override.conf) Il y a pas mal de monde a avoir des pbs, sur pleins de services, du genre https://forum.proxmox.com/threads/upgrade-lxc-16-04-to-18-04-problems-cgrou… et la réponse est souvent de passer les conteneurs en mode privilégiés avec du nested = 1 (ce qui revient +/- à rompre l'isolation) 1) logrotate # logrotate.service: Failed to set up mount namespacing: Permission denied # logrotate.service: Failed at step NAMESPACE spawning /usr/sbin/logrotate: Permission denied # cf https://forum.proxmox.com/threads/logrotate-issue-in-buster-lxc.56726/ [Service] PrivateDevices=false PrivateTmp=false ProtectControlGroups=false ProtectKernelModules=false # lui ne devrait pas coincer (ça passe en ro /usr /boot /efi /etc), mais # sans ça il veut pas… ProtectSystem=false 2) munin-node # Cf https://github.com/munin-monitoring/munin/issues/1278 [Service] PrivateTmp=false ProtectHome=false ProtectSystem=false 3) varnishncsa [Service] # vu qu'on tourne dans lxc sans les CAP_SYS_ADMIN, si on veut éviter de mettre dans la conf du conteneur du # lxc.apparmor.profile = unconfined # faut ajouter ça # pour ProtectSystem, yes passe /usr et /boot en read-only, full ajoute /etc et strict ajoute /dev /proc et /sys # pourquoi faut du no ? (en tout cas même avec yes ça démarre pas pour un pb de namespace) ProtectSystem=no ProtectHome=false PrivateTmp=false PrivateDevices=false # ça limite la sécurité dans la VM mais l'augmente vis-à-vis du host # (si varnish est troué il pourrait mettre plus de bazar dans la vm mais ne pourra pas accéder au host) # ça marchait sans cette option, mais y'avait régulièrement des alertes systemd (le notify ci-dessus) avec du # Failed to set up mount namespacing # on essaie ça pour voir si ça va mieux NoNewPrivileges=yes J'ai d'abord eu l'impression qu'avec proxmox6 j'avais moins de pbs, mais ça semble pas tellement le cas, je vais faire un autre thread pour ça.