HOAB

Le problème :

J'ai des VM imposantes de 45Go à 100Go (ne me demandez pas pourquoi, c'est une contrainte externe...). Je les utilisais localement sous Virtualbox.

J'utilisais Virtualbox car celui-ci s'intégre mieux à mon Linux que VMWare qui nécessitait une recompilation avec une version GCC obsolète, un peu galère.

Les VM ont été transférées par l'hébergeur directement sur l'ESXi sur l'espace de stockage, au format OVA.

Le problème a été lors du déploiement de ces OVA en local sur l'ESXi, je devrais dire LES problèmes....

Solution :

Cela a été un peu long car je ne connaissais rien à VCenter (le manager de ESXi).

D'abord il faut savoir que c'est un OS, donc pas d'accès SSH pour aller voir ce qui se passe (enfin, voir la suite, ce n'est pas tout à fait vrai !)

1) Déployer OVA depuis le local store de l'ESXi

Bon ce n'est pas possible. Le client demande une URL et pas un chemin "local"

2) Webbrowser du local store (ne marche pas)

Malin le singe ! Le local store a un webbrowser : http://<ip esxi>/folder/ (d'ailleurs décrit ici par exemple)
Donc on redémarre le déploiement en indiquant une adresse en

http://172.16.29.100/folder/test/toto.ova?dcPath=ha%2ddatacenter&dsName=data

Le problème ici est que vu la taille des VM ou le serveur HTTP associé, on obtient au bout de quelques temps une erreur 503.

3) Format OVA Virtualbox non supporté

Alors avant de tomber sur l'erreur 503, VSphere a eu le temps d'analyser l'OVA pour indiquer que :

- le system est inconnu (normal virtualbox) : remplacer par vmware
- l'interface disque est inconnue (normal SATA alors que SCSI sur le serveur) : remplacer par du SCSI
- la carte son est inconnue (normal aussi, le serveur n'a pas le temps de jouer de la musique)i : supprimer la section

Pour corriger ça, c'est simple, c'est décrit à plusieurs endroits (ici, là) : il faut modifier l'OVF. Rappel dans l'OVA il y a un disque un VMDK + un descripteur l'OVF.

Donc modifier l'OVF. Qui est sur l'ESXi. Dans un OVA que je ne peux pas télécharger et uploader car trop gros. Easy (décrit ici):

1. ouvrir l'accès SSH VSphere pour un utilisateur,
2. transférer 7z portable,
3. dézipper l'OVA avec 7z
4. modifier le fichier OVF.

Petite astuce pour savoir où sont stocké les VMDK / OVA :

1. accès SSH
2. find . -name "*ova"

4) Recréer une VM à partir du VMDK (ne marche pas)

J'ai essayé de créer une nouvelle VM vierge en utilisant un disque VMDK existant.

Outre le fait qu'on ne peut sélectionner le VMDK que si un descripteur VMDK est recréé (méthode ici) au final la VM ne démarre pas. Un boot avec une iso GParted montre un disque vide. Le descripteur VMDK ne doit pas être correct pourtant monsieur ! je jure ! j'ai tout fait comme il faut !

5) Déploiement final

L'OVF est modifié, il reste à avoir un serveur HTTP digne de ce nom pour servir l'image au VCenter.

Sur le serveur j'avais déjà une VM existante... Donc :

1. on transfère l'OVF et le VMDK sur la VM existante
2. qui est trop petite, donc on l'agrandit avec un disque supplémentaire
3. on créé les volume group, logical volum et filesystem sous linux
4. on retransfère l'OVF et le VMDK dans un répertoire qui a de la place
5. on démarre un serveur python dans ce répertoire :

python -m SimpleHTTPServer

6. dans le vClient on donne l'adresse IP de la VM : http://<ip VM>:8000/monfichier.ovf
7. et ça déploie.... pas. Enfin si mais lentement. Parce que même si la VM et l'ESXi sont dans le même sous réseau on passe par le poste du vClient... en ADSL...
8. donc nouvelle VM (ou la même) : installation du vClient dans le même sous réseau et on utilise le vClient dans le même sous réseau

