Outils pour utilisateurs

Outils du site


owncloud

OwnCloud

Migration vers NextCloud

Divers

Sauvegarde / récupération d'un calendrier:

  • identifier le calendrier
 select * from oc_calendars where principaluri like '%tom%' ;
  • récupérer le champ calendardata:
mysql nuage -N --batch -e 'select calendardata from oc_calendarobjects where calendarid=40 order by lastmodified'  |sed -e 's/^M\\n/\n/g' > calendar.vcard

Et on obtient fichier vcard inutilisable

Mise à jour

Il ne faut surtout pas utiliser les paquets de la distribution, et préférer les paquest officiels

Les mises à jour doivent se suivre, pas possible d'en sauter une. Donc le principe consiste à configurer un à un les dépôts adéquats, et faire les mises à jour les unes après les autres. On peut trouver les différents dépôts via le changelog

Concernant le changement de fournisseur de paquet, testé sur un lxc octest sur gelatine:

  1. origine: owncloud 8.1 from epel
  2. passage en 8.2 officiel - récupération de la config
  3. passage en 9.0, puis 9.1 - récupération du datadir: ça marche plutôt bien

Erreurs rencontrées: erreur 500 lors de la connexion causé par un max_allowed_packets trop bas.

À priori aucune information (cf test migration ldap ci-dessous) n'a été perdue

Création d'un dossier partagé Public accessible en mode openbar lecture-seule à l'adresse: https://cloud.opendoor.fr/index.php/s/4SyvRpgMOJJuJOI

La ligne de commande

En v8, il est possible de faire beaucoup de chose via /usr/share/owncloud/console.php :

su - apache -s /bin/bash
/usr/share/owncloud/console.php user:resetpassword root

Migration sql backend -> ldap

Bilan

La migration est simplissime à réaliser:

“raccorder” l'uid du compte existant, ainsi que son répertoire de donnée à l'utilisateur ldap

update oc_ldap_user_mapping set owncloud_name='tom', directory_uuid ='tom' where ldap_dn='uid=tom,ou=opendoor.fr,dc=od' ;

Si l'utilisateur n'est pas présent dans la table (car il ne s'est jamais connecté) il suffit de rajouter une ligne avec les bonnes valeurs:

 insert into oc_ldap_user_mapping values( 'uid=sophie,ou=lesconstans.fr,dc=od', 'sophie', 'sophie' ) ;

Supprimer l'utilisateur owncloud

update oc_users ser uid='tom.ORIG' where uid='tom' ;

Communiquer le mot de passe ldap à l'utilisateur. (Il peut être nécessaire de relancer le poste dans le cas où l'on utilise le plugin desktop)

Tests

Infos à récupérer:

  1. avatar
  2. mot de passe
  3. appartenance au groupe
  4. statut admin
  5. statut group admin
  6. fichiers et répertoires
  7. fichiers et répertoires partagés
  8. calendriers partagés

La correspondance compte utilisateur ldap (dn), sql et répertoire de donnée se fait via la table oc_ldap_user_mapping.

Il faut penser à la fin à supprimer les utilisateurs de la table oc_users, et les groupes (?) de la table oc_groups(?)

Fait:

  1. ✓ créer un compte owncloud - migr
  2. ✓ configurer le client desktop
  3. ✓ rajouter des fichiers
  4. ✓ configurer le backend ldap
  5. supprimer l'utilisateur dans la table oc_users delete from oc_users where uid='migr' ;
  6. modifier le directoryuid dans la table oc_ldap_user_mapping afin qu'elle corresponde à owncloudname

2016.07.18: essai de migration user db -> ldap

Création d'un compte “local” tom avec les caractéristiques suivantes:

  1. mot de passe défini
  2. membre des groupes users et mygroup
  3. avatar
  4. accès au calendrier de root
  5. admin du groupe mygroup
  6. répertoire Documents partagé en RW avec mygroup
  7. présence du dossier Photos et “owncloud manual” par défaut
  8. présende d'une photo perso
  9. présence du répertoire “toto”

Création d'un compte ldap:

  1. définition d'un mot de passe
  2. association du compte ldap avec les données owncloud:
insert into oc_ldap_user_mapping values( 'uid=tom,ou=rndfacts.com,dc=od', 'tom', 'tom' ) ;
delete from oc_users where uid='tom'
  1. connection et vérification:
  2. ✓ avatar
  3. ✓ fichiers et répertoires
  4. ✓ calendrie
  5. ✓ accès au calendrier partagé de root
  6. ✓ répertoire partagé toujours partagé
  7. les fichiers sont

Divers

2016.01.12 : déplacement du répertoire de donnée dans un partage nfs sur turbine ('/srv/home/owncloud')

À l'issue de l'opération les fichiers de l'utilisateur ne sont pas visibles : il faut demander à owncloud à resynchroniser le système de fichier et la base de donnée:

su -s /bin/bash apache -c "php /var/www/html/owncloud/console.php files:scan tom

 su -s /bin/bash apache -c "php /usr/share//owncloud/occ files:scan christel"

Pour être valide, un compte ldap doit disposer de l'attribut displayname

Bugs

