[Module Config] Cohérence des valeurs ?

Version imprimable

04/03/2011, 16h56
Deneteth

[Module Config] Cohérence des valeurs ?

Bonjour à tous,

Dans un script j'utilise le module Config de perl pour déterminer la version de l'OS sur laquel le script est en train de tourner et décider d'un certain nombre d'actions en conséquence. Pour cela je récupère la valeur de la clef 'osvers' du hash %Config.

Mon problème est le suivant: sans raison apparente des incohérence apparaissent dans les valeurs remontées dans cette variable. Par incohérence j'entend des valeurs identiques pour deux OS différent, et (presque pire) deux valeurs différentes pour un même OS.

Exemples en utilisant la commande perl -e "use Config;print $Config{osvers};":

Sur mon pc (XP Pro SP3 32bits, ActivePerl 5.8.9.827) => 5.00 comme valeur remontée
Sur celui d'un collègue (XP Pro SP3 32bits, ActivePerl 5.10.1.1008) => 5.2
Sur un troisième (Win 7 64bit, ActivePerl 5.8.9.829) => 5.2
Sur un Windows Server 2008 R2 => 5.2 (aussi)
Sur un Windows 2003 SP2 => 5.00

Jusqu'à présent je pensait la valeur de osvers unique pour un OS donné (contrairement à $^O qui renvoi à une typologie d'OS). La différence constatée sur XP m'inquiète, le comportement du script devant être homogène pour une version d'OS donnée (je pourrais... difficilement mais bon.. traiter l'identité entre valeurs pour des OS différents).

Avez vous déjà rencontré ce problème ? Est-ce une erreur d'utilisation de ma part sur cette variable ? Sinon, comment faites vous pour déterminer la version d'OS sur laquelle vous vous exécutez ?

Merci d'avance.
04/03/2011, 17h10
djibril

Il faudrait nous donner les listes des informations que tu souhaites récupérer et en fonction de cela, nous t'orienterons peut être vers un module plus adéquat.
04/03/2011, 17h22
Deneteth

En fait la version d'OS est la seule information qui m'intéresse dans Config car je fais une correspondance OS/liste d'actions à réaliser (grosso modo).

Présentement seuls Windows 2008 R2 et Linux RHEL 5.4 nécessitent une identification non équivoque car les actions que le script doit réaliser présentent des différences par rapport aux autres (dues à un changement de normes).

Seulement je prend en considération que le prédécesseur de ce (nouveau) script à vécu plus de 10 ans, et que je ne sais pas vraiment ce que l'avenir réserve donc je cherche à être le plus ouvert possible. Je pensait que osvers me permettrait d'avoir ce type de flexibilité....

Bon après quelques recherche (assez breves en fait, je ne sais pas comment j'ai pu passer à coté) il apparait que le contenu de %Config est herité de l'OS sur lequel Perl est compilé. Utilisant une distrib pré-compilée, cela explique les 'incohérences' constatées, qui du coup n'en sont pas.

Pour ce qui est de la récupération de la version d'OS je pense que je vais avoir à passer par un test de type pour récupérer l'info de man ière appropriée.

Quelque chose comme (pseudo code)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 use MWin32; ... sub GetOSVer() { if ($^O eq 'MSWin32') { return MSWin32::GetOSName(); # probable traitement sur la chaine ici avant le return selon ce qui est effectivement renvoyé par GetOSName } elsif ($^O eq 'linux') { return ... ; # equivalent GetOSName sous linux ? } else { return 'unknown'; } }
Qu'en pensez vous ? Savez vous si il existe un equivalent à GetOSName sous linux ?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
#!/usr/bin/perl
use strict;
use warnings;
use Sys::Info;
 
if ( $^O eq 'MSWin32' ) {
  require Win32;
  print 'OSName : ',           Win32::GetOSName(),        "\n";
  print 'GetOSDisplayName : ', Win32::GetOSDisplayName(), "\n";
  print 'GetOSVersion : ',     Win32::GetOSVersion(),     "\n";
}
elsif ( $^O eq 'linux' or $^O eq 'darwin' ) {
  print 'uname -a : ', `uname -a`;
}
else {
  print 'unknown';
}
 
##
print "\n\n=================================\n\n";
 
my $info = Sys::Info->new;
printf "Perl version is %s\n", $info->perl;
if ( my $httpd = $info->httpd ) {
  print "HTTP Server is $httpd\n";
}
my $cpu = $info->device('CPU');
my $os  = $info->os;
printf "Operating System is %s\n", $os->name( long => 1 );
printf "CPU: %s\n", scalar $cpu->identify;

Voilà !!

07/03/2011, 10h25
Deneteth

Merci pour ce retour.

Malheureusement après une première série de tests via perl -e "use Win32;print Win32::GetOSName();", il y a toujours des incohérences remontées sous Windows server 2008.

Sur quatre serveurs 2008 testés j'ai eu les résultats suivant:
Win7Service Pack 1
Win7 (pour deux serveurs)
WinXP/.Net :(

Cela semblerait lié à l'OS ou à son shell pour une raison qui m'échappe (ca en fait des choses qui m'échappent...). Un collègue me dis qu'il rencontre le même problème d'identification 'Windows 7'' sur nos serveurs 2008 avec un de nos outils Computer Associate et que nous ne sommes pas les seuls (une entrée KB chez CA existant sur le sujet).

Reste les clefs de registre... en espérant qu'il y en ait une qui existe sur tous les type de serveurs M$ et qui contienne une valeur cohérente.

Sinon pour le linux, c'est nikel ! (ouf)
07/03/2011, 12h15
djibril

Mais as-tu testé mon programme en entier ? Car il y a une autre variante utilisant le module Sys::Info !
07/03/2011, 12h52
Mr6

Si le but est juste de récupérer la version de l'OS, une méthode peut-etre un poil plus bourrine mais peut-etre également plus fiable (et encore, je ne sais pas comment est renseigné le champ) serait de récupérer le contenu de l'OID SNMP qui va bien... (si rien d'autre ne satisfait au résultat)

@+
Mr6
07/03/2011, 12h52
Deneteth

Plus ou moins :)

Après plus de verif la partie sys::info remonte bien l'information (spécifiquement $os->name()). Dans l'absolu c'est donc ok.

Par contre je suis dans un environnement difficile pour manipuler du perl hors distribution (même si c'est possible): pas d'accès en téléchargement au CPAN ni au repository PPM Activestate à cause de nos règle de sécurité. J'ai partiellement récupéré sys::info à la main (ce qui me permet de dire que c'est bon) mais beaucoup d'erreurs sont générées car sous Windows une partie du module doit être compilée (les drivers) ce que je ne peux pas faire faute de compilateur. Je tenterai une recup complète de chez moi (moins contraignant).

Je vais donc passer par le registre pour l'instant sous windows car j'ai déjà les outils pour les manipuler. En l'occurence après quelques recherches la clef HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion contiens la valeur remontée dans $info->name() et conviendra pour le test.

Dans tous les cas un grand merci Djibril !
07/03/2011, 13h03
djibril

Sinon pourquoi ne pas créer un exécutable de ton programme perl via le module PAR. Ainsi, sur tes autres postes, tu n'aurais plus besoin d'avoir perl d'installé, ou des modules CPAN ?
07/03/2011, 13h04
djibril

Citation:

Envoyé par Mr6

Si le but est juste de récupérer la version de l'OS, une méthode peut-etre un poil plus bourrine mais peut-etre également plus fiable (et encore, je ne sais pas comment est renseigné le champ) serait de récupérer le contenu de l'OID SNMP qui va bien... (si rien d'autre ne satisfait au résultat)

@+
Mr6

Encore faut il que snmp soit activé :aie:
07/03/2011, 13h53
Deneteth

Citation:

Sinon pourquoi ne pas créer un exécutable de ton programme perl via le module PAR. Ainsi, sur tes autres postes, tu n'aurais plus besoin d'avoir perl d'installé, ou des modules CPAN ?

Pour deux raisons:
- je n'ai jamais été foutu de générer un exe à partir de perl (en tout cas sous Windows et avec ce qui viens nativement avec le language).
- le script devant tourner tant sur des Windows que des linux (ainsi que qq HP mais c'est anecdotique), il faudrait que je maintienne autant de binaires que d'OS avec ses évolutions, alors que la version 'pur script' me rend indépendant de l'OS en termes d'exécution puisque recompilé à chaque fois.

Bon d'un autre coté je ne connais pas le module PAR donc ces deux raisons sont le reflet de mes aprioris pour l'instant. Il faudrait que je regarde cela plus en détail avant d'avoir une réponse définitive, ce que je ferai dès que j'aurai une ou deux heures de dispo :D
07/03/2011, 14h03
djibril

Ok, tes arguments me conviennent !
07/03/2011, 20h41
Mr6

Citation:

Envoyé par djibril

Encore faut il que snmp soit activé :aie:

Ho bah hein, si en plus faut ke la soluce soit parfaite... :pastaper:
(tiens, si tu veux une idée de concours t'en tiens une la : le moyen le plus détourné pour arriver à faire une opération toute simple afin d'illustrer le TIMTOWTDI :sm: :mouarf3:)