Asustor Logiciels tiers : perte de confiance pour le suivi. A quand la notation par les utilisateurs ?

[shaks2022]

Bonjour

Photoprism est un bon outil d'album, il peut se baser sur sqlite ou mariadb pour fonctionner, et des outils de migrations d'une base vers l'autre sont proposés sur le site.

Là où ça ne va pas, c'est la façon pour le moins désinvolte de la personne qui tient Photoprism à jour de procéder à la mise à jour :
Je cite :

Version: 221116.0.r02

1. Change backend server from SQLite to MariaDB/MySQL Server.
2. Initial release with Docker version 221116, and the maintainer and the default password of the app are changed.
3. Copy the uploaded content "/photoprism/originals" of the previous photoprism 1.0.1 to the "/share/Docker/PhotoPrism/data" on the NAS, please scan all originals in the Library again.

Donc, je vous la refais en clair:
- recopiez toutes vos photos vers le nouvel emplacement qui sera reconnu ( pour rappel , dans la version précédente, c'était carrément pas géré, et il fallait créer le lien vers les photos à scanner après installation, par exemple via portainer )
- rescannez toutes vos photos.
- Si vous avez taggé tous les visages et associé des noms de personnes, créé des partages,etc...., ben, vous l'avez dans le c...l et vous recommencez à zéro..

La dernière ligne n'est pas écrite, mais c'est clairement le ressenti,
Je peux comprendre que l'auteur n'ait pas envie d'intégrer le processus de migration ( qui existe sur le site web de photoprism ), mais le minimum de la correction, c'est de se fendre d'une ligne dans ce style :
" - sorry for users with already existing database, and who have associated faces with photos, but adding migration steps in application is too time consuming for me. Advanced users may slip to full docker solution in order to benefit of migration tools, or try to modify container after upgrade in order to perform migration or revert back to sqllite3".

D'ailleurs, l'auteur s'est tellement pas mouillé dans sa description qu'on ne sait même pas ce qui est migré, c'est juste un gros soupçon à partir de l'instruction "scan all in library again", qui fait penser qu'on repart en fait à zéro.

Pour l'instant , je bloque la MAJ de photoprism à cause de ça, mais je commence à regretter de ne pas avoir choisi une version purement docker : au moins, je serais libre de mettre à jour Photoprism sans devoir deviner ce que la MAJ a pu casser coté paramétrage.

Et je commence à me dire que si les autres applications tierces type "docker avec habillage ADM/App central" sont du même tonneau, je vais très très vite bifurquer sur mes propres intégration directement à partir des images docker, quitte à me taper de la ligne de commande et quelques scripts pour organiser tout ça...

A bon entendeur salut.

 

[MilesTEG]

Hello @shaks2022
Je t’avoue que c’est pour ce genre de chose que je n’ai rien installé via ADM qui puisse être installé en docker par moi même.
Je n’ai installé que des paquets asustor (pour le peu Que ça me sert…) et le seul qui n’est pas estampillé asustor c’est Duplicati qui fonctionne bien mieux que la version docker que j’ai essayé. (C’est la seule solution viable sur un asustor pour faire des sauvegardes versionnées et chiffrée car de base il n’y a pas ça , je trouve ça inadmissible… mais c’est un autre sujet ).
Bref j’ai préféré installé ma version EE de portainer directement depuis la ligne de commande, puis j’ai tout fait depuis Portainer.
Watchtower, Adguard Home, Plex , Tautulli et bientôt swag avec Crowdsec.

Pour revenir à ton message, je suis bien d’accord avec toi , il n’est pas acceptable de modifier le fonctionnement de l’application sans laisser le moyen à l’utilisateur de migrer sa configuration…
Et du coup il semble préférable de ne plus utiliser ces applications issues de ADM si elles existent en docker directement.

Et je commence à me dire que si les autres applications tierces type "docker avec habillage ADM/App central" sont du même tonneau

Tu parles des autres applications docker ?
Mais qu’entends-tu par habillage adm ?

 

[shaks2022]

Hello @shaks2022
Je t’avoue que c’est pour ce genre de chose que je n’ai rien installé via ADM qui puisse être installé en docker par moi même.
Je n’ai installé que des paquets asustor (pour le peu Que ça me sert…) et le seul qui n’est pas estampillé asustor c’est Duplicati qui fonctionne bien mieux que la version docker que j’ai essayé. (C’est la seule solution viable sur un asustor pour faire des sauvegardes versionnées et chiffrée car de base il n’y a pas ça , je trouve ça inadmissible… mais c’est un autre sujet ).
Bref j’ai préféré installé ma version EE de portainer directement depuis la ligne de commande, puis j’ai tout fait depuis Portainer.
Watchtower, Adguard Home, Plex , Tautulli et bientôt swag avec Crowdsec.

Pour revenir à ton message, je suis bien d’accord avec toi , il n’est pas acceptable de modifier le fonctionnement de l’application sans laisser le moyen à l’utilisateur de migrer sa configuration…
Et du coup il semble préférable de ne plus utiliser ces applications issues de ADM si elles existent en docker directement.


Tu parles des autres applications docker ?
Mais qu’entends-tu par habillage adm ?

photoprism est une appli disponible dans le magasin d'applications d'asustor.
mais une fois installée ,tu t'aperçois que ça a créé un container 'photoprism'. Et l'arrêt/relance de l'application via adm, ça arrête et relance le container 'photoprism'
Donc, je devrais pouvoir mettre photoprism à jour directement via des commandes docker ou via portainer , qui ne devraient pas modifier la customisation du container.
mais après ça ,l'appli sera toujours à mettre à jour côté ADM. Et si je fais la MAJ côté ADM, je pense que ça va détruire le container , et en placer un autre à la place ,du même nom, mais avec des paramètres entièrement différents , pour travailler avec une base mariadb et non plus sqlite3 .
J'avais pris la précaution de sortir la bdd et les données de photoprism du container , mais après ce genre de maj, ça sera plus difficile de les réintégrer.
Et puis tant qu'à faire à utiliser mariadb, autant utiliser la version native du nas ,et pas une version embarquée dans le container ou dans un autre container ... C'est déjà flou en lisant les explications sur le site Web de photoprism , et c'est pas la description laconique dans le portail applicatif du nas qui va aider.

 

[nedrack]

LA problématique pour moi n'impute pas à Asustor qui permet à des développeurs ( plus ou moins ) ou intégrateurs de pouvoir publier sur leur store d'app.

Tu es forcément dépendant de ceux qui publient les premières apps. Alors oui, il serait je pense possible côté asustor de forcer via un contrat d'intégration dans le store, en sachant que cela pourrait en freiner beaucoup. Mais rien n'empêche n'importe qui de s'inscrire sur le coin développeur et de packagé des scripts dockers dockers par exemple.

Si sur le moment c'est fonctionnel; cela passe ( et c'est normal) la validation de asustor ... mais tu ne peux forcer aucun tiers ( entreprise ou particulier) à maintenir les apps qu'il a proposé. Beaucoup d'ailleurs le font en tant que bénévole.

 

