Les bugs de owncloud étaient effectivement dur à supporter au début.

A présent NextCloud assure très bien et j'ai plusieurs PME qui
l'utilisent de façon intensive (multi desktop / smartphone / tablette
par compte souvent en même temps). Le seul reproche que j'ai à faire
c'est le stockage externe Swift / S3 qui s'intègre pas comme racine des
comptes mais en tant que sous répertoire. Du coup dur de proposer une
solution où le stockage n'est pas local, les utilisateurs ayant tendance
de tout mettre à la racine.

Seafile je l'ai écarté par le côté restrictif des différences entre la
version open source et pro. Certains clients n'iront pas payer des
comptes à des prix hallucinants pour un compte pour un prestataire
externe qui doit juste déposer une fois pas mois des fichiers. Et
pourtant on les encourage à prendre du support payant mais là c'était
vraiment pas tenable pour une boite de 40 personnes avec 120 comptes
externes.

Sinon en très bien aussi https://syncthing.net/ mais moins orienté client.

Le 06/03/2018 à 19:33, Stéphane Rivière a écrit :

Bonsoir Emmanuel,

Puisque tu abordes le sujet, tu évoques Seafile et tu n'es pas le

premier qui m'en parle. Ça consiste en quoi la meilleure fiabilité ?

Ayant commencé par Owncloud, j'en étais parfaitement content. Je

l'avais testé quelques mois, ça semblait rouler génial et tout...

Alors je le met en prod. Evidemment, plus de monde que moi tout seul

pour tester sur quelques PC... Puis quelques temps plus tard (pas eu

longtemps à attendre), des fichiers ont été explosés.

Bien sûr le pétage de fichiers a été propagé sur tous les repository

clients. J'aurais pas eu de sauvegardes journalisées dessus, j'étais

mort. Quand même passé pour un "crétin d'admin" auprès des users :()

Creusé dans les sources d'owncloud et trouvé l'endroit où la grande

décision (ce fichier a t-il été mis à jour ou pas ?) était prise et

j'ai pleuré devant la criminelle naïveté de l'algo (à l'époque tout du

moins, 2015/2016 de mémoire). J'avais décrit l'algo sur le bar@ovh à

l'époque, pas retrouvé le message.

Puis maté le coté transfert et réalisé (toujours à l'époque) que la

modif d'un bit sur un fichier d'un Go impliquait également la maj

complète (je suppose aussi que c'est mieux aujourd'hui).

Alors j'ai cherché autre chose.

Trouvé seafile, qui reprend des concepts git pour la réplication et

torrent pour les chunck et la déduplication (pour faire simple).

Avec pour résultat une fiabilité absolue et redoutable efficacité : un

truc de 4 Go a un peu bougé ? C'est détecté à coup sûr et on ne

transmet que le chunck dans lequel apparaît la modif, quelques

dizaines de Ko...

Pour mieux voir comment ça marche :

https://manual.seafile.com/develop/data_model.html

https://manual.seafile.com/develop/sync_algorithm.html

https://indico.cern.ch/event/336753/contributions/1726347/attachments/658854/905703/Seafile__Cloud_Storage_Platform.pdf

On est donc très loin d'owncloud (qui fait plein d'autres choses que

ne fait pas seafile toutefois). Seafile ne fait qu'une chose, mais le

fait incomparablement mieux. Par ailleurs l'implémentation du moteur

est en C, c'est légèrement plus efficace que le php pour ce genre de

choses. En tout cas, mon cpumètre de serveur avait aimé la migration

owncloud>seafile.

Des users qui sont content d'owncloud m'ont reporté une utilisation

cpu modérée. Ce n'est pas ce que j'ai constaté, mais préfère le dire.

Toutefois seafile n'est pas nourri à la https://www.poudreverte.org :

Si Bob et Alice chargent Toto.txt, puis sauvent avec des modifs

différentes, on obtiendra un nouveau Toto.txt et pour le second (le

dernier arrivé) un Toto-Conflict_User_GDH.txt (groupe date heure).

Charge à Bob et/ou Alice d'y mettre bon ordre à la main.

Ca m'est arrivé, entre moi-même (sic), des versions de fichiers sauvés

à partir de différentes machines... (le con). Du coup j'ai rien perdu

et bien constaté que seafile gère parfaitement des sauvegardes

multiples de version différentes : il laisse à l'humain le soin de

choisir la bonne version du fichier et "ne pense pas à sa place".

Seafile a une version libre (50 users ou users illimités je ne sais

plus) qui est très bien, une "complète payante mais gratuite (sic)" (3

users), puis une payante pas chère (100$ pour 9 users) et c'est après

que ça se gâte (le prix par siège devient plus coûteux).

La version non libre a (presque que) des fonctions pas fondamentales

pour un usage tpe (mise en avant des derniers fichiers modifiés, des

logs, des validations par machine, LDAP...). A voir selon le besoin.

La version libre est très bien.

La "mise en avant des derniers fichiers modifiés", imho la seule

fonction réellement utile de la version payante, peut être implémentée

avec un utilitaire windows "Everything" correctement paramétré ou avec

un utilitaire Linux (qu'il me reste à découvrir, sic) - j'ai pas

besoin de cette fonction pour l'instant.

L'app android est gratuite et ça permet aussi d'avoir les photos qui

arrivent direct dans le drive sans rien faire (une case à cocher).

J'ai un tuto validé tout prêt à dispo (avec nginx, je n'utilise plus

apache). Pré-requis :

- MariaDB ;

- Nginx ;

- Groupe de Diffie-Hellman fort (c'est mieux) ;

- Certificat Letsencrypt à jour.

Bien sûr le client seafile est multi-serveurs et un serveur seafile

est multi-dossiers dans un seul compte. J'ai trois serveurs dans des

vm séparées (soc 1 et soc 2 avec n comptes, perso avec plusieurs

dossiers et 7 comptes avec des droits différents).

Le chiffrement des chunks sur un serveur seafile contenait, il y a

encore quelques temps, une faille parait-il exploitable. Encore

faut-il bien sûr avoir l'accès root dessus pour ensuite tenter de

casser le chiffre selon l'exploit qui est parfaitement documenté sur

le net (je n'ai pas le niveau pour juger de la validité du POC). Je

signale ce point par objectivité. Perso je m'en fiche. Si accès root,

j'ai un problème immédiat bien plus grave.

Tu l'auras compris, j'adore seafile :)