VICTORY.... Argh.... ça été dur.

Le problème :

La suite de cet article : http://hoab.fr/zabbix-et-monitoring-installation

Solution :

On a zabbix qui tourne et ensuite ?

Astuce générale : le bouton Refresh / Actualiser = Sauvegarder la configuration...

Plein de petites choses :

• ajouter un agent sur une machine (la même ou une distante)
• créer un serveur à monitorer : Configuration > Hôtes
• lui ajouter des templates (des listes de choses à surveiller) Hôte > monHôteAMoi > Templates
• pour mysql, vérifier que les métriques remontent bien depuis l'agent. Sur la machine qui héberge l'agent :
  • créer le user zabbix qui peut observer la base :

mysql -uroot -p -e"GRANT USAGE ON *.* TO 'zabbix'@'127.0.0.1' IDENTIFIED BY '123456'";
mysql -uroot -p -e"GRANT USAGE ON *.* TO 'zabbix'@'localhost' IDENTIFIED BY '123456'";
mysql -uroot -p -e"flush privileges"
mysql -uzabbix -p123456 -e"status"

• continuer sur la machine qui héberge l'agent :
  • vérifier qu'il y a un fichier : /etc/zabbix/zabbix_agentd.d/userparameter_mysql.conf
  • pour ajouter des choses spéciques à la connexion au serveur mysql, ce que j'ai trouvé le mieux c'est un script spécifique
  • dans le userparameter_mysql.conf

UserParameter=mysql.status[*],echo "show global status where Variable_name='$1';" | /home/admin/monitortools/zabbix/mysql_zabbix.sh -N | awk '{print $$2}'

• toujours pour mysql, sur le serveur qui héberge l'agent
  • dans le fichier /home/admin/monitortools/zabbix/mysql_zabbix.sh

    #/bin/bash
    mysql --defaults-extra-file=/home/admin/monitortools/zabbix/.my1.cnf -S /var/run/mysqld/mysqld1.sock $*

     

