Du nouveau dans les solutions d'inventaires et déploiements. UpdatEngine est un outil publié sous licence GPL v2 permettant principalement d'effectuer l'inventaire de postes de travail et serveurs qu'ils soient sous systèmes Windows ou Linux, de créer des paquets de déploiements et de gérer des profils de configurations logicielles.
Face aux différents logiciels existants, UpdatEngine propose des fonctionnalités inédites en abordant la question des mises à jour logicielles sous un angle différent des solutions actuelles. Le logiciel retient aussi comme principes premiers la simplicité d'utilisation et la pérennité de la solution en s'appuyant pour tous ses composants sur le langage Python et son framework phare Django.
De part ses composants, la solution se révèle ainsi évolutive, robuste et adaptable à tout environnement que se soit au niveau du serveur web (Apache2, Nginx, lighttpd) ou de la base de données (SQLite, MySQL, PostreSQL etc.). Le mode d'installation conseillé et détaillé très précisément (virtualenv) permet aussi d'éviter tous les tracas liés aux dépendances nécessaires à l'application.
Sommaire
Quelles sont ses fonctionnalités?
Avant d'aborder les différentes fonctionnalités et pour ne pas me répéter, je voulais avant tout préciser que toutes celles-ci sont accessibles via l'interface du logiciel dans un environnement simple d'utilisation (premier principe du logiciel ;-) ).
Inventaires
Pour pouvoir effectuer des déploiements de mises à jour, UpdatEngine propose comme première fonctionnalité l'inventaire des postes de travail et serveurs grâce à l'installation d'un client lui aussi développé en python permettant de remonter les informations matérielles et logicielles des postes inventoriés.
L'installation du client Windows est entièrement packagée sous forme d'un exécutable pour ne pas avoir à installer d'environnement python sur l'ensemble des postes de travails. Le déploiement du client est également facilité par l'utilisation d'options d'installations silencieuses pour le configurer avant diffusion.
Fonctionnant en http ou en https, le client peut s'exécuter à une fréquence soutenue (jusqu'à un inventaire par poste et par minute) de façon à disposer d'un outil d'inventaire et déploiement le plus réactif possible. Aussi, des benchmarks ont été réalisées permettant de valider la très bonne tenue en charge de la solution.
Ecran d'accueil
Aperçu de l'inventaire
Création de paquets de déploiements en une étape
La création de paquets de déploiement se révèle très facile et ne nécessite qu'une seule étape. Il est aussi possible de revenir à tout moment sur un paquet de déploiement pour en modifier sa composition (nom, description, commande, exécutables, conditions etc…). Il est ainsi très simple de suivre les mises à jour proposées par les éditeurs de logiciels.
L'affectation d'un paquet se fait de façon tout aussi facile, soit en ciblant un poste en particulier depuis sa fiche détaillée soit sur un ensemble de postes en utilisant la fonctionnalité de modification massive qui permet d'effectuer des traitements sur des ensembles de postes.
Exemples de paquets:
Conditions d'installations
Si il est possible de filtrer les postes sur lesquels installer un logiciel en effectuant des recherches précises, il est aussi possible de créer des conditions d'installation directement depuis l'interface de façon à n'installer des logiciels que si cela est nécessaire (et possible).
L'administrateur crée ainsi des conditions qu'il associe par la suite aux paquets de déploiements créés. Tout comme pour les paquets de déploiement, l'administrateur peut à tout moment revenir sur une condition pour en modifier le contenu. Une condition déjà définie peut aussi servir à plusieurs paquets. Par exemple une condition du type "Le poste doit être de type Windows 64 bits" pourra être partagée entre tous les paquets nécessitant cette architecture.
Exemple de conditions:
Profils de configurations logicielles
Après avoir crée quelques paquets de déploiements et les conditions associées, il est possible de créer des profils de configurations qui définissent quels logiciels doivent obligatoirement être installés sur les postes disposant de ce profil.
Il est ainsi possible de créer des profils différents pour les différentes utilisations des postes inventoriés. Par exemple:
- Profil standard (pour les postes classiques)
- Profil expérimental (pour tester les dernières versions des logiciels sur un panel de postes)
- Profil graphiste (pour les postes DAO/PAO)
- Profil développeur etc…
L'association d'un profil à un poste est très rapide et offre un meilleur contrôle du parc informatique administré.
Les profils sont vérifiés à chaque inventaire pour être ré-appliquer si nécessaire.
Exemples de profils:
Périodes de déploiements
Inventorier des postes en cours de session ne pose pas de soucis mais déployer des logiciels ou mises à jour à n'importe quel moment de la journée peut légèrement perturber les utilisateurs. Pour cette raison, il est possible d'associer un poste de travail à un « profil horaire de déploiement » qui définit les plages horaires pendant lesquelles un poste peut être mis à jour. Pas de risque ainsi d'installer la dernière version de LibreOffice alors que votre Directeur peaufine la dernière version de son tableau d'investissement.
Pour des mises à jour urgentes ou de sécurité, vous pouvez aussi ajouter une option spéciale à un paquet (« ignorer les horaires de déploiement ») qui permettra à ce paquet et seulement celui-ci de s'installer sans respecter ces plages horaires.
Exemple de périodes horaires:
Wake on lan
Si vous définissez des périodes de déploiement de nuit il est plus que probable que la majorité des postes seront éteints à ce moment là. Pour remédier à ce problème, il est possible de programmer des tâches de réveil par le réseau (WOL) qui seront lancées pour tous les postes sélectionnés à la date et l'heure choisie.
Exemple de tâche de wake on lan:
Installation à l'initiative du client
Si l'installation classique d'un paquet se fait depuis le serveur, il est aussi possible de lister les paquets disposant de l'option « publique » directement depuis le client du poste et d'en déclencher l'installation sans avoir à la programmer dans l'interface web du logiciel.
En dépannage sur un poste, il est ainsi possible de lister puis utiliser instantanément et sans risque les paquets déjà configurés sur le serveur.
Quel support?
Le site support d'UpdatEngine propose des documentations pour l'installation du logiciel, son utilisation ainsi que des fiches dédiées à la création de paquets de déploiements.
Il est aussi possible de tester directement le logiciel en utilisant la machine virtuelle de démonstration proposée en téléchargement sur le site.
Enfin, vous découvrirez en suivant le lien suivant les motivations qui m'ont poussées à développer ce logiciel: Pourquoi, par et pour qui
Pour très bientôt:
UpdatEngine est passé en version stable depuis le 02 juin et les développements ont repris pour apporter de nouvelles fonctionnalités qui seront proposées en version béta à partir du mois d’août.
Parmi les prochaines fonctionnalités, on peut notamment citer:
- une utilisation plus poussée des entités pour permettre l'affectation de paquets et l'association de profils à des groupes entiers sans avoir besoin de recourir à la fonction de modification massive.
- l'héritage de profils afin de pouvoir bâtir des profils de configuration de base dont hériteront des profils "enfants".
- la possibilité d'exporter et d'importer des paquets de déploiements ce qui offrira la possibilité d'échanger très simplement des paquets de déploiements entre utilisateurs de l'application.
Aller plus loin
- Site source d'UpdatEngine (900 clics)
- Détail des fonctionnalités (294 clics)
- Par où commencer (180 clics)
- Exemples de paquets de déploiements (323 clics)
# Agent d'inventaire...
Posté par David DURIEUX . Évalué à 3.
Pourquoi redévelopper un agent d'inventaire alors qu'il en existe des bons en libre (FusionInventory, OCS Inventory…) ? (c'est pas un troll, c'est juste pour savoir ce qui a pu motiver ce développement)
[^] # Re: Agent d'inventaire...
Posté par sparklyon . Évalué à 1.
Peut-être trouveras-tu la réponse en suivant le lien où il explique ses motivations :
[^] # Re: Agent d'inventaire...
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 8.
Pour résumer et compléter les infos du lien rappelé par sparklyon: En fait la raison est assez simple, je suis parti d'une page blanche afin de n'être dépendant d'aucun projet existant et implémenter les fonctionnalités que je souhaite sans aucune contrainte (par exemple, je ne souhaitais pas être "contraint" par les mécanismes existants de déploiements).
J'ai beaucoup de respect pour les deux projets que tu cites (sinon, je n'aurais pas écris l'ouvrage sur l'application OCS Inventory paru dernièrement ;-) ), mais je veux simplement faire quelque chose de différent / complémentaire apportant de réelles nouveautés tout en restant accessible. C'est d'ailleurs un point sur lequel j'ai déjà eu l'occasion de discuter avec les membres de la communauté OCS que je salue si ses membres passent par ici :)
Je souhaitais enfin développer la partie serveur et cliente dans le même langage afin d'être efficace et cohérent avec la philosophie du projet.
[^] # Re: Agent d'inventaire...
Posté par pasBill pasGates . Évalué à -3.
J'ai quand meme bcp de mal a comprendre… pourquoi est-ce que qq'un s'amuserait a installer ca pour un parc Windows compare a Active Directory / group policy / powershell ?
Ces 3 ensembles sont la de base et amenent tout ce dont tu parles.
[^] # Re: Agent d'inventaire...
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 9.
Je comprend tout à fait votre remarque. Ce logiciel comme les autres solutions du même domaine (wpkg, OCS, Fusion) répond à cinq besoins principaux:
- Les grands parcs basés sur des solutions autres que Active Directory (Samba / Ldap);
- Les parcs de dimension réduites qui n'utilisent pas Active Directory, n'ont pas les ressources ou les moyens d'utiliser ces solutions;
- Les parcs Active Directory qui cherchent des solutions simples et complémentaires;
- Les administrateurs qui cherchent des solutions évolutives et adaptables à leurs besoins propres;
- Les curieux et passionnés par les solutions libres qui recherchent des alternatives aux solutions propriétaires: on est bien sur Linuxfr.org n'est-ce pas ;-) .
[^] # Re: Agent d'inventaire...
Posté par Andre Rodier (site web personnel) . Évalué à 7.
Il y en a certainement d'autre…
Je trouve cette question totalement incongrue, c'est comme si on avait demandé à Linus pourquoi il avait démarré le dévelopement de Freax…
[^] # Re: Agent d'inventaire...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Pour ne pas avoir de serveur sous Windows
Afin de dé-installer (et non seulement dé-activer) le partage de fichier sur l'ensemble de postes clients Windows (c'est bête mais s'avère très efficace en terme de sommeil).
[^] # Re: Agent d'inventaire...
Posté par Philippe M (site web personnel) . Évalué à 2.
Born to Kill EndUser !
[^] # Re: Agent d'inventaire...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
OCS, c'est bien pour un inventaire sous GN U/Linux mais pas pour les gérer ! On le fait pour Windaube parce que c'est tout moisis mais pour GNU/Linux, cfengine et ses enfants sont bien plus performant.
# test
Posté par el_profesor . Évalué à 0.
Outil très intéressant. Je vais le tester pour voir les différences qu'il y a entre cet outil et Fusiondirectory et OCS.
# depot de configurations logicielles ?
Posté par aderumier . Évalué à 1.
Bonjour,
D'abord bravo pour le travail fourni, ca l'air vraiment nickel. (je vais l'essayer dans le mois qui vient).
Est-ce qu'il est prévu d'avoir un genre de depot communautaire où l'on pourrait avoir des configuration de deploiements pour tel ou tel logiciel ?
(Un peu comme le wiki de wpkg, mais en mieux, intégré à l'application par exemple ;)
[^] # Re: depot de configurations logicielles ?
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 2.
bonjour et merci pour votre commentaire.
Sinon oui, c'est effectivement une fonction que j'ai prévu pour la prochaine version et que je souhaitais n'annoncer qu'à la sortie. Mais comme ça c'est fait ;-).
# typo
Posté par palm123 (site web personnel) . Évalué à 2.
dans les déploiements
s/pose de midi/pause de midi
Ca m'a l'air excellent sinon.
ウィズコロナ
# Création de paquets de déploiements en une étape
Posté par Kerro . Évalué à 2.
Ah là là, naïf que je suis.
Je vois « Création de paquets de déploiements en une étape » alors forcément je me dis que quelqu'un a trouvé une manière sympa qui fonctionne avec ces fichues machines Windows (ou du moins la fichues absence de méthode générale, genre gestionnaire de paquets que tous les éditeurs utiliseraient).
UpdatEngine lance une ligne de commande. En gros j'installe PDFCreator car il est déjà prévu pour s'installer via une simple ligne de commande.
Bon alors ok, UpdatEngine fait plus que ça. Il gère des conditions et des horaires. Mais les « paquets de déploiements » ne font rien de plus qu'un bête .bat
Cela dit, quelles solutions sont disponibles pour faire autrement ?
Je n'en connais pas.
Dès qu'on a besoin d'une configuration spécifique, il faut se farcir un .bat ou .ps1 qui va chercher des dll supplémentaires, ou modifier des valeurs dans la base de registre.
Pareil avec du Linux.
L'idéal étant une installation automatisée (que je fais tout de même aux petits oignons), avec configuration contrôlée par CFEngine par exemple.
[^] # Re: Création de paquets de déploiements en une étape
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 1.
Je suis très intéressé par le besoin que vous exprimez, pourriez vous m'en dire un peu plus (ici ou par mail). Perso, dans ce cas (mais je n'ai peut être pas tout saisi) je fais un paquet d'installation des dll avec inno setup ce qui me permet de suivre facilement les versions puis je fais une condition sur ce paquet pour le logiciel initial.
Dans ce cas, les profils sont très utiles car en mettant à la fois le paquet de dll et le logiciel en ayant besoin, UpdatEngine installera d'abord les dépendances nécessaires puis le logiciel qui ne pouvait pas s'installer à la base (pas besoin de les placer dans un ordre précis, le système se débrouille seul lors de la vérification du profil). Par exemple si un logiciel A nécessite B et B nécessite le logiciel C et que ces trois logiciels sont dans le même profil (peu importe l'ordre), alors UpdatEngine installera automatiquement C puis B et enfin A.
[^] # Re: Création de paquets de déploiements en une étape
Posté par Kerro . Évalué à 6.
La problèmatique est valable pour tous les OS : déployer un logiciel ne peut se faire qu'au cas pas cas.
Si le logiciel est prévu pour s'installer tout seul (gestionnaire de paquet, ou installeur Windows) ET que sa configuration par défaut est bonne, alors c'est simple.
Si la configuration par défaut ne convient pas à l'usage qu'on en fait, il faut mettre en œuvre un moyen de l'adapter. Avec Linux ce sont de simples scripts, éventuellement la copie d'un fichier de configuration. Avec Windows c'est parfois bien plus compliqué car certains logiciels ne sont manipulables qu'à la souris (donc il faut passer du temps à identifier l'emplacement où le logiciel stocke ses paramètres. Base de registre, fichiers, base de données. Parfois sur le web. Puis bricoler).
Un exemple tout bête : Microsoft Office.
Il est possible de créer un fichier de configuration pour automatiser l'installation avec tous les paramètres souhaités… parmi ceux disponibles.
Une fois que le logiciel est installé, chaque utilisateur de la machine se voit poser des questions auxquelles la majorité des gens en entreprise n'ont absolument rien à fiche, et auxquelles ils n'y comprennent rien. Il faut donc que le processus d'installation soit complété par un script exécuté à la connexion des utilisateurs (car si l'utilisateur est créé plus tard, il faut configurer pour lui).
Autre exemple : OpenVPN
Que ce soit sur Windows ou Linux, une fois qu'OpenVPN est installé, il ne sert à rien sans fichiers de configuration. Il faut donc un script pour mettre cela en place.
Il n'y a pas encore de consensus sur une méthode qui permette de définir TOUS les paramètres désirés.
Par exemple un fichier .conf qui accompagne l'installeur Windows, ou je ne sais quoi. avec Linux c'est plus simple, mais aucune garantie que ça continue avec les logiciels graphiques.
Bref, une fois l'installation « de base » effectuée, on est dans le domaine de CFEngine, Puppet, etc.
Hors ces logiciels savent déjà faire de l'installation.
Par contre la documentation à s'enfiler est rude.
[^] # Re: Création de paquets de déploiements en une étape
Posté par flan (site web personnel) . Évalué à 1.
Dans la famille, Salt est assez accessible je trouve. Il n'a sûrement pas toute la puissance de CFEngine, Chef ou Puppet (même s'il ne doit pas en être loin), mais il n'est pas trop compliqué, c'est déjà ça.
Mais dans tous les cas, ce qu'il y a de vraiment compliqué (y compris pour Salt), c'est d'organiser les classes de configuration. C'est vite le bordel, il faut bien le dire :(
Je te rejoins quand même sur le fond : installer des logiciels, ce n'est qu'une étape, il faut ensuite gérer les fichiers de configuration et également garantir que l'état reste stable (donc que le logiciel reste installé, que les fichiers ne sont pas modifiés, etc.)
[^] # Re: Création de paquets de déploiements en une étape
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 2.
Merci beaucoup pour vos précisions, je les garde de côté pour voir si certaines questions peuvent être traitées par le logiciel dans les prochaines versions (que ce soit par l'ajout de fonctionnalités, des bonnes pratiques ou de la documentation).
[^] # Re: Création de paquets de déploiements en une étape
Posté par Philippe M (site web personnel) . Évalué à 5.
Je suis souvent confronter à ce problème sur Windows. Après avoir passé l'étape du paquet qu'il faut refaire car il est pas prévue pour s'installer en mode silencieux, il faut gérer la mise en place de la configuration.
Entre ceux qui stockent tout dans un ini dans le répertoire d'installation, ceux qui stockent dans ini dans le répertoire du profil utilisateur, ceux qui stockent la configuration dans un fichier illisible avec un éditeur de texte, ceux qui stockent dans la base de registre dans une branche tout utilisateurs et ceux encore qui stockent la configuration dans la base de registre dans la branche de l'utilisateur, ceux qui stockent un peu de partout dans la base de registre et dans des fichiers… Si en plus vous rajouter la couche contrôleur de domaine avec profil itinérant vous devrez gérer pour le cas d'ini le répertoire "Local Settings" et "Application Data"… Vous avez de quoi regretter les terminaux passifs.
Born to Kill EndUser !
# GLPI compliante ou pas
Posté par J Avd . Évalué à 1.
D'abord bravo ça doit pas être simple.
Ensuite je vais être clair si ce produit n'est pas compatible directement avec GLPI je ne vais même pas le tester malgré tout le respect que je peux avoir pour ton travail.
La page blanche c'est bien mais l'autarcie non merci.
"Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
[^] # Re: GLPI compliante ou pas
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 3.
Merci pour votre commentaire et vous êtes donc embauché pour le plugin GLPI ;-) Plus sérieusement, j'y ai réfléchi et échangé rapidement sur ce point avec Nelly de GLPI aux solutions linux. Je pourrais m'appuyer sur le plugin webservice de GLPI pour pouvoir gérer la création et mise à jour des machines directement depuis l'outil.
Maintenant, ce n'est pas un besoin que nous avions aujourd'hui car le couple OCS / GLPI que j'utilise me satisfait dans ses fonctions de gestion de parc. Pour quelqu'un qui ne souhaiterait pas installer de serveur OCS, il est aussi possible d'utiliser uniquement l'agent fusion et son plugin GLPI associé. C'est aussi pour ça que je parle dans le premier commentaire d'une solution différente / complémentaire.
En attendant, il est enfinpossible de faire un export des données puis un import avec le plugin data injection par exemple. En bref pas de problèmes, que des solutions! On se recontacte pour démarrer les devs de ce plugin alors?
[^] # Re: GLPI compliante ou pas
Posté par swap38 (site web personnel) . Évalué à -2.
Malheureusement, l'agent Fusion ne semble plus maintenu et Remi Collet a même décidé d'arrêter la création de paquets pour celui-ci.
Il y a donc un vrai manque à combler pour la remontée d'inventaire automatique dans GLPI sans serveur OCS.
Est-ce que UpdatEngine ne pourrait pas se positionner sur ce créneau là ?
[^] # Re: GLPI compliante ou pas
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
Tu as des sources, parce que ça ne transparaît pas sur la page de fusion, ni sur les différentes forges ou dépôts git ?
[^] # Re: GLPI compliante ou pas
Posté par David DURIEUX . Évalué à 1.
J'adore comme les gens enterrent les logiciels rapidement :p
# Paramètres du serveur
Posté par flan (site web personnel) . Évalué à 2. Dernière modification le 09 juin 2013 à 21:09.
J'ai une petite remarque :
Comme tout projet Django, tous les paramètres sont dans settings.py.
Je trouve ça particulièrement moche, ne serait-ce que l'utilisateur modifie le code d'origine, et si toi tu modifies les paramètres, la mise à jour est délicate.
Une solution est de faire en sorte de mettre des paramètres par défaut dans settings.py, et que ce même module Python aille lire un fichier de configuration pour écraser certains paramètres. Il y a sûrement d'autres solutions, c'est en tout cas celle que j'ai choisie.
Une autre solution plus souple, mais plus laide à mes yeux, c'est de mettre à côté de settings.py un fichier other_settings.py et un fichier default_settings.py.
Dans settings.py, tu peux faire
[^] # Re: Paramètres du serveur
Posté par MeAndMyKeyboard (site web personnel) . Évalué à 1.
En fait, le fichier du code source est setting.py.model. A l'installation, l'administrateur copie ce fichier en settings.py ce qui permet de conserver les mises à jour par git sans avoir à gérer de conflit. Si vous avez utilisé la machine virtuelle, ce détail n'est pas visible c'est vrai.
Je garde cependant la remarque ( et vos solutions) en tête et regarderai si il y a des bonnes pratiques sur ce point. Merci ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.