Journal Retour d'expérience Nextcloud

• # "Chez moi ça marche"™

  Posté par Maclag le 26 décembre 2017 à 01:12. Évalué à 9.

  

  Dix clameurs:
  Je ne suis pas admin sys. J'ai tout installé via Yunohost. Mon Nextcloud n'a que 2 utilisateurs vraiment actifs, et on totalise quelque chose comme 50Go de données, essentiellement des photos. Pas de chiffrage. Côté matériel: un Kimsufi KS-1 (Atom N2800, RAM 2Go).
  Comprendre: je ne sais pas de quoi ça va avoir l'air, mais ce commentaire ne sera pas à prendre comme des affirmations basées sur des connaissances et une expérience poussée!

  De ce que j'ai compris, il y a pas mal de paramètres à optimiser finement pour que NC ait de bonnes perfs, notamment au niveau du cache. Je ne saurais en dire plus (cf ci-dessus: je n'ai jamais eu à m'en occuper).

  Les besoins matériels que tu avances pour supporter la charge me paraissent ahurissant (il faut un cluster pour supporter 10 utilisateurs!?). Notamment parce que je sais que OC/NC sont utilisés dans des environnements professionnels, et j'ai du mal à croire que les organismes qui s'en servent s'offrent de très grosses machines juste pour ça. Les admins auraient hurlé (bon, ils l'ont peut-être fait et on n'est pas au courant…).

  J'utilise aussi les clients Windows, Android et Linux sans souci. Le client Windows on va dire moins: je ne synchronise que de touts petits dossiers. Je n'ai jamais eu le moindre souci.
  Et pareil pour le reste: je n'ai jamais eu de message d'erreur ou de bug. NC a juste été très fiable pour ma petite utilisation, encore une fois peu poussée.

  Est-il possible que tu n'aies pas optimisé la chose comme elle doit l'être?

  D'un autre côté, s'il y a des optimisations "de base" sans lesquelles les perfs sont catastrophiques, on peut aussi légitimement se demander à qui la config par défaut est censée servir.

  • [^] # Re: "Chez moi ça marche"™

    Posté par voxdemonix le 26 décembre 2017 à 01:51. Évalué à 1.

    

    Le mien manque de puissance alors qu'il consomme déjà 3 tour (cluster BDD + cluster stockage) et un Odroid-Xu4 (Frontend HaProxy), pour quelques To de données chiffrées dans 229 950 fichiers et 36 250 dossiers. Le tout utilisé par entre 3 et 5 humains régulier + 3 ou 4 robots.

    Les besoins matériels que tu avances pour supporter la charge me paraissent ahurissant (il faut un cluster pour supporter 10 utilisateurs!?).

    Sans Haute Disponibilité tu n'as besoin que de deux machines (une qui gère nextcloud et une qui sert de backup).

    Si tu veux de la Haute Disponibilité il te faut 3 (bonnes) machines rien que pour le cluster de base de données (MariaDB 10 + Galera 3), ajoute le cluster de stockage qui va lui nécessiter à minima deux autres machines (et on peut reconvertir un des serveurs de base de données en arbitre pour le cluster de stockage mais ça pourrait l'amener à lagger).
    Par contre le cluster de base de données semble amener des erreurs quand il dépasse les 70% du processeur.
    Et le processus btrfs-transaction (qui gère le JBOD de mes disques) quand il s'y met bouffe à lui seul 3x l'i3 de la machine d'où je l'observe.

    Note que ça dépends aussi de se que font tes utilisateurs.

    Pas de chiffrage.

    Ce module change la vie mdr (actuellement il bug assez souvent avec les grosses installations).

    Est-il possible que tu n'aies pas optimisé la chose comme elle doit l'être?

    J'ai suivis (à peu près) les procédures indiquées dans les tutos listés dans le Farm Link, je suis preneur de toutes améliorations :)

    J'utilise aussi les clients Windows, Android et Linux sans souci.

    Attention à ne pas confondre les clients de synchronisation et les clients de montage webdav/davfs2 ;)

    • [^] # Re: "Chez moi ça marche"™

      Posté par grmp le 27 décembre 2017 à 11:12. Évalué à 4.

      

      J'ai suivis (à peu près) les procédures indiquées dans les tutos listés dans le Farm Link, je suis preneur de toutes améliorations :)

      Il y a un soucis déjà.

      Pourquoi ne pas s'être basé sur le documentation officiel Nextcloud ? Elle est très bien expliqué, fournit, et ne manque pas d'information sur presque tout les types d'installation.

      Là on dirait que tu t'es embarqué dans une installation un peu bancal sur des "tutos" écrit par des tiers, à la différence de la doc officiel, les informations, les infos et les instructions peuvent être inexacte par rapport à ta config ou même à la version de Nextcloud utilisé.

      Je tourne en ce moment avec un nextcloud 12, une machine gérant le web, une autre la BDD et la dernière qui me sert de backup, le chiffrement est activé coté serveur + HTTPS pour transfert, aujourd'hui je touche du bois, jamais eu aucun soucis.

      De même pour la synchro des clients, sur Smartphone c'est client Davdroid (Recup sur F-droid) pour synchro agenda + contact, appli Nextcloud pour accéder à mes fichiers et les envoyer directement sur le serveur.
      Pour les clients desktop, synchro Agenda + contact dans Thunderbird en Caldav+Cardav et l'accès aux fichiers se fait soit via l'application lourde officiel, sinon accès via l'interface web.

      • [^] # Re: "Chez moi ça marche"™

        Posté par Psychofox (Mastodon) le 27 décembre 2017 à 11:49. Évalué à 5.

        

        Là on dirait que tu t'es embarqué dans une installation un peu bancal sur des "tutos" écrit par des tiers, à la différence de la doc officiel,

        C'est l'impression que j'ai aussi.

        J'ai aussi l'impression que l'auteur du journal mélange des concepts comme la synchronisation/publication de documents et les backups.

        Genre je comprends pas pourquoi l'auteur bricole en faisant des backup des machines sur un nextcloud avant de les réinstaller plutôt que d'utiliser un logiciel de backup fait pour ça.

        Je ne comprends pas non plus pourquoi il a monté une lourde infra avec des clusters nextcloud tout ça pour perdre des données alors que monter un nextcloud standalone, sans raid mais avec une infra et une procédure de backup bien ficelée à côté lui aurait permis de restaurer ses nextcloud sans douleur ni perte de données.

        • [^] # Re: "Chez moi ça marche"™

          Posté par voxdemonix le 27 décembre 2017 à 14:03. Évalué à -2.

          

          1. Tout les tutos sont de moi et sont plus fun a lire que la doc anglophone avec ecriture grise sur fond blanc que je trouve insuportable (surtout sur leur forum)

          2. Mes backups ne sont pas uniquement sur le cloud, si non comment je ferai pour recup mon backup du cloud quand le cloud est peté?

          3. Je veux de la haute disponibilité.

          4. L'utilisation de l'un n'est pas l'utilisation de l'autre, idem pour les contraites.

          • [^] # Re: "Chez moi ça marche"™

            Posté par grmp le 27 décembre 2017 à 15:49. Évalué à 3.

            

            Tout les tutos sont de moi et sont plus fun a lire que la doc anglophone avec ecriture grise sur fond blanc que je trouve insupportable (surtout sur leur forum)

            Bha justement du coup, comment tu peux être sur à 100% que tes tutos sont fonctionnels alors que sur ton environnement de prod c'est pété ? Je ne comprend pas ta logique.
            Sinon personnellement la doc nextcloud je la trouve claire, un sommaire à gauche en bleu, suivis étape par étape, avec chaques fois plusieurs solutions.

            Après niveau design si là ça ne te va pas … Tu préfères réellement le site que tu as mis en Farm Link ? il est horrible.

            Je veux de la haute disponibilité.

            Moi aussi, le fait d'avoir plusieurs machine AVEC le chiffrement (chose que tu accuses un peu) ne casse rien à mon nextcloud.

            L'utilisation de l'un n'est pas l'utilisation de l'autre, idem pour les contraites.

            Je n'ai pas de commentaire là dessus, on est d'accord.
            Mais si déjà tu utiliserais la doc au lieu de tuto glané ci et là sur le net …

            • [^] # Re: "Chez moi ça marche"™

              Posté par voxdemonix le 27 décembre 2017 à 16:03. Évalué à -4. Dernière modification le 27 décembre 2017 à 16:07.

              

              Bha justement du coup, comment tu peux être sur à 100% que tes tutos sont fonctionnels alors que sur ton environnement de prod c'est pété ? Je ne comprend pas ta logique.

              1. Les tutos ne couvrent pas tout l'écosystème (qui est large on parle de clustering de base de données, de clustering de stockage, de load balancer, de VPN, de hardware, de répartition de fichiers, rien que mon écosystème client dépasse de loin les retours d'expérience cités plus bas)

              2. trouver des infos en français à propos de l'écosystème est difficile voir impossible (cherche sur Linuxfr tu trouvera des topics où je demande de l'aide pour choisir quel logiciel de clustering utiliser et à chaque fois … … … aucune réponse. Tout au plus des gens vont te conseiller un logiciel mais sans avoir essayé les autres).

              3. le thread est ouvert sur le forum de nextcloud et eux mêmes ne semblent pas avoir la réponse.

              Après niveau design si là ça ne te va pas … Tu préfères réellement le site que tu as mis en Farm Link ? il est horrible.

              Bien sur, vu que c'est le mien … Je viens du monde du jeux vidéos, où on utilise des interfaces riches, joviales et pleine de couleurs. Les interfaces monocouleur je ne supporte pas ça et d'après mes retours utilisateurs, je ne suis pas le seul.

              Moi aussi, le fait d'avoir plusieurs machine AVEC le chiffrement (chose que tu accuses un peu) ne casse rien à mon nextcloud.

              Hein?
              Le chiffrement apporte des bugs (lisible dans nextcloud.log), j'espère sincèrement qu'il n'est pas cause de crash.

              Mais si déjà tu utiliserais la doc au lieu de tuto glané ci et là sur le net …

              Mes tutos ont été conçu grâce à la doc et à mes tests. Faut arrêter les préjugés au bout d'un moment.
              Quand j'ai découvert Owncloud on en était encore au raspberry pi type 1, je l'ai testé dans tout les sens depuis ;)

