UpdatEngine-server (Nouvelle version)

[Noël Martinon]

Bonjour à tous,

Je viens de déposer une nouvelle version d'UpdatEngine-server ici : https://github.com/noelmartinon/updatengine-server

Bien que pour l'instant en version RC1, je l'utilise en production pour 120 machines avec le client 2.4.9.4 de Damien et pas de soucis.

J'ai fait de nombreux tests mais dites-moi si vous rencontrez des problèmes ou bugs.

Pour la compatibilité avec Ubuntu 18 je n'ai pas testé mais on est maintenant sur du Django 1.11 (dernière LTS).

Bon déploiements,

Noël

[Damien Guillem]

Bonjour,

C'est vraiment super de voir d'autres personnes qui ont envie de faire évoluer UpdatEngine !

Je suis très content que le client que j'ai proposé te soit utile.

Je ne manquerai pas de tester cette nouvelle version d'ici la prochaine semaine et d'y participer si possible.

A très bientôt.

Damien

[sebastien]

Bonjour, merci pour le travail.

Pour la ubuntu 18 à priori il y a des erreurs de python, sur quelle version est ce fonctionnel ? 

Sinon pour le client ça marche également avec les anciennes versions ?

Merci

[Noël Martinon]

Bonjour Sébastien,

UE serveur et client sont écrits en Python2.7 mais Ubuntu 18.04 est livré avec Python3.

Je pense qu'il te suffit juste d'installer ton environnement virtuel en Python2.7 donc :

- sudo apt-get install python2.7

- sudo virtualenv --distribute --no-site-packages -p `which python2.7` /var/www/UE-environment

Ensuite le reste de la procédure doit se dérouler correctement.

Pour les UE-client, ça doit fonctionner avec toutes les versions. Je viens de tester, c'est sûr avec la 2.4.9.3 et aussi avec la version 2.4.9 (je crois) qu'on trouve sur https://updatengine.com/.

Attention, éviter d'utiliser cette ancienne version car elle ne contient pas les corrections apportées par Damien (prise en compte des accents ni sûrement TLS>=1 ou comparaison des versions de logiciels).

Pour la suite, une migration en Python3 est envisagée mais je pense qu'il y a pas mal de temps à passer dessus ;)

Bonne journée,

[sebastien]

Bonjour, merci pour ces précisions.

Pour le client en effet il n'y a sans doute pas les corrections mais comme j'utilise encore l'ancienne version il faudra que je bascule sur la nouvelle mais le changement des accents risque de poser des petits problèmes pendant la transition.

Merci pour votre travail.

[Michael Lance]

Super initiative !

4 ans que mon serveur UE ronronne une petite update s'impose !

[allfre...@gmail.com]

Bonjour,

