Nerdzcore's technical blog
 
Login:


Password:


  
 

Alors content que ce soit d'retour ?
Oui
Non
Rien à secouer
Trop vieux pour ces conneries.
Plus le temps pour ces con...
Retourne bosser Psyko -_-
    Résultats
 Overall :

1
Psyko
18/11/14 à 02:07
0
Jboss-as 7 + VisualVM en remote
Ci-dessous la procédure pour accéder au monitoring d'un server JBoss 7 en standalone depuis un poste du réseau local via Visual VM.

C'est surtout utile dans le cas où suivre les documentations sur le net conduisent quand même à des erreurs. (Ce qui m'est arrivé)

Ajouter ceci dans le fichier $PATH_JBOSS/bin/standalone.conf :

JAVA_OPTS="$JAVA_OPTS -Djboss.bind.address.management=IP_SERVER"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=PORT_JMX"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=false"
JAVA_OPTS="$JAVA_OPTS -Djava.rmi.server.hostname=IP_SERVER"
JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
JAVA_OPTS="$JAVA_OPTS -Xbootclasspath/p:$PATH_JBOSS/modules/org/jboss/logmanager/main/jboss-logmanager-1.2.2.GA.jar"
JAVA_OPTS="$JAVA_OPTS -Xbootclasspath/p:$PATH_JBOSS/modules/org/jboss/logmanager/log4j/main/jboss-logmanager-log4j-1.0.0.GA.jar"
JAVA_OPTS="$JAVA_OPTS -Xbootclasspath/p:$PATH_JBOSS/modules/org/apache/log4j/main/log4j-1.2.16.jar"
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=org.jboss.logmanager"

Dans le cas où on veut y accéder depuis le net, il faut utiliser SSL (Voir la doc de jboss) et rajouter l'utilisation du compte RealManagement permettant d'accéder à l'interface d'admin de JBOSS. Mais bon normalement cette dernière étape est déjà faite en général, vu que c'est aussi nécessaire pour accéder à l'interface d'admin de JBOSS sur le LAN.

Avec visualVM => dans remote, ajouter IP du serveur. Puis click droit => ADD JMX Connexion et ajouter le port défini dans la conf à la suite de l'IP et ça roule....


Psyko
09/11/14 à 15:12
0
[Cyber-Entomologie] Quand y'en a plus, y'en a encore !
Petit billet adressé aux développeurs GWT :

Voilà c'est bon, après de longs mois de travail, vous allez enfin faire la release de votre application, tous les voyants sont au vert, Jenkins est heureux, Sonar est heureux, et toute la batterie de tests passe sans encombre.

C'est l'heure du passage en production. (Ou en pré-prod si vous faites bien les choses et que votre pré-prod est STRICTEMENT identique à votre environnement de prod, car sinon ça ne sert à rien, selon la loi d'emmerdement maximal qui dit que si il y a un problème dans ce cas, ce sera INÉVITABLEMENT sur le delta entre prod et pré-prod.)

Donc vous faites le passage en production et l'application s'affiche et fonctionne, c'est merveilleux...

Atata, pousse encore un peu. Ah oui, un 'select' sur la base de données... Cela fonctionne niquel, bien, bien...
Atata, pousse encore un chouilla, voui voilà, faire une écriture sur la base avec un appel GWT-RPC.
EH OUI ! Une exception vous pète à la gueule à ce moment là ! C'est-y-pas meugnooonnnnn... (Si vous n'avez pas d'erreur, vous pouvez arrêter la lecture de ce post.)

Alors que se passe-t-il ? Quel est le seul delta entre une application avec ce bug et une application qui fonctionne normalement ? Réponse : le serveur Apache qui sert de frontal et qui redirige les requêtes destinées à votre appli sur le serveur JEE à l'aide des directives PROXY et REVERSE PROXY.

A noter que pour que ce bug se produise, il faut aussi que le context que vous avez défini dans l'appli (le truc qu'il faut renseigner entre autre dans le web.xml, par exemple => "/appContext/appService") soit différent du nom du war (en général un truc du genre "application-version" si vous utilisez Maven).

Et dans ce cas là, GWT ne "voit" pas son contexte "appContext" mais celui du nom de l'appli (app-version) envoyé par Apache, du coup il ne trouve pas ses fichiers dans l'arborescence du WAR et il vous explose à la tronche. So sweet...


Ci-dessous un exemple de configuration qui provoque l'erreur :

