Journal Remplacer Google (Calendrier et Contacts) par Owncloud, oui mais…

Posté par  (site web personnel) . Licence CC By‑SA.
24
4
fév.
2014

J’ai 2 raspberry pi. un avec xbian qui me sert de mediacenter, un autre qui me servira pour de la domotique/surveillance un jour. Mais en attendant que la flemme disparaisse je m’en occupe, je me suis dit qu’un Owncloud pourrait être sympathique.

  1. J’ai donc installé Raspbian et avec l’ajout d’un dépôt debian, j’ai un owncloud dernière version prêt à être testé en très peu de temps. Cette étape a été bien plus simple que ce à quoi je m’attendais. Bon il y a du boulot pour sécurisé tout ça mais c’est déjà agréable de voir cette première étape se passer sans embûche. Parfait !

  2. Ensuite, on exporte depuis google, on importe dans owncloud. Les procédures sont parfois assez peu évidentes mais finalement après un peu de recherche, c’est assez simple (importer les fichiers de calendriers dans owncloud files et cliquer dessus est moins intuitif qu’un bouton import à mon avis mais bon, c’est pas la mort). Parfait !

  3. Plus qu’à synchroniser les différentes machines… plus qu’à… et merde !

    • Synchronisation du calendrier Owncloud dans Thunderbird : Avec Lightning ça se fait facilement ! Parfait !
    • Synchronisation des contacts Owncloud dans Thunderbird : Thunderbird et caldav c’est pas vraiment le grand amour pour l’instant… Zut !
    • Synchronisation contacts/agenda Owncloud avec mon téléphone : Grâce à ce journal je suis très enthousiaste mais mon téléphone n’est pas sous Android 4 ou +, il faudrait que je prenne le risque de le transformer en brique pour profiter de cette fonctionnalité… Zut !

Pas si simple de se passer de Google, finalement !

Bref. Je ne dis pas que les choses sont impossibles, je veux juste témoigner ici auprès de ceux qui comme moi sont attirés par l’idée d’héberger eux-même certaines de leurs données personnelles : les choses ne sont pas forcément aussi simples que vous le souhaiterez. En lisant parfois certains anti-google on est tenté de croire que ce passer de Google est facile, que l’hébergement de nos propres données se fait facilement… et ben pas forcément jusqu’au bout finalement !