Je valide la migration sur une CentOs 7, toutes les données sont bien récupérées. Bravo pour le petit tuto (au passage j'ai upgradé aussi pip: sudo /var/www/UE-environment/bin/pip install --upgrade pip, peut-être à rajouter dans la doc).

 Je vais lancer des tests plus poussés cette semaine avec le nouveau client pour valider une mise en production fonctionnelle depuis 4 ans (2000 machines).

Un grand bravo Noël pour tout ce travail, j'associe évidemment les autres contributeurs sans oublier Yves bien entendu.

Je désespérais de ne pas voir cette merveilleuse application évoluer, c'est chose faite, un grand merci.

Allan

[Noël Martinon]

Bonjour et merci pour ces retours,

Votre intérêt est très motivant pour en faire plus !

Pour l'installation sur CentOS 7 c'est une bonne nouvelle et effectivement un petit ajout du pip upgrade à ajouter.

Concernant la suite je pense qu'on peut s'orienter sur les fonctionnalités. Déjà je vais relire les posts pour lister les besoins et j'ai qques idées d'améliorations comme pouvoir basculer sur le serveur UE principal en cas de défaillance de telechargement sur un serveur de rebond.
Certaines modifs se feront côté client et d'autres côté serveur mais en tout cas je suis preneur de vos propositions. A voir sous quelle forme synthétiser tout ça : Nouveau sujet ici ou issue sur github ou autre ?

Bref, à suivre !

A bientôt,
Noël

[sebastien]

Bonjour, tant que ce forum marche personnellement j'ai une petite préférence pour ici mais effectivement à voir.

Petite question je prévois une transition prochaine d'updatengine vers la nouvelle version (avec une nouvelle installe) est ce que je peux importer la base sql sans soucis ou la structure à changer ? Je pose cette question car j'ai vu que sur la nouvelle version certaines colonnes ne sont plus tout à fait les même d'après l'historique.

Merci

[sebastien]

En fait j'ai vu qu'il y a une procédure pour l'upgrade de 2.1.1 et django mais du coup il faudrait que j'importe mon ancienne table sur le nouveau serveur et qu'ensuite j'applique la procèdure d'upgrade si j'ai bien compris ?

Merci pour les précisions.

[Noël Martinon]

Bonjour Sébastien,

Coté structure de la base, je n'ai fait qu'ajouter 1 champ et 1 table.

Alors là c'est au choix, tu peux effectivement d'abord importer puis migrer mais vu que c'est un nouveau serveur tu peux faire l'installation "neuve" puis :

1. importer tes données dans la base (les nouvelles tables "django_migrations" et "configuration_globalconfig" sont conservées):
   mysql -u root -p nom_base_updatengine < UE_backup.sql
2. Remettre le nouveau champ "ip_range" dans "inventory_entity" et supprimer l'ancienne table de migrations :
   
   /var/www/UE-environment/bin/python /var/www/UE-environment/updatengine-server/manage.py dbshell
   ALTER TABLE inventory_entity ADD ip_range VARCHAR(200);
   DROP TABLE south_migrationhistory;
   quit
   

[Noël Martinon]

J'oubliai, une fois la base migrée sur le nouveau serveur, il faut aussi copier les packages dans le répertoire "updatengine/media/package-file/".

[sebastien]

Bonjour, parfait merci je test ça dès que possible. 

[Alain Valancogne]

Bonjour,

Merci beaucoup pour cet effort !

Nous essayons de migrer en 2.1.2 RC1, mais rencontrons des erreurs avec les utilisateurs qui n'ont pas le statut "super-utilisateur".

Visiblement le filtrage sur subuser.id_entities_allowed ne fonctionne pas !

Certainement un problème évident pour un expert Python...

Sinon, j'ai corrigé un problème sur la création d'un nouvel utilisateur :

configuration/admin.py : ligne 74, remplacer admin.util.flatten_fieldsets par admin.options.flatten_fieldsets

Je poste ça sur GitHub ASAP.

Alain

[Noël Martinon]

Bonjour,

Merci du retour et de ta participation au debug !

Je n'avais pas tester pour les utilisateurs.

Ok pour la modif ligne 74 que je peux intégrer directement sur github.

Et effectivement même constat sur le filtre "id_entities_allowed",

Je vais regarder au plus vite.

Noël

[Noël Martinon]

Bonjour,

Je viens de mettre à jour github.

C'est ok pour les utilisateurs non 'superuser' chez moi après un 'git pull'.

Alain ton retour ?

Merci

[aldr...@gmail.com]

Bonjour,

Je réponds à la place d'Alain, c'est tout bon.

Les utilisateurs autre que 'superuser' peuvent maintenant avoir accès à l'inventaire des machines/entités/logiciels ainsi que tous la partie déploiement.

Un grand merci.

Allan

[Alain Valancogne]

Cool !

Merci beaucoup !!!

Tout semble désormais OK.

[sebastien]

Bonjour, je suis en train d'installer la nouvelle version et j'aurais des petites questions, tout d'abord est ce que la correction mentionnée ci dessous est intégré à la version récupéré via le git clone ?

Ensuite juste pour confirmation la partie upgrade from 2.1.1/django 1.6.2 n'est qu'a faire en cas d'upgrade ou même sur une version fraîchement installé ?

Merci

[Noël Martinon]

Bonjour,

Oui le git clone récupère bien toutes les corrections et c'est pour une nouvelle installation.

Pour la partie upgrade 2.1.1 ce n'est à faire qu'une seule fois en effet. Ensuite seulement git pull.

[sebastien]

Bonjour, ok merci pour l'information par contre je ne comprends pas bien, pour la partie upgrade 2.1.1 à faire une fois c'est à dire qu'il faut tout de même le faire lors d'une nouvelle installation ? (pas d'ancien serveur updatengine)

Merci

[Noël Martinon]

Bonjour,

L'upgrade est à faire 1 fois uniquement par ceux qui avaient déjà un serveur UE installé en version 2.1.1 (celle de 2014) et qui migrent vers la nouvelle version.

Pour une installation nouvelle il ne faut faire que la partie "install".

[sebastien]

Bonjour, merci ca confirme donc ce que je pensais, dernier point j'ai une erreur sql lors de l'import des dates :(  mysql_tzinfo_to_sql)

Warning: Unable to load '/usr/share/zoneinfo/iso3166.tab' as time zone. Skipping it.

Warning: Unable to load '/usr/share/zoneinfo/leap-seconds.list' as time zone. Skipping it.

Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it.

Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skipping it.

Je ne pense pas que ce soit très important, on l'ignore simplement ?

Merci

[sebastien]

Autre chose j'ai remarqué le nouveau allowed host 

# List of host/domain names that this Django site can serve

# Add your ip and/or domain else you will have a "Bad Request (400)" error

Pour fonctionner j'ai du mettre l'ip de mon serveur, mais j'avais personnellement compris cela comme l'ip du navigateur qui tente d’accéder au serveur mais ca ne fonctionne pas sans mettre l'ip du serveur c'est normal ?

Sinon on peut toujours activer le ssl sans souci ?

Merci pour l'aide.

[Noël Martinon]

Bonjour,

Les warnings de mysql ne sont pas importants, il s'agit de fichiers utilisés par la commande 'tzselect' de Linux et non de fichiers de timezone d'où les messages d'avertissements.

Pour 'ALLOWED_HOSTS' :

• c'est une sécurité lors d'une utilisation de serveur en http
  
• c'est une liste d'IP/FQDN auxquels ton serveur est autorisé à répondre et pas seulement ton accès à l'interface web. Ainsi il faut :
  
• 'localhost', '127.0.0.1', '[::1]' pour des requêtes http locales (ex 'usage du script 'clear_history')
  
• 'ip_serveur' si cette IP est utilisée pour l'accès à l'interface ou par updatengine-client
• le nom complet FQDN (ex 'ue.domain.tld') pour la même raison que ci-dessus
• En utilisation uniquement intranet donc à priori sur un réseau de confiance, on peut mettre ['*'] pour autoriser django à répondre quel que soit l'entête host reçu.

Et pas de problème pour mettre en ssl.

Autrement, pour info, je travaille actuellement sur une amélioration des conditions de déploiement pour notamment autoriser plusieurs * dans les noms. Je teste actuellement et je mettrai un message sur le forum pour vous tenir au courant.

[sebastien]

Bonjour, merci pour ces explications.

Sinon c'est un détail mais j'ai remarqué que sur la nouvelle interface certaines choses sont passés en anglais, par exemple modification massive on avait mettre à jour maintenant j'ai update, c'est voulu ?

Merci

Cordialement

BRUN Sébastien

[Noël Martinon]

Bonjour,

Effectivement c'est un oubli. Je n'y avais pas prêté attention. C'est depuis la migration en django 1.11.

Je corrigerai.

Merci

Noël

[sebastien]

Ok merci, par ailleurs je viens de remarqué que les colonnes dans inventaire machine ne sont pas les même (domaine remplacé par système d'exploitation par ex, est ce qu'on peut choisir quelle colonne affichée ?

Merci

Cordialement

BRUN Sébastien

[Noël Martinon]

Bonjour,

Oui on peut mais ce sera écrasé lors de la prochaine mise à jour d'UpdatEngine-server et il faudra alors refaire les modfis manuellement.

Par rapport à l'ancienne version 2.1.1 j'ai retiré 'Domaine' et 'Commentaires' et ajouté 'Syst. exploitation'.

C'est sûr que c'était un choix arbitraire mais je peux remettre ces colonnes ou juste 'Domaine'. Pour ma part je n'utilise pas le champs 'Commentaires' mais ça manque peut-être à d'autres ?

Bon j'attends un peu les réactions pour savoir quel est le besoin de la majorité et voir ce qu'on affiche.

Si urgence tu peux modifier la ligne 134 du fichier updatengine-server/inventory/admin.py :

     list_display = ('lastsave','entity','name','domain','username','operatingsystem','vendor','product','typemachine','packageprofile','timeprofile','comment')

ce qui rétablira les 2 colonnes précitées.

J'insiste sur le fait qu'alors tu auras des problèmes d'update avec 'git pull' et qu'il faudra passer par des 'git fetch --all' et 'git reset --hard origin/master' puis refaire tes modifs locales. Au passage, la branche 'master' est maintenant devenu la dernière stable.

Noël

[sebastien]

Bonjour, merci pour ces éclaircissement, effectivement commentaires je n'ai jamais utilisé domaine il m'est arrivé parfois de l'utiliser par contre même si c'est plutôt rare.

Pour la branche master qui est devenu stable c'est à dire il y a eu des changements ou juste passage en stable (par rapport a la 2.1.2 que j'ai installé il y a quelques semaines ?)

Sinon j'avais posté une question sur le post client mais je ne sais pas si le problème vient du client ou du serveur mais j'ai toujours le problème de forcer la remontée d'inventaire à partir de la console (complètement aléatoire toujours)

Merci encore pour le travail sur ce logiciel qui est tout de même pratique et qu'on est je suis sur nombreux à utiliser et que je suis heureux d'avoir pu installer sur une distrib récente.

[Noël Martinon]

Bonjour,

Je pense qu'un administrateur réseau utilise 1 seul domaine donc normalement pas besoin d'afficher cette colonne. Avoir l'info affichée pour chaque machine me polluait plutôt l'affichage.

Autrement tu peux faire la manip d'update car tu devrais être en 2.2.0 là où au moins en 2.2-RC1.

Les modifications sont visibles sur github dans commits et c'est dans cette branche master où dorénavant je validerai ce qui est 'sans risque' (correctifs mineurs et nouvelles fonctionnalités testées depuis pas mal de temps).

Pour le client, je te réponds dans sa partie.

[Jp S]

Bonjour,

Personnellement j'utilise le champs commentaire mais le champs domaine pas besoin. J'ai remarqué que certaines machines de bureau qui ont des petits disques durs était prises pour des portables !!

Au niveau du client, il y a deux tâches planifiées, est-ce bien nécessaire ? Surtout que la première est mise en erreur par la deuxième toutes les dix minutes.

Merci pour le suivi de cette application.

[sebastien]

Bonjour, je me demandais, pourquoi avoir ajouter un champs envoyer sur la nouvelle version ? Pour plus de sécurité sur les actions ?

Merci

Cordialement

[Noël Martinon]

Bonjour,

Lors de la migration en django 1.11 j'ai dû aussi mettre à jour django-adminactions (https://github.com/saxix/django-adminactions) et c'est cette partie du code qui intègre le bouton 'envoyer'.

Par habitude, j'avoue qu'il m'arrive parfois d'oublier de cliquer dessus et d'attendre que l'action se fasse !