• # Verrouillage de fichiers et script cron

  Posté par damaki le 26 décembre 2017 à 09:51. Évalué à 3.

  

  Pour l'histoire d'impossibilité de modifier, supprimer ou déplacer des fichiers, c'est le système de verrouillage de fichiers qui est en cause. La solution est normalement le job cron.

  Je n'arrive ceci dit toujours pas à comprendre pourquoi ce qui me semble être un contournement misérable est obligatoire.

  • [^] # Re: Verrouillage de fichiers et script cron

    Posté par voxdemonix le 26 décembre 2017 à 16:57. Évalué à 1.

    

    Pour l'histoire d'impossibilité de modifier, supprimer ou déplacer des fichiers, c'est le système de verrouillage de fichiers qui est en cause.

    Tu aurais plus d'infos stp? Car j'ai le bug malgré un cron régulier et cela ne touche que certains fichiers.

    • [^] # Re: Verrouillage de fichiers et script cron

      Posté par damaki le 26 décembre 2017 à 18:52. Évalué à 2.

      

      J'avais eu la réponse dans ce sujet de l'aide. J'avais utilisée la solution bourinnissime décrite là.
      DELETE FROM oc_file_locks WHERE 1;
      Vu la tronche de la requête, c'est à utiliser avec modération. C'est probablement plus malin de regarder si la valeur dans la colonne TTL a expiré.

