vendredi 25 novembre 2011

WAS - PMI & Métriques

Ci dessous la liste des métriques WebSphere disponibles dans la configuration de base:

Catégorie nom description
EJB MethodReadyCount Nombre d’instances de bean à l’état prêt
PassiveCount Nombre de fois où des beans ont été passivés
MessageCount Nombre de messages fournis à la méthode de bean onMessage (s’applique aux beans gérés par messages)
PooledCount Nombre moyen d’objets dans le pool
MethodResponseTime Temps de réponse moyen (en millisecondes) des appels aux méthodes distantes du bean
MethodCallCount Nombre d’appels aux méthodes distantes du bean
ReadyCount Nombre d’instances de bean à l’état prêt
RemoveCount Nombre de fois où des beans ont été supprimés
CreateCount Nombre de fois où des beans ont été créés
Pool JDBC WaitTime Temps moyen d’attente d’octroi d’une connexion, en millisecondes
UseTime Durée moyenne d’utilisation d’une connexion en millisecondes. Différence entre l’heure à laquelle la connexion est allouée et celle où elle est libérée. Cette valeur inclut la durée de l’opération JBDC
PercentUsed Pourcentage moyen du pool en cours d’utilisation. La valeur repose sur le nombre total de connexions configurées dans le pool de connexions, pas sur le nombre actuel de connexions
WaitingThreadCount Nombre moyen d’unités d’exécution qui attendent simultanément une connexion
FreePoolSize Nombre de connexions libres dans le pool
PoolSize Taille du pool de connexions
CloseCount Nombre total de connexions fermées
CreateCount Nombre total de connexions créées
JVM ProcessCpuUsage Utilisation de l’unité centrale (CPU) (en pour cent) de la machine virtuelle Java
UpTime Durée, en secondes, de l’exécution de la machine virtuelle Java (JVM)
UsedMemory Mémoire utilisée (ko) dans l’environnement d’exécution de la JVM
HeapSize Mémoire totale (ko) dans l’environnement d’exécution de la JVM
JCA WaitTime Temps moyen d’attente d’octroi d’une connexion, en millisecondes
UseTime Durée moyenne, en millisecondes, d’utilisation des connexions (depuis leur affectation jusqu’à leur libération)
WaitingThreadCount Nombre moyen d’unités d’exécution qui attendent simultanément une connexion
FreePoolSize Nombre de connexions gérées disponibles actuellement dans le pool
PoolSize Nombre moyen de connexions gérées dans le pool
CloseCount Nombre total de connexions gérées supprimées
CreateCount Nombre total de connexions gérées créées
Gestionnaire de sessions web LiveCount Nombre total de sessions actuellement actives
système CPUUsageSinceLastMeasurement Utilisation CPU moyenne depuis la dernière demande
Pool de Thread du WebContainer PoolSize Nombre moyen d’unités d’exécution dans le pool
Gestionnaire de transactions RolledbackCount Nombre de transactions globales annulées
CommittedCount Nombre de transactions globales validées
ActiveCount Nombre de transactions globales actuellement actives
WEB URIRequestCount Nombre total de requête (associée à une URI) traitée par une servlet
ServiceTime Temps moyen en milliseconde pour qu’une requête soit traitée
RequestCount Nombre total de requête qu’une servlet a traitée
URIServiceTime Temps de réponse moyen pour qu’une URI soit associée à une servlet

vendredi 18 novembre 2011

JYTHON - Manipuler les ressources JDBC

Ce petit tuto vous explique comment manipuler les objets WebSphere via Jython.
L'objectif étant de récupérer de manière automatique des valeurs relatives à la configuration JDBC d'une application.

1 - Dans un premier temps, il faut se connecter en wsadmin sur le serveur d'application de votre choix.

Pour la connexion, consulter ce lien
http://admin2base.blogspot.com/2011/11/was-connexion-wsadmin-pour-jython.html

/appli/test >wsadmin.sh

WASX7209I: Connected to process "server1" on node siphnosNode using SOAP connector;  The type of process is: UnManagedProcess
WASX7031I: For help, enter: "print Help.help()"


2 - Récupérer les identifiant de ressources de la JVM