• cela peut se tester avec (http://hoab.fr/shaarli/?aPEmew) : zabbix_agentd -t mysql.status[Com_begin]
• vérifier que les métriques remontent dans Monitoring > Latest Data
  • choisir le serveur configuré plus haut dans les filtres, appliquer
• si les métriques remontent bien, vous pouvez créer des graphiques et des écrans Monitoring > Ecran
• maintenant il reste à configurer les alertes
  • Administration > Type de Media : configurer comment vous voulez être notifié
    • pour les emails, cette page configure l'email émetteur ainsi que le serveur SMTP qui accepte d'émettre des emails pour cette adresse. Moi j'avais un serveur SMTP sur mon serveur, je me suis créé un compte et voilà. Sinon utiliser un email et un compte ailleurs. Attention pour les versions Zabbix 2.x c'est un peu galère, il n'y a pas beaucoup d'options
  • Administration > User > myUser > Media
    • c'est là où vous configurer le ou les adresses destinatrices qui vont recevoir les alertes
  • Configuration > Action : les actions à réaliser lorsque les triggers se déclenchent. L'action par défaut prévient l'administrateur de tout, après on peut réaliser des filtres assez avancé suivant les triggers
• Ajouter des alertes personnalisées
  • Configuration > Template > leTemplateQuiContientLaMétrique > Triggers > Create Trigger (en haut à droite)
  • Les expressions de triggers ne sont pas simples, heureusement il y a un éditeur ! (qui s'ouvre d'une popup à côté)
  • Exemple : dans Configuration > Template > Template OS Linux > Triggers > Create Trigger
    • Déclenchement si CPU Idle < 20% pendant 5 secondes : {Template OS Linux:system.cpu.util[,idle].avg(5s)}<20
    • Qui peut se faire via le bouton "constructeur d'expression"

Voilà mes notes pour un début. Ca l'air bien complet avec des triggers de type "tendance" et c'est ce que je cherchais.

Pas très compliqué à mettre en place, j'ai un peu galéré pour les triggers mysql parce que j'ai deux instances de bases sur mon serveur, mais avec l'astuce du shell tout va bien. Et puis surtout ce p*#! de bouton "Actualiser" qui veut dire "Sauvegarder"....

Le problème :

Ne pas passer son temps à réagir au problème et être prévenu à l'arrache.

Solution :

Du monitoring évidemment. J'ai eu l'occasion de voir Zabbix, c'était l'occation de tester.

Installation presque simple (je suis sous une Debian Jessie) :

1. Ajout du repository Zabbix dans APT

wget http://repo.zabbix.com/zabbix/3.2/debian/pool/main/z/zabbix-release/zabbix-release_3.2-1+<codename>_all.deb
dpkg -i zabbix-release_3.2-1+<codename>_all.deb
apt-get update
apt-get install zabbix-server-mysql
apt-get install zabbix-frontend-php

1. Soit on a une base de données qu'on veut utiliser, dans ce cas, vérifier qu'on a bien mysql-client (ou mariadb-client) d'installé. cf ici : "zabbix-server-mysql packages has dependency "mysql-client" or "virtual-mysql-client"."
2. Soit on en a pas et zabbix va installer un mysql... je vous laisse trouver la littérature sur le sujet si vous voulez mieux maitriser l'installation de la base. Sinon c'est debian, ça marche tout seul
3. On créé l'utilisateur zabbix, la base et les tables pour la partie zabbix-server (là où seront stockés les métriques, les alertes etc...). Je ne sais pas trop quel place çà va prendre sur le disque. A surveiller (via zabbix ^^). Ca se passe par ici pour la base et l'utilisateur
4. Création des tables, ça change pas mal suivant les versions, pour la 3.2 c'est :

zcat /usr/share/doc/zabbix-server-mysql/create.sql.gz | mysql -uzabbix -p<password> zabbix

5. Normalement le apt ajoute la configuration pour Apache, sinon, le voilà :

# Define /zabbix alias, this is the default
<IfModule mod_alias.c>
    Alias /zabbix /usr/share/zabbix
</IfModule>

<Directory "/usr/share/zabbix">
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all

    <IfModule mod_php5.c>
        php_value max_execution_time 300
        php_value memory_limit 128M
        php_value post_max_size 16M
        php_value upload_max_filesize 2M
        php_value max_input_time 300
        php_value always_populate_raw_post_data -1
        # php_value date.timezone Europe/Riga
    </IfModule>
    <IfModule mod_php7.c>
        php_value max_execution_time 300
        php_value memory_limit 128M
        php_value post_max_size 16M
        php_value upload_max_filesize 2M
        php_value max_input_time 300
        php_value always_populate_raw_post_data -1
        # php_value date.timezone Europe/Riga
    </IfModule>
</Directory>

<Directory "/usr/share/zabbix/conf">
    Order deny,allow
    Deny from all
    <files *.php>
        Order deny,allow
        Deny from all
    </files>
</Directory>

<Directory "/usr/share/zabbix/app">
    Order deny,allow
    Deny from all
    <files *.php>
        Order deny,allow
        Deny from all
    </files>
</Directory>

<Directory "/usr/share/zabbix/include">
    Order deny,allow
    Deny from all
    <files *.php>
        Order deny,allow
        Deny from all
    </files>
</Directory>

<Directory "/usr/share/zabbix/local">
    Order deny,allow
    Deny from all
    <files *.php>
        Order deny,allow
        Deny from all
    </files>
</Directory>

6. Connexion sur http://<mon ip>/zabbix
7. On suit l'assistant de connexion
8. La suite plus tard

Le problème :

Convertir en masse une liste d'utilisateurs vpopmail vers postfix

Solution :

J'avais référencé ce script mais il ne fonctionne pas (il manque des includes).

D'abord je créé le domaine voulu : mondomaine.Com

Et ce petit script qui parcours le fichier vpasswd et génère les insert SQL qui vont bien dans la table postfix.mailbox

#!/bin/bash

SAVEIFS=$IFS

CONVERT_DOMAIN="<mondomaine.com>"
DATE=`date "+%Y-%m-%d %H:%M:%S"`

while IFS='' read -r line || [[ -n "$line" ]]; do
    IFS=': ' read -r -a array <<< "$line"
	
	echo "INSERT INTO mailbox (username, password, name, maildir, quota, local_part, domain, created, modified, active) VALUES('${array[0]}@$CONVERT_DOMAIN', '${array[1]}', '${array[0]}', '${array[0]}@$CONVERT_DOMAIN/', 0, '${array[0]}', '$CONVERT_DOMAIN', '$DATE', '$DATE', 1);"

    IFS=''
done < "vpasswd"

IFS=$SAVEIFS

Et ensuite j'insère tout ça directement dans ma base SQL, vérification avec postfixadmin.

Le problème :

Je veux migrer en douceur et de manière transparente un serveur de courier d'un serveur A vers un serveur B.
Le serveur A est un qmail/vpopmail/courier-imap.
Le serveur B est un postfix/dovecot
Go !

Solution :

Pour palier au temps de propagation des DNS qui peut être rapide ou pas, l'idée est donc :

Serveur B : préparation

<domaine.com> mail._domainkey.<domaine.com>

1. créer dans postfixadmin sur le serveur B le nom de domaine à gérer
2. générer la clé DKIM pour ce nouveau domaine (cf configuration DKIM multi-domaine)
3. vérifier le domaine (cf post 10/10)
4. créer les boites aux lettres, j'en ai peu, mais il y a des scripts de migration à partir des vpasswd a priori (ou ça en fait)
5. via thunderbird portable, et mes configurations, je créé des comptes et je teste l'envoi et la réception

IMAP
ip du serveur (le DNS n'est pas migré), port 143, STARTTLS, mot de passe non chiffré

SMTP
ip du serveur (le DNS n'est pas migré), port 587, STARTTLS, mot de passe non chiffré

Serveur A : relay

Le serveur B étant prêt à gérer les mails, on redirige le trafic SMTP du serveur A vers le B pour ce domaine.

Un guide ici.

1. Vérifier la présence de <domaine.com> dans /var/qmail/control/rcpthosts
2. Supprimer la référence à <domaine.com> dans /var/qmail/control/smtproutes
3. Ajouter la redirection dans : /var/qmail/control/smtproutes

<domaine.com>:<IP serveur B>

4. redémarrer qmail
5. Tester l'envoi d'un email en utilisant le DNS mail.<domaine.com>, il passe par serveur A et est forwardé au serveur B

DNS : bascule

Modifier les DNS

Serveur A/B : recopier les boites aux lettres

Via un rsync plusieurs jours avant si les boites sont volumineuses, c'est la copie qui est longue, la conversion est rapide (quelques fichiers à modifier).

Le script de migration est ici : http://wiki.dovecot.org/Migration/Courier

Donc :

1. recopier les boites courier-map

# Serveur A
cd /home/vpopmail/domains
tar zcf <domaine.com>.tgz <domaine.com>
scp <domaine.com>.tgz <Serveur B>:/home/vmail/<domaine.com>/tmp_migrate

# OU rsynch
cd /home/vpopmail/domains
rsync -razh --delete root@<serveur A>:/home/vpopmail/domains/<domaine.com> .

2. les extraire

# Serveur B
cd /home/vmail/<domaine.com>/tmp_migrate
tar zxf <domaine.com>.tgz

3. les convertir

 ./courier-dovecot-migrate.pl <domaine.com> --recursive 
# si ok
 ./courier-dovecot-migrate.pl <domaine.com> --recursive --convert

4. les transférer dans la nouvelle boite

chown -R <user dovecot:user dovecot> *
cp -r <domaine.com>/* /home/vmail/<domaine.com>/