Bienvenue...
Soumis par kacy le
...sur mon blog, j'utilise ce site pour noter les petites choses qui me sont utiles, que ça soit informatique ou autre :)
Blog
Il y a 10 années 9 mois
Lorsque j'ai eu cloné une VM, impossible d'avoir la carte réseau en eth0, l'os (centos) me mettait systématiquement l'interface en eth1 en duplicant les lignes dans /etc/udev/rules.d/70-persistent-net.rules
relou...
En fait c'est super simple, le clonage de VM implique un changement de la MAC Adresse de la carte réseau qui du coup ne correspond plus dans le fichier /etc/sysconfig/network-scripts/ifcfg-eth0 (HWADDR). Il suffit de mettre à jour cette valeur avec la nouvelle MAC Adresse (issue de ifconfig -a) et c'est bon !
Il y a 10 années 10 mois
Impossible de trouver l'executable jmap (ou tout autre utilitaire du jdk) sur une machine linux (avec openjdk installé) ?
Vous ne trouvez que la jre basique ?
...facile faut installer le package java-*-openjdk-devel
perdre une heure... CHECK !
OK, cool vous avez jmap, trop bien essayez ça :
> jmap -dump:file=/tmp/dump.bin <PID>
...ça ne marche pas ? NORMAL faut être avec le même user qui execute le process Java !!
> sudo -u <USER> jmap -dump:file=/tmp/dump.bin <PID>
COOL !! (et perdre une heure de plus : CHECK ! ;)
Il y a 11 années 2 mois
Petit soucis rencontré sur une machine CentOS avec l'utilitaire qload (ServicePack MO03), lorsque j'execute la commande j'ai systématiquement le message :
[mqm@host:~]$ qload -m QM1 -i DLQ -f glop QLOAD Program by Paul Clarke [ V1.9 Build:Jun 26 2012 ] Error loading MQAPI DLL RC(11) [mqm@host:~]$
Du coup je cherche sur le net, giyf* quoi... impossible de trouver quoi que ce soit... je tombe quand même sur ce thread, donc en gros le dev du ServicePack (Paul Clarke) a quitté IBM a priori, c'est mal engagé... y'a quand même un e-mail donc je tente un e-mail avec la description de mon problème... et le mec me répond !!
Donc le problème venait du fait que nous avons installé WMQ avec un préfixe différent de celui par défaut (/opt/mqm) et du coup le programme ne trouve pas les librairies WMQ.
La solution est de positionner une variable MQM_DLL_PATH avec le chemin vers le repertoire /lib64 de WMQ.
Il existe aussi une variable MQACCESS_DEBUG qui permet de se positionner en mode debug.
#petit trick qui permet de spécifier a qload ou se trouvent les libs MQ... MQM_DLL_PATH=`which strmqm | awk -F "/bin/strmqm" '{print $1}'`"/lib64" #si pb avec qload y'a aussi export MQACCESS_DEBUG=yes pour débugger le merdier ${MQ_HOME}/supportpac/mo03/bin/qload -m ${QM_LOCAL_NAME} \ ${PARAM_QUEUE} ${QUEUE} \ -F ${DESTINATION}/${TARGET_FILE} >> ${LOG_FILE} 2>&1
Il y a 11 années 2 mois
"'tin j'ai tjs les fichiers/repertoires en nobody.nobody sur le point de montage là..."
"ah, mmmh depuis que j'ai fait les manips oui j'ai changé un UID ou deux... y'a p'tet des trucs qui ont merdé..."
Du coup on cherche on cherche, monte/démonte le volume, pas de changement, relance des services NFS sur le client, change rien...
Ah tiens y'a un nfsvers=4 là dans le fstab client, mmh vas y met 3 pour voir... OH CA MARCHE :P
Les exports sur le serveur NFS étaient en nfs v3 d'où le problème dans la gestion des uid/gid...
Il y a 11 années 2 mois
Bon, ça fait trois heures que j'essaie tout, cocher l'option ci supprimer l'option là de mon putty et ce lonnard veut tjs pas démarrer l'application Xwindows que je lance à partir de la session SSH...
J'ai bien activé "X11 Forwarding" dans les paramètres putty de la session... rien n'arrive, toujours le même message "can't open display blabla"
Tiens si je regardait les logs du serveur Xming (que j'ai arrêté-redémarré X fois ;)... OH... mais que vois-je !?
AUDIT: Sun Jul 07 23:00:30 2013: 6020 C:\Program Files (x86)\Xming\Xming.exe: client 4 rejected from IP x.x.x.x
LUTAIN !! bon du coup googling et trouvage de solution, j'opte pour la crade : ajouter l'option "-ac" au raccourci windows qui lance Xming :P