1) Context de l'application : appContext
2) Nom du war généré : appContext-1.0.0
3) Configuration d'Apache :
ServerName application.domaine.ltd
ProxyPass / http://localhost:8080/appContext-1.0.0/
ProxyPassReverse / http://localhost:8080/appContext-1.0.0/
ProxyPreserveHost on

Cela va donner des logs d'erreur dans ce genre :

16:54:52,588 INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/appContext-1.0.0]] (http--0.0.0.0-8080-2) RandomServiceRPCImpl: ERROR: The module path requested, /appContext/, is not in the same web application as this servlet, /appContext-1.0.0. Your module may not be properly configured or your client and server code maybe out of date.

16:54:52,590 INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/appContext-1.0.0]] (http--0.0.0.0-8080-2) RandomServiceRPCImpl: WARNING: Failed to get the SerializationPolicy 'CAF937D808E3EF37D3463BBA55641E5E' for module
'https://application.domaine.ltd/appContext/'; a legacy, 1.3.3 compatible, serialization policy will be used. You may experience SerializationExceptions as a result.

Voilà à partir de là plusieurs solutions sont disponibles ici :
http://stackoverflow.com/questions/1517290/problem-with-gwt-behind-a-reverse-proxy-either-nginx-or-apache

Personnellement, j'ai d'abord essayé de renommer mon WAR comme le nom du context, le premier log à disparu mais le second était toujours présent. Ensuite j'ai choisi d'implémenter la solution de "KC BERG" que je trouve particulièrement élégante. Au niveau du code rien de compliqué, par contre au niveau du header à bidouiller dans apache, c'est un peu subtil je rajoute donc un paragraphe pour bien expliquer ce qui se passe :

A première vue j'avais rajouté une ligne comme ceci pour faire comprendre à GWT de remplacer le context sans version (celui dans le code) par le context avec la version (celui transmis par apache).
RequestHeader edit X-GWT-Module-Base ^(.*)/appContext/(.*)$ $1/appContext-1.0.0-SNAPSHOT/$2

Voui sauf que si on refait un test, on tombe sur un nouveau message d'erreur :
01:44:55,891 INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/appContext-1.0.0]] (http--0.0.0.0-8080-3) RandomServiceRPCImpl: ERROR: The serialization policy file '/CAF937D808E3EF37D3463BBA55641E5E.gwt.rpc' was not found; did you forget to include it in this deployment?

Donc là, on constate ça ne grogne plus à cause des contextes différents mais que c'est le fichier A LA RACINE (important de voir ce petit '/' au début) qui n'est pas trouvé. Et effectivement si vous inspectez votre WAR, vous verrez que ce fichier se trouve dans le répertoire "appContext" du WAR, et donc en conséquence il faut changer le RequestHeader pour rajouter le nom de ce répertoire à la chaine de remplacement comme ceci :
RequestHeader edit X-GWT-Module-Base ^(.*)/appContext/(.*)$ $1/appContext-1.0.0/appContext/$2

Et là ça roule. OUF ! (Alors celui-là autant dire qu'il m'a fait franchement galérer)...


Psyko
22/10/14 à 18:10
0
Tranche de vie d'un développeur JEE
Je commence cette section par un petit message pour évacuer la frustration et montrer par l'exemple que la technique, c'est rarement une sinécure :

***

Aller tiens, je vais lancer JVisualVM pour monitorer mon serveur.

1) Oui bon j'ai pas de serveur graphique sur la machine dédié donc je vais faire ça à distance.
2) Lancement de JVisualVM sur un poste de développement du LAN, je renseigne l'IP du serveur et hop rien ne s'affiche (expected, faut pas rêver quand même...)
3) Tour sur le net histoire de voir ce qui cloche. Ah! Donc faut lancer jstatd sur le serveur. Logique, il faut bien que le serveur communique ses infos par un moyen ou un autre (expected, ça roule...)
4) Lancement de jstatd sur la Debian et vlan une exception me pète direct à la gueule. SU-PER... Come on ffs (début de rage inside)
5) Bonnnnn tour sur le net bis. Alors il faut créer un fichier jstatd.all.policy avec une commande spécifique et lancer jstatd avec l'option suivante -J Djava.security.policy=$PATH_OF_FILE/jstatd.all.policy pour que ça marche.
6) Youpee, JVisualVM voit mon remote victoire \o/
7) Aller se faire foutre, car si il voit bien le remote, il n'affiche absolument AUCUNE donnée.
8) Re-Re tour sur le net. Il faut rajouter une autre obscure option '-J-Djava.rmi.server.hostname=192.168.1.2.' à jstatd sinon il n'affiche rien. (Blasé...)
9) Ouiiii cette fois ça y est, JvisualVM voit... jstatd et aucun autre truc de la JVM. (Fuck off !!!)
10) Blabla tour sur le net blabla. Ah en fait quand les applis s'exécutent dans un serveur JEE, il faut faire un link différent avec JMX.
11) Je jette un oeil rapide, mon instinct me dit que ça a l'air d'être le bordel. (Comprendre quelques heures de galère supplémentaire en perspective...)
12) OK soit. Ce sera une autre aventure pour un autre jour.

