C’est une très bonne nouvelle, merci à tous pour ce travail d’empaquetage, de tests et de documentation.
Comme ça concerne autant les utilisateurs de dodoc qui voudraient se simplifier l’installation d’un serveur dodoc en passant par Yunohost que des utilisateurs de Yunohost qui pourraient découvrir dodoc, je trouverais intéressant d’avoir de la documentation de chaque côté.
Pour dodoc : un tuto sur ce forum dans un fil dédié dans la catégorie « tutoriels » semble le bon endroit.
Pour Yunohost je connais peu leur forum, mais il pourrait peut-être y avoir aussi au moins un lien qui redirige vers le forum de dodoc, ou une documentation plus complète avec le détail sur la partie liée à Yunohost.
Et un tuto sur ton instance de dodoc qui tourne sur Yunohost serait aussi bien vu et un bel exemple qui prouve que ça marche.
Le côté redondant n’est pas une mauvaise pratique pour toucher les différents utilisateurs potentiels.
On avait fait un peu la même chose pour les installations pour Raspberry.
Il y a de la documentation sur ce forum avec des échanges pour donner un coup de main ou quelques options de paramétrages et on a fait quelques tutos plus rapides avec les lignes de commandes principales pour installer et mettre à jour un dodoc sur RPI. Cette doc a été reprise sur plusieurs instances de dodoc (Fablab à l’école / FabriqueEdu / Test.dodoc.fr…)
C’est l’avantage de pouvoir exporter et importer / modifier facilement un projet sur une autre instance
Bonne soirée
Super ! Alors je vais m’y atteler !
On a 4 moyens d’installer dodoc ! C’est pas génial ?
En attendant permettez moi ces quelques notes :
Transférer les données d’un dodoc sur un VPS seul à un dodoc sur un VPS tournant sur Yunohost.
1/ Importer les données du premier VPS vers votre PC
Les données sont par défaut stockés au chemin suivant : /root/Documents/dodoc
Si vous avez un doute, retrouvez ce chemin dans les paramètres de votre instance dodoc, rubrique « stockage ».
Ce dossier n’est pas accessible avec l’utilisateur courant. Mais seulement avec root. J’ai bien essayé de changer les droits mais ca ne marche pas. Alors, j’ai déplacé le dossier dans un répertoire dont j’ai les dorits. Pour cela se connecter en SSH au VPS, puis copier le dossier dans le répertoire /home/ubuntu/data :
mv /root/Documents/dodoc /home/ubuntu/data
Ici j’ai nommé le dossier data car il existe déjà un dossier dodoc qui est l’application.
Puis lancer la commande depuis le terminal de l’ordinateur pour importer le dossier :
Par contre pour les paramètres, si j’ai bien compris, c’est le fichier settings_base.json ? Je n’ai pas de settings.json dans mon VPS 1 mais j’en ai un dans celui avec yunohost. Que faut-il copier coller et où ?
Hello,
Je crois que j’ai été un peu vite hier.
J’ai cherché à déplacer mes datas et mes paramètres d’un ancien dodoc vers dodoc YNH. J’ai donc déplacé le dossier /root/Documents/dodoc du premier dodoc vers le yunohost en supprimant le dossier home/yunohost.app/dodoc pour le remplacer par le répertoire précedemment importé.
J’avais compris qu’il fallait importer le settings.json pour que les paramètres (titre, sous-tire, logo, favicon, users) que j’avais paramétré dans le premier dodoc puisse s’appliquer au second dodoc, celui du YNH. (Je n’ai pas fait cela car, sur mon dodoc 1 il n’y a pas de settings.json.
Comme je n’arrive pas à restaurer cela (titre sous-titre, logo…) via une méthode propre, pour bien faire, et apprendre comment déplacer un dodoc, j’ai essayé de modifier les paramètres à la main. C’est impossible, je n’arrive pas à modifier le logo, le favicon le sous-titre…
Rien que je puisse modifier dans les paramètres ne veut s’appliquer.
Est-ce que les paramètres que j’avais avant de coller les data ne seraient-ils pas en confrontation avec celles que je viens de coller dans home/yunohost.app/dodoc/meta.txt ? Je précise que j’avais modifié quelques paramètres avant d’importer les datas. Le dodoc n’était pas tout a fait vierge.
Existe t-il un moyen pour corriger cela ?
Sinon je désinstalle et réinstalle dodoc YNH et j’importerai les données à la main projet par projet.
Et au passage, j’ai fais l’erreur de me déconnecter et les mots de passes des deuc comptes (dont je suis pourtant certain) sont érronné ! Donc plus moyen de me connecter.
Mais il faut faire très attention à ne pas confondre :
le dossier d’installation de dodoc (qui contient les dossiers/fichiers listés sur github : build, client, settings_base.json, node_modules, etc. et potentiellement un fichier settings.json si tu en as créé un)
et le dossier des contenus, qui est dans /Documents par défaut, et contient les contenus utilisateurs (archives, authors, folders, meta.txt et pleins de sous-dossiers / fichiers).
En règle général, quand je migre un dodoc, je ne prends que le dossier des contenus et je ne me soucie pas de settings.json qui est vraiment spécifique à mon installation serveur (multi dodoc, avec un volume externe, etc.).
Hello Louis !
Ok merci je comprend mieux le rôle du settings.json. Je me suis emmêlé les pinceaux, on en avait parlé une autre fois pour sauver le contenu d’un dodoc.
Enfin bref, j’y vois plus clair.
Donc en fait c’est bien ce que j’ai fais, une migration de dodoc en ne déplaçant que le dossier des contenues.
J’ai recommencé à 0 ce soir et je rencontre le même problème.
Après avoir déposé les dossiers dans /home/yunohost.app, les tutoriels et projets de mon ancien dodoc s’affichent bien.
J’ai après cela essayé de modifier les paramètres de l’instance en cliquant sur la petite roue cranté en haut à droite (accessible en admin).
Quand je modifie un paramètre, rien ne peut s’enregistrer. Si je modifie le titre, le sous-titre, les droits d’admin, le logo… je ne peux rien enregistrer.
N’y aurait-il pas là une erreur de lecture de yunohost du fichier Meta.txt ?
Je vous met ici un apperçu de la console lorsque je souhaite enregistrer le titre de l’instance dodoc :
Ce problème pourrait-il venir du fait que le dodoc d’où j’extrais les données est en V10.0.13-dev alors que le dodoc qui réceptionne, celui de YNH est sur 11.1.3 ?
Rapido comme ça : EACCES = problème de permission
Vérifier les droits sur les fichiers/dossiers, ça arrive souvent quand on déplace les contenus. Le user qui les a créé n’est plus celui qui veut les écrire – il faudrait modifier le user je pense.
Attention, le chemin d’accès au dossier de données est /home/yunohost.app/dodoc/. Le chemin avec un autre nom comme /home/yunohost.app/UnAutreNom/ posera des problèmes (scripts YunoHost de sauvegarde et de restauration)
edit : S’il y a plusieurs projets: /home/yunohost.app/dodoc/projet_1
Et on change contentPath dans /var/www/dodoc/settings.json : "contentPath": "/home/yunohost.app/dodoc/projet_1,
et on oublie pas de redémarrer le service. (Webadmi → Outils → Services → dodoc → Redémarrer)
Pour les autorisations à appliquer au dossier de données :
@louis J’ai fait des tentatives infructueuses d’installation dans un sous-dossier domain.tld/dodoc, (j’ai une page blanche). L’installation dans un sous-dossier est-elle possible ?
Merci @eric_g !
Oui oui je parlais bien de /home/yunohost.app/dodoc
J’ai modifier les droits comme tu as dit et ça marche.
Les paramètres de l’ancien dodoc ce sont appliqués à celui de Ynohost.
Bravo à toustes ! On a fait une belle équipe
Je déterre ce message car après la mise à jours vers la version 11 je rencontre à nouveau ce problème. @louis m’a fait installer un second dodoc et l’identification fonctionne pour ce second. Quand au premier, c’est devenu impossible de se connecter.
Une idée de quoi faire ?
Merci par avance
Guillaume
Salut à toustes ,
On m’a répondu sur le forum de Yunohost. En fait pour pouvoir faire la commande que tu me damande il faut passer en « shell » de la manière suivante :
yunohost app shell dodoc
Puis d’ici on peut lancer les commandes que tu demande souvent pour régler les bugs. Tel que dans mon cas : npm run debug
Entre-temps, j’avais restauré la sauvegarde de dodoc d’avant la mise à jour vers la version 11. Ce qui m’avait permis de récupérer l’accés admin à dodoc.
Maintenant je vais remettre à jour dodoc vers la version 11 et si le problème se représente je saurai quoi fournir à @Louis.
J’ai un dernier bug que j’avais repéré sur la dernière version et qui n’est pas dissous après mise à jour. C’est la fonction de montage vidéo qui echoue à 100%.
Mainteant que je sais comment trouver le journal (pour rappel avec journalctl -u dodoc -f), voici le log avec l’erreur :
Mar 02 17:37:41 cloud.guillaumeleguen.xyz node[233113]: ! EXPORTER • An error happened: ffmpeg was killed with signal SIGSEGV
Mar 02 17:37:41 cloud.guillaumeleguen.xyz node[233113]: ! API2 • Failed to export file: Error: ffmpeg was killed with signal SIGSEGV
Et le log complet :
Mar 02 17:36:28 cloud.guillaumeleguen.xyz node[233113]: API2 • _restrictToContributors – Parent inheritance: Token is contributor
Mar 02 17:36:34 cloud.guillaumeleguen.xyz node[233113]: API2 • _restrictToLocalAdmins – Parent inheritance: Token is contributor
Mar 02 17:36:40 cloud.guillaumeleguen.xyz node[233113]: ! TASKS • An error happened: ffmpeg was killed with signal SIGSEGV
Mar 02 17:36:40 cloud.guillaumeleguen.xyz node[233113]: ! TASKS • ffmpeg standard output:
Mar 02 17:36:40 cloud.guillaumeleguen.xyz node[233113]: ! TASKS • ffmpeg standard error:
Mar 02 17:36:40 cloud.guillaumeleguen.xyz node[233113]: ffmpeg version 6.0-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2023 the FFmpeg developers
Mar 02 17:36:40 cloud.guillaumeleguen.xyz node[233113]: built with gcc 8 (Debian 8.3.0-6)
Mar 02 17:36:40 cloud.guillaumeleguen.xyz node[233113]: configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc --enable-fontconfig --enable-frei[…]
Mar 02 17:36:40 cloud.guillaumeleguen.xyz node[233113]: ! EXPORTER • An error happened: ffmpeg was killed with signal SIGSEGV
Mar 02 17:36:40 cloud.guillaumeleguen.xyz node[233113]: ! API2 • Failed to export file: Error: ffmpeg was killed with signal SIGSEGV
Mar 02 17:37:35 cloud.guillaumeleguen.xyz node[233113]: API2 • _restrictToLocalAdmins – Parent inheritance: Token is contributor
Mar 02 17:37:41 cloud.guillaumeleguen.xyz node[233113]: ! TASKS • An error happened: ffmpeg was killed with signal SIGSEGV
Mar 02 17:37:41 cloud.guillaumeleguen.xyz node[233113]: ! TASKS • ffmpeg standard output:
Mar 02 17:37:41 cloud.guillaumeleguen.xyz node[233113]: ! TASKS • ffmpeg standard error:
Mar 02 17:37:41 cloud.guillaumeleguen.xyz node[233113]: ffmpeg version 6.0-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2023 the FFmpeg developers
Mar 02 17:37:41 cloud.guillaumeleguen.xyz node[233113]: built with gcc 8 (Debian 8.3.0-6)
Mar 02 17:37:41 cloud.guillaumeleguen.xyz node[233113]: configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc --enable-fontconfig --enable-frei[…]
Mar 02 17:37:41 cloud.guillaumeleguen.xyz node[233113]: ! EXPORTER • An error happened: ffmpeg was killed with signal SIGSEGV
Mar 02 17:37:41 cloud.guillaumeleguen.xyz node[233113]: ! API2 • Failed to export file: Error: ffmpeg was killed with signal SIGSEGV
Je suis désolé mais mon niveau ne me permet pas encore de comprendre ce genre de log. J’éspère qu’un jour je saurai faire
Est-ce que tu peux me donner accès à un projet pour que je test avec mon compte Louis ?
Savoir si ça échoue immédiatement ou non, et tester différents contenus dans le montage, etc.
Merci !
Je découvre l’existence d’un bug à cette occasion : si l’espace parent d’un projet est privé, et que le compte qui accède au projet n’a pas accès à l’espace (car privé), alors la fenêtre qui permet d’importer des médias dans une publication ou une fabrication ne charge pas (car elle tente de lister les autres projets de l’espace et n’y arrive pas). Je résous ce soucis
Du coup pour tester tu pourrai me créer un espace privé dont je suis contributeur ou admin ? merci !
