dani a écrit 116 commentaires

On parle de la même chose pourtant. Niveau technique, tout est déjà faisable, en IPv4 y compris. Ça demande juste des manipulations différentes de la part de l'utilisateur qui doit être assisté (ce qu'on cherche justement à éviter). Et je maintiens qu'IPv6 ne changera rien à ça (entre faire un renvoi de port + configurer le pare feu, ou juste configurer le pare feu……).

C'est la raison pour laquelle j'utilise aussi VNC (sans en être satisfait). J'aimerai une solution à la TeamViewer, libre, et avec laquelle je pourrais déployer mon propre serveur

Si on prend la main sur la machine de quelqu'un pour l'assister, c'est qu'en général il n'aura pas la moindre idée de ce qu'est le DNS, ni de quelle adresse IP il dispose, ni de comment ouvrir un port dans son pare feu. En fait, s'il connait tout ça, il y a déjà de grandes chances pour qu'on ait pas besoin de prendre la main, mais au pire, IPv4 ne sera pas un verrou, puisqu'il saura vraisemblablement rediriger le port nécessaire. Donc non, IPv6 peut enlever un tout petit verrou, mais ne changera globalement rien à ce problème.

C'est pas une histoire de goût et de couleur. C'est simplement pas du tout les mêmes choses. Pour moi, VNC n'est pas une solution d'assistance à distance (ce que TeamViewer est par contre). VNC n'est qu'un outil bas niveau, au dessus duquel on pourrait le faire. Mais ça n'existe pas (d'où le vide de Zenitram).
Quand au VNC haute performance, tu peux regarder du côté de spice. Il a été spécialement conçus pour le VDI (déport d'affichage des VM). Je ne sais pas s'il est utilisable en dehors de qemu-kvm par contre.

VNC fournit l'affichage déporté uniquement. Il manque tout le reste (des performances décentes, connexions sécurisées "simple", passage de NAT, client multiplateforme, transfert de fichiers, chat, utilisation intuitive pour les néophytes, bref, tout le reste, qui va autour de l'affichage, et qui en fait un vrai service). J'utilise moi aussi VNC, faute de mieux. Mais on ne peut pas dire que ça soit un équivalent, faut pas se voiler la face.

Non, le terme "vide" me semble tout à fait pertinent là. Il n'y a rien dans le libre qui pourrait se rapprocher de TeamViewer. Absolument rien. J'ai pourtant cherché un moment. VNC n'a rien à voir, il pourrait être une brique (une petite brique) d'une telle solution, mais sûrement pas la totalité (et je parle pas encore des problèmes de performances)

IPv6 (sans parler du fait qu'il ne sera jamais fini de déployer) ne réglera pas ce problème. Avoir une IP joignable directement c'est qu'une toute petite partie du problème. Reste quand même à ouvrir le port dans le pare feu. Et puis identifier l'adresse IP en question aussi. Bref, TeamViewer a encore de beaux jours devant lui, et IPv6 ne lui fera jamais d'ombre

Oui, je parle bien des instanced services unit, avec une bonne présentation ici: http://0pointer.de/blog/projects/instances.html

C'est marrant parce que je pense exactement l'inverse: systemd a des tonnes d'intérêts sur un serveur, et j'en vois beaucoup moins sur un desktop/laptop. Dans les faits, je l'utilise partout (Fedora sur les postes, CentOS sur les serveurs), mais il y a pleins de trucs qui le rendent vraiment utile sur un serveur, de mon point de vue d'admin sys. Les limites d'allocation de ressources par exemple, le redémarrage auto en cas de crash (c'est qu'un palliatif, mais sur la prod, il vaut mieux relancer et analyser à posteriori que de réveiller l'admin sys au beau milieu de la nuit), les instances multiples d'un même démon (très utile pour OpenVPN par exemple: on peut maintenant ne relancer qu'une seule instance), les renforts de sécu, en simplifiant le drop des privilèges, les namespaces qui permettent de masquer certaines parties du FS, ou de ne pas donner accès au réseau à certains démons. Journald aussi qui permet de ne plus rater de journaux, de les centraliser, et de les indexer. C'est aussi bien plus simple de créer un nouveau service, ou de personnaliser un existant sans avoir à se soucier des futures MaJ qui écraseront les changements. Ça m'arrive de rencontrer un ou deux problèmes bien sûr, et je dois encore assez souvent me taper la doc pour retrouver les directives qui vont bien, mais dans l'ensemble, je bénie systemd, c'est vraiment un truc qui manquait (et non, il n'y a pas d'ironie là dedans, je trouve vraiment que systemd apporte beaucoup de choses positives)

C'est indiqué sur l'instance de référence, ici: https://vroom.im/documentation (c'est même d'ailleurs sur la première ligne de la doc)

Aucune solution (tar, rsync, dump2fs) de haut niveau ne fonctionne quand on fait une utilisation intensive de hardlinks. Rsync demande trop de RAM (moins depuis la v3, mais toujours bcp), tar en demande moins, mais dans tous les cas, ce n'est pas tellement la RAM occupée le pb, mais le temps nécessaire à scanner tout ça, et à recréer la structure sur la destination. Quand le nombre de hardlinks est trop important, la seule solution (v|f)iable est la copie bas niveau