[shaks2022]

LA problématique pour moi n'impute pas à Asustor qui permet à des développeurs ( plus ou moins ) ou intégrateurs de pouvoir publier sur leur store d'app.

Tu es forcément dépendant de ceux qui publient les premières apps. Alors oui, il serait je pense possible côté asustor de forcer via un contrat d'intégration dans le store, en sachant que cela pourrait en freiner beaucoup. Mais rien n'empêche n'importe qui de s'inscrire sur le coin développeur et de packagé des scripts dockers dockers par exemple.

Si sur le moment c'est fonctionnel; cela passe ( et c'est normal) la validation de asustor ... mais tu ne peux forcer aucun tiers ( entreprise ou particulier) à maintenir les apps qu'il a proposé. Beaucoup d'ailleurs le font en tant que bénévole.

Comme je l'ai écrit , le problème n'est pas que le dev de l'appli ne code pas une migration complète de l'appli ( et je comprends pourquoi ), mais qu'il ne prévienne pas ses utilisateurs clairement des conséquences d'une maj sans migration de données .
C'est le manque de transparence du dev que j'epingle ici, avec la complicité silencieuse d'asustor.
Et ça a pour conséquence ce que j'expose dans le titre: se méfier des applis tierces si on veut un vrai suivi et préférer sa propre implémentation quand c'est possible , et docker rend cette option tout à fait envisageable .

