Archives mensuelles : janvier 2015

Installation de l’agent Nagios sur VCSA 5.5

Installation des repository

Se connecter en SSH sur la VCSA5.5


zypper addrepo -f http://download.opensuse.org/distribution/11.2/repo/oss/ opensuse

Vérifier la configuration des nouveaux repos

zypper repos -d

Rafraichir les sources

zypper refresh

Installer Nagios-NRPE

# zypper install nagios-nrpe-client

Activer le service

# chkconfig nrpe on

Configuration de l’agent Nagios

Editer les fichier /etc/nagios/

Lancer le service

# /etc/init.d/nrpe start

Autoriser l’accès distant à l’agent

Ajouter la ligne suivante à la fin du fichier « /etc/hosts.allow » pour autoriser votre serveur Nagios.

nrpe: 192.168.0.10 : ALLOW

Installation agent-zabbix sur VCSA 5.5

Installation des repository

Se connecter en SSH sur la VCSA5.5

zypper addrepo -f http://download.opensuse.org/repositories/server:/monitoring:/zabbix/SLE_11 server_monitoring

Vérifier la configuration des nouveaux repos

zypper repos -d

Rafraichir les sources

zypper refresh

Installer Zabbix-Agent

zypper install zabbix24-agent

Configuration de l’agent Zabbix

Editer le fichier /etc/zabbix/zabbix-agentd.conf

Commenter les lignes :

Hostname=Zabbix server
Server=127.0.0.1
ServerActive=127.0.0.1

Et ajouter en fin de fichier :

LogFileSize=1
DebugLevel=3
Server=192.168.0.10
ServerActive=

Activer le service

chkconfig zabbix-agentd on

Lancer le service

/etc/init.d/zabbix-agentd start

Autoriser l’accès distant à snmpd

Ajouter les 2 lignes suivantes à la fin du fichier « /etc/hosts.allow »

zabbix-agentd: 192.168.0.10 : ALLOW

Tester depuis le serveur Zabbix

$ zabbix_get -s 192.168.0.25 -k agent.hostname
esxi25.lepesant.com

$ zabbix_get -s 192.168.0.25 -k agent.version 
2.4.3

Ca marche !

Installation snmpd sur VCSA 5.5

Installation des repository

Se connecter en SSH sur la VCSA5.5

zypper addrepo -f http://download.opensuse.org/repositories/net-snmp:/factory/SLE_11_SP2/ opensuse_snmp
zypper addrepo -f http://download.opensuse.org/distribution/11.2/repo/oss/ opensuse

Vérifier la configuration des nouveaux repos

zypper repos -d

Rafraichir les sources

zypper refresh

Installer Net-snmp

zypper install net-snmp

Configuration net-snmp

Editer le fichier /etc/snmp/snmpd.conf

Activer le service

# chkconfig snmpd on

Lancer le service

# /etc/init.d/snmpd start

Autoriser l’accès distant à snmpd

Ajouter 1 ligne suivantes à la fin du fichier « /etc/hosts.allow » pour autoriser votre serveur de polling snmp.

snmpd: 192.168.0.10 : ALLOW

Tester depuis le serveur snmp

$ snmpwalk -v 2c -c public -On 192.168.0.25 .1.3.6.1.2.1.1.1.0
.1.3.6.1.2.1.1.1.0 = STRING: Linux esxi25.lepesant.com 3.0.101-0.7.19-default #1 SMP Fri May 9 14:41:39 UTC 2014 (aab30c0) x86_64

Ca marche !

saltstack : remonter le master

Mon process Saltstack master fonctionne dans un container Docker.
Quand j’ai commencé à jouer utiliser Saltstack, je ne maîtrisais pas Docker (non plus, NDLR).
J’avais donc mon répertoire « file_roots: » (par défaut /srv/salt) dans mon container.

Et puis un jour j’ai voulu construire ma propre image Docker à partir d’un Dockerfile (docker build) pour Saltstack.

J’ai donc fait une copie dans ma HOME du répertoire « srv/salt » à partir du système AUFS.

mkdir -p srv/salt
sudo cp -a /var/lib/docker/aufs/mnt/ce45266348553e0e240e86dbb2cdbd27c50965f2f2d9707ec7a37a766e11cdbe/srv/salt/* srv/salt/
sudo chown -R hugues:hugues srv/salt

Puis j’ai buildé mon image, et je l’ai lancé.

docker run -i -t -p 4505:4505 -p 4506:4506 -v /home/hugues/srv:/srv hlepesant/saltstack:latest /bin/bash

Puis je rentre dedans avec docker-enter

docker ps
CONTAINER ID        IMAGE                   [...]
74601a54cf89        hugues/saltstack:latest [...]
docker-enter 74601a54cf89
root@74601a54cf89:/# 

Là les minions sont tous revenus voir papa.

root@74601a54cf89:/# salt-key -L
Accepted Keys:
Unaccepted Keys:
minion-01
minion-02
minion-03
Rejected Keys:
root@74601a54cf89:/# 

Le problème c’est que les commandes salt échouent lamentablement.

Pour débugger : https://salt.readthedocs.org/en/v2014.1.0rc1/topics/troubleshooting/minion.html

A grand coup de « # salt-call -l debug state.highstate » exécuté à partir d’un des minions, l’erreur devient plus flagrante.
La clef publique échangée entre le minion et le master n’est plus la même.

Pour y remédier :

1. Sur le master :

salt-key -d <minion_id>

2. Sur le minion

sudo rm /etc/salt/pki/minion/minion_master.pub
sudo /etc/init.d/salt-minion restart

3. Retour sur le master

salt-key -a <minion_id>

Et voilà.