Journal Retour d'expérience Nextcloud

Posté par  . Licence CC By‑SA.
26
25
déc.
2017

Sommaire

Préambule

  • Nextcloud est un logiciel libre de stockage en ligne permettant de créer un cloud. Nextcloud est une alternative a owncloud, pydio, cozycloud, seafile. Il permet de synchroniser des données, depuis divers appareils principalement mobile, sur un ou plusieurs serveurs. Avec son mécanisme d'utilisateurs il permet aussi de partager des informations et fichiers avec des permissions assez fine.
  • Attention : Je vais énoncer pas mal de défauts et avoir parfois un ton péjoratif envers Nextcloud. Néanmoins je n'ai pas encore testé la concurrence (et donc ne puis actuellement pas comparer aux autres offres) et suis complètement fan de se que permet de faire Nextcloud. Origine de l'article : Retour d'expérience Nextcloud

Les fonctionnalités (que j'ai testé)

  • Gestion des utilisateurs, groupes, cercles (groupe administré par les utilisateurs)
  • Fédération de serveur (possibilité d'échanger avec des utilisateurs d'autres serveurs nextcloud|owncloud|pydio)
  • Stockage/partage de fichiers.
  • Synchronisation de données de géolocalisation avec possibilité de partage et de visualisation sur une carte.
  • Synchronisation de contacts.
  • Synchronisation des SMS.
  • Client mail.
  • Gestionnaire de flux RSS/Atom.
  • Streaming de fichier multimédia (.mp3, .flac, .wav, .mp4)
  • Montage de serveurs distants (entre autre : SFTP, FTP, DropBox, Google Drive, Webdav, Open Stack Object Storage, Nextcloud, Amazon S3).
  • Galerie de photos/images.
  • Synchronisation, édition et visionnage de Calendriers (webcal).
  • Installation/suppression d'extension tiers.
  • Synchronisation de favoris/marque-page de navigateur.
  • Synchronisation/édition de Note
  • Édition de documents.
  • Vidéos-conférence (via WEBRTC).
  • Tchat via XMPP ou non.
  • Mood (alternative au mur de facebook, encore trop dur a mettre en place)
  • Accès aux fichiers depuis un client via montage webdav/davfs2.

L'installation.

  • En suivant les tutoriaux sur le net il devient assez facile de mettre en place un serveur simple de Nextcloud.
  • Le plus simple se résumant sur ubuntu/debian à lancer la commande apt-get install nextcloud, qui va installer automatiquement nextcloud.
  • Si non, manuellement, il suffit d'installer un serveur web (apache2, nginx), un moteur de base de données (PostGreSQL, MariaDB), créer un utilisateur de base de données puis laisser la webui de nextcloud faire son job.
  • Par contre si vous souhaitez bien faire la difficulté se fait rapidement sentir : unifier des disques dur, créer un raid réseau, mettre en place des systèmes de backup pour la base de données voir pour les fichiers, mettre en place un ou plusieurs répartiteurs de charge, répartir les fichiers du serveur web sur plusieurs machines. Tout ces problèmes sont compliqué à régler et ce même si vous suivez les tutos. Sans compter la demande de puissance machine exagérée et les instabilités liés aux bugs logiciels.

Fonctionnement.

  • Le moteur de nextcloud est basé sur des scripts en PHP (5.4+). L'interface quant à elle est faite en HTML5 avec une utilisation massive d'AJAX offrant une certaine fluidité. Cette fluidité à des limites vu que les mises à jours de fichiers ne sont pas forcément directement répercutées sur l'interface web. (c'est implémenté, mais ça bug :D ) Ce système fait que la consommation machine d'un montage webdav/davfs2 va consommer beaucoup beaucoup beaucoup plus de ressources qu'un montage SFTP/SSHFS.

Requis Hardware.

  • Pour le test.
    • Un simple raspberry pi type 1 ou équivalent suffit (très fort lag).
    • Consommation électrique : de 1 à 5 watts.
  • Pour une utilisation par un unique utilisateur.
    • Un raspberry pi type 3, un Odroid XU4 ou autres équivalent suffit. Ça laggera mais se sera utilisable.
    • Consommation électrique : de 5 à 25 watts.
  • Pour une utilisation pour 1 à 5 utilisateurs sans protection des données.
    • Un processeur 64bit QuadCore (au moins 2Ghz) sera le minimum requis. Il devra être accompagné d'au moins 4Go de RAM.
    • Consommation électrique : de 35 à 150 watts.
  • Pour une utilisation pour 1 à 10 utilisateurs avec protection des données.
    • Là il vous faudra au minimum 3 machines puissantes + 2 ou 3 moins puissantes. Ceci afin de faire tourner un cluster de base de données MariaDB, un raid réseau (glusterfs consomme moins que Ceph, mais est complètement instable (voir ici, ici et ici), unifier la mémoire sur chaque machine avec btrfs (qui consomme à lui seul 3x la charge d'un intel i3 d'après ma commande top) et faire tourner le serveur web.
    • Ces logiciels sont tellement gourmand que chacun nécessiterait une machine dédiée pour fonctionner sans lag ni erreur. Sans compter que pour disposer d'une haute disponibilité + un système de backup cela signifie de tripler voir quadrupler la mémoire. Si vous installez le serveur web sur plusieurs machines il ne faudra pas non plus oublier d'ajouter un répartiteur de charge (voir ce tuto).
    • Consommation électrique : de 150 à 500 watts.

Astuces

Ne faites pas confiance au LAN.

  • 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).