je pense d'ailleurs que le problème doit être le même chez les concurrents .

 

[nedrack]

complicité silencieuse d'asustor.

Au fait, c'est plus cela qui me dérange ; imputer en partie cela à Asustor qui ne fait que proposer effectivement des apps tiers sur lesquelles il n' a pas de contrôle. soit Asustor contrôle tout, même les MaJ; et à ce moment-là, on peut s'(attendre a bcp moins d'apps; soit ils font une délégation de confiance aux mainteneurs , avec les différents risques que cela comporte.

Par contre, Asustor montre bien quelles sont les apps que eux maintiennent, et celles sur lesquelles ils n'interviennent pas.

Dans mon travail, j'interviens en aide à l'intégration des apis de notre entreprise chez des partenaires. Comment ils l'intègrent techniquement et comment ils proposent le service ensuite, on ne pourra jamais le savoir car cela dépend de leur SI entre autre.

Je n'aimerais pas que l'on m'impute une responsabilité quelconque sur une situation que je ne pourrais aucunement contrôler. C'est pour tout cela que pour moi, les mots "complicité silencieuse" sont trop fort car cela induit une volonté de "laisser pourrir"; alors que pour moi, on est véritablement dans une délégation de confiance; comme sur bcp de store d'app ou en allant plus loin de marketplace d'articles.

 

[shaks2022]

Au fait, c'est plus cela qui me dérange ; imputer en partie cela à Asustor qui ne fait que proposer effectivement des apps tiers sur lesquelles il n' a pas de contrôle. soit Asustor contrôle tout, même les MaJ; et à ce moment-là, on peut s'(attendre a bcp moins d'apps; soit ils font une délégation de confiance aux mainteneurs , avec les différents risques que cela comporte.

Par contre, Asustor montre bien quelles sont les apps que eux maintiennent, et celles sur lesquelles ils n'interviennent pas.

Dans mon travail, j'interviens en aide à l'intégration des apis de notre entreprise chez des partenaires. Comment ils l'intègrent techniquement et comment ils proposent le service ensuite, on ne pourra jamais le savoir car cela dépend de leur SI entre autre.

Je n'aimerais pas que l'on m'impute une responsabilité quelconque sur une situation que je ne pourrais aucunement contrôler. C'est pour tout cela que pour moi, les mots "complicité silencieuse" sont trop fort car cela induit une volonté de "laisser pourrir"; alors que pour moi, on est véritablement dans une délégation de confiance; comme sur bcp de store d'app ou en allant plus loin de marketplace d'articles.

Ha, je vois ce que tu veux dire .
Disons, qu'il y a le risque que d'autres personnes partagent mon point de vue ( légèrement trollesque , je l'accorde ) , juste parce que le risque de dérive existe : asustor a tout intérêt ( a court terme sans doute ) de ne pas être trop regardant sur les applications publiées , afin de pouvoir se vanter de la volumétrie du magasin d'appli...
Sans tomber dans l'autre extrême façon Apple ,ça serait bien que Asustor garde un œil sur au moins les notices des applications publiées dans son store, et impose une éthique minimum et une transparence , une description détaillée dans la façon dont les applications sont intégrées.
Avec docker ,il y a également la facilité pour certains de proposer des applications Tier à peu de frais, avec une intégration très superficielle : la 1ère version de photoprism n'était pas opérationnelle pour scanner des photos déjà sur le nas car rien de prévu pour pointer en dehors du container ....
Et ça c'est le niveau 0... le niveau 1,ça aurait été de proposer un chemin de scan 'en dur' ( comme c'est fait dans cette dernière version ) , et le niveau 2, de proposer une interface dans adm qui permette de choisir ce répertoire sur le nas ...

la différence avec ton exemple ,c'est que Asustor peut toujours revenir faire une revue sur ce qui est publié dans le store et faire le ménage si besoin ...mais il faut le vouloir .

Dans tous les cas ,si j'ai ouvert ce topic ,c'est parce que le risque non nul existe qu'un utilisateur ayant installé photoprism en confiance ( c'est pas une appli officielle ok, mais elle est dans le magasin ) perde plusieurs mois de boulot sans rien comprendre à ce qui lui arrive .