La ressource JDBC est liée à la JVM et non à l'application. Ce n'est que dans un deuxième temps (une fois l'application déployée) que l'on mappe cette ressource à l'application.
Il faut donc chercher l'identifiant de ressource qui se ramène au serveur d'application.

wsadmin>$AdminConfig getid /JDBCProvider:/

"Derby JDBC Provider (XA)(cells/
CellName/Application 1.ear/deployments/application1|resources.xml#builtin_jdbcprovider)"
"Derby JDBC Provider (XA)(cells/
CellName/applications/Application2.ear/deployments/Application2|resources.xml#builtin_jdbcprovider)"
"Derby JDBC Provider (XA)(cells/
CellName/applications/Application3.ear/deployments/Application3|resources.xml#builtin_jdbcprovider)"
"Derby JDBC Provider (XA)(cells/
CellName/applications/Application4.ear/deployments/Application4.xml#builtin_jdbcprovider)"
"Derby JDBC Provider(cells/CellName/nodes/NodeName/servers/server1|resources.xml#JDBCProvider_1265195948776)"
"Oracle JDBC Driver(cells/
CellName/nodes/NodeName/servers/server1|resources.xml#JDBCProvider_1275658163588)"

En l'occurence, nous recherchons des informations sur notre driver JDBC Oracle (non XA)
"Oracle JDBC Driver(cells/CellName/nodes/NodeName/servers/server1|resources.xml#JDBCProvider_1275658163588)"

3 - Maintenant que nous avons l'identifiant de ressources, nous allons pouvoir l'interroger pour obtenir les informations que nous cherchons:

wsadmin>$AdminConfig show {propertySet (cells/CellName/nodes/NodeName/servers/server1|resources.xml#JDBCProvider_1275658163588)}
{classpath ${ORACLE_JDBC_DRIVER_PATH}/ojdbc14.jar}
{description "Oracle JDBC Driver"}
{implementationClassName oracle.jdbc.pool.OracleConnectionPoolDataSource}
{name "Oracle JDBC Driver"}
{nativepath {}}
{providerType "Oracle JDBC Driver"}
{xa false}



On retrouve bien les informations relative au driver.




La prochaine étape, nous effectuerons une extraction des données relatives aux datasources ...
To be continued

vendredi 4 novembre 2011

Conversion PEM - DER

PEM to DER

openssl x509 -in cert.crt -outform der -out cert.der

DER to PEM

openssl x509 -in cert.crt -inform der -outform pem -out cert.pem

CRYPTO - .PEM vs .DER et extensions

Encodage des certificats

Il existe deux types d'encodage pour les certificats:

  • Fichier au format .DER
    L'extension DER est utilisée pour les certificats encodé au format DER. Ces fichiers peuvent avoir indifféremment l'extension .crt ou .cer. A proprement parlé, on dit plutôt "J'ai un certificat encodé DER" plutôt que "J'ai un certificat DER".

  • Fichier au format .PEM 
    L'extension PEM est utilisé pour les fichiers de type X509 v3 et qui contiennent des données ASCII encodées en base64 et généralement préfixé des balises "-- BEGIN CERTIFICATE --"

Les Extensions communes

  • .CRT
     L'extension CRT est utilisée pour désigner un certificat. Ce certificat doit être encodé au format DER ou en PEM. Cette extension est propre au certificats Microsoft.
  • .CER 
    Alternative au format CRT, le fichier CER est légèrement différent du CRT mais reste compatible sur les environnements Windows car le système embarque une APICrypto qui permet la conversion.
          Cette extension est plus largement utilisée sur les environnements Unix.
  • .KEY 
     Cette extension est utilisées pour les clés publiques & privées au format PKCS#8. Le format d'encodage peut être PEM ou DER

CRYPTO - Format fichier PEM

Il arrive souvent que l'on cherche des informations sur les certificats et notamment sur l'extension à utiliser (.crt, .cer) et sur l'encodage.

La définition ci dessous résume tout,  simplement.

PEM - Privacy Enhanced Mail

Peut contenir des clés privées, des clés publiques et des certificats X509.
Le format PEM est du DER encodé en base64 auquel sont ajoutées des en-têtes en ASCII.
Extensions usuelles : .pem, .cer, .crt, .cert

Java - Obtenir un Dump

Le dump peut être utilisé par hpjtune pour une analyse.

-XX:+HeapDump    SIGQUIT    ASCII;
et
set the _JAVA_BINARY_HEAPDUMP environment variable to get binary    java_<pid>_<date>_<time>_heapDump.hprof.txt

-XX:+HeapDumpOnCtrlBreak     SIGQUIT    Binary    java_<pid>.hprof.<millitime>

-XX:+HeapDumpOnOutOfMemoryError    Out of Memory    Binary    java_<pid>.hprof or the file specified by -XX:HeapDumpPath=file

-XX:+HeapDumpOnly    SIGVTALRM    ASCII; set the _JAVA_BINARY_HEAPDUMP environment variable to get binary    java_<pid>_<date>_<time>_heapDump.hprof.txt

 Ou Kill -3

jeudi 3 novembre 2011

J2EE - Process Livraison


TSM - Client Web

Process

Lancer le daemon dsmcad sur le serveur

Interface Graphique

Lancer un browser et se rendre sur l'URL

http://hostname:1581/

Le nom du user correspond au nom du serveur + passwd

Sécurité : Mécanismes d'authentification

Mécanismes d'authentification

Un inconvénient majeur de l'utilisation des mécanismes de chiffrement asymétriques est le fait que la clé publique est distribuée à toutes les personnes : Bob, Carole, ... souhaitant échanger des données de façon confidentielle. De ce fait, lorsque la personne possédant la clé privée, Alice, déchiffre les données chiffrées, elle n'a aucun moyen de vérifier avec certitude la provenance de ces données (Bob, ou Carole ...) : on parle de problèmes d'authentification. Afin de résoudre ce problème, on utilise des mécanismes d'authentification  permettant de garantir la provenance des informations chiffrées. Ces mécanismes sont eux aussi fondés sur le chiffrement asymétrique.

Principe d'authentification par chiffrement asymétrique :
Objectif : Bob souhaite envoyer des données chiffrées à Alice en lui garantissant qu'il en est l'expéditeur.

Bob crée une paire de clés asymétriques : il conserve la clé privée et envoie la clé publique à Alice
Alice crée une paire de clés asymétriques : clé privée (qu'elle conserve), clé publique (qu'elle diffuse librement, notamment à Bob)
Bob effectue un condensat de son message "en clair" puis chiffre ce condensat avec sa propre clé privée
Bob chiffre son message avec la clé publique d'Alice.
Bob envoie le message chiffré accompagné du condensat chiffré.
Alice reçoit le message chiffré de Bob, accompagné du condensat.
Alice déchiffre le message avec sa propre clé privée. À ce stade le message est lisible mais elle ne peut pas être sûre que Bob en est l'expéditeur.
Alice déchiffre le condensat avec la clé publique de Bob.
Alice utilise la même fonction de hachage sur le texte en clair et compare avec le condensat déchiffré de Bob. Si les deux condensats correspondent, alors Alice peut avoir la certitude que Bob est l'expéditeur. Dans le cas contraire, on peut présager qu'une personne malveillante a tenté d'envoyer un message à Alice en se faisant passer pour Bob !

Cette méthode d'authentification utilise la spécificité des paires de clés asymétriques : si l'on chiffre un message en utilisant la clé publique, alors on peut déchiffrer le message en utilisant la clé privée ; l'inverse est aussi possible : si l'on chiffre en utilisant la clé privée alors on peut déchiffrer en utilisant la clé publique.
 
Ainsi donc si le condensat reçu par Alice a été chiffré par une clé privée, pour le déchiffrer, elle utilise la clé publique de l'expéditeur présumé. L'utilisation de la clé publique de Bob fait apparaitre le condensat envoyé par Bob.
 
Si au contraire, ce n'est pas Bob qui a envoyé le message, lorsque la personne malveillante a chiffré le condensat, elle a utilisé sa propre clé privée : pas celle de Bob ! Ainsi donc le déchiffrage avec la clé publique de Bob mènera à un texte erroné et lorsque Alice le comparera à son propre condensat, elle verra qu'ils ne correspondent pas : elle en déduira que Bob n'est pas l'expéditeur mais une autre personne !

Tomcat & Magasin Certificat

Pour des besoins de WebServices distant, nous avons besoin parfois de stocker dans la configuration Tomcat propre à une application des certificats qui permettront à cette même application d'interroger un WebService Sécurisé. Pour que cette interrogation soit possible, le certificat du site distant est nécessaire.

Au niveau de Tomcat, nous avons mis en place cela:

Déclaré dans le fichier d'environnement (sourcé au lancement de l'application)

[root@b5195 env]# cat setvar_app.ksh
export JAVA_MIN_HEAP_SIZE=256M
export JAVA_MAX_HEAP_SIZE=256M
export JAVA_PERM_SIZE=128M
export JAVA_MAX_PERM_SIZE=128M
export JAVA_OPTS="    -Xms${JAVA_MIN_HEAP_SIZE}
            -Xmx${JAVA_MAX_HEAP_SIZE}
            -Xloggc:/product/tomcat/logs/app/garbage_app.log
            -Djavax.net.ssl.trustStore=/product/tomcat/env/CASSLROOT.jks
            -Djavax.net.ssl.trustStorePassword=casslroot"

Les deux dernières lignes sont utilisées pour charger au niveau de la jvm le magasin de certificats ainsi que la clé correspondant au mot de passe du même magasin.

Oracle : Identifier requêtes exécutées sur schéma + plan

La première requête permet de connaitre les requêtes exécutées sur un schéma.

set line 300
set pages 80

select to_char(LAST_ACTIVE_TIME,'YYYY-MM-DD HH24:MI'),SQL_TEXT, SQL_ID from v$sql where PARSING_SCHEMA_NAME='BMP12RC6' ORDER BY 1;


La deuxième requête permet de voir le plan d'exécution de la requête, de détecter les éventuelles contentions

select OPERATION,COST,BYTES, CPU_COST, IO_COST from v$sql_plan where SQL_ID='7j76nm42vsc81';