N-C

Aller au contenu | Aller au menu | Aller à la recherche

Bugs resolves - astuces

Fil des billets - Fil des commentaires

vendredi 23 mars 2012

[ Calcul ] à partir d'un fichier linux

calculer un total à partir d'un fichier :

ex : cat du_sh.log

51564
49936
50132
51536
52700
53728
51524
51100
...

les commandes suivantes vont faire le total :

[user@server ~]$ Size1=`cat log_du.bis`
[user@server ~]$ echo $Size1
[user@server ~]$ echo ${Size1} | awk '{total=0 ; for (i=1 ; i<=NF ; i++) total += $i ; print total}'
[user@server ~]$ Size2=`echo ${Size1} | awk '{total=0 ; for (i=1 ; i<=NF ; i++) total += $i ; print total}'`
[user@server ~]$ echo $Size2



vendredi 17 février 2012

[VMware-VMFS] - new Lun on RHEL Guest

l'ajout d'un nouveau Lun VMFS sur un guest type RHEL (centOs) en live sans reboot n'est pas dynamique. via le bus scsi

pour le moment, sans trop savoir pourquoi le kernel n'implémente pas la détection auto par défaut sous RHEL5.x il suffit de passer cette commande afin de détecter le nouveau Lun :

echo "- - -" >/sys/class/scsi_host/host0/scan

ensuite un # dmesg permettra de voir le nouveau device ! (exemple /dev/sdb)

puis donc un fdisk  /dev/sdb pour le partitionnement :

Sinon pour l'autorisation d'un rescan sur le disque primaire (le /) ou bien /dev/sda par exemple, il faut autoriser un rescan sur le device

echo "- - -" >/sys/class/scsi_device/0\:0\:0\:0/device/rescan




vendredi 10 février 2012

[ Bug ] Fiber channel (multipath) + SAN (NetApp) RedHat 6.x

un jolie bug sur les distrib à base de RH6.x X86_64 concernant la détection de nouveau Lun sur le système link en FC

  • quelque soit le type de carte Emulex / QLA ... le Bug n'est pas lié aux modules (confirmer par l'arrêt/relance)
  • le bug n'est pas lié à udevd (arrêt/relance + debug-trace)
  • un scsi_rescan ne trouvera rien
  • un modprobe de toute la couche DM ne changera rien :(ici avec QLA)

    modprobe qla2xxx scsi_transport_fc  scsi_tgt dm_multipath dm_round_robin dm_mirror dm_multipath dm_mod

  • l'utilisation de dmsetup rien non plus : exemple où rien ne se passe !

    dmsetup create mpathl -v -u mpath-360a980006467467564346937484d3174

  • un arrêt relance du service multipath ne changera rien non plus, même avec l'ajout manuelle de l'id dans : /etc/multipath.conf ; /etc/multipath/wwids ; /etc/multipath/bindings
Au final, j'ai remonté chaque process au démarrage du système pour trouver la solution, et ce fût HALd le problème.
Normalement HAL est en écoute pour détecter tout nouveau D-bus périphérique, et bien apparemment, pour la couche FC il n'y arrive pas.

il suffit de relancer le service et cela fonctionne !

/etc/init.d/haldaemon restart

Une fois relancé, un nouveau device virtuel apparaît enfin dans /dev/mapper/mpath*  ( cf : ci-dessus mpathl )

Cette technique permet d'éviter le reboot système pour la détection de nouveaux Lun en FC !!!

mardi 28 juin 2011

SSH - Astuce

désactiver le prompt ssh d'authentification via known_host :

Si vous avez un retour de la commande tel que :

[user@server ~]# ssh client_distant
The authenticity of host 'client_distant (172.xxx.xxx.xx)' can't be established.
RSA key fingerprint is c5:d8:30:fd:4f:b1:12:bb:21:73:fb:a2:90:41:f0:d5.
Are you sure you want to continue connecting (yes/no)?

Pour passer automatiquement ce prompt, il suffit d'ajouter un fichier de config pour le user :

echo "StrictHostKeyChecking no" >> ~/.ssh/config

Et voilà !

vendredi 4 juin 2010

SSHD

Si les clef ssh ne sont pas fonctionnelles, vérifier l'option :  /etc/ssh/sshd_config

# StrictModes yes

permet d'obliger des masque sur $HOME; $HOME/.ssh ; $HOME/.ssh/authorized_keys

Ces restrictions sont : 

$HOME 700

$HOME/.ssh 700

$HOME/.ssh/authorized_keys 644

Si l'un de ces mask n'est pas respecter alors l'utilisation de clef ssh ne fonctionne pas.

Sinon désactiver l'option par :

StrictModes no

et penser à restart sshd : /etc/init.d/sshd restart

page 2 de 2 -