• # C'est pour ça que j'aimerais bien de la vraie IPV6 avec adresse en /48 plutôt qu'en /54

  Posté par totof2000 le 26 décembre 2017 à 10:34. Évalué à 2.

  

  Sur TOUT les réseaux privés on trouve aujourd'hui des "box internet" (routeur indigne de confiance provenant des Fournisseurs d'Accès Internet), des objets connecté sans aucune sécurité, des cameras de surveillance chinoises avec des softwares fragile voir vérolé, des machines tournant dangereusement sous windows/mac os, des smartphone/tablettes avec plein d'applications chelou d'installées, des machines qui font des va-et-vient (par exemple un membre de la famille ou un ami en visite à la maison qui se connecte).

  J'aimerais avoir mon vrai réseau IPV6 sur lequel je pourrais confiner tout ces trucs plus ou moins horribles, sans avoir à devoir gérer un affreux NAT ou des verrues ignobles tout ça parce que les FAI ne respectent pas la norme IPV6.

  • [^] # Re: C'est pour ça que j'aimerais bien de la vraie IPV6 avec adresse en /48 plutôt qu'en /54

    Posté par GnunuX (site web personnel) le 26 décembre 2017 à 19:24. Évalué à 4.

    

    ou des verrues ignobles tout ça parce que les FAI ne respectent pas la norme IPV6

    Tu peux développer svp ?

    Alors un petit spoiler pour ceux qui sont pressés : https://fr.wikipedia.org/wiki/IPv6#Attribution_des_blocs_d'adresses_IPv6

    • [^] # Re: C'est pour ça que j'aimerais bien de la vraie IPV6 avec adresse en /48 plutôt qu'en /54

      Posté par totof2000 le 26 décembre 2017 à 21:36. Évalué à 4.

      

      Tout simplement parce qu'en IPV6, un bloc d'adresse en /64 correspond à 1 LAN (remarque : dans mon titre j'ai écrit /54 au lieu de 64, c'est une erreur). De ce fait il faut recourir à des bricolages pour pouvoir subdiviser son LAN en plusieurs sous-réseaux.
      (voir par exemple ici ).

      Alors certes, j'exagère avec un /48, mais la proposition évoquée sur la page donnée en lien ( un masque sur 60 bits soit 16 sous-réseau) me parait déjà plus raisonnable et permettrait de gérer plus facilement, pour un particulier, une séparation entre les divers équipements qu'il popssède chez lui (1 sous-réseau pour certains objets connectés, un autre pour le wifi de passage pour famille et amis, un autre pour les machines de bureau et NAS qui contient des informations plus sensibles, etc …).

      • [^] # Re: C'est pour ça que j'aimerais bien de la vraie IPV6 avec adresse en /48 plutôt qu'en /54

        Posté par GnunuX (site web personnel) le 26 décembre 2017 à 21:50. Évalué à 3.

        

        Tout simplement parce qu'en IPV6, un bloc d'adresse en /64 correspond à 1 LAN

        Je sais bien et je ne remet pas en cause ce que tu dis là. Mais en quoi est-ce que les FAI ne respectent pas "ces normes" ?

        • [^] # Re: C'est pour ça que j'aimerais bien de la vraie IPV6 avec adresse en /48 plutôt qu'en /54

          Posté par totof2000 le 26 décembre 2017 à 23:18. Évalué à 8. Dernière modification le 26 décembre 2017 à 23:21.

          

          Effectivement, je n'aurais pas du parler de norme mais de recommandation. Celà dit, comme ça fait un bail que je n'ai plus mis le nez dans IPV6, j'ai voulu revérifier mes souvenirs. Et j'ai constaté un truc assez étrange. En voulant vérifier d'ou venait les recommandations d'allocations d'adresses IPV6, je suis tombé sur ce document ou on peut lire :

          5.4. Assignment

          LIRs must make IPv6 assignments in accordance with the following provisions.
          5.4.1. Assignment address space size

          5.4.1. Assignment address space size

          End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site).

          Ca m'a surpris car à l'époque ou je m'y suis intéressé (il y a 5 ou 6 ans), beaucoup de sources indiquaient que l'attribution de préfixes de longueur 48 était la norme. En cherchant un peu et en reprenant les recommandations, j'ai constaté que cette recommandation avait changé. En effet, si on remonte à cette version (RIPE-267 datant du 22 January 2003) :

          5.4. Assignment
          LIRs must make IPv6 assignments in accordance with the following provisions.
          5.4.1. Assignment address space size
          Assignments are to be made in accordance with the existing guidelines
          [RFC3177, RIRs-on-48], which are summarized here as:
          * /48 in the general case, except for very large subscribers
          * /64 when it is known that one and only one subnet is needed by design
          * /128 when it is absolutely known that one and only one device is connecting.

          On a cette recommandation jusqu'à la RIPE-412 publiée le 08 Jul 2007 puis on passe à ceci à partir de la RIPE-421 publiée le 16 Nov 2007 :

          5.4. Assignment
          LIRs must make IPv6 assignments in accordance with the following provisions.
          
          5.4.1. Assignment address space size
          End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site).

          Quelque part, ça me rassure : je ne suis pas fou, j'ai bien vu cette histoire de /48 quelque part, mais d'un autre côté je me demande ce qui a poussé le RIPE à passer d'une extrême à l'autre. Un fort lobying de la part des FAI pour créer une pénurie artificielle ? (j'ai de vagues souvenirs d'une présentation d'IPV6 chez Orange ou il a été question de ce genre de débat à peu près à cette période, et ou je considérais déjà que limiter un particulier à un seul LAN chez lui, c'est se moquer du monde, d'autant plus qu'IPV6 permet largement de ne pas limiter aussi drastiquement le réseau).

          Donc au final, je n'aurais pas du parler de norme mais de recommandation, et celles que j'avais en tête n'étaient plus à jour: aujourd'hui le RIPE considère que l'attribution par défaut doit être un masque /64) : je n'avais pas vérifié mes sources depuis assez longtemps. Mais comme tu le dis, ça ne change rien à ce que je pense du sujet : un /60 aurtait été plus raisonnable.

          En tout cas merci à toi pour m'avoir donné l'envie de me remettre en question et permis de mettre à jour mes connaissances. Comme quoi il n'y a pas besdoin d'être brutal ou désagréable pour pousser les gens à se remettre en question (je te pertinentise du coup sur tes deux posts).

          • [^] # Re: C'est pour ça que j'aimerais bien de la vraie IPV6 avec adresse en /48 plutôt qu'en /54

            Posté par SRL le 29 décembre 2017 à 16:56. Évalué à 2.

            

            mais d'un autre côté je me demande ce qui a poussé le RIPE à passer d'une extrême à l'autre. Un fort lobying de la part des FAI pour créer une pénurie artificielle ? (j'ai de vagues souvenirs d'une présentation d'IPV6 chez Orange ou il a été question de ce genre de débat à peu près à cette période, et ou je considérais déjà que limiter un particulier à un seul LAN chez lui, c'est se moquer du monde, d'autant plus qu'IPV6 permet largement de ne pas limiter aussi drastiquement le réseau).

            C'est plus une histoire de verrue que de spéculation. Le déploiement d'IPv6 consiste à faire du 6to4rd. L'attribution d'un /48 par abonné est alors techniquement impossible. Dans mon cas, Free possède son /28 sur lequel on rajoute les 32 bits de mon IPv4 et les 4 bits restants servent à créer des /64. Le 6to4rd était une bonne solution de transition mais elle a toute les chances d'être définitive.

• # ça marche bien chez moi

  Posté par Ecran Plat (site web personnel) le 26 décembre 2017 à 11:39. Évalué à 8.

  

  ici sur un serveur amd de soyoustart je fait tourner deux containers avec le couple nextcloud/owncloud (vu que next est un fork de own).
  Sur un container j'ai 5 utilisateurs et sur l'autre j'ai 23 utilisateurs (15 vraiment actifs) c'est le container d'une association.
  C'est fluide, il y a du partage de fichiers, synchronisation de contact et d'agenda, sur mon premier container je fait tourner news (que pour moi).
  Le serveur passe sa vie à se tourner les pouces, il n'y a pratiquement pas de charge.
  Je pense que ton problème vient de tes montages davfs, si tu utilise uniquement en local, pourquoi ne fait tu pas un serveur nfs/samba ? Et t'on instance de nextcloud pourrait taper dedans pour les nomades.

  Ici on utilise que l'agent de synchronisation (dans l'association il a remplacé google drive et dropbox).

  Bon j'ai pas de haute disponibilité par contre je rapatrie les backups ici sur une machine spécifique (j'ai une connexion 500/50 mbs).

  • [^] # Re: ça marche bien chez moi

    Posté par Arkem le 02 janvier 2018 à 00:37. Évalué à 2.

    

    Moi aussi. Je ne sais pas s'il y a une grosse différence avec owncloud… j'utilise ce dernier depuis plusieurs années sans soucis particulier avec des clones de Raspberry (olinuxino a20 1 GB, puis bananapi ultra 2GB car je commençais à manquer de RAM). Il y a 8 sessions qui tournent dessus, dont 3-4 très couramment, et je n'ai pas de soucis particulier, à part virer le mode maintenance manuellement à chaque mise à jour ;-)
    Je précise que je ne suis pas du tout informaticien ! Juste un peu bricoleur…

• # Docker

  Posté par nomorsad le 26 décembre 2017 à 12:16. Évalué à 5.

  

  J'utilise Nextcloud avec beaucoup de satisfaction.

  Pour ma part, j'ai opté pour un Kimsufi 2To à 9€/mois et une installation par Docker. J'utilise https://github.com/chrootLogin/docker-nextcloud et j'en suis très content. L'image embarque un Nginx+PHPfpm+crontab, auquel j'ai branché une image PostgreSQL.

  J'ai aussi ajouté une image Traefik (https://traefik.io/) qui se propose de déduire le routage HTTP en détectant des container chargés. Il s'occupe également de gérer les certificats LetsEncrypt.

  Pour gérer tout ça, j'utilise un simple docker-compose. C'est habituellement déconseillé en production, mais vu que je suis en mono-machine, je n'ai aucun besoin orchestration. Je me tâte à passer sur Kubernates, histoire de monter en compétence…

  Je suis globalement d'accord avec le journal, c'est ultra simple et efficace en mono-serveur, mais ça devient vraiment galère dès qu'on veut scaler, notament à cause de SQL et des fichiers à garder synchronisés.

