Les dossiers utilisateurs serait physiquement dans /home/yunohost.multimedia mais avec un lien symbolique dans chaque home.
L’idée étant d’échapper à la copie du backup (avec --no-dereference), ce qui devrait être le cas si la copie utilise -a.
Je pense qu’il est préférable de ne pas inclure par défaut les fichiers multimédia car ça pourrait vite faire exploser le stockage.
Chaque utilisateur devrait, à mon avis, s’assurer lui même de sauvegarder ce genre de fichiers si il veux.
Je n’ai rien contre créer des sous-dossiers dans le dossier vidéos. Et je pense qu’il est préférable que ce soit le cas par défaut pour habituer un utilisateur à s’en servir si il installe une telle application.
Toutefois, chaque utilisateur devrait pouvoir gérer ses dossiers je pense. Auquel cas, les app nécessitant des dossiers spécifiques devrait s’assurer de leur existence. Ou accepter leur absence.
Une seconde solution serait qu’une application nécessitant strictement certains dossier en limite les droits pour éviter sa suppression.
J’ai commencé un script pour créer le groupe, les dossiers et appliquer les droits.
Je pense qu’il appartient à owncloud (et autre) de s’ajouter au groupe multimedia par la suite. (Je posterais des issues).
En fait chaque app le nécessitant devrait, après avoir exploité ce script, s’ajouter au groupe multimedia et s’interfacer avec les dossiers.
Pour transmission, je pense que le chown va foutre la merde sur le dossier torrent. C’est à tester.
De la même manière, c’est transmission lui-même qui devrait ajouter son dossier en ln dans share, après exécution du script (issue à prévoir là aussi pour en discuter). Ce qui évite de devoir vérifier sa présence.
Je vais continuer à tester tout ça, notamment avec owncloud et transmission. Mais pas ce soir
J’ai avancé un peu sur la question.
Le dépôt github est à jour de mes derniers travaux.
J’ai eu quelques problèmes avec umask, avant d’en comprendre le véritable fonctionnement. (Qui est pour le moins décevant…)
Je me suis donc finalement tourné vers les ACL (c’est Kload qui va être content) pour supplanter les carences de umask en matière d’héritage des droits pour le groupe sur les nouveaux fichiers.
J’ai ajouté un script pour simplifier l’ajout d’un dossier par une app dans le dossier Share.
Transmission est toutefois un cas particulier car son dossier, yunohost.transmission est lui-même interdit en lecture par quiconque autre que lui-même (pour une raison qui m’échappe). Pour que le lien symbolique soit lisible dans le dossier Share, le dossier yunohost.transmission DOIT disposer d’un droit de lecture par other.
Mais, tout n’est pas si simple, et je bute actuellement sur 2 problèmes que je ne comprend pas…
Owncloud, fait parti du groupe multimedia. sudo usermod -a -G multimedia owncloud
Mais il indique ne pas avoir de droit d’écriture dans le dossier Multimedia. Impossible donc de tester avec owncloud pour le moment.
Transmission ne respecte ni le setgid, ni l’héritage d’acl pour les fichiers qu’il créé. Les dossiers seuls les respecte.
Il est à noter que j’ai tenté d’appliquer les mêmes droits sur le dossier progress sans plus de succès.
Là, je sèche actuellement et un peu d’aide ne serait pas de refus
En espérant être encore un peu suivi sur ce projet
J’ai enfin réussi à obtenir un comportement satisfaisant sur la gestion des droits du dossier multimédia. En utilisant exclusivement les ACL.
Le dépôt github est à jour de mes dernières avancées.
Le résultat est donc le suivant:
Le script ynh_media_build.sh créer le groupe multimedia, les dossiers de base ainsi que les dossiers pour les utilisateurs.
Il créer un lien symbolique du dossier share dans chaque dossier utilisateur, puis un lien vers les home de chaque utilisateur.
Ainsi chaque utilisateur a dans son home son dossier multimedia, et dans celui-ci le dossier share, qui est commun à tous.
Ensuite les droits sont appliqués sur l’ensemble du dossier en ACL, une partie qui m’a fait perdre pas mal de cheveux. Je soupçonne l’umask d’interférer avec le masque ACL…
Puis le hook est mis en place pour l’ajout d’utilisateur.
Enfin, une copie du script est placé à la racine du dossier multimedia. L’idée étant de pouvoir le réutiliser manuellement pour recréer les dossiers ou réappliquer les droits.
Le script est fait pour pouvoir être réappliqué autant fois que voulu sans provoquer d’erreur (en théorie, hein!).
Le script ajout_dossier_media.sh permet à une application de partager son dossier de media dans le dossier share.
Le script s’utilise simplement en donnant comme argument le chemin du dossier à partager et le nom du dossier dans share.
Le dossier sera partagé via un lien symbolique dans le dossier share. Et il se verra appliquer les mêmes droits que les autres dossiers multimedia. Ce qui le rend inscriptible par le groupe multimedia.
A l’usage, c’est assez simple pour une application désirant utiliser le dossier multimédia.
Il lui suffit de faire appel au script ynh_media_build.sh (même si d’autre applications l’ont déjà fait auparavant), puis d’ajouter son dossier de media avec le script ajout_dossier_media.sh.
A partir de là, le dossier sera accessible à tous les users et les app exploitant le dossier multimédia.
Si l’application doit avoir un droit d’écriture sur l’ensemble des medias (son droit sur son propre dossier n’étant pas modifié), il lui suffit de s’ajouter au groupe multimedia.
J’ai fait des tests avec succès sur transmission et owncloud. Transmission respecte les acl sur la création de ses fichiers et owncloud est capable de les supprimer et de les déplacer à sa guise.
Owncloud a simplement été ajouté au groupe multimedia.
Quand à transmission, c’est un peu plus délicat. Le dossier progress doit également appliquer les acl, car c’est là que les fichiers sont créés. Donc j’ai ajouté le dossier yunohost.transmission entier dans share, puis le dossier complete seul par dessus. Ainsi le dossier yunohost.transmission entier prend les bons droits.
Dés que j’ai du temps, je rédige une notice pour accompagner les scripts et clarifier tout ça.
De manière générale, je pense que l’ensemble est stable. Reste à discuter des détails si il y a des remarques à faire.
Vu que je maintient owncloud assez régulièrement, j’avoue que je suis ce post de prés, même si je n’ai pas grand chose à dire.
La démarche me va, reste à voir comment implémenter ça dans l’app owncloud.
Je me demande si on ne devrait pas ajouter cette gestion multimedia aux hooks officiels de yunohost…
L’implémentation dans owncloud est très simple.
Il n’a qu’à s’ajouter au groupe multimedia pour jouer son rôle de gestion sur le dossier. sudo groupadd -f multimedia sudo usermod -a -G multimedia owncloud
Et, si l’on souhaite que les dossiers multimedia soit déjà présent pour habituer l’utilisateur à leur usage ou tout autre raison, il suffira d’exécuter le script ynh_media_build.sh
Par contre, si l’ajout au groupe intervient après la création des dossiers (dans le cas d’une mise à jour par exemple), on rencontre un problème avec la mise à jour de l’arborescence des dossiers d’owncloud. Il refuse d’écrire car il ne sait pas que ses droits ont changés.
Il est nécessaire de forcer la reconstruction de son index pour prendre en compte ses nouveaux droits. sudo -u owncloud php /var/www/owncloud/console.php files:scan --all
Salut, je suis aussi de très prêt. Merci pour tout ça. Je compte intégrer ça à la future app Kodi que je développe, et ensuite et je vais voir pour faire des pull requests sur couchpotato et sickbeard, peut etre packager sickrage ou sonarr, headphones et d’autres trucs qui me passent par la tete.
Dans ton repo je pense qu’il faut proposer une structure assez proche du système de package actuel:
Un dossier “hooks” avec dedans post_user_create
Les scripts dans le dossier “script”? (ou conf ?)
Internationalisation du script: Renomer “ajout_dossier_media.sh” en “ynh_media_addfolder.sh” par exemple ? Instructions et noms de dossier en anglais
J’ai peut etre le temps ce weekend de faire cette structure et les traductions puis un PR
Oui les scripts peuvent être rangés dans des dossiers, c’était pour le moment un simple essai. Mais maintenant que c’est fonctionnel, pourquoi pas. Reste toutefois que ce n’est pas une application à part entière.
[…]
C’est fait du coup.
Les noms de dossiers sont déjà en anglais, ça me surprend de ma part d’ailleurs!
Sauf les 2 sous-dossiers car ils n’ont pas de raison d’être, ils ne sont là que pour servir d’exemple. Pour définir les sous-dossiers vidéo que l’ont veut ajouter. Et en recherchant, c’était ta demande d’ailleurs, donc n’hésite pas à les modifier et mettre ce qui convient le mieux pour les app dont tu parlais.
Pour les instructions, pour ma part je ne peux les écrire qu’en français. Mais ça peut être traduit sans problème.
Je vais rédiger un readme pour expliquer l’usage (dés que je peux), dans l’idéal il devrait être dans les 2 langues je pense.
En tout cas, merci les gars, j’avais l’impression d’être perdu tout seul dans mon topic . Ça fait plaisir de voir que le projet intéresse toujours.
Ça intéresse même carrément ! Moi je ne suis qu’utilisateur, je vais pas beaucoup vous aider, mais je m’en servirais volontiers quand ça sera utilisable.
Merci !
Le script pour mettre en place les dossiers multimédia est déjà utilisable.
Reste maintenant l’intégration dans les app. Je travaille actuellement (et lentement…) sur l’intégration dans owncloud et transmission. De manière générale, l’implémentation est très simple.
Désolé pour mon manque d’implication … Pas trop ma priorité en ce moment.
Je pensais pour ma part retravailler CouchPotato et SickRage en premier lieu, et les intégrer à Transmission
Je compte aussi remplacer sickbeard par sickrage (que je trouve bien mieux), et trouver un moyen de rajouter Transmission dans CouchPotato en m’inspirant de ta méthode Sickbeard.
Enfin bien sur rajouter les dossiers multimédia dans chaque app …
L’idée de partager les médias entre les applis me parait génial !
J’essaie d’intégrer iGalerie à yunohost, c’est une galerie photo en php.
Cette appli pourrait très bien entrer dans ce partage de media.
Est-ce que vous avez avancé sur ce sujet depuis début mars ?
Salut Maniack_Crudelis, et merci pour la réponse rapide !
A priori pour une galerie photo, je n’ai pas besoin d’avoir un dossier propre de média (donc pas de ynh_media_addfolder.sh)
Je ne pense pas qu’elle ai besoin d’un accès en écriture, si jamais c’est le cas j’ai vu comment faire.
Et à priori, les différents utilisateurs ne partagent pas leur albums photo.
J’ai juste quelques questions :
Faut-il que dans le script d’install, je change le répertoire des albums photo de iGalerie pour lui dire que c’est dans les dossiers multimédia ?
Est-il conseillé que je mette en place un sous dossier du type /home/yunohost.multimedia/$admin/Picture/iGalerie ?
(Sachant que toutes les images seront donc publiés en ligne sur la galerie Photo igalerie, c’est public ou non suivant ce qu’a décidé l’utilisateur à l’installation.)
Ou alors je pose la question du répertoire à partager lors de l’installation ?
D’ailleurs j’ai prévu de permettre du multi instance, dans ce cas il faudrait peut être un sous repertoire par instance ?
Oui, d’une manière ou d’une autre. J’imagine que iGalerie utilise un dossier dans son propre répertoire pour stocker les images. Soit tu modifies l’emplacement du dossier dans la config, soit tu créés un lien vers ce dossier dans Multimedia avec ynh_media_addfolder.sh.
Oui, si tu souhaites que seul l’user $admin ai accès aux photos. Les photos apparaîtront dans son Home, mais ne seront pas visibles par d’autres utilisateurs.
[quote=“quent57, post:38, topic:1200”]
3) Est-il conseillé que je mette en place un sous dossier du type /home/yunohost.multimedia/$admin/Picture/iGalerie ?(Sachant que toutes les images seront donc publiés en ligne sur la galerie Photo igalerie, c’est public ou non suivant ce qu’a décidé l’utilisateur à l’installation.)Ou alors je pose la question du répertoire à partager lors de l’installation ?D’ailleurs j’ai prévu de permettre du multi instance, dans ce cas il faudrait peut être un sous repertoire par instance ?[/quote]
Alors, c’est une question de préférence. Si tu ne fais pas de sous-dossier, toutes les images de l’utilisateurs se trouveront dans iGalerie. Si tu choisis un sous-dossier, tu limites l’affichage aux photos qui s’y trouvent. Laisser ce choix à l’utilisateur est peut-être le plus judicieux.
Pour le multi-instance, je pense que ce n’est pas un problème. Un multi-instance avec un user différent ne changera rien. Un multi-instance en sous-dossier cohabitera très bien, et si enfin il est sur le dossier global comme le précédent, ce sera juste inutile…
Globalement, laisser le choix à l’utilisateur me semble le plus simple.
Mais ça amène une configuration très différente.
Si le choix se porte sur le dossier Picture dans sa globalité, je pense qu’un accès en lecture et éventuellement écriture est suffisant. Mais il faudra passer un sed dans le fichier de config pour changer le dossier des images.
Si le choix est sur un sous-dossier, l’usage du script ynh_media_addfolder.sh est certainement le plus simple car il ne nécessitera pas de modifier la config.
Bon en fait j’ai regardé le script, et il créer un lien symbolique dans share. Je pense qu’il devrait être plus flexible et proposer aussi de créer le dossier dans un répertoire user.
Et également d’inverser la position du lien symbolique, le dossier serait plus en sécurité dans Multimedia (en cas de suppression de l’app) avec un lien symbolique dans le dossier de l’app.
Je viens de mettre à jour le script ynh_media_addfolder.sh, tu peux à présent ajouter un dossier chez un utilisateur et plus seulement dans share.
Et il est possible également de déplacer le dossier de l’app et le remplacer par un lien symbolique, plutôt que d’avoir le lien symbolique dans yunohost.multimedia.
J’ai du mal à appréhender le fonctionnement de mini_dlna il me semble…
Pour pouvoir accéder aux téléchargements de transmission, j’ai utilisé ton script de cette manière:
Ce qui crée bien un lien dans Share. Néanmoins, quand je consulte vlc, je ne vois pas apparaître ce dossier, ni son contenu dans les dossiers préconfigurés.
Je pense ne pas avoir tout compris. Je pense éventuellement créer de la même manière un lien dans Share/Video par exemple, mais si je télécharge également de la musique?
. Ça fait plaisir de voir que le projet intéresse toujours.