Du coup je décide de switcher sur autre chose histoire de me changer les idées. Aller, je vais faire un petit test de charge avec JMeter tiens.
1) DL JMeter et lancement du bouzin. Ah oui, j'avais oublié qu'il y a 1 milliard de trucs dans le soft (dont une profondeur d'ergonomie à faire bondir de joie un spéléologiste) et que la documentation c'est l'équivalent du volume des encyclopédies de Diderot, D'alembert, Volaire et Rousseau réunies. Mbon, ben je vais juste suivre un petit tuto sur le net alors, j'ai pas envie d'y passer les deux prochaines années non plus...
2) Donc je refais un petit mvn clean install du projet pour le redéployer sur mon jboss de dev et faire mes tests. (ça fait quelques jours que j ai pas effectué l'opération) ET LA HOP SOUDAINEMENT CA MARCHE PLUS. (Grosse fracture morale à cet instant) Y'a rien dans le répertoire deployement mais il voit quand même les anciens deploy... Du coup il faut faire un sort vaudou et effectuer le sacrifice des fichiers de cache pour que l'entité JBOSS soit de meilleure humeur. Bref la petite blagounette JUSTE pour faire chier.

Voilà voilà avec tout ça j'ai encore rien fait de concret et il y a bien 2H de temps de passé... Le problème c'est que ce genre de situation est typique et se reproduit tout le temps, partout, pour chaque truc à faire dès lors qu'on veut creuser un peu dans la technique... L'en faut du courage je vous le dit moi :x

D'où ma conclusion qu'il faut être passionné pour être un bon programmeur (ou admin système). Et si on est un petit peu mono-maniaque c'est encore mieux. Donc ne stigmatisez pas un informaticien si il à l'air un peu bizarre, c'est probablement qu'il est bon ;) (probablement hein). Et encore de nos jours ça va mais pensez un peu à la quantité de borderlines qu'IE6 a envoyé à l'asile :D...


Psyko
31/05/14 à 21:30
0
Demonoid is back
L'ex meilleur tracker torrent après t411 is back online (hébergé aux Philippines huhu).

Bon ben c'est tant mieux car j'étais un peu à court de solution de secours valable ces derniers temps

En espérant qu'ils aient fait un backup de la database et que sa seconde vie soit aussi prolifique que sa première.

Mouarf...


Psyko
27/04/14 à 21:23
4
Exhumation
Hello,

Dans le cadre de mon projet foutoir, j'avais besoin d'un blog, du coup je me suis dis que j'allais déterrer le code source de 'NewsIUT' qui roupille depuis bientôt 10 ans sur ma machine.

J'ai un peu galéré à tout refaire marcher :
- 1) Le code est cradingue à mort.
- 2) J'ai du changer des trucs deprecated de PHP 5.
- 3) Je passe d'une BD MySQL à PostgreSQL donc modifs inside aussi.
- 4) J'avais des merdes d'encodage, donc j'ai du le modifier sur tous les fichiers.

(Oui bon 2 et 3 et 4 résultent de 1 mais je vous merde :>)

Cette fois j'héberge tout chez moi (serveur dédié powa) et je fais des backup de la BDD toutes les nuits donc il n'y aura pas de coupure surprise.

Sinon le code du site est "vanilla", c'est à dire que je n'ai rien changé, c'est comme en 2004 donc en gros c'est bon à jeter et à refaire. (C'est prévu à ma roadmap mais pas prioritaire).

J'ai juste ajouté un antibot vite fait sur les formulaires sinon ça va être rapidement la misère niveau spambots.

J'ai aussi changé l'algo de hash du password de md5 (c'est vraiment plus possible) vers SHA-512 (même si dans l'absolu faudrait utiliser Bcrypt mais bon SHA-512 est encore safe)

Du coup si vous voulez participer vous êtes bienvenus :D...


1