HTTPS n'apporte AUCUNE sécurité en LAN.

  • Pour qui sait lire les tutos en anglais sur le net, il n'est guère impossible de casser une connexion https non certifiée. Comme on ne peut certifier les noms de domaines ou IP LAN, et qu'on a autre chose à faire de notre vie que de vérifier manuellement des certificats TLS, je vous conseil de privilégier le passage par un VPN. (attention qu'OpenVPN est mono-thread et limitera donc drastiquement votre débits, Wireguard a de meilleures performances mais est très mal documenté et en version AlphaTest uniquement).

Nextcloud est compatible multi-domaines et Tor Hidden Service.

  • Alors ne vous en privez pas, quand votre nom de domaine principale sera inaccessible pour une raison X ou Y ou que votre frontend se tapera un bad, cela vous dépannera fortement.

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

  • Nextcloud s'amuse a stocker plusieurs versions d'un même fichier lorsqu'il y a modification. On peut régler ce mécanisme mais pas le supprimer.
  • Il va aussi stocker des fichiers nomFichier.ocTransferidxxxxxx.part en assez grand nombre et dont je n'ai pas compris s'il compte les supprimer au bout d'un moment ou non. Ces fichiers contiennent les données de fichiers que l'on est en train ou que l'on a tenté d'envoyer sur le cloud.
  • La corbeille ne se vide automatiquement que quand l'utilisateur fait une action sur les fichiers (modification ou ajout) et que l'utilisateur consomme au moins 50% du quota mémoire qu'on lui a alloué. (vous les remarquerez vite quand vous ferez un backup de vos fichiers avant une ré-installation)

Taggez vos fichiers.

  • L'option est toute discrète sous le nom de chaque fichier dans ses détails propre, mais elle est disponible ! Cette option est tout simplement géniale pour s'y retrouver dans ses fichiers ainsi que dans les partages (car avouons le, sur le cloud on est généralement aussi bordélique quand dans une chambre d'adolescent).

Utilisation de serveur distant (stockage externe).

  • Si vous n'avez pas la fibre, pour envoyer un fichier de plus de quelques Mo je vous conseils très fortement de d'abord poster votre fichiers sur votre serveur puis de le Déplacer vers le montage externe. Ceci vous évitera de saturer la connexion de votre serveur et de devoir laisser activer votre page de téléchargement ou votre montage webdav/davfs2 durant des heures. En effet si vous postez un fichier sur un montage externe, les données seront envoyées directement dessus.

Les bugs qui m'ont pêté les burnes.

Nextcloud refuse de modifier certains fichiers.

  • Parfois pour une raison inconnue Nextcloud refuse de déplacer, modifier, renommer, supprimer certains fichiers. Ce problème n'est pas lié à une erreur de permission sur les fichiers ni un fail du système de fichier.

Quand la base de données ne suit pas Nextcloud crash plus tôt qu'attendre.

  • Ce problème a provoqué chez moi des erreurs de type "General error: 2006 MySQL server has gone away" par milliers et ce malgré que la commande top sur mes serveurs n'indiquaient aucune surconsommation de ressources machine. C'est très très pénible car cela nécessite de relancer plusieurs fois les clients lorsqu'on veut exporter des centaines/milliers de fichiers ou lorsqu'on tente d'expédier des gros fichiers.

Nextcloud refuse de fonctionner si le propriétaire du fichier de configuration (config.php) n'est pas le même que celui qui fait tourner le serveur web (apache2/nginx)

  • Ce mécanisme (qui n'est pas un bug) ne vous ennuiera que lorsque vous utiliserez plusieurs machines comme serveur web et qu'il faudra propager des modifications via un utilisateur dédié (comme ici).

Les clients webdav/davfs2 sont pourris.

  • Ce n'est ici pas de la faute de Nextcloud mais bien des logiciels clients.
  • Le client de base de Windows est volontairement pourris afin de pousser les gens à utiliser Google Drive (on dira que c'est habituel venant d'une boite malhonnête comme microsoft). Le client fonctionnera quand bon lui semblera et cassera à chaque redémarrage.
  • Sur Android les clients sont actuellement lié à leur logiciel de système de fichier, se qui fait que vous pourrez accéder a vos fichiers depuis ce logiciel mais pas depuis l'ensemble de votre écosystème.
  • Sur Ubuntu/Debian le client est un peu plus poussé mais pas terrible pour autant. Si un logiciel a besoin d'un morceau de fichier, plus tôt que de streamer ce morceau de fichier comme avec SSHFS, davfs2/webdav va télécharger tout le fichier, le lire puis le supprimer. Cela va bouffer de la bande et des ressources inutilement. Le client n'est pas capable de demander des hashages à distance, si vous l'utilisez avec des logiciels de partages de fichiers type P2P, F2F, Torrent chaque fichiers devra être téléchargé localement avant d'être hashé puis supprimé. Donc déconseillez à vos utilisateurs de partager des dossiers cloud sur ces logiciels.

Routeur pas compatible HairPinning.

  • Encore une fois, ce n'est pas de la faute de Nextcloud mais bien des fabricants de routeurs et des fournisseurs d'accès internet qui refilent des box bridées. Le HairPinning est une option normalement implémentée dans tout les routeurs et permettant de joindre vos services via votre nom de domaine que vous soyez sur votre LAN ou sur internet. Si vous avez une box pourrie, vous devrez soit la remplacer par un vrai routeur soit utiliser des hacks (exemple avec OpenVPN).

Conclusion

Nextcloud est un énorme goinfre en puissance machine qui se retrouve très vite limité, voir buggé, par le processeur et la quantité de RAM.
Nextcloud et ses dépendances ne sont pas vraiment des exemples de stabilité, et cette surconsommation de ressource provoque des erreurs à la pelle à s'en arracher les cheveux.
Notons que souvent, même quand les machines glandent, on se tape des tonnes de "Internal server error" et de temps en temps tout pète.
Comme pour une majorité de logiciels libre, Nextcloud est très prometteur et nous fait regretter de ne pas être né dans 50 ans (quand on en aura terminé avec tout ces "'projets prometteurs" et que l'on pourra enfin utiliser des "projets stable et "just work' pour le long terme").
Des fois tout fonctionne pendant plusieurs jours/semaine voir mois puis pouff sans rien avoir touché (ni mis à jours) vous vous retrouvez avec des bugs et problèmes prises de tête.
Sachez que mettre en place un Nextcloud capable de vivre plusieurs années nécessitera que vous développiez un panel de compétences très (trop) large en matière d'administration système, de sécurité, de réseau, d'hardware. Bref vous y passerez plus de temps que sur un MMORPG, et ce sans y trouver forcément du plaisir. Au début vous serez fier de vous comme après avoir butté votre premier boss dans Dark Soul 3, mais rapidement vous en viendrez à vous faire la remarque que vous dépensez beaucoup de votre temps de vie pour apprendre des trucs qui seront très probablement inutile dans 10 ans.
Pour l'anecdote à au moins 3 reprises en cluster (et au moins 2x en mono-serveur) mon nextcloud a crashé, nécessitant une ré-installation totale avec pertes de données lorsque le module de chiffrement est utilisé.

Mis à part ça, Nextcloud offre des outils auquel on devient vite accroc, dont l’indisponibilité même temporaire se remarque très rapidement. On retrouve cette impression de maîtrise de ses données (l'admin n'ayant pas accès aux datas lorsque le module de chiffrement est activé).
Si vous n'avez jamais essayé Nextcloud, vous avez loupé une petite révolution.

Tuto

Problèmes et solutions

Quelques screenshot

Odroid-XU4 (bien ventilé) dédié à Nextcloud avec un seul client qui upload (via nextcloud-client synchronisation), les fichiers sont accessible via montage glusterfs.

screenshot-2017_10_06-OdroidXu4-Dedied_4_Nextcloud_With_Glusterfs_Mountage_With_Remote_MariaDB_#Overload

Interface web de Nextcoud, vue Login (avec extension Unsplash activée qui change le fond d'écran à chaque affichage).

screenshot-2017_12_25-Nextcloud-Login

Interface web de Nextcoud, vue des fichiers.

screenshot-2017_12_25-Nextcloud-Fichiers

Interface web de Nextcoud, vue des Activités.

screenshot-2017_12_25-Nextcloud-Activité

Interface web de Nextcoud, vue Visionneur de Document (ici PDF).

screenshot-2017_12_25-Nextcloud-Visionnneur_de_document_pdf

Interface web de Nextcoud, vue Galerie.

screenshot-2017_12_25-Nextcloud-Galerie_photo_images

Interface web de Nextcloud, vue Gestion des Utilisateurs.

screenshot-2017_12_25-Nextcloud-Admin_Gestion_des_utilisateurs

Joyeux Noël !

  • # "Chez moi ça marche"™

    Posté par  . É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  . É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  . É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  (Mastodon) . É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.

          Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

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

            Posté par  . É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  . É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  . É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  . É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  . É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  . Évalué à 2.

        J'avais eu la réponse dans ce sujet de l'aide. J'avais utilisée la solution bourinnissime décrite .
        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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  . É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  (site web personnel, Mastodon) . É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  . É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  . É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  . É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  . É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).

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

    Posté par  (site web personnel) . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  . É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  . É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  (site web personnel, Mastodon) . É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  . É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  (site web personnel, Mastodon) . É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  . É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  . É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  . É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  . É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  . É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  . É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  (site web personnel) . É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  . É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  (Mastodon) . É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.

            Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

          • [^] # Re: vocabulaire

            Posté par  . É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  . É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  . É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  . É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  (site web personnel, Mastodon) . Évalué à 4.

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

        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.


        1 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  . É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  . É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  . É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  (site web personnel) . É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 "-".

Suivre le flux des commentaires

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