tient, si le dev avait publié une nouvelle appli 'photoprismv2' qui crée un container du même nom, avec la nouvelle archi bdd, j'aurais rien dit : on pouvait alors installer les 2 en même temps et voir tranquillement comment migrer.
En plus ,c'est comme ça qu'a évolué l'appli d'album photo officielle : nouvelle appli dans le store et l'ancienne qui a disparu .

 

[nedrack]

la différence avec ton exemple ,c'est que Asustor peut toujours revenir faire une revue sur ce qui est publié dans le store et faire le ménage si besoin ...mais il faut le vouloir .

Cela équivaudrait à faire une recette à chaque mise a jour de chaque appli pour être sûr qu'il n'y a pas de régression; Irréalisable en nombre d'applis disponible avec les divers mises a jour fournies. De plus, comme ils n'ont pas forcement en tête toutes les fonctionnalités des applis ( il faudrait se taper tous les git avec les montées de version etc....), en terme de ressources humaines pour juste faire cela; cela serait très compliqué.

C'est d'ailleurs pour cela que l'on parle d'app tiers, c'est le fait que la confiance soit déléguée. Côté Apple d'ailleurs, ils valident l'entrée d'une app , mais les maj ( a part pour de flux suspects dans les apps) sont souvent regardé à postériori suite a des remontées soit utilisateur; soit de règles enfreignant leurs contrats ( comme l'histoire de EPIC). Apple dans leur store n'a pas été épargné par des apps qui ont eu des régressions ou des soucis lors de MaJ.

La seule chose qui permettrait de contrôler, c'est les appréciations des utilisateurs; et pour le coup, ce qu'il manque pour moi, c'est une notation des app fournies faite par les utilisateurs qui les ont téléchargés . Cela permettrait de séparer le bon grain de l'ivraie.

Est ce que l'on tape sur google quand suite à une maj d'une app, cette app à une régrassion??? On est sur le même schéma . Ill faut contacter le mainteneur via le mail qui est dans la description de l'app

 

[shaks2022]

.......La seule chose qui permettrait de contrôler, c'est les appréciations des utilisateurs; et pour le coup, ce qu'il manque pour moi, c'est une notation des app fournies faite par les utilisateurs qui les ont téléchargés . Cela permettrait de séparer le bon grain de l'ivraie.

ça, c'est une bonne idée !!
Je viens même de changer le titre du topic du coup

 

[nedrack]

ça, c'est une bonne idée !!

pas besoin de réinventer la roue

 

[Dami1]

"Là où ça ne va pas, c'est la façon pour le moins désinvolte de la personne qui tient Photoprism à jour de procéder à la mise à jour :"


"Et je commence à me dire que si les autres applications tierces type "docker avec habillage ADM/App central" sont du même tonneau, je vais très très vite bifurquer sur mes propres intégration directement à partir des images docker, quitte à me taper de la ligne de commande et quelques scripts pour organiser tout ça...

A bon entendeur salut."

C'est une application tierce non ASUSTOR intégrée et maintenue à jour par un bénévole.
Personnellement (mais je respecte ton avis ), je remercie ces intégrateurs tiers . La personne fait ça bénévolement sur son temps personnel.
Enfin, tu peux leur donner ton avis directement en cliquant sur le nom du mainteneur https://www.asustor.com/app_central/app_detail?id=1214&type=4&model= tu auras son adresse e-mail.

 

[shaks2022]

bonjour
autre exemple avec nextcloud ici :https://www.forum-nas.fr/threads/mise-à-jour-nextcloud-sur-asustor-3202.20214/

 

[Drthrax74]

Bonjour,

ASUSTOR utilises des outils déjà construit par des tiers, comme les images Docker par exemple.
Le problème se situe sur celui qui le gère et aussi celle qui peut être valider pour être intégrer.

Exemple:
Application 1 qui est crée par XXX compagnie dont YYYY (Utilisateurs lambda) a créer un conteneur > REFUSER CAR c'est un utilisateur
Application 2 qui est crée par XXX compagnie dont celle ci gère le conteneur : Accepter

La compagnie maintient l'application et le conteneur ce qui suit une logique de maintenance et de mise à jour.

SI on respecte pas celà, c'est le bordel.

Ceci ne m'engage que moi, c'est une simple observation de ma part.