corwin-31 / fbxtool

Python tools for Freebox management (using fbxapitool package)
GNU General Public License v3.0
0 stars 0 forks source link

only contact - no issue #1

Closed nbanb closed 2 years ago

nbanb commented 2 years ago

Dear Corwin-31

Sorry to open an issue here but I did not find the way to contact you elsewhere. I would be interested if you can have a look on this bash 'nearly full Freebox Delta Virtual Machine management' tool: https://github.com/nbanb/fbx-delta-nba_bash_api.sh/tree/nbanb-freebox-api (specially fbx-delta-nba_bash_api.sh last commit and fbxvm-ctrl, last commit)

Why bash ? first, I'm not developer => don't have a good knowledge of programming, and second, the idea was to use the less possible external tool but it's not possible in all case (to be run on certain UNIX where tools like 'jq' are not available). I'm interested about what you think of these tools, the code, and as I'm not developer, maybe I did not do things in the right way, so all your comments are welcome.

PS: I can speak french

Kind regards nbanba

corwin-31 commented 2 years ago

Bonjour,

Je ne comprends pas la demande. Quel avis serait attendu et pourquoi ? NB : le 1er repo est public, le 2nd certainement privé car non visible

Cordialement

nbanb commented 2 years ago

Bonjour

Merci pour votre retour. Désolé, j'ai encore du mal à manier les outils comme GitHub / GilLab ... Effectivement, j'avais mis tout le code dans la branche fork du dépot soit ici, mais je me rend bien compte que ce n'est pas comme ça que j'aurais du faire. Je vais donc faire un repo par programme.

Vous pourrez trouver la lib que j'ai modifié, directement dans la branche fork ici : https://github.com/nbanb/fbx-delta-nba_bash_api.sh/tree/nbanb-freebox-api ou directement :

La lib : $ curl -L https://github.com/nbanb/fbx-delta-nba_bash_api.sh/raw/nbanb-freebox-api/fbx-delta-nba_bash_api.sh >fbx-delta-nba_bash_api.sh

Le README : $ curl -L https://github.com/nbanb/fbx-delta-nba_bash_api.sh/raw/nbanb-freebox-api/README.md

Vous pourrez trouver le script fbxvm-ctrl au sein du nouveau repo créé suite à votre retour: https://github.com/nbanb/fbxvm-ctrl ou directement : https://github.com/nbanb/fbxvm-ctrl.git

Sinon pour répondre à vos questions :


avis sur le code avis sur la semantique avis sur l'architecture interne, la structuration du programme avis sur le potentiel d'industrialisation (pour utilisation par des non informatitiens faisantde la domotique) et est ce que ça fonctionne ailleurs de chez moi ?


Pourquoi :

Plus globalement, le seul endroit ou j'ai tester c'est chez moi, je n'ai aucune idée de si ça fonctionne chez d'autres. Aujourd'hui avec les VM en ARM64 dans la Freebox, monsieur toutlemonde se met à avoir bash et linux chez lui, surtout ceux qui font de la domotique.

