You are not logged in.
Bonjour,
j'ai installé GLPI 9.4.3 ainsi que les plugins Fusion Inventory 9.4+1.1 et Flyve MDM 2.0.0-rc.3 dans le but de gérer le parc informatique de mon entreprise mais surtout, de contrôler avec le MDM une flotte d'une dizaine de terminaux mobiles.
Je déploie sur ces terminaux une application, conçue selon nos besoins, et beaucoup de nouvelles versions voient le jour sachant que nous sommes sur la fin des tests.
La première fois, lorsque je suis allé dans le menu du plugin Flyve MDM et que j'ai ajouté un nouveau paquetage, les informations "version" et "nom du paquetage" ont été récupérées et le déploiement s'est fait sans problème.
Maintenant, lorsque j'ajoute un nouvel apk, ces deux informations ne sont plus récupérées et la tâche de déploiement de l'application ne peut se réaliser. Le JSON contient deux champs vides et l'apk ne s'installe pas sur les terminaux.
La seule parade que j'ai trouvé est d'aller directement dans la base de données et de renseigner manuellement les champs vides dans la table 'glpi_plugin_flyvemdm_packages'. A ce moment là, une fois la tâche de déploiement lancée, les apk sont bien envoyés sur la flotte.
Quelqu'un aurait-il une idée ou une piste à me donner ?
Cordialement,
GLPI 9.4.3 - Fusion Inventory 9.4+1.1 - Plugin GLPI Flyve MDM 2.0.0-rc.3 - Android MDM Agent 2.0.0-rc.7
Offline
Bonjour
Quand vous uploadez un apk dans Flyve MDM il y a une phase d'analyse de l'APK qu se déroule en arrière plan, et surtout en différé. Le différé est nécessaire car l'analyse d'un APK de plusieurs MO s'avère assez long.
Tant que les infos sur l'apk sont vides (nottament avsence de son icône) cela signifie que l'apk n'a pas été analysé, ou bien que l'analyse a échoué.
Des echecs ont été constatés avec certains APK et PHP 7.0 car la librairie ZIP de php ne supportait pas le protocole de compression ZIP de ces APK. Avec un PHP 7.1 ou 7.2 (à l'époque), l'analyse de ces APK a fonctionné. Flyve peut donc être impacté par une limitation fonctionnelle de PHP. Comme ces cas étaient rares il n'y a pas en de développement fait pour informer l'administrateur sur le succès ou échec de l'analyse. C'est un point à améliorer.
Cependant l'information est disponible dans la base de données. Commencez par vérifier le statut de l'analyse.
L'analyse différée s'exécute via une action automatique que le plugin ajoute à GLPI à l'installation. Vérifiez que les actions automatiques sont bien exécutes chaque minute par une tâche cron (linux) ou une tâche planifiée (windows). Si besoin, vous pouvez forcer l'exécution de l'analyse comme vous le feriez avec une action auto de GLPI. Attention toutefois, une analyse échouée ne sera pas relancée. C'est voulu pour "conomiser les ressources système. Cela aussi mérite une petite amélioration (mais les priorités sont ailleurs pour le moment).
Je surveille le fil et attend votre retour.
No support with MP - Always run an upgrade task on a testing instance before running it on production! Always backup before any upgrade task!
Offline
Merci beaucoup pour votre réponse.
Je ne savais pas pour cette phase d'analyse des apk via une action automatique, ça éclaire beaucoup de choses sur le fonctionnement.
Effectivement, le champs parse-statut sur les lignes des apk dernièrement uploadés dans la table est au statut pending.
Je vais devoir me pencher sur la question de la bonne exécution des tâches automatiques, car au final c'est cela le problème rencontré.
J'ai forcé l’exécution de l'action automatique ParseApplication pour analyser les 2 derniers uploads (4 Mo chacun), j'ai PHP 7.2. Elle est toujours en cours d'exécution depuis 30 minutes. Je n'ai plus qu'à attendre la fin de l'analyse.
Encore merci.
Cordialement,
GLPI 9.4.3 - Fusion Inventory 9.4+1.1 - Plugin GLPI Flyve MDM 2.0.0-rc.3 - Android MDM Agent 2.0.0-rc.7
Offline
Je ne sais pas quelle est la taille de vos apk, ni le nombre en attente, mais 30 minutes c'est beaucoup trop. Un apk comme firefox, sur un simple PC de développemnt met quelques dizaines de secondes à se faire analyser.
De plus (il faut relire le code car je n'ai plus tout en tête sur cette partie) une action automatique va effectuer une analyse sur un nombre limité d'APK. Si il y en a plus que ce nombre à analyser, ils seront traités aux déclenchements suivants.
No support with MP - Always run an upgrade task on a testing instance before running it on production! Always backup before any upgrade task!
Offline
Bonjour,
voyant que le statut de l'action automatique restait sur en cours d'exécution et que le parse_statut ne passait pas en failed j'ai laissé.
Alors qu'en fait j'avais cette erreur sur le premier des apk à analyser :
Fatal error: Uncaught Exception: Attribute not found : versionCode in ...\ApkParser\Manifest.php
Cordialement,
GLPI 9.4.3 - Fusion Inventory 9.4+1.1 - Plugin GLPI Flyve MDM 2.0.0-rc.3 - Android MDM Agent 2.0.0-rc.7
Offline