• # Autres retour d'expérience : 2 utilisateurs, synchro calendrier et contacts

  Posté par damaki le 26 décembre 2017 à 16:39. Évalué à 3.

  

  Je n'ai pas du tout la contrainte de haute disponibilité, donc mon install est beaucoup plus simple. J'utilise un VPS d'OVH pour faire tourner. On utilise principalement la synchro des contacts et des calendriers, un peu moins le stockage de fichiers. Je n'ai relevé aucun souci de perf sur ce modeste environnement et pas de problème d'erreurs.
  Comme dit ci avant, j'ai mal lu la doc et j'ai oublié la mise en place du cron initialement, donc ça m'a verrouillé tous mes fichiers. Mais ça a vite été résolu, avec une recherche.

  Voici les défauts que j'y trouve :
  - chiffrement/déchiffrement côté serveur. C'est une limitation de sécurité que je trouve hallucinante en 2017. Par contre, dans un contexte pro l'avantage est certain ; l'administrateur peut avoir une clé de déchiffrement de secours qui permet de déchiffrer les fichiers de tous les utilisateurs si besoin est
  - côté administration système, ça n'est pas une bonne pratique de pousser autant les mises à jour par le site lui même. Ça suppose que le site ait le droit d'écrire dans les dossiers du site et ça ouvre le serveur de façon béante en cas de faille de sécurité. A noter qu'un outil en ligne de commande est aussi fourni pour mettre à jour. Je n'ai pas vu si on peut aussi installer ou mettre à jour les plugins en ligne de commande.

  • [^] # Re: Autres retour d'expérience : 2 utilisateurs, synchro calendrier et contacts

    Posté par NicolasP le 27 décembre 2017 à 02:31. Évalué à 1.

    

    • chiffrement/déchiffrement côté serveur. C'est une limitation de sécurité que je trouve hallucinante en 2017

    Je ne connais pas NextCloud, mais je vois quelques considérations d'ordre générale sur le fait que le chiffrement côté client ne soit pas implémenté sur toutes les applications en 2017 :
    - Ça complique le dédoublonnage de fichiers à des fins d'économie d'espace disque (le serveur ne peut pas savoir que 2 utilisateurs ont uploadé la même photo)
    - Ça empêche les recherches côté serveur (une recherche de tous les fichiers contenant un mot donné devient concrétement impossible)
    - Si les métadonnées sont chiffrées, il devient aussi impossible de trier côté serveur pour par exemple afficher les 20 commentaires les plus récents (il faut rapatrier toutes les données côté client pour les trier, ce qui a un impact sur les performances)
    - De manière générale, toute opération en masse qu'on aurait tendance à effectuer côté serveur devient impossible (générer des miniatures des photos, recherche de contacts en doublons, …)
    - Impossible d'être compatible avec des protocoles standards (diffusion de fichiers multimédia par exemple) qui n'ont pas prévu cette fonctionnalité.

    Pour répondre à certaines de ces problématiques, on aurait besoin de chiffrement totalement homomorpe sacrément performant. On ne sait pas faire aujourd'hui. Du coup, il faut choisir entre le chiffrement côté client ou les fonctionnalités.
    A noter que les 2 options ne sont pas exclusives. Il se pourrait très bien qu'il y ait un module de gestion de photos avec du chiffrement côté serveur et un module de gestion de mots de passe avec du chiffrement côté client.

    Par contre, dans un contexte pro l'avantage est certain ; l'administrateur peut avoir une clé de déchiffrement de secours qui permet de déchiffrer les fichiers de tous les utilisateurs si besoin est

    Si le besoin c'est que l'administrateur soit capable de déchiffrer les fichiers car un utilisateur a perdu son mot de passe, c'est compatible avec le chiffrement côté client. Il suffirait que les clefs de chiffrement des utilisateurs soit chiffrées avec une clef publique de l'administrateur et stockées sur le serveur. Ça nécessite cependant de faire confiance aux utilisateurs (pour pas qu'ils envoient une clef bidon, ce que le serveur serait incapable de détecter). Ça ne répondrait donc pas à un besoin de l'administrateur de vérifier par exemple que le contenu des fichiers uploadés respecte certaines règles (et encore il pourrait supprimer a posteriori les fichiers qu'il ne peut pas lire).

    • [^] # Re: Autres retour d'expérience : 2 utilisateurs, synchro calendrier et contacts

      Posté par damaki le 27 décembre 2017 à 09:17. Évalué à 2. Dernière modification le 27 décembre 2017 à 09:18.

      

      Merci, j'avoue que je n'avais pas poussé la réflexion jusque là. Je n'avais pas non plus trop fait attention aux fonctionnalités de recherche et de métadonnées inclues dans Nextcloud.
      J'en viens à me poser des questions sur la sécurité des métadonnées des fichiers quand on active le chiffrement. Ça n'a pas l'air trop documenté, je crois que je vais jeter un coup d'oeil à leur modèle en base.

      Je vais revoir ravaler mes complaintes, Nextcloud inclut le chiffrement end-to-end depuis septembre. Faut que je teste ça.

      • [^] # Re: Autres retour d'expérience : 2 utilisateurs, synchro calendrier et contacts

        Posté par damaki le 27 décembre 2017 à 09:24. Évalué à 1.

        

        J'ai parlé un peu vite. C'est une version de test inclue dans la 12.0.3 et la version finale sera dans la version 13.

    • [^] # Re: Autres retour d'expérience : 2 utilisateurs, synchro calendrier et contacts

      Posté par gouttegd le 27 décembre 2017 à 10:39. Évalué à 4.

      

      Il se pourrait très bien qu'il y ait un module de gestion de photos avec du chiffrement côté serveur et un module de gestion de mots de passe avec du chiffrement côté client.

      C’est le cas. Le chiffrement des fichiers de manière générale se fait côté serveur, mais Passman, le module de gestion de mots de passe, chiffre les mots de passe côté client. Le serveur ne voit jamais le mot de passe permettant d’ouvrir un coffre.

• # Pendant ce temps là, Seafile, ça marche

  Posté par Florence Birée (site web personnel) le 27 décembre 2017 à 10:35. Évalué à 4.

  

  J'avais testé OwnCloud il y a quelques années (avant le fork de NextCloud), et j'avais vite abandonné devant les besoins de ressources…

  J'ai fini par adopter Seafile, qui fonctionne très bien pour ~20 utilisateurs·trices sur mon vieux serveur P3 à 1Ghz et 512Mo de ram, et pour les Éclaireuses Éclaireurs de France, on a déployé un Seafile sur une machine virtuelle de tetaneutral qui absorbe sans broncher sa centaine d'utilisateurs·trices.

  Le client de synchro fonctionne très bien (et commence enfin à arriver dans les dépôts des distros, un problème de conflit entre deux licences libre a été levé).

  Par contre, les fonctionnalités sont bien plus limitées que sur NextCloud : c'est juste du partage et de la synchro de fichiers (même pas de tagging). Mais l'intégration avec libreoffice online (qui là demande un serveur qui tient la route) donne une autre ampleur à l'outil.

• # Montage webdav/davfs2

  Posté par voxdemonix le 27 décembre 2017 à 15:22. Évalué à 2.

  

  Je suis assez étonné que, pour le moment, dans les retours d'expérience il n'y a aucun utilisateur de montage distant Webdav/davfs2 (qui est pourtant LA fonctionnalité qui fait de Nextcloud une alternative à DropBox, iCloud, Skydrive etc).

  Donc petites questions :

  • Pour ceux qui connaissent et utilisent davfs2/webdav, avez-vous des astuces pour l'améliorer ? (toute plateforme confondue). Savez-vous si le protocole est bloqué à son stade ou si un jour on peut espérer qu'il soit aussi bon que SSHFS?

  • Pour ceux qui ne connaissent pas, comment avez-vous découvert Nextcloud?

  :)

  • [^] # Re: Montage webdav/davfs2

    Posté par Christophe "CHiPs" PETIT (site web personnel) le 27 décembre 2017 à 18:30. Évalué à 3. Dernière modification le 27 décembre 2017 à 18:31.

    

    Effectivement, j'utilise avec ma compagne un ownCloud hébergé sur un VPS OVH de base, toujours avec le client ownCloud sous Linux pour elle et le client ownCloud sous Linux, Windows et Android pour moi, sans rencontrer de problèmes de performances ni de bugs.

    Concernant WebDAV, ça ne me serait pas venu à l'idée en dehors de l'accès ponctuel à un fichier type Keepass, j'ai toujours vu OC/NC comme une application de réplication multiple d'un dossier local avec un accès Web pour récupérer un ou quelques fichiers…

    J'ai découvert ownCloud il y a un bon moment (ici ?), et je me tâte depuis le fork NextCloud pour migrer dessus.

    • [^] # Re: Montage webdav/davfs2

      Posté par Pol' uX (site web personnel) le 29 décembre 2017 à 19:48. Évalué à 7.

      

      Concernant WebDAV, ça ne me serait pas venu à l'idée en dehors de l'accès ponctuel à un fichier type Keepass, j'ai toujours vu OC/NC comme une application de réplication multiple d'un dossier local avec un accès Web pour récupérer un ou quelques fichiers…

      Beh moi j'ai un use case très simple : la synchro entre un serveur sur un lan que je maîtrise, et un vieux OwnCloud (v6) sur un serveur en cœur de réseau que je ne maîtrise pas (donc exit ssh, rsync et consorts). Oui, à la campagne, le service de partage de fichiers, avec un débit montant de 20ko/s les bons jours, on oublie (ou alors avec modération).

      Le client de synchro officiel est inexploitable car n'existe pas en headless (nécessite qt), et l'API Rest de OwnCloud 6 laisse franchement à désirer (j'ignore pour les versions qui suivent mais en v6 c'est clairement une blague de parler d'API pour les fichiers). Je suis donc passé par unison/davfs2 avec des scripts maisons/bugués.

      Clairement, les perfs sont atroces (normal, comme dit plus haut, la plupart des opérations utiles à la synchro nécessitent de télécharger complètement le fichier) et Davfs2 se comporte curieusement en cas de problèmes. Genre : serveur possiblement inaccessible, avec un montage qui devrait échouer, mais à la place il monte un dossier vide et retourne 0. On appréciera :
      
/sbin/mount.davfs: connection timed out two times;
trying one last time
/sbin/mount.davfs: server temporarily unreachable;
mounting anyway

      Par ailleurs, aucune possibilité simple de gérer les conflits. Unison fait une copie. Owncloud ignore que ça devrait être une « version ». Et pas de moyen simple de faire que Unison réconcilie…

      Bref, je plussoie le « Les clients webdav/davfs2 sont pourris. » A posteriori, j'aurais du monter une VM KVM avec le client graphique démarré.

      PS: avec NextCloud, on a un vrai client de synchro headless ?

      Adhérer à l'April, ça vous tente ?

      • [^] # Re: Montage webdav/davfs2

        Posté par Pol' uX (site web personnel) le 29 décembre 2017 à 19:54. Évalué à 4.

        

        Ha, j'oubliais, j'ai aussi été amené à écrire un script maison/bugué pour intervenir tellement davfs est stable en cas d'éternuement de la connexion. Son nom : unfuck.davfs.sh ; et il contient plein de pkill. :-/

        Adhérer à l'April, ça vous tente ?

        • [^] # Re: Montage webdav/davfs2

          Posté par voxdemonix le 30 décembre 2017 à 15:53. Évalué à 2.

          

          Je confirme qu'il est habituel sur Xubuntu de devoir forcer l’arrêt du gestionnaire de fichier qui se retrouve freeze à cause du montage webdav.
          Ou encore la commande 'dh -f' qui se tape aussi des freeze :(

      • [^] # Re: Montage webdav/davfs2

        Posté par gouttegd le 29 décembre 2017 à 20:27. Évalué à 4.

        

        PS: avec NextCloud, on a un vrai client de synchro headless ?

        Le client Owncloud (qui fonctionne tant avec Owncloud qu’avec Nextcloud) a un client en ligne de command owncloudcmd. Il dépend toujours de Qt (Qt5Network, Qt5Core, etc.) mais fonctionne sans serveur graphique.

        Toutefois, contrairement à son homologue graphique, owncloudcmd fait une synchro puis se termine — il ne reste pas à monitorer les fichiers et refaire une synchro en cas de changements.

  • [^] # Re: Montage webdav/davfs2

    Posté par damaki le 27 décembre 2017 à 23:33. Évalué à 1. Dernière modification le 27 décembre 2017 à 23:33.

    

    Je pense que j'avais entendu parler d'Owncloud sur Slashdot. J'ai ensuite entendu parler du fork Nextcloud quand je me suis lancé pour de vrai dans ma dégooglisation. Je cherchais les autres alternatives à Google Drive.

  • [^] # Re: Montage webdav/davfs2

    Posté par steph1978 le 29 décembre 2017 à 12:20. Évalué à 5.

    

    Ton étonnement vient du fait que les clients fournis pour oc/nc sont très efficaces.
    Sur desktop/laptop, ils permettent de choisir ce qui est synchroniser. Et donc de limiter l'espace de stockage requis.
    Sur mobile, ils ne synchronisent que sur demande. Idem, pour maîtrise l'espace de stockage requis.
    Webdav correspond à un usage connecté qui n'est pas le plus courant.
    Le plus courant est un usage de synchro, à la trucdrive, bidulecloud, machinbox.

    • [^] # Re: Montage webdav/davfs2

      Posté par voxdemonix le 29 décembre 2017 à 15:59. Évalué à 0. Dernière modification le 29 décembre 2017 à 16:02.

      

      Le plus courant est un usage de synchro, à la trucdrive, bidulecloud, machinbox.

      Ben justement, les trucscloud permettent un montage à distance (c'est en cherchant "alternative skydrive" que je suis tombé sur owncloud). Avec justement l'idée de pouvoir profiter d'une mémoire "illimité" sur des périphériques limité par la taille/prix des carte microSD. (a la base je tournais sur FreeNAS mais trop austère, et compliqué (rien que mettre a jours le système s'était chiant avec le système en read-only))
      D'où mon étonnement (après tout, sshfs est très très utilisé dans les communautés NAS).

      Ton étonnement vient du fait que les clients fournis pour oc/nc sont très efficaces.

      Boaf : il faut plusieurs clients pour synchroniser contact/calendrier/photos/geolocalisation/News/bookmark. On est hélas encore loin d'un tout en un.
      Sur pc les clients de synchro ne fonctionnent pas en ligne de commande.
      Sur smartphone ca peut caffouiller (sur le mien nextcloud auto-crash par contre owncloud fonctionne parfaitement).
      D'ailleurs en passant, sur pc (ubuntu/debian) on sait synchroniser les contactes, calendriers, etc?

      • [^] # Re: Montage webdav/davfs2

        Posté par Adrien Dorsaz (site web personnel, Mastodon) le 30 décembre 2017 à 00:18. Évalué à 4. Dernière modification le 30 décembre 2017 à 00:19.

        

        D'ailleurs en passant, sur pc (ubuntu/debian) on sait synchroniser les contactes, calendriers, etc?

        Pour l'environnement GNOME 3 (donc Debian et Ubuntu récentes), oui, il suffit d'ajouter un compte "Owncloud" ou "Nextcloud" (les 2 systèmes sont compatibles) dans les paramètres "Comptes en ligne". Ça configure automatiquement le backend d'Evolution pour synchroniser les calendriers par caldav et les contacts par carddav.

        Comme c'est le backend Evolution, tu peux ensuite utiliser en frontend soit Evolution, soit Gnome Calendar, soit Gnome Contact pour accéder à tes infos (voir même California qui était développé par Yorba, mais dont je ne sais pas si des mainteneurs ont repris le projet).

        PS: même que le racourci webdav est automatiquement ajouté à Nautilus et Gnome Documents peut faire des recherches directement avec les mineur en ligne de Tracker.

        • [^] # Re: Montage webdav/davfs2

          Posté par voxdemonix le 30 décembre 2017 à 14:03. Évalué à 0.

          

          Pas mal merci. Je ne trouve pas d'infos pour faire de même sur XFCE, sais-tu si c'est possible ?

          • [^] # Re: Montage webdav/davfs2

            Posté par Adrien Dorsaz (site web personnel, Mastodon) le 30 décembre 2017 à 18:08. Évalué à 3.

            

            Si je me souviens bien, XFCE n'a pas de gestionnaire de compte centralisé commme gnome-online-account qui se cache derrière gnome-control-center). Il te faudra donc trouver des outils qui connaissent caldav, carddav, webdav et tous les configurer à la main.

            Pour caldav et carddav, Evolution sait gérer, mais tu devras configurer chaque calendrier et chaque carnet d'adresse à la main. Il y a aussi Thunderbird, mais il faut utiliser l'extension SoGo.

            Pour webdav, c'est géré par gnome-vfs qui est utilisé par Thunar si mes souvenirs sont bon.

• # Le service de gestion Nextcloud ideal

  Posté par Gueulderack le 28 décembre 2017 à 12:36. Évalué à 3.

  

  Salut,

  je suis un peu étonné par ton retour sur Nextcloud. Pour ma part, j'ai decouvert owncloud il y a 3 ans, ou je te l'accorde, a l'epoque, c'etait une belle galere a installer et a gerer. Mais tres rapidement ca s'est ameliore. Je suis passe a nextcloud il y a 2 ans, mais dans l'ensemble, l'administration du service reste le meme.
  Pour ce qui est des ressources utilisees. la aussi, j'ai du mal a te croire. Par exemple, l'annee derniere, j'avais installe un serveur nextcloud sur un laptop equipe d'un celeron 1GHz et de 1Go de memoire vive. Dessus etait branche un disque dur usb de 500 Go. La base de donnee etait en MariaDb, et ca marchait au poil, pour 3 utilisateurs et 300 Go de donnees synchronisees.

  Malgres cela, je ne voulais plus avoir a gerer l'administration de ce service. Je me suis donc mis a la recherche d'un service Nextcloud, me permettant de stocker 500 Go de maniere securisee (donc au moins en europe), crypte, et pas trop cher. J'ai trouve ce service: ItsGow

  Situe en Suisse, (mais les serveurs sont en France), je paye 130 euros par ans pour 500 Go de donnees stocke chez eux. Il n'y a aucune limite d'utilisateur, de debit, de taille de ficheir ou meme de plugin pouvant etre installe sur votre instance. Vous faites ce que vous voulez de votre instance. Les debits sont excellents, et la disponnibilite parfaite. Bref je vous le recommande si vous ne souhaitez pas vous embeter comme moi.

  @+

• # vocabulaire

  Posté par steph1978 le 31 décembre 2017 à 16:37. Évalué à 2.

  

  Quand tu dis

  Nextcloud consomme plus de mémoire que prévu.

  Je le lis comme "RAM".
  Alors qu'en lisant le détail du paragraphe, je pense que cela parle d'espace de stockage disque.
  C'est confondant.

  D'autre part, je partage l'avis des commentaires employant le terme délirant quant au dimensionnement dont il est question dans l'article. Mon expérience est sur owncloud - mais l'architecture est semblable - et confirme que l'on peut héberger une dizaine d'utilisateurs actifs sur petite machine.

  • [^] # Re: vocabulaire

    Posté par voxdemonix le 31 décembre 2017 à 17:20. Évalué à -5. Dernière modification le 31 décembre 2017 à 17:25.

    

    et confirme que l'on peut héberger une dizaine d'utilisateurs actifs sur petite machine.

    Si on lit les commentaires ci-haut on se rend compte qu'ils se limitent TOUS aux clients de synchronisation de fichiers Nextcloud/Owncloud.
    À part un commentaire qui se plain lui aussi du support webdav pourris côté client, personne n'est venu indiquer utiliser toutes les autres fonctionnalités disponible (synchronisation de calendrier, note, news, géolocalisation, webdav, streaming, crypto).
    Sans ajouter que la majorité semble déléguer l'hébergement à OVH (qui utilise des VM) et donc n'ont aucune idée de la puissance machine requise par Nextcloud pour les auto-hébergés adeptes de machines de récupération.

    Donc enfaîte, en gros, vous prêchez le faux uniquement [par fierté] car vous vous restreignez à l'utilisation de Nextcloud à ce que permettait Owncloud avant le fork.
    Si non je suis honnêtement curieux de pouvoir comparer la puissance machine requise par vos infras lorsque vous avez votre service de backup qui tourne en même temps qu'au moins 5 utilisateurs simultanés (qui font plus que laisser tourner le client de synchro).

    Note : je suis aussi très curieux d'avoir des retours de gens qui ont activé le module "Encryption" avec au moins 1 To de données (partagé entre plusieurs utilisateurs histoire de bien faire tourner la mécanique).

    • [^] # Re: vocabulaire

      Posté par steph1978 le 01 janvier 2018 à 22:24. Évalué à 3.

      

      Client de synchro : c'est l'usage principal.
      Et la synchro ça utilise webdav. Donc je vois même pas pourquoi différencier les deux du point de vue serveur.
      J'ai en plus, la synchro calendrier, contact, l'instant upload, la sychro mozilla.
      Je rsync tous les soirs pour externaliser les sauvegardes.
      Mes utilisateurs stockent 133k fichiers pour 160GB.
      La machine fait aussi seedbox.
      Le serveur est un serveur physique, un KS1 de chez OVH, donc le moins puissant qu'ils aient.

      Donc enfaîte, en gros, vous prêchez le faux uniquement [par fierté]

      En fête, c'est pas de la fierté, juste du réalisme.

      • [^] # Re: vocabulaire

        Posté par voxdemonix le 02 janvier 2018 à 02:38. Évalué à -2. Dernière modification le 02 janvier 2018 à 02:41.

        

        Et la synchro ça utilise webdav.

        Je ne sais pas quel protocole le client nextcloud utilise mais le client indiqué dans son user agent est mirall tandis que le client utilisé par Thunar est davfs2.

        Donc je vois même pas pourquoi différencier les deux du point de vue serveur.

        Si le client de synchro prend deux heures pour télécharger/uploader tes fichiers, tu t'enfou.
        Par contre tes applications (ex jdownloader) qui freezent pendant plusieurs minutes, surtout le gestionnaire de fichier, c'est bourrin.
        Petit truc bourrin aussi: si tu ouvres un dossier webdav avec ton gestionnaire de fichiers et que dans ce dernier tu as des vidéos, tu va te taper un énorme lag (voir freeze) pendant que ton gestionnaire de fichier va télécharger toutes les vidéos du dit dossier afin de créer ses prévisualisations.

        Client de synchro : c'est l'usage principal.

        Et donc on ne devrait faire que ça?
        Puis, ne serait-ce pas aussi simplement car la majorité des utilisateurs de nextcloud ne savent pas se qu'est un montage distant?

        En fête, c'est pas de la fierté, juste du réalisme.

        Si tu veux de la scalabilié et de la haute dispo, tu dois utiliser des logiciels qui sont originellement conçu pour tourner sur des machines véloces et dédiées. Ils surconsomment et n'aiment pas quand ils arrivent au bout des ressources (ni que le ping monte trop haut).
        Le nier est futile et mène à des déceptions.

        Le serveur est un serveur physique, un KS1 de chez OVH, donc le moins puissant qu'ils aient.

        J'ai l'impression que beaucoup de gens sont chez un hébergeur et je m'en viens a me demander pourquoi?
        Ne pas avoir confiance en Dropbox mais avoir confiance en OVH n'est-il pas contradictoire?

        • [^] # Re: vocabulaire

          Posté par steph1978 le 02 janvier 2018 à 11:10. Évalué à 4.

          

          Si le client

          On parlait performance serveur et tu repars sur le comportement client.

          Si le client charge des vidéos pour afficher une liste de fichiers distants comme si il lisait en local, peu importe le protocole et la puissance du serveur : ça va lagguer, c'est principalement dû à la bande passante et ma latence : 100Mbps en remote contre 3Gbps en local, y a pas photo.

          J'ai l'impression que beaucoup de gens sont chez un hébergeur et je m'en viens a me demander pourquoi?

          Disons que c'est un compromis. C'est plus fiable que de l'auto-hébergement principalement question électricité et sans la fibre à la maison, c'est même pas vraiment envisageable.

          Ne pas avoir confiance en Dropbox mais avoir confiance en OVH n'est-il pas contradictoire?

          Si ça peut se comparer du point de vue utilisateur (quoique patriot act, etc.), du point de vue de l'administrateur système, ça n'a rien à voir.

        • [^] # Re: vocabulaire

          Posté par gouttegd le 02 janvier 2018 à 12:28. Évalué à 4.

          

          J'ai l'impression que beaucoup de gens sont chez un hébergeur et je m'en viens a me demander pourquoi?

          Une raison parmi d’autres : je viens de déménager et il m’a fallu pas moins de six semaines pour avoir une connexion Internet dans mon nouvel appartement.

          J’étais bien content que mon serveur mail/contacts/agenda/etc. soit bien au chaud dans un datacenter bien connecté d’où je pouvais toujours le joindre avec le peu de connectivité que j’avais (depuis mon lieu de travail ou en passant par mon téléphone avec des cartes 4G pré-payées).

          L’auto-hébergement, c’est peut-être bien pour quelqu’un qui a une situation raisonnablement stable. Mais quand on ne sait pas où on sera dans deux ans (dans quelle ville voire dans quel pays), quel service on pourra avoir (FTTH ? FTTC ? ADSL ? port 25 ouvert ? adresse IP fixe ? IPv6 ?) et à quel prix, ou combien de temps ça va prendre (deux jours, deux semaines ou deux mois ?)… non merci.

          • [^] # Re: vocabulaire

            Posté par voxdemonix le 02 janvier 2018 à 19:05. Évalué à -4.

            

            J’étais bien content que mon serveur mail/contacts/agenda/etc. soit bien au chaud dans un datacenter bien connecté d’où je pouvais toujours le joindre avec le peu de connectivité que j’avais (depuis mon lieu de travail ou en passant par mon téléphone avec des cartes 4G pré-payées).

            Pour le côté geek? Car a respect de la vie privé égale (france-USA, kiff kiff bouricot), je suppose que les gafam seront moins chers et plus fiable.

        • [^] # Re: vocabulaire

          Posté par Psychofox (Mastodon) le 02 janvier 2018 à 17:22. Évalué à 5.

          

          Ne pas avoir confiance en Dropbox mais avoir confiance en OVH n'est-il pas contradictoire?

          Les deux idées n'ont aucun rapport entre elles.

        • [^] # Re: vocabulaire

          Posté par damaki le 05 janvier 2018 à 12:11. Évalué à 2. Dernière modification le 05 janvier 2018 à 12:12.

          

          J'ai l'impression que beaucoup de gens sont chez un hébergeur et je m'en viens a me demander pourquoi?
          Ne pas avoir confiance en Dropbox mais avoir confiance en OVH n'est-il pas contradictoire?

          Oui et non. Oui, parce que mes VPS loués sont localisées en France, pas aux états-unis et oui parce que je les administre moi même.
          Non, je n'ai pas une confiance absolue en OVH. C'est bien pour ça que j'attends avec une grande impatience le chiffrement bout-en-bout sur Nextcloud. Mais pas spécialement à cause d'OVH en soi, mais au cas où le serveur serait compromis.

          Sinon, comme ça a été évoqué dans d'autres réponses, j'ai aussi une connexion misérable à domicile, avec un upload insuffisant pour beaucoup d'usages (12 Mb/s down, 1 MB/s up). Donc je n'ai pas vraiment le choix. A noter que si j'avais la fibre, s'auto-héberger correctement demande pas mal de taf. Ca demande de savoir bien faire de l'administration réseau et d'isoler correctement les serveurs du reste du réseau local, pour éviter les pépins en cas de brèche.

          On parle de Nextcloud et de stockage de fichiers, mais pour stocker ses mails le problème est le même. En effet, la plupart des hébergeurs les stockent en clair (sauf protonmail et probablement d'autres) et je ne connais pas de solution open source permettant de chiffrer les mails avec une clé publique lors de la réception, de les déchiffrer côté client.

          • [^] # Re: vocabulaire

            Posté par voxdemonix le 05 janvier 2018 à 13:09. Évalué à 1.

            

            Oui, parce que mes VPS loués sont localisées en France, pas aux états-unis

            Je pense compréhensible pour tout le monde que cet argument n'est valable que pour des franco-français (et encore, faut être ni militant, ni opposé au gouvernement, ni fumeur de djogo, etc). En tant que belge j'accorde aussi peu de confiance aux pays de la Lois Renseignement qu'aux pays du Patriot Act :P

            je ne connais pas de solution open source permettant de chiffrer les mails avec une clé publique lors de la réception, de les déchiffrer côté client.

            Ce n'est pas de l'émail a proprement parlé, mais l'implémentation du mail dans RetroShare correspond à cela.

            Mais pas spécialement à cause d'OVH en soi, mais au cas où le serveur serait compromis.

            Il y a aussi le cas où le disque dur tombe en panne ou part sur le marché de seconde main.

          • [^] # Chiffrement des mails à la réception

            Posté par Arthur Accroc le 05 janvier 2018 à 14:15. Évalué à 2.

            

            On parle de Nextcloud et de stockage de fichiers, mais pour stocker ses mails le problème est le même. En effet, la plupart des hébergeurs les stockent en clair (sauf protonmail et probablement d'autres) et je ne connais pas de solution open source permettant de chiffrer les mails avec une clé publique lors de la réception, de les déchiffrer côté client.

            Posteo le propose et affirme n’utiliser que des logiciels open source et publier ses propres développements sur son dépôt GitHub.

            C’est donc que ça doit être possible ; cela dit, je ne sais pas comment est configuré leur serveur pour faire ça.

            « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

            • [^] # Re: Chiffrement des mails à la réception

              Posté par damaki le 08 janvier 2018 à 08:33. Évalué à 1.

              

              J'y ai un peu plus réfléchi et ça doit être possible de bricoler ça avec procmail. Il reste cependant le souci de traiter les mails passés et d'avoir un client Android compatible ou un bridge (un peu comme protonmail depuis peu).

    • [^] # Re: vocabulaire

      Posté par Adrien Dorsaz (site web personnel, Mastodon) le 01 janvier 2018 à 23:01. Évalué à 4.

      

      Ce que je ne comprends pas vraiment, c'est pourquoi tu insistes pour utiliser wedav¹ ?

      De mon expérience avec le module mod_dav d'Apache2 et aussi le module d'Owncloud à l'époque (vers 2013, en utilisant Nautilus et/ou un montage dav2fs pour la partie client), ça ne marche pas hyper bien, les clients donnent des erreurs incompréhensibles au bout d'un moment (style, "Serveur indisponible", "verrou actif sur le fichier", alors que j'étais juste en train de naviguer à travers les dossiers et que je suis le seul à utiliser ces dossiers; maintenant que j'y pense, il faut sûrement donner des instructions spéciales au serveur web pour la gestion du protocole HTTP dans ce cas, car il va y avoir beaucoup de requêtes et que ce n'est pas vraiment le comportement par défaut attendu pour des clients HTTP).

      Le client de synchronisation quant à lui est clairement intéressant, puisqu'il ne surcharge pas le serveur web avec des requêtes HTTP fréquentes pour simplement naviguer à travers les fichiers. Le système de fichier local est efficace pour rechercher à travers les méta-données des fichiers et, si tu utilises des logiciels comme Tracker/Baloo, ils sont complètement fonctionnels (à l’exception du fait que Nextcloud ne synchronise pas les extended attributes).

      Le client est capable d'écouter les modifications sur le poste local pour les envoyer au serveur. Dans l'autre sens, il retrouve automatiquement les modifications du serveur pour les appliquer en local. Seul les données modifiées passent à travers le réseau et donc la bande passante, la RAM et le CPU du serveur sont largement moins utilisées qu'avec le webdav.

      En plus, seul le client est compatible avec le nouveau chiffrement end-to-end (E2E, client-à-client) annoncé en fin d'année 2017: https://nextcloud.com/blog/nextcloud-introducing-native-integrated-end-to-end-encryption/ (voir les commentaires).

      Pour le chiffrement côté serveur, c'est bien écrit dans la documentation que son seul intérêt est pour l'envoi des données sur des "Remote Share" (style Google Docs, Dropbox, …):

      The primary purpose of the Nextcloud server-side encryption is to protect users’ files on remote storage, such as Dropbox and Google Drive, and to do it easily and seamlessly from within Nextcloud.

      Or souvent, le but est d'utiliser Nextcloud est de se détacher de ces services, donc ça ne me surprend pas que peu de monde active ce chiffrement.

      Sans ajouter que la majorité semble déléguer l'hébergement à OVH (qui utilise des VM) et donc n'ont aucune idée de la puissance machine requise par Nextcloud pour les auto-hébergés adeptes de machines de récupération.

      J'utilise Nextcloud sur un laptop Acer acheté à l'époque de Windows Vista: Nextcloud ne consomme quasiment rien sur mon serveur (mais bon, évidemment, il n'est pas constamment en train de gratter les disques et envoyer des données puisque je n'utilise la fonctionnalité webdav qu’occasionnellement). C'est surtout Gitlab qui se goinfre de CPU et de RAM chez moi, mais c'est gérable grâce aux limitations de ressources par service proposées par les slice de systemd.

      ---

      ¹ Note bien que je ne parle que de webdav, car c'est lui qui utilise le plus de ressources pour communiquer (CPU, RAM, bande passante) à cause de la nature et de la quantité de données: caldav et carddav ont beaucoup moins d'impact sur ces ressources, car les données finales à transmettre sont beaucoup plus petites que des milliers de fichiers.

      • [^] # Re: vocabulaire

        Posté par voxdemonix le 02 janvier 2018 à 01:51. Évalué à 1. Dernière modification le 02 janvier 2018 à 01:56.

        

        Ce que je ne comprends pas vraiment, c'est pourquoi tu insistes pour utiliser wedav1 ?
        Le client de synchronisation quant à lui est clairement intéressant, puisqu'il ne surcharge pas le serveur web avec des requêtes HTTP fréquentes pour simplement naviguer à travers les fichiers.

        Client de synchro nextcloud = alternative a rsync (voir syncthing).
        Webdav/davfs2 = alternative à sshfs/sftp.
        L'utilité et le fonctionnement ne sont pas les mêmes, une utilisation n'est pas une autre.
        Exemple d'utilisation : un utilisateurs qui a plusieurs machines et souhaitent y accéder sans devoir les stoker sur chaque machine. Quel intérêt de synchroniser les archives de vidéos surveillance sur son smartphone? Aucune, par contre les visionner en streaming via l'interface web ou via VLC+webdav là c'est plus cool :P (par contre c'est dommage qu'on ne peut pas gérer les fichiers depuis son gestionnaire de fichier, ou afficher les commentaires etc)

        En plus, seul le client est compatible avec le nouveau chiffrement end-to-end (E2E, client-à-client) annoncé en fin d'année 2017: https://nextcloud.com/blog/nextcloud-introducing-native-integrated-end-to-end-encryption/ (voir les commentaires).
        Pour le chiffrement côté serveur, c'est bien écrit dans la documentation que son seul intérêt est pour l'envoi des données sur des "Remote Share" (style Google Docs, Dropbox, …):

        Intéressant, je ne pensais pas que le fichiers dans files_encryption étaient suffisant pour le déchiffrement. Nextcloud baisse drastiquement dans mon estime :( (va falloir activer la crypto au niveau system file se qui nécessite d'encore apprendre un autre logiciel youpee)

        Note bien que je ne parle que de webdav, car c'est lui qui utilise le plus de ressources pour communiquer

        Oui il consomme exagérément de ressources comparé à SSHFS. En monoserveur dés qu'un utilisateur utilise ce type de montage en UI (car j'ai l'impression que les robots ont moins de soucis), on le remarque.
        Typiquement activer les prévisualisations des fichiers images et vidéos peut provoquer une bonne grosse charge sur le serveur et de long freezes dans les gestionnaires de fichiers.

        • [^] # Re: vocabulaire

          Posté par voxdemonix le 02 janvier 2018 à 02:43. Évalué à 0.

          

          par contre c'est dommage qu'on ne peut pas gérer les fichiers depuis son gestionnaire de fichier, ou afficher les commentaires etc

          faute de frappe, je voulais dire "[…]par contre c'est dommage qu'on ne peut pas gérer les partages depuis son gestionnaire de fichier, ou afficher les commentaires etc[…]

    • [^] # Re: vocabulaire

      Posté par jolitorax le 02 janvier 2018 à 17:24. Évalué à 4.

      

      Pour un Owncloud 7 pour environ 80 personnes avec une quinzaine très actives, c'est sur notre plateforme de virtualisation (VMWare):

      2 cpu virtuelles
      4 Go de mémoire
      600 Go de disque

      Il est géré en best effort, et tourne depuis 3 ans.

      D'après la supervision, on a été très gras avec la machine virtuelle, puisque on utilise entre 5 et 10% de mémoire et moins de 5% de CPU.
      Je n'ai pas de chiffres sur Nextcloud puisqu'on ne l'utilise pas (encore), mais ça donne une idée.

• # Noms de fichier et compatibilité Linux / OsX / Windows

  Posté par Benjamin (site web personnel) le 08 janvier 2018 à 11:41. Évalué à 2.

  

  Bonjour,

  à ajouter : un bug qui m'a pourri des jours durant :

  Si vous avez un utilisateur sur MAC / OsX qui crée des fichiers avec "/" dans le nom (oui, c'est possible sur Mac…) le finder de Mac nomme en fait le fichier avec ":" au lieu de "/"

  Or, ni "/" ni ":" ne sont autorisés sous Windows, et "/" n'est pas autorisé sous Linux donc :

  • sous Linux le fichier est bien synchronisé avec ":" dans le nom
  • sous Windows, le fichier est juste ignoré par le client de synchronisation :/

  Seule solution : renommer en masse pour remplacer les "/" par, par exemple, un "-".

  • [^] # Re: Noms de fichier et compatibilité Linux / OsX / Windows

    Posté par voxdemonix le 09 janvier 2018 à 15:49. Évalué à 0.

    

    Informations utile à savoir.
    Peut-être le signaler dans le bug trackers de nextcloud afin qu'ils mettent une rustine :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.