I’d like to migrate a Nextcloud from another server to my yunohost (same version). To be sure:
I will set in maintenance mode both nextcloud. Migrate nextcloud data (rsync -Aax) into the new data directory, apps into apps directory & export and import databases. I think it will erase default data & users and remplace it with my other config.
I’m right ? How can i setup nextcloud in maintenance mode with yunohost ? I don’t know how SSO work but can i link two users ? (a nextcloud migrated one and a yunohost sso created before/after the migration ? )
Thx
Salutations,
J’aimerais faire une migration d’une instance Nextcloud depuis un serveur sur mon yunohost (versions identiques). Pour être sûr:
Je vais mettre en maintenance mes deux Nextcloud. Envoyer mes data (rsync -Aax), mes app dans les dossier data et app de yunohost et exporter/importer ma base de donnée. Ce qui devrais écraser proprement la configuration par défaut de Nextcloud sur Yunohost.
Suis-je dans le vrai ? Comment mettre nextcloud en maintenance manuellement sur Yunohost ? Ne connaissant pas SSO, est-il possible de refaire le lien entre deux utilisateurs (un compte Nextcloud migré et un compte créé avant/après la migration sur le sso) ?
je ne sais pas si c’est ce que tu cherches, mais certain font des migrations avec le systeme de backup/restore de YunoHost… (c.f. la commande yunohost backup create et yunohost backup restore, ou la section Backup de la webadmin)
Tu backup sur ton serveur initial. Suivant si tu veux migrer tout ton systeme (incluant les users) ou juste Nextcloud, il faut mettre des options différentes (genre si tu veux backuper que Nextcloud, c’est --apps nextcloud --ignore-system
Tu transfere l’archive .tar.gz aui sera dans /home/yunohost_backups/ (un truc du genre) vers ton autre serveur
Un coup de yunohost backup list pour verifier qu’il est bien reconnu sur l’autre serveur, puis yunohost backup restore <nomdubackup>
Zut, j’avais exactement la même question (avec en plus le soucis que le nom de mes utilisateurs va changer au passage à yunohost).
Bon ben ça sera synchro à la main des fichiers, tant pis pour leur date de création qui va être perdue
J’ai exactement la même question que @vitria.
Je voudrais migrer mes données d’une instance Nextcloud sur un hébergement mutualisé sans YunoHost et sans LDAP vers une nouvelle machine virtuelle avec YunoHost et son SSO.
Je me demande si le SSO YunoHost continuera à fonctionner après cette migration. Les deux utilisateurs conservent le même nom.
Quelqu’un a une autre idée que d’importer à la main les fichiers (donc perdre les partages, les dates, etc), les contacts et le calendrier ?
I have exactly the same question as @vitria.
I would like to migrate my data from a Nextcloud instance to shared hosting without YunoHost and without LDAP to a new virtual machine with YunoHost and its SSO.
Ayant moi-même réalisé cette opération avec succès, je me permets de copier/coller ci-dessous la petite documentation que j’avais rédigée au moment de ma migration, il y a quelques mois. À utiliser “en l’état”, en espérant que ça puisse servir !
Migrer d’un Nextcloud standalone à un Nextcloud YunoHost revient à deux choses :
migrer le Nextcloud existant (backup puis restauration),
ajouter un annuaire LDAP (celui utilisé par YunoHost) incluant les utilisateurs existants.
Pour info, je suis parti de ce sujet sur le forum Nextcloud :
Pour désigner le serveur/Nextcloud d’origine, je parlerai de “antérieur” , pour le nouveau, ce sera “YunoHost”.
L’astuce va consister à installer un Nextcloud YunoHost, récupérer les informations relatives au LDAP, restaurer son Nextcloud antérieur en écrasant celui qu’on a installé, puis ré-injecter les données LDAP.
Prérequis :
connaître le shell de vos serveurs et un peu de SQL,
avoir accès aux deux hôtes en SSH,
avoir la même version de Nextcloud installé sur le serveur antérieur et sur le YunoHost (ici, la procédure a été faite pour Nextcloud 20),
avoir activé l’application Nextcloud ‘LDAP user and group backend’ sur le Nextcloud antérieur ; je ne suis pas sûr que ce soit essentiel à vrai dire, mais il n’est pas gênant de l’activer et de ne pas l’utiliser.
Si vous ne comprenez pas ce qui est fait par les commandes ci-dessous, il est dangereux de vous engager dans cette procédure en faisant des copier-coller !
Dans tous les cas, assurez-vous d’avoir sauvegardé des données qui pourraient être exposées.
Procédure :
Sur l’hôte antérieur, faire un backup des répertoires data (qui contient vos données) et nextcloud (qui contient les sources de Nextcloud), ainsi que de la base de donnée
(cf Backup — Nextcloud latest Administration Manual latest documentation pour la procédure détaillée).
Sur l’hôte YunoHost :
On va tout faire en CLI avec le Nextcloud en mode maintenance pour éviter qu’il n’aille interroger le LDAP
Passer root :
sudo -s
Installer Nextcloud :
yunohost app install nextcloud
NE PAS se connecter à Nextcloud une fois celui-ci installé.
Restaurer les données issues du Nextcloud antérieur :
sauvegarder le répertoire de configuration du Nextcloud YunoHost (exemple : cp -a /var/www/nextcloud/config/ /tmp)
remplacer le répertoire nextcloud du YunoHost par celui de l’antérieur
remplacer le répertoire data du YunoHost par celui de l’antérieur (ou modifier le paramètre datadirectory dans la config)
vérifier que l’utilisateur nextcloud est bien propriétaire des répertoires (si non : chown -R nextcloud:nextcloud /path/to/directory)
fusionner les deux fichiers de configuration (ancien et nouveau), sur la base du nouveau, en récupérant notamment le paramètre instanceid de l’ancienne config (bien regarder ligne par ligne ce qu’il est pertinent de garder de l’un ou l’autre des fichiers)
Pour la base de données, nous allons détruire la base générée à l’installation, en recréer une et importer les données de la base antérieure :
AVANT la destruction, nous exportons certaines données relatives au LDAP YunoHost (ainsi que les tables oc_external_*) :
Dans ce dernier fichier, nous devons faire quelques modifications :
<> retirer le bloc de création de la table (elle existera déjà)
<> ajouter la ligne suivante avant les requêtes d’insertion des données :
DELETE FROM `oc_appconfig` WHERE `appid`='user_ldap';
On recrée la BDD :
mysql -u root -p$(cat /etc/yunohost/mysql)
DROP DATABASE nextcloud;
CREATE DATABASE nextcloud;
\q
On importe les données de la base antérieure, puis celles conservées de YunoHost :
mysql -u root -p$(cat /etc/yunohost/mysql) nextcloud < /your/backup/directory/db_dump_ante.sql
mysql -u root -p$(cat /etc/yunohost/mysql) nextcloud < /tmp/oc_yunohost_new_tables.sql
mysql -u root -p$(cat /etc/yunohost/mysql) nextcloud < /tmp/oc_yunohost_appconfig_ldap.sql
Nous devons maintenant modifier certaines données dans la BDD pour éviter les conflits et que le LDAP prenne en compte les utilisateurs existants.
Les utilisateurs qui avaient un compte Nextcloud sur l’antérieur et qui ne sont pas dans le LDAP de YunoHost vont perdre leur accès ! Pour éviter cela, assurez-vous que tous les utilisateurs du Nextcloud antérieur ont bien un compte dans le LDAP YunoHost.
mysql -u root -p$(cat /etc/yunohost/mysql)
USE nextcloud;
DELETE FROM `oc_accounts`;
DELETE FROM `oc_users`;
DELETE FROM `oc_ldap_user_mapping`;
\q
Les tables oc_accounts, oc_users, oc_ldap_user_mapping et oc_ldap_group_mapping doivent être vides.
[Étape facultative en fonction de votre installation] Changer la correspondance nom d’utilisateur Nextcloud <-> attribut LDAP.
Par défaut, Nextcloud va récupérer l’attribut uid du LDAP YunoHost (les prénoms en minuscule théoriquement). Si dans votre Nextcloud antérieur vous identifiiez vos utilisateurs différement, il faut utiliser un autre attribut des utilisateurs LDAP, qui aura exactement la même valeur que celle utilisée dans l’antérieur. Par exemple, si vous utilisiez le prénom avec une majuscule, vous pouvez utiliser l’attribut cn, ou givenName. Dans le pire des cas, il faudra créer un attribut supplémentaire, pour tous vos utilisateurs YunoHost.
Pour faire la correspondance (dans cet exemple, je remplace uid par cn) :
mysql -u root -p$(cat /etc/yunohost/mysql)
USE nextcloud;
UPDATE `oc_appconfig` SET `configValue`='cn' WHERE `configKey`='ldap_expert_username_attr' AND `configValue`='uid';
UPDATE `oc_appconfig` SET `configValue`='(&(|(objectclass=posixAccount))(cn=%uid))' WHERE `configKey`='ldap_login_filter' AND `configValue`='(&(|(objectclass=posixAccount))(uid=%uid))';
UPDATE `oc_appconfig` SET `configValue`='1' WHERE `configKey`='ldap_login_filter_mode' AND `configValue`='0';
\q
Vérifier que les différentes applications installées sur votre Nextcloud vont fonctionner correctement.
Par exemple, si vous utilisez le webmail, il faudra vérifier la correspondance entre les adresses mails des utilisateurs. Chaque application possède ses tables dans la base de données, et stocke des réglages dans la table oc_appconfig.
Vérifier le bon fonctionnement de Nextcloud.
Pour cela, on va simplement lancer un status :
sudo -u nextcloud php /var/www/nextcloud/occ status
Pour ma part, lors d’un premier essai où je ne pensais pas devoir migrer tout le répertoire nextcloud, j’avais une différence de version mineure (19.0.3 côté YunoHost vs 19.0.6 côté antérieur), j’ai donc mis à jour côté YunoHost en 19.0.6, mais Nextcloud n’était pas content et a quand même réclamé un upgrade (pourtant j’avais changé le numéro de version dans la config), qui a résolu le problème :
Lors de la migration avec la version 20.0.7 des deux côtés, le status était normal (en migrant tout le répertoire nextcloud ou pas).
Si tout est bon, on sort Nextcloud de la maintenance, on tente de se connecter avec un utilisateur LDAP avec les droits d’administation sur le Nextcloud (un utilisateur qui les avait avant, donc), et on va voir la liste des utilisateurs pour vérifier qu’il n’y a eu aucune collision (si c’est le cas, les utilisateurs ajoutés par le LDAP auront un numéro aléatoire ajouté à leur nom).
@SveDec Je me permets de répondre car je viens de réaliser avec succès une migration dans les mêmes conditions grâce au tutoriel ci-dessous, qui a dans l’ensemble très bien fonctionné. Merci beaucoup d’avoir partagé cette doc interne
Pour information, j’utilisais Nextcloud 23 sur l’instance “antérieure” et seul Nextcloud 22 était disponible sur Yunohost au moment de la migration. Lors de tests préliminaires, j’ai réussi à effectuer la migration sans activer l’application LDAP dans l’instance antérieur, mais j’ai quand-même fini par le faire pour ma tranquilité d’esprit. Par contre, j’ai dû m’y reprendre à quelques fois concernant les permissions. En effet, malgré un chown nextcloud:www-data autant sur le dossier nextcloud que sur celui des données, j’ai eu des soucis d’accès et j’ai dû répéter l’opération. Donc en cas de problème d’accès après une migration apparemment sans accros, cela vaut la peine de jeter un oeil à cela.
Une recommandation que je ferais également à toute personne intéressée par cette migration est de la tenter sur un autre sous-domaine temporairement (eg. un sous-domaine fournis par Yunohost) et de tester la synchronisation en changeant l’url dans le fichier nextcloud.cfg sur l’un des clients. Cela m’a permis de faire des tests tout en étant en mesure de retourner en arrière en cas de problème. Il est ensuite très simple de changer le sous-domaine de l’installation a posteriori.
Bonne chance à ceux qui voudront tenter l’aventure.
Merci pour ce précieux tutoriel ! on a pu migrer une instance qui était en 21 (Argh !!) en 2024. D’abord on la migrer et mise en prod sur une vm docker pour l’upgrader en 22.2.10.2 (en buildant l’image).
Ensuite j’ai tester en local avec une yunohost Virtualbox le tutto
Pour info, j’avais sur cette instance un utilisateur impossible à migrer car un user admin avec une Majuscule et sans mail (il servait de dossiers de groupe, c’est à dire que presque toutes les datas sont chez cet user et il les partage),
Mais après la migration, il me suffisait de le créer via l’interface de Yuno en admin, en renommant son dossier avec un autre nom provisoire, sinon il ne veut pas créer l’user, une fois créer je renomme de nouveau le dossier avec son ID, tout cela avant de scanner les dossiers, pour ne voir que le résultat de la base de données… Et le tour est joué…
Pour la modif du fichier oc_yunohost_appconfig_ldap.sql
J’ai du aussi enlever une ligne…
l’original ressemblait à
-- MariaDB dump 10.19 Distrib 10.5.23-MariaDB, for debian-linux-gnu (x86_64)
--
-- Host: localhost Database: nextcloud
-- ------------------------------------------------------
-- Server version 10.5.23-MariaDB-0+deb11u1
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Table structure for table `oc_appconfig`
--
DROP TABLE IF EXISTS `oc_appconfig`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `oc_appconfig` (
`appid` varchar(32) NOT NULL DEFAULT '',
`configkey` varchar(64) NOT NULL DEFAULT '',
`configvalue` longtext DEFAULT NULL,
PRIMARY KEY (`appid`,`configkey`),
KEY `appconfig_config_key_index` (`configkey`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=COMPRESSED;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `oc_appconfig`
--
-- WHERE: appid='user_ldap'
LOCK TABLES `oc_appconfig` WRITE;
/*!40000 ALTER TABLE `oc_appconfig` DISABLE KEYS */;
INSERT INTO `oc_appconfig` VALUES ('user_ldap','_lastChange','1713955506'),('user_ldap','background_sync_interval','1800'),('user_ldap','background_sync_offset','0'),('user_ldap','background_sync_prefix',''),('user_ldap','enabled','yes'),('user_ldap','installed_version','1.12.2'),('user_ldap','ldap_base','dc=yunohost,dc=org'),('user_ldap','ldap_base_groups','ou=groups,dc=yunohost,dc=org'),('user_ldap','ldap_base_users','ou=users,dc=yunohost,dc=org'),('user_ldap','ldap_cache_ttl','600'),('user_ldap','ldap_configuration_active','1'),('user_ldap','ldap_display_name','displayname'),('user_ldap','ldap_email_attr','mail'),('user_ldap','ldap_expert_username_attr','uid'),('user_ldap','ldap_group_display_name','cn'),('user_ldap','ldap_group_filter','(&(objectclass=top)(memberUid=*))'),('user_ldap','ldap_group_filter_mode','0'),('user_ldap','ldap_group_member_assoc_attribute','memberUid'),('user_ldap','ldap_groupfilter_objectclass','posixGroup'),('user_ldap','ldap_host','localhost'),('user_ldap','ldap_login_filter','(&(|(objectclass=posixAccount))(uid=%uid)(permission=cn=nextcloud.main,ou=permission,dc=yunohost,dc=org))'),('user_ldap','ldap_login_filter_mode','0'),('user_ldap','ldap_port','389'),('user_ldap','ldap_quota_attr','userquota'),('user_ldap','ldap_tls','0'),('user_ldap','ldap_user_display_name','cn'),('user_ldap','ldap_user_filter_mode','0'),('user_ldap','ldap_userfilter_objectclass','posixAccount'),('user_ldap','ldap_userlist_filter','objectclass=posixAccount'),('user_ldap','s01_lastChange','1713955246'),('user_ldap','s01ldap_configuration_active',''),('user_ldap','types','authentication');
/*!40000 ALTER TABLE `oc_appconfig` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
-- Dump completed on 2024-04-30 16:57:16
et après édition
-- MariaDB dump 10.19 Distrib 10.5.23-MariaDB, for debian-linux-gnu (x86_64)
--
-- Host: localhost Database: nextcloud
-- ------------------------------------------------------
-- Server version 10.5.23-MariaDB-0+deb11u1
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Table structure for table `oc_appconfig`
--
LOCK TABLES `oc_appconfig` WRITE;
/*!40000 ALTER TABLE `oc_appconfig` DISABLE KEYS */;
DELETE FROM oc_appconfig WHERE appid='user_ldap';
INSERT INTO `oc_appconfig` VALUES ('user_ldap','_lastChange','1713955506'),('user_ldap','background_sync_interval','1800'),('user_ldap','background_sync_offset','0'),('user_ldap','background_sync_prefix',''),('user_ldap','enabled','yes'),('user_ldap','installed_version','1.12.2'),('user_ldap','ldap_base','dc=yunohost,dc=org'),('user_ldap','ldap_base_groups','ou=groups,dc=yunohost,dc=org'),('user_ldap','ldap_base_users','ou=users,dc=yunohost,dc=org'),('user_ldap','ldap_cache_ttl','600'),('user_ldap','ldap_configuration_active','1'),('user_ldap','ldap_display_name','displayname'),('user_ldap','ldap_email_attr','mail'),('user_ldap','ldap_expert_username_attr','uid'),('user_ldap','ldap_group_display_name','cn'),('user_ldap','ldap_group_filter','(&(objectclass=top)(memberUid=*))'),('user_ldap','ldap_group_filter_mode','0'),('user_ldap','ldap_group_member_assoc_attribute','memberUid'),('user_ldap','ldap_groupfilter_objectclass','posixGroup'),('user_ldap','ldap_host','localhost'),('user_ldap','ldap_login_filter','(&(|(objectclass=posixAccount))(uid=%uid)(permission=cn=nextcloud.main,ou=permission,dc=yunohost,dc=org))'),('user_ldap','ldap_login_filter_mode','0'),('user_ldap','ldap_port','389'),('user_ldap','ldap_quota_attr','userquota'),('user_ldap','ldap_tls','0'),('user_ldap','ldap_user_display_name','cn'),('user_ldap','ldap_user_filter_mode','0'),('user_ldap','ldap_userfilter_objectclass','posixAccount'),('user_ldap','ldap_userlist_filter','objectclass=posixAccount'),('user_ldap','s01_lastChange','1713955246'),('user_ldap','s01ldap_configuration_active',''),('user_ldap','types','authentication');
/*!40000 ALTER TABLE `oc_appconfig` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
-- Dump completed on 2024-04-30 16:57:16
Voilà, merci pour ce tutoriel précieux ! Juste pas de SSO avec la migration mais sinon tous est là et j’ai pu upgrader en Nextcloud 27.1.9 avec la branche oldstable
Prérequis :
Si vous ne comprenez pas ce qui est fait par les commandes ci-dessous, il est dangereux de vous engager dans cette procédure en faisant des copier-coller !
NE PAS se connecter à Nextcloud une fois celui-ci installé.
Pour ma part, lors d’un premier essai où je ne pensais pas devoir migrer tout le répertoire 