Il est possible de remplacer « Google » dans ce journal par n’importe quel site proposant caldav-carddav (ou protocole équivalent), j’ai pris l’exemple de Google parce qu’il est largement répandu, que c’est celui que j’utilise et que bon nombre de billets fleurissent sur la toile estimant que c’est Google l’ennemi… Je pense que je suis ici mon propre ennemi puisque c’est moi qui fourni mes infos en échange de facilité, personne ne m’a obligé à créer mon compte. D’ailleurs ce n’est pas la première fois que je me fais avoir.

  • # carddav/caldav c'est pas la meme chose.

    Posté par  . Évalué à 3.

    Synchronisation des contacts Owncloud dans Thunderbird : Thunderbird et caldav c’est pas vraiment le grand amour pour l’instant… Zut !

    c'est sur que la synchro des contacts avec caldav ca ne marchera jamais.

    par contre si tu essaies avec CardDav ca devrait aller mieux, non ?

  • # sogoconnector

    Posté par  (site web personnel) . Évalué à 1.

    Dans la liste de Radicale (qui fait aussi du (cal|card)DAV mais qui a le bon goût d'être en python) on signale qu'une évolution de sogo-connector devrait bientôt voir le jour. Censément, ça devrait permettre de faire du CardDAV proprement dans thunderbird.

    El linko : http://librelist.com/browser//radicale/2014/1/3/sogo-connector-patches-merged-into-upstream/

    • [^] # Re: sogoconnector

      Posté par  (site web personnel) . Évalué à 2.

      il y a un plugin déjà fonctionnel (je l'utilise): http://www.sogo.nu/downloads/frontends.html

      • [^] # Re: sogoconnector

        Posté par  . Évalué à 2.

        Idem j'utilise Inverse SOGo Connector et ça marche nickel !

        • [^] # Re: sogoconnector

          Posté par  (site web personnel) . Évalué à 1.

          Ah oui, zut, je me suis planté.

          En fait le bug du SoGo connector relevé dans la mail list ne concerne que Radicale. Un nom respect de la RFC je sais plus quoi…

          • [^] # Re: sogoconnector

            Posté par  . Évalué à 2.

            le problème que j'ai avec sogo connector, c'est qu'il merde un peu si tu as plusieurs comptes carddav: il ne retiens qu'un login/password.

            on peut contourner en mettant un user:pass@serveur comme adresse distante, mais c'est pas très propre.

  • # Synchro Android

    Posté par  . Évalué à 4. Dernière modification le 04 février 2014 à 23:26.

    Pour la synchronisation avec Android, j'utilise les application suivantes, sur un HTC Desire avec Cyanogen 7.2 (Android 2.3) :
    CalDav-Sync --> https://play.google.com/store/apps/details?id=org.dmfs.caldav.lib&hl=fr
    Cardav-Sync --> https://play.google.com/store/apps/details?id=org.dmfs.carddav.sync&hl=fr

    J'ai complété ma panoplie avec les autres applications du même développeur :
    Tasks --> https://play.google.com/store/apps/details?id=org.dmfs.tasks&hl=fr
    Contact Editor --> https://play.google.com/store/apps/details?id=org.dmfs.android.contacts&hl=fr

    Tout est plutôt stable, selon mon expérience.

    Enfin, pour Thunderbird, je confirme que les connecteurs Sogo fonctionnent bien.

    • [^] # Re: Synchro Android

      Posté par  . Évalué à 2.

      Tout pareil que Miguel,
      et ça marche du feu de Dieu !

      "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

    • [^] # Re: Synchro Android

      Posté par  . Évalué à 5.

      Sauf que vouloir se passer de Google et devoir installer le Play Store qui nécessite un compte GMail est un peu paradoxal, non ?

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # C'est pas libre mais ça marche

    Posté par  . Évalué à 3.

    J'utilise CalDAV-sync et CardDAV-Sync avec un Android 2.2 et ownCloud. Ça marche. Il y a des limitations sur les contacts, on ne peut pas modifier tous les champs sur le téléphone et c'est embêtant (n° de télephone, par exemple).

    L'auteur écrit que les logiciels deviendront libres. Les promesses n'engagent…

  • # Thunderbird ok avec Sogo connector

    Posté par  . Évalué à 2.

    Tout est dans le titre.
    Et puis je suis passé à Kontact, pas de plugin et ça juste marche. Dommage qu'Akgrator ne puisse pas se synchroniser avec le lecteur de flux d'Owncloud.

  • # synchro fichiers & raspberry pi ?

    Posté par  . Évalué à 1.

    Question : tu as essayé le client Owncloud pour synchroniser des répertoires ? Si oui, comment ça se comporte avec un raspberry pi ?

    • [^] # Re: synchro fichiers & raspberry pi ?

      Posté par  . Évalué à 4.

      je ne suis pas l'auteur du journal, mais je donne mon avis:

      config: Pi B avec l'OS (et les données) sur disque dur USB, Raspbian à jour, LAMP "classique", Owncloud 6.0.1, php-apc (pour la mise en cache)

      La première synchro PC => Owncloud portait sur 11Gb, répartis en 40K fichiers (client xubuntu 13.10, owncloud-client à jour). Autant pour les gros fichiers (en réseau local) je trouvais que c'était rapide, par contre quand sont venus les milliers de fichiers de 4 à 5kb j'ai constaté la lenteur relative du bouzin: il faut compter 3 à 4 secondes de "pause" entre chaque fichier. Pour cette synchro en réseau local, ça m'a pris environ 3 jours non stop.

      une deuxième expérience a été réalisée en synchronisant un ordi distant, PC => Owncloud toujours, via une connexion qui a un 512k en upload (client win XP, owncloud-client à jour). Là le volume était de 9Gb pour 16K fichiers, ça a tourné un peu plus de 48h. La vitesse de transmission étant bien plus lente qu'en réseau local, la pause entre fichier ne se faisait pas remarquer autant.

      Pour la synchro Owncloud => PC, ça se réalise maintenant avec un ou deux fichiers de temps en temps, en général j'ai un popup sur mon poste qui apparait à l'ouverture de session (et de pc) pour me dire que "tel fichier a été synchronisé" avant même que je ne déplace la souris pour faire ma première action.

      Pour résumer (mais je n'ai jamais testé owncloud sur un "vrai" serveur), pour de grosses synchros de petits fichiers, ça rame, c'est indéniable. Après, par rapport à l'utilisation légère et personnelle que j'en ai, je ne m'arrache pas les cheveux à attendre le système, il reste plus rapide que moi (alors qu'en distant, je n'ai jamais qu'une connexion 4M down / 512K up pour le Pi).

      L'acacia acajou de l'académie acoustique est acquitté de ses acrobaties. Tout le reste prend "acc".

      • [^] # Re: synchro fichiers & raspberry pi ?

        Posté par  . Évalué à 1. Dernière modification le 05 février 2014 à 09:57.

        oublié de préciser que le Pi est overclocké au paramètre maximum via raspi-config.

        L'acacia acajou de l'académie acoustique est acquitté de ses acrobaties. Tout le reste prend "acc".

      • [^] # Re: synchro fichiers & raspberry pi ?

        Posté par  . Évalué à 2.

        Merci pour ce retour détaillé.

        J'ai constaté le même comportement PC => OC avec un gros paquet de photos, des pauses de 3 à 5 secondes entre chaque fichier. Le tout en local, c'est ce qui faisait perdre le plus de temps finalement (plusieurs jours aussi). J'imagine que la pause correspond à l'inscription des données dans la DB.
        Chez moi ça tourne dans un conteneur (OpenVZ), LAMP classique aussi, avec l'hôte à base d'Atom d510.

    • [^] # Re: synchro fichiers & raspberry pi ?

      Posté par  . Évalué à 2.

      Pour les personnes (comme moi) qui n'ont pas de matériel (pi ou autre) et qui souhaitent un jour investir pour se monter ce genre de solution, il existe Cubox de la compagnie SolidRun Ltd.

      4 modèles sont disponibles et les 2 plus puissants (94.99 et 119.99 $) disposent d'un port eSata.

      Pour ma part, je suis encore loin de faire le pas, mais ça pourrait être une alternative intéressante.

  • # Sécurisation

    Posté par  . Évalué à 4.

    Bon il y a du boulot pour sécurisé tout ça mais c’est déjà agréable de voir cette première étape se passer sans embûche.
    J'envisage moi aussi de mettre owncloud sur un raspberry. Mais vu que je débute, je voudrais savoir quel genre de sécurisation est ce que tu as mis en place ?
    Merci d'avance.

  • # ActiveSync

    Posté par  (site web personnel) . Évalué à 1.

    Pour la synchro mobile j'utilise Z-Push.
    Certes, ça utilise le protocole Active-Sync, mais le client mail natif de android permet de gérer les comptes de type "Exchange".

    • [^] # Re: ActiveSync

      Posté par  . Évalué à 2.

      Ça gère les calendriers multiples, ça?

      • [^] # Re: ActiveSync

        Posté par  (site web personnel) . Évalué à 0.

        À priori, le protocole Active-Sync le permet. Par contre, le support de cette fonctionnalité n'est pas diponible dans toutes les versions du client mail natif android voir ce lien.

        La dernière version du client semble par contre l'implémenter ligne 88.

        Côté Z-push par contre, je n'ai pas l'impression que ça soit supporté.

  • # La lenteur du truc

    Posté par  . Évalué à 2.

    Je suis le seul à avoir trouvé Owncloud inutilisable sur un Raspberry?

    J'ai essayé avec plusieurs distros (arkOS, raspbian) et l'interface web est tellement lente qu'elle est inutilisable. Dès qu'on clique sur un truc, il faut attendre jusqu'à quelques dizaines de secondes pour que l'action se réalise. Et pourtant j'ai fait les tests sur un réseau qui p00tre. Du coup j'ai à peine testé la synchro de fichiers parce que je me voyais pas utiliser ça.

    Si c'est plus rapide chez vous, ça m'intéresse de savoir.

    • [^] # Re: La lenteur du truc

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Hello!

      Chez moi aussi avec un EEEPC 900 le client web rame pas mal, mais ce n'est pas un problème, puisque tu ne l'utilises que pour configurer 2-3 trucs (style le partage de fichier, de calendrier…). Par contre, je n'ai eu de soucis avec d'autres clients *Dav qui ne ramaient pas.

    • [^] # Re: La lenteur du truc

      Posté par  . Évalué à 1. Dernière modification le 06 février 2014 à 13:06.

      j'ai eu une légère amélioration en installant php-apc, qui fait une mise en cache en RAM des pages php les plus souvent demandées (si j'ai bien compris).

      Mais là où j'ai vraiment eu une claque (relative tout de même) sur la vitesse de chargement de l'interface web, c'est en désactivant les "thumbnails" des icones (pour les pdf et les jpg notamment - avec certains gros PDF, le temps qu'il fasse la preview sur l'icone je pouvais tranquillement aller me faire une café puis donner un biberon au gamin). Dans ton fichier de configuration owncloud ( config/config.php ) tu peux ajouter la ligne
      'enable_previews' => false,

      Après ce changement, ça devient réellement utilisable (enfin, pour qui n'est pas hyperkinétique ou trop monté en caféine).

      …et le mode "turbo" dans l'overclocking via raspi-config arrange aussi un peu les choses, mais ça amène de belles instabilités si ton système est sur une carte SD (sur disque dur USB, pas encore eu le moindre plantage en un peu plus de 40 jours d'utilisation, et sans refroidissement particulier ajouté)

      L'acacia acajou de l'académie acoustique est acquitté de ses acrobaties. Tout le reste prend "acc".

    • [^] # Re: La lenteur du truc

      Posté par  (site web personnel) . Évalué à 4.

      Je suis le seul à avoir trouvé Owncloud inutilisable sur un Raspberry?

      Oui owncloud est lent sur un Rasberry PI, en particulier avec SQLite come DB.

      Le problème c'est que owncloud est en PHP qui est lent par définition. Tout comme pratiquement tout les languages pour faire du web coté serveur. En général on dit: « C'est pas un problème si le language est lent et/ou que les dévelopeurs codent comme des pieds : rajoutez de la RAM et des serveurs, ça coûte moins cher que le temps de dévelopment gagné. » Mais ce n'est pas vrai quand le produit est utilisé par des particuliers sur un rasberry pi.

Suivre le flux des commentaires

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