Bonjour,
Pour ma curiosité, avant que je mette à jour, quel changement impose de lancer le démon en root dans la version beta du plugin ?
Un problème remonté sur le community qui est corrigé par le passage en root
Ok, merci. Je reste preneur de précisions et/ou d’un lien. C’est pas un changement anodin
Le lien fait faire une recherche sur le community je l’ai plus sous la main.
L’explication j’en ai pas et ça change pas grand chose en vrai
Dommage, je ne partage pas cet avis : Les élévations de privilèges c’est à utiliser avec parcimonie.
3 « J'aime »
Ben oui mais quand ça marche pas faut bien trouver une solution pour que ça marche
Oui, sauf que toutes les solutions ne sont pas bonnes.
D’où la question de @naboleo.
Il y a une différence entre choisir la solution de facilité car le dev n’est pas suffisamment de compétences ou parce qu’il n’y a vraiment pas d’autres solutions.
La réponse me semble light.
Jeedom est un projet plus qu’interessant (et j’en parle en bien dans la vie de tous les jours). Je pense que cela vaut le coup de répondre avec un peu plus d’explications au moins pour le sérieux de la solution. Car là, cela ne donne vraiment pas une bonne image de communication.
2 « J'aime »
Désolé mais la comme tu l’as si bien dit je ne suis pas assez compétant sur le sujet pour faire mieux désolé.
Bien vu ! Effectivement ça semble correspondre. Pour autant, ça ressemble quand même à un cas bien particulier d’environnement python foireux
1 « J'aime »
Cela m’avait l’air aussi d’un cas isolé.
La personne n’a pas voulu investiguer plus et a clôturé le sujet du coup j’ai laissé tomber
Donc pour un gars, une situation, toute la gestion du plugin est revue ?
Ce type de résolution pour un individu et généralisé à tous n’est pas l’idée de l’année.
Surtout au regard du contournement choisi (sudo).
Il serait bien que malgré la charge de Jeedom, un peu de temps y soit consacré pour revenir à une situation moins risquée.
Loïc dit qu’il est incompétent, c’est possible, mais il faut quand même ne pas faire n’importe quoi.
Non c’est pas un cas un isolé j’ai eu le même souci au support sur un autre plugin c’est un changement de gestion sur rpi j’ai l’impression mais comme dit je n’ai pas les compétences techniques pour faire mieux que cette correction…
Mais vous avez raison je vais revenir en arrière et j’arrête d’essayer d’aider a tout prix les utilisateurs (voir même d’aider tout cours ça sera plus simple)
Je vous laisse donc le soins d’expliquer aux utilisateurs pourquoi ça ne marche pas chez eux et pourquoi il y a une correction possible mais qu’on la mets pas en place.
Je vais aussi réduire grandement mes modifications sur le code car suite a ce sujet je viens de me rendre compte que je ne suis pas assez compétant pour le faire et loin de votre niveau d’exigence. Clairement je suis plus là bonne personne et je veux trop en faire.
Bonjour à tous,
Je vois qu’on est dans la partie beta, que le commit date de 2 jours aujourd’hui, que celui-ci s’appel test !
On vas peut-être commencer par arrêter de fustiger sans arrêt sur des bouts de code, et peut-être ce lancer dans une beta constructive ou les personnes ayant plus de compétences au niveau des droits Debian pourrait donner leurs avis et leurs aides. merci !
arrêtons donc les débats d’idéologie. et travaillons tous ensembles.
Merci à vous tous !
1 « J'aime »
Beta peut oui, commit récent oui (comme quoi les BT font leur job, a peine commit, ils font un retour)
Donc cette partie là a bien marcher.
Mais là non explication de Loïc sur la/les raisons de ce changement effectivement violent, ça c’est pas la beta constructive que tu évoques.
Le seul cas visible sur le forum, ça ne mérite sûrement pas cette modif. Après un uograde système, se retrouver avec un pip bancal pour www-data et corriger en faisant sudo … Même l’utilisateur est revenu en arrière.
Sudo est déjà une bombe pointée du doigt par le concurrents car trop utilisé. Je me souviens d’une époque où il avait même fallu en exclure le maximum (la même époque où a été mis en place des commandes pour proposer une alternative a apt-get sur le systèmes non debianeux, la aussi chantier abandonné)
Openzwave a besoin d’accéder a un port série et lancer un service sur un port non système. Donc rien ne justifie sudo, surtout pas parceque des lib python sont pas installées pour www-data
2 « J'aime »
@lunarok, je n’ai pas pointé du doigt les betas testeurs et leur test.
Si tu as des idées pour améliorer cette partie, tu peux contribuer.
Après sur le pourquoi du comment il a fait cette modification c’est que c’est la seul qu’il a trouvée pour le faire et c’est là où il faudrait aider plutôt que de crier à l’incompétence, je ne vois pas de message de fermeture à changer cette partie par autre chose pour régler le souci en fait.
mais il est vrai qu’exécuter en sudo ne serait peut-être pas la meilleure des solutions, mais Loic à cet instant T trouvé que ça (on parle toujours de beta etc )
Merci à tous pour votre participation.