Impossible de synchroniser Mes Documents sous windows XP. En effet ce n'est pas un vrai répertoire. Merci $MS.

Pas de solution, l'os n'étant plus supporté.

Mise à jour du 2015/03/04

Installation très rapide sur une centos 6.5, de la dernière version (8) en utilisant le dépôt, et la version 5.4 de php disponible sur les dépôts de remi:

[remi]
name=Les [[:rpm|RPM]] de remi pour Enterprise Linux 6 - $basearch
#baseurl=http://rpms.famillecollet.com/enterprise/6/remi/$basearch/
mirrorlist=http://rpms.famillecollet.com/enterprise/6/remi/mirror
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-remi

Montage nfs de turbine:/srv/Maison/TestOC sur le serveur owncloud, dans /var/www/html/owncloud/data/tom/files/ concluant

Utilisation du client owncloud en GPL gratuit depuis F-Droid, sur android. Activation de l'upload automatique des photos et vidéos: looks promising

Le paquet mirall permet de synchroniser un dossier local avec un dossierowncloud

Old:

Application PHP+MySQL de partage très très sympa, simplissime à déployer via git.

  • url calendrier caldav: /apps/calendar/caldav.php/calendars/tom/default%20calendar/
  • url carnet d'adresse : /apps/contacts/carddav.php/addressbooks/tom/default/

Les premiers tests d'accès / synchro sont concluants avec Evolution

L'intégration ldap est fonctionnelle.

L'application est en cours de test sur centosine/owncloud

Argh : no contact / calendar sharing …

Informations pratiques

urls

* SOGO: contacts: SERVER/remote.php/carddav/addressbooks/USER/NOMCARNET (par défaut Default).

Import export contacts

Un peu compliqué. Pour l'heure, seul Evolution peut se connecter sur un serveur carddav, et l'import export pose quelques problèmes:

  • utilisation de syncml pour récupérer les contacts du téléphone
  • conversion en csv pour édition / correction sous libreoffice
  • conversion csv vers vcard avec csv2vcard
  • les adresses mails sont remplacées par des uid ( il faut modifier le champs EMAIL )

mais c'est quand même la pagaille… on perd des colonnes, des infos se retrouvent dans de mauvais champs, etc (pb de csv ?)

Version 3.3

Plus mieux bien: import et export de contact.

Synchro parfaite avec IOS (ne pas mettre http: dans l'url

Synchro presque parfaite des contacts avec evolution. attention : pour un affichage correct des téléphones, il faut choisir téléphone principal et téléphone mobile

Version 4.0

Quelques bug (encodage, erreur 404 sur certains script) mais un développement actif, et de nouvelles fonctionnalités, dont le partage de calendrier !

Les urls ont changé, un .htaccess s'occupe de la réécriture pour assurer la rétro compatibilité.

Les clients

  • la synchro client et agenda marche très bien avec cardav-sync et caldav-sync sous Android
  • synchro sunbird/lightning: marche très bien
  • synchro contact thunderbird: marche très bien avecsogo
  • synchro evolution: contacts: ça marche mal, très mal (perte / corruption d'info, …)

Les tests

Synchro et partage calendrier

  • client lourd: lightning
  • client iphone
  • clientandroid

échec : le partage de calendrier fonctionne très bien, mais uniquement depuis l'interface web. Il faut donc s'abonner à chaque calendrier séparément. C'est lourd d'un point de vue config, et pas de possibilité de gestion fine des droits…

à tester: ajout, modification, suppression coté client | idem coté interface web

Synchro et partage contact

  • Pas de client lourd (evolution n'est pas fiable)
  • client iphone - M, S, A
  • client android - carddav-sync not working : sur le tel, on a accès à toutes les informations (y compris la photo), mais impossible de modifier d'autres champs que le nom, le prenom et la photo. Impossible également de rajouter des champs… Idem pour la création. EDIT : toutes les informations de contacts sont éditables en utilisant l'application android contact editor du même auteur que carddav-sync. Tests du 2012.08.17 : même la synchro photo entre android et TB fonctionne. (mais la photo n'est pas visible dans OC)
  • client SOGO - semble très bien marcher.

à tester: ajout, modification, suppression coté client | idem coté interface web

Partage de photos et de fichiers

  • Voir les facilités d'upload et de publication.

Un modèle de simplicité, à par le bouton upload; complètement invisible (à coté de nouveau)

  • Voir la possibilité pour un extérieur de créer un compte.

Import (export) de données

Trouver la meilleur forme sous laquelle contacts et calendrier peuvent être importés de manière satisfaisante, notamment vis à vis des clients testés ci-dessus.

L'importation d'un calendrier depuis un export //TB// semble parfaitement fonctionnelle.
L'importation d'un carnet d'adresse depuis un export //TB// (via morefunctionforaddressbook) semble parfaitement fonctionnelle.

Conclusion

Une très belle application, (2012.08)mais la gestion des contacts n'est pas suffisamment fonctionnelle (pas de client lourd, pas de client android satisfaisant) pour justifier une migration. Cependant, vue la vitesse de développement actuelle, owncloud reste à surveiller attentivement.

# vim: set filetype=dokuwiki:

owncloud.txt · Dernière modification: 2017/09/13 07:21 (modification externe)