Oui, c'est effectivement une possibilité. Mais c'est spécifique à BackupPC, et c'est pas toujours plus rapide qu'un dd/raidsync (dépend de la vitesse d'accès aléatoires de ton pool de sauvegarde, et du taux d'utilisation du FS). Dans tous les cas, j'ai plus confiance dans une copie bas niveau pour ce genre de schéma de stockage.

J'utilise plusieurs solutions, parfois combinées selon le niveau de service requis (dans un cadre pro, donc dépend du client, de la bande passante, du volume de données, du budget etc…).

J'utilise le plus souvent l'externalisation par le RAID1 effectivement. C'est limité à la taille d'un disque (mais on trouve des disques externes de 12To comme les Laci 2Big par exemple). Avec cette technique, il n'y a pas vraiment à restaurer quoi que ce soit. En cas de besoin, il suffit de ré-assembler le RAID depuis le disque externe (mdadm --assemble /dev/md127 /dev/sdb1 par exemple). Si on veux réinjecter les données sur le NAS, il suffit d'assembler le RAID1 depuis le disque externe, puis d'ajouter le RAID6 du NAS en tant que membre, et la synchro se fera dans l'autre sens.

J'utilise DRBD aussi entre 2 machines d'un DC, pour avoir de la redondance. C'est la solution la plus complexe je trouve.

Enfin, pour dd, comme pour le RAID, la restauration est très simple: dd te donne une image de ton périphérique block. Tout dépend de la destination de ton dd (tu peux utiliser un autre périphérique block comme destination, ou alors un fichier). Dans tous les cas, il suffit de refaire un dd dans l'autre sens (inversant source et dest) pour "restaurer"

Aussi, autre option possible (et que j'utilise souvent): un autre serveur de sauvegarde, externalisé. Ton serveur local et le distant sauvegardent tous les deux les mêmes jeux de données, sur des créneaux horaires différents. Le premier transfert sera long, mais les suivants pourront profiter de rsync

J'utilise BackupPC depuis des années, qui a le même problème concernant l'externalisation: la quantité de hardlinks rend la copie "au dessus" du FS quasi impossible (que ce soit rsync, ou cp, ou dump2fs). Deux axes pour externaliser

• Exporter uniquement le dernier jeux de sauvegarde (ça ne semble pas être ce que tu cherches, mais c'est très souvent plus que suffisant)
• Faire une copie "sous" le FS

Pour le deuxième axe, là encore, plusieurs possibilités:

• Un bon vieux dd de temps en temps. Problème: pas de copie incrémentielle, il faut tout transférer à chaque fois, ça peut être long. Aussi, le FS source doit être figé pendant la copie, donc snapshot LVM obligatoire selon la durée de la copie
• Une synchro RAID logiciel (c'est ce que j'utilise assez régulièrement): sur ton NAS, il faut stacker 2 couches de RAID: un premier RAID6 comme l'actuel, et de ce RAID6, tu crées au dessus un RAID1 avec un seul membre. Au dessus de ce RAID1, tu y mets ce que tu veux (FS directement ou LVM + FS, ou dmcrypt + LVM + FS, bref….). Ensuite, de temps en temps, tu connectes ton disque externe, tu l'ajoutes au RAID1, il récupère toutes les données, quand la synchro est terminée, tu peux casser le RAID et mettre ce disque en lieux sûr. Il faut par contre impérativement avoir 2 disques externes au minimum, et toujours en avoir un hors site. J'ai un petit script qui permet d'automatiser l'ajout/retrait de disques externes à un RAID logiciel: https://wikit.firewall-services.com/doku.php/tuto/sauvegardes/externalisation_raid1 (c'est pour BackupPC, mais ça peut s'adapter facilement)
• Une autre possibilité est d'utiliser drbd sous le FS (il faut par contre une autre machine, pas juste un disque externe). drbd est plutôt efficace quand la connexion se rétablie pour ne transférer que les zones modifiées depuis la dernière fois
• enfin, comme déjà évoqué, les FS modernes type ZFS ou BTRFS avec leur fonctions respectives de send/receive devraient permettre aussi de faire ça (mais j'ai pas d'expérience avec ceux là)

voilà mes 2ct sur ce sujet ;-)

Comme expliqué dans la doc, dans la mesure du possible, les connexions s'établissent en direct entre les navigateurs. Mais si ça n'est pas possible (NAT des deux côté par exemple), les trames sont relayées via un serveur TURN (qui, sur l'instance https://vroom.im est la même machine que celle qui héberge l'appli). Voir ça pour plus de détails sur le fonctionnement, et les méthodes de fallback

Bonjour à tous. Développeur de VROOM, j'avoue être assez flatté qu'il apparaisse ici.
Pour tout dire, j'ai commencé ce projet juste pour me faire un peu les dents en HTML/JS/CSS. Petit à petit, j'ai ajouté les fonctions dont j'avais besoin, voir un peu plus. Le projet est plus à l'état de POC qu'autre chose, et malheureusement, j'ai peu de temps à y consacrer. Si certains veulent aider, ça se passe sur GitHub :-)