N'étant pas développeur, je ne sais pas si ce que j'ai fait "respecte les règles de l'art", si il y a des bugs, si il y a des failles, etc. Aillant vu votre repo et votre retour (https://dev.freebox.fr/bugs/task/30666), je me suis dit que vous connaissiez bien mieux que moi le developpement et les call API et que votre avis pourrait m'aider à faire évoluer positivement ces outils.

PS : Bien sûr, si vous avez le temps

En vous remerciant d'avance Cordialement nbnba

nbanb commented 2 years ago

Bonjour

Nouveau commit sur fbx-delta-nba_bash_api.sh directement dans la branche fork (pas merge avec le master) :

"Update CA / PKI options for a better support Now if you don't have your own PKI or if your CA certificate is not found, the system fallback to use '--insecure' option of cURL (= -k) It solve bug when the CA certificate were not found, the API URL was not functionnal "

C'est un a workarround, je me suis rendu compte que si vous n'aviez pas de PKI ou si le path du CA certificate n'était pas valide, l'utilisation de la lib fbx-delta-nba_bash_api.sh etait impossible (sans faire des modifs manuelles), et dans ces conditions, il vous était difficile de pouvoir tester.

Fixé temporairement par ce commit

Cordialement nbanba

corwin-31 commented 2 years ago

Bonjour,

Je ne pense pas que M. Toutlemonde passe en mode terminal pour utiliser un outil bash. A ce niveau c'est une appli graphique qui serait plus appropriée, voire mieux une appli mobile Android ou iOS (personnellement, je me suis développé une appli iOS de gestion des VM et autres fonctions non présentes dans les applis officielles). Pour ceux, un peu moins M. Toutlemonde qui iraient jusqu'au terminal, ils seront plus intéressés par des outils Python, tout simplement parce que c'est la mode et que c'est désormais le langage qu'on apprend un peu partout (et en Python on peut aussi avoir une appli graphique). Installer Python n'est pas compliqué, surtout avec les gestionnaires de paquets graphiques. Le choix de bash est intéressant néanmoins, parce que peu vont y proposer quelque chose, mais c'est un choix plus personnel.

Est-ce que ça va marcher ailleurs que chez vous ? je le pense oui sans même regarder le code, parce que ce qui compte c'est l'API et sa version, pas le modèle de Freebox ou autre. Le seul obstacle que je verrais serait de hardcoder des grosses spécificités.

Sur le potentiel d'industrialisation, c'est un paradigme fondamental d'une API, donc c'est déjà porté par l'API de la Freebox en elle-même. Sur celui de votre dev, il va dépendre des fonctionnalités de vos scripts : plus ils portent des fonctions génériques, mieux c'est. Et si vous séparer librairie d'exploitation de l'API des scripts, vous gagnez encore sur le potentiel d'industrialisation.

Actuellement, je n'ai pas énormément de temps, je regarderais le code peut-être plus tard dans l'été. Je n'ai pas la prétention d'être un "prof" d'informatique et d'algorithmique, qui plus est je suis un peu rouillé en bash, donc mon avis sera limité à ce niveau.

Cordialement

nbanb commented 2 years ago

Bonjour

Déjà, un grand merci pour votre retour, très constructif que je partage sur beaucoup de points. Effectivement, une appli graphique pour M.Toulemonde serait bien mieux, c'est malheureusement hors de mes compétences pour le moment (je ne suis pas dev, peut être y arriverai je en C avec des lib comme GTK). En regardant les forums de domotique notamment, j'ai constaté (et je trouve ça très positif) que M.presquetoulemonde n'hésite plus à pop un linux ARM64 et a executer des commandes ou des scriptes depuis le terminal.

Concernant le dev en python, je vous l'accorde, c'est à la mode et beaucoup de personnes connaissent aujourd'hui, mais 2 points m'ont écartés de ce choix :

Pour le dev d'une appli pour smartphone ayant les fonctionnalités que l'appli Freebox Compagnon ne fournit pas (backup de la box, gestion des VM des disques RAID, ...), je partage le point à 100%, mais pour le coup, je suis loin d'en sortir une (jamais fait), et comme vous l'avez déjà fait pour iOS, il faudrait que j'attaque la partie Android ce qui aujourd'hui n'est pas dans mes compétences.

PS : les seuls infos hardcoded sont : dans la lib : l'URL de la box et le path vers le rootCA de la pki qui a signé le certificat de la box dans le script de gestion des vm : le nom de l'application et le token permettant l'authentification Pour tester, il faut donc mettre la lib et le script à jour avec les valeurs

En vous remerciant encore, Bien cordialement nbanba

corwin-31 commented 2 years ago

Bonjour,

Voici mes retours ou plutôt commentaires sur les sources.

fbx-delta-nba_bash_api.sh

FREEBOX_URL + FREEBOX_CACERT + _API_VERSION + _API_BASE_URL seraient à mettre de préférence en variable d'environnement dans un fichier .fbx_env.profile ou autre nom, à charger au login genre .profile Une petite fonction de setup de ce fichier serait aussi la bienvenue, à mettre par exemple avec le check de websocat Comme les 1ères variables sont à paramétrer localement, il faudra guider l'utilisateur pour qu'il les renseigne correctement dans le fichier Ce setup devrait aussi définir APP_ID + APP_NAME + APP_VERSION + DEVICE_NAME en variable d'environnement ; prévoir peut-être une fonction d'upgrade de version.

Le token applicatif (MY_APP_TOKEN) devrait aussi être mis dans ce fichier d'environnement et donc géré en variable d'environnement.

_SESSION_TOKEN="PFK0tGTH09QAG3NImHgZVIeXBo09QAG3NImHgZVIeXBo8LKwmbaOyYMUpz0RIjSU" : il ne faut pas faire ça, il faut l'initialiser à vide et lors des appels si cette chaîne est vide, il faut renvoyer une erreur. Le token de session ne doit pris qu'au login. Il faut aussi une fonction logout pour clore la session et en libérer les ressources allouées sur la freebox.

NBA PROGRESSBAR : à mettre dans un source à part FUNCTIONS FROM JSON.SH : idem L'idée est de scinder les sources par plus petits ensembles, plus faciles à gérer et cohérent, comme on le fait avec des classes.

call_freebox_api & call_freebox_api2 : si la différence est juste ajouter une trace, c'est mieux de prévoir uune option d'appel de traçabilité/debugging et ça se globalise d'ailleurs.

Enfin, je fusionnerais avec fbx-delta-nba_bash_api_screen.sh pour ne faire qu'un source "propre" et éventuellement des options en paramètres.

fbxvm-ctrl

MY_APP_ID="app-vm" MY_APP_TOKEN="app-vm_token" Bien évdemment, à prendre dans l'environnement.

Je n'ai d'autres remarques si ce n'est que cela reste bas niveau, ce qui s'entend pour du bash donc du scripting, mais c'est austère voir rebutant pour beaucoup d'utilisateurs.

nbanb commented 2 years ago

Bonjour

Un grand merci pour votre retour et pour avoir regardé le code. J'ai déjà fusionné fbx-delta-nba_bash_api_screen.sh pour n'avoir qu'une seule source propre avec option car websocat supporte maintenant l'exit quand le terminal est en raw mode (Vitaly shukela "websocat developper" à développé la fonction depuis sa release de websocat en 1.10 spécialement pour ce use case). L'utilisation de programmes externes comme screen ou dtach n'est plus indispensable pour gérer l'interruption de la session websocket depuis le shell courant. Cependant, je n'ai pas encore pu commit cette partie, cela sera pour bientôt et je vais essayer d'inclure d'autre changes suite à vos remarques et conseil. (effectivement, paramétrer l'environnement et guider l'utilisateur pour le faire semble être une bonne solution)

Question sur le rebut des utilisateurs à utiliser une solution très bas niveau en bash : Pensez vous qu'un user débutant ne connaissant pas particulièrement la programmation et se lançant dans la création de VM Linux (en arm64) sur sa Freebox Delta serait plus à l'aise avec du code en python ou en perl (voir éventuellement en C qu'il devra au préalable compiler/debugger ) ? Ce user devant interagir avec sa VM en ligne de commande (ce sera au moins neufs fois sur dix dans un shell bash), ne serait il pas plus à l'aise avec du code bash qui est le même que les commandes qu'il doit déjà nécessairement taper dans son terminal pour administrer ses VM ? Le premier contact avec Linux d'un user passe souvent par l'utilisation des commandes GNU-coreutils dans un shell bash, il me semblait que de ce fait cela parlerai au plus grand nombre, maintenant, je ne suis pas dev et j'ai peut être une vision faussée par toutes mes années d'utilisation de Linux.

En tout cas, encore un grand merci pour votre retour et vos conseils Bien cordialement nbanba

corwin-31 commented 2 years ago

Bonjour,

Ça n'est pas le choix de bash qui est en question pour moi dans l'usage de vos outils, c'est leur mode d'utilisation. Pour les utilisateurs plus "lambda", il faudrait 1 commande simple avec juste quelques options en paramètres pour chaque fonction, par exemples : startvm ou stopvm [-force] . Sinon, c'est très bien pour scripter. Après comme je l'ai dit au départ, l'utilisateur "lambda" préfère les outils intégrés à l'interface graphique, avec menus, des icônes et tout. C'est mon opinion, rien de plus.

nbanb commented 2 years ago

Bonjour Merci pour votre retour et effectivement en terme d'ergonomie, j'ai voulu que tout soit scriptable, jusqu'à la conversion des fichiers yaml du cloudinint user-data en un oneline injectable dans le json_vm_object. Je vais essayer de faire une version split en de plus petites commandes, pour les éléments de base (start, stop, list, console)

Au niveau UI, j'avoue que moi-même j'apprécierai avoir une belle appli sur mon téléphone android permettant de gérer tout ce que les appli Free officielles ne gèrent pas, mais le dev java android est hors de mes compétences ( aujourd'hui j'utilise un terminal pour lancer les scripts bash sous android (remanié en sh brut) et c'est assez peu adapté à l'utilisation sur un smartphone)

Cependant, par déformations je ne pourrais pas me contenter juste d'une belle appli graphique même qui fait tout (sauf si elle peut s'utilser en ligne de commande également), j'aime pouvoir tout faire en ssh... ou pouvoir faire des trucs un peu plus avancés comme du routage dynamique des flux geo restreint au travers de points de sortie vpn tournant dans des vm dans la freebox, mais je vous l'accorde, les monsieur tout le monde ne fait pas ça et on sort du cadre d'une utilisation pour tous.

D'autre part, j'adhère de moins en moins à la philosophie de Free qui split les appli en différentes d'appli pour la partie home, wifi, files ... Je regrette que l'appli FreeboxCompagnon ne soit pas enrichie avec des fonctionnalités avancées de gestion des VM, du stockage, etc... afin d'en faire une bonne appli qui fais tout. Idem pour FreeboxOS qui ne gère pas la domotique/sécurité, je trouve ça très dommage, heureusement qu'il y a l'API ...

En vous remerciant encore pour vos retour Cordialement nbanba