Quorum proxmox planté après mise à jour en version 5

Retour d’expérience sur une upgrade proxmox  4.4 => 5 qui tourne mal sur une machine munie de plusieurs interfaces réseaux.

Symptôme:

Au reboot, après mise à jour, le quorum ne démarre plus un problème cmap.
toutes les commandes pvecm renvoi l’erreur « cannot initialize CMAP », le répertoire /etc/pve semble ne plus contenir qu’une partie des fichiers, et ce, en lecture seule. bref catastrophique.

Le détail indique des défaillances multiples de telle que celle-ci:

[libqb] debug: qb_ipcc_disconnect() (ipcc.c:398:qb_ipcc_disconnect)
[quorum] crit: quorum_initialize failed: 2 (quorum.c:112:service_quorum_initialize)
[libqb] debug: qb_ipcc_disconnect() (ipcc.c:398:qb_ipcc_disconnect)
[confdb] crit: cmap_initialize failed: 2 (confdb.c:239:service_cmap_initialize)
[main] debug: dfsm_set_mode – set mode to 0 (dfsm.c:520:dfsm_set_mode)
[libqb] debug: qb_ipcc_disconnect() (ipcc.c:398:qb_ipcc_disconnect)
[dcdb] crit: cpg_initialize failed: 2 (dfsm.c:1382:dfsm_initialize)
[main] debug: dfsm_set_mode – set mode to 0 (dfsm.c:520:dfsm_set_mode)
[libqb] debug: qb_ipcc_disconnect() (ipcc.c:398:qb_ipcc_disconnect)
[status] crit: cpg_initialize failed: 2 (dfsm.c:1382:dfsm_initialize)
[main] debug: enter cfs_fuse_getattr / (pmxcfs.c:126:cfs_fuse_getattr)

 

Après avoir vainement cherché un problème de fichiers de config perdus, en fait,  il s’agissait d’un problème réseau assez sournois car pourtant tout les tests effectués (ping du nom, ssh et test multicast vers les autres proxmox) fonctionnaient sans soucis dans les deux sens.

Si, comme moi,  vous disposez de plusieurs interface réseaux, vous aurez peut-être opté pour l’idée de « dédier » l’interface vmbr0 pour l’accès à l’interface, les sauvegardes et le quorum, et fait un agrégat (bond) sur vmbr1 afin d’optimiser les performances réseaux des VM.

Pourtant, c’est en supprimant l’agrégat que tout c’est remis à fonctionner.

=> Donc =>

Une solution possible:

Si, après mise à jour, vous rencontrez ce problème, vous pouvez tenter la désactivation ou la suppression / recréation de cette seconde interface (vmbr1).

 

Ps: Après cette remise en marche, un problème de certificat est apparu, (probablement lié aux nombreuses tentatives de remise en état durant plusieurs heures) réglé par

pvecm updatecerts –force

suivi d’un reboot.

Bon courage à vous si vous êtes dans cette situation, en espérant avoir pu vous aider.

IPv6 Ubuntu et Windows

Bonjour,

Ceci n’est pas un tutoriel mais plus un retour d’expérience car je n’ai pas la prétention de connaitre tout les mécanismes en place dans l’IPv6.

Suite a quelque méli-mélo  un problème commercial avec OVH, je me suis retrouvé avec un serveur en housing chez eux, mais sans IPv4 pour mes VM.

J’ai donc profité de cette latence commerciale pour tenter le faire un point sur l’avancement de l’IPv6.

Afin de pouvoir accrocher des nom d’hote sur mon domaine, j’ai décidé d’affecter des IPv6 statiques sur mes différentes VM.

Attribution:

En IPv6, le fournisseur vous fourni un sous réseau IPv6, généralement de classe /64 et vous laisse donc les 64 autres bits a votre disposition soit 18 milliards de milliards d’adresses !

Passerelle:

Chez FREE, l’adresse de la freebox est généralement la 1ere IP de la plage  donc l’adresse 2001:xxxx:xxxx:xxxx::1
Chez OVH, selon leur documentation, les octets bas des 5 derniers nombres sont a ff cela donne donc quelque chose du genre
2001:xxxx:xxxx:xxff:ff:ff:ff:ff   c’est a dire en affichant l’adresse avec les zero non significatifs cela donne 2001:xxxx:xxxx:xxff:00ff:00ff:00ff:0ff …

=> Oups !!! OVH semble avoir oublié le but d’un masque de sous réseau => Tout ce qui est en dehors du masque est défini comme extérieur et donc à la passerelle située OBLIGATOIREMENT dans le sous réseau…
Le masque réellement fonctionnel avec une telle passerelle est donc /56

Expérimentation sous Windows:

Depuis ma machine virtuelle équipée d’un Windows 2008 Sp2, l’IPv6 se configure sans difficulté. Microsoft n’est pas regardant sur le fait que la passerelle ne se trouve pas dans le même sous réseau…
En faisant pointer les DNS IPv6 vers ceux de Google dont je le rappel les ip sont:

2001:4860:4860::8888 et
2001:4860:4860::8844

L’accès à google est immédiat. Un petit test sur www.ipv6-test.com confirme que tout vas bien.

1ère observation: Sur un poste uniquement IPv6, on n’a accès a aucun site dont le serveur n’est qu’en IPv4.
2ème observation, plus curieuse: Windows Update ne fonctionne pas… il n’est pas IPv6 ready en 2015 alors qu’ils intègrent pourtant l’IPv6 depuis 2008 dans leurs logiciels ?!

Hormis ce problème de défaut de préparation du système de mise à jour, le système s’accoutume bien de l’IPv6 statique, et fonctionne de façon stable, même en désactivant totalement l’IPv4.
La connexion au bureau distant par exemple fonctionne très bien, ainsi qu’un serveur web IIS situé sur ce poste.
En revanche les petits logiciels annexes, une très vieille version de Serv-U (version 6.4) et freeFTPd ne fonctionnent pas mais cela parait assez logique.

Expérimentation sous Ubuntu 14.04.2

L’installation de l’IPv6 statique se fait dans le fichier /etc/network/interfaces

1ère observation: La mise à jour via apt-get update && apt-get upgrade -y fonctionne nickel. Preuve que les dépôts Ubuntu ont une longueur d’avance sur leurs alter-égo de Microsoft.
2ème observation: SSH fonctionne nickel. La connexion réalisée avec Winscp et Putty depuis mon poste abouti parfaitement.
3ème observation: La suppression de la config de l’IPv4 mène a un dysfonctionnement et a plus de 2 mn d’attente a chaque redémarrage. Donc j’ai laisser un config réseau bidon pour qu’il passe outre ce problème.

Sauf qu’Ubuntu, contrairement a Microsoft, ne tolère pas cette erreur de masque… Et au bout d’un délai aléatoire se plante, perte de connectivité totale du serveur jusqu’au reboot.

L’incohérence a pour effet de lui faire perdre sa route par défaut … Donc seul les postes dans le même sous réseau que lui peuvent continuer a dialoguer avec lui… et … c’est bête pour un serveur situé dans un datacentre !

conclusions

Même les grands de l’informatique tel qu’OVH peuvent se perdre dans la complexité de l’IPv6.
Les choses avances tout doucement sur cette évolution inévitable. Il y’a plein de pièges a connaitre, les mécanismes sont beaucoup plus complexes qu’en IPv4 et on est encore loin de pouvoir faire du FULL IPv6 sous peine de ce couper d’une grande partie du monde…

A bientôt

 

Compacter le vhdx d’un serveur Ubuntu virtualisé sur Hyper-v

Attention, AVANT TOUTE CHOSES:

  • Pour éviter tout problème, d’abord faire une sauvegarde de la machine virtuelle avant cette opération a faire à vos risques & périls
  • L’opération est longue, donc à faire a un moment ou la machine peut être arrêté suffisamment longtemps (genre 2h)

 La problématique:

Hyper-v fait croitre un disque dynamique mais ne le réduit jamais. Lorsqu’une machine travaille beaucoup en création/effacement de fichiers, le volume s’accroit sans jamais décroitre une fois l’activité terminée. Ce qui peut poser des problèmes de place et aussi des difficultés pour sauvegarder un vhdx devenu gigantesque.

Dans cette exemple, un serveur Ubuntu nommé srv-travail (serveur web de test) et autre nommé srv-web (serveur proxy) tous deux passés de Ubuntu V12 à V14.

0-avancompactage

Sur un Windows virtualisé, seule l’étape 2 de ce tutoriel serait nécessaire: il suffit d’ordonner à hyper-v de compacter l’image.
Mais un serveur Ubuntu virtualisé, le contenu de l’image n’est pas directement « comprise » par hyper-v, il faut faire une étape supplémentaire assez longue qui consiste à remplir l’espace vide de 0.

Ceci peut se faire grâce à la commande zerofree

Sauf que bien sûr, cette opération ne marche pas sur un volume en activité donc, il faut le faire en étant « offline ».
On peut donc facilement réaliser cette opération avec un système portable nommé SystemRescueCD

Il peut être téléchargé sur ce lien

http://sourceforge.net/projects/systemrescuecd/files/latest/download?source=typ_redirect

1ère Étape: le vidage de l’espace libéré

  • Arrêter votre machine virtuelle Ubuntu,
  • Chargez le l’image iso dans le lecteur cdrom virtuel de votre machine,
    1-insertioncd
  • Redémarrez votre machine => celle-ci va se lancer sur SystemRescueCD
    2-demarragesystemrescuecd
  • Choisissez l’option 1, le chargement se lance pour ne s’interrompre uniquement pour demander la définition du clavier.
  • Tapez fr puis entrer
  • Vous arrivez alors sur l’interface.
    3-arrivesurinterface
  • A ce point, deux possibilités soit votre système est installé sur un LVM, soit il est basé sur un partition normale:

Si votre système est créé sur une partition LVM:

vgchange -a y

=> cette instruction vous renvoi un warning a ignorer, mais aussi le nom du volume LVM.

  • zerofree /dev/[nom du volume LVM]/root

Si votre système est créé sur une partition normale:

Vous trouverez alors votre VHDX en /dev/sda1

  • zerofree /dev/sda1

Si vous avez réussi, l’opération est longue (genre 20mn à 1h). Si cela rend la main presque immédiatement, c’est qu’en sda1 est monté une partition de boot toute petite pour un volume LVM donc dans ce cas il faut suivre le process pour un volume LVM

Exemple en LVM sur la seconde machine, srv-web:

4-operationsurlvm

 

2ème étape: le compactage

Comme d’habitude ce qui fonctionnait très bien sur les versions précédentes (Windows 2008r2) ne fonctionne plus sur les version actuelles (Windows 2012r2), quand on demande le compactage du volume sous un Windows 2012r2… il ne se passe rien ! Génial ! Donc il faut le faire en PowerShell

Click droit sur votre icône Powershell puis « Exécuter en tant qu’Administrateur »
Dans la console PowerShell, vous devrez saisir les 3 instructions suivantes

Mount-VHD -Path "[chemin et nom du fichier]" -ReadOnly
Optimize-VHD -Path "[chemin et nom du fichier]" -Mode Full

5-compactagevhdx
Là aussi, cela dure assez longtemps… voire très longtemps…

Dismount-VHD "[chemin et nom du fichier]"

A noter que les commandes Mount et Dismount sont optionnelles, mais elles permettent de verrouiller le VHDX pendant l’opération pour diminuer les risques sur un environnement multi utilisateurs.

Opération terminée. Ejectez le cdrom du lecteur virtuel de la VM puis redémarrez.

Résultats

7-resultat

Dans mon exemple, j’ai gagné 6Go sur la VM srv-travail et 9Go sur la VM srv-travail. Sur d’autre machines ou j’ai effectué l‘opération, le gain a même été bien plus important. Ainsi sur un serveur de prod le vdhx est passé de 156Go à 27Go.

Dépasser les 2To sur un serveur HP Gen8 non équipé uEFI

Les serveurs HP de la gen8, contrairement à leurs équivalents IBM, ne sont pas équipés de rom uEFI.

C’est pourtant le pré-requis indispensable pour pouvoir booter sur un disque au format GPT, seul format Microsoft permettant le partitionnement de plus de 2To, capacité aujourd’hui très courante.

La seule solution est donc de créer deux lecteurs logiques sur le raid. L’un de 300Go par exemple qui restera en mbr pour être compatible avec le bios, et l’autre, qui servira pour les données qui sera converti en GPT depuis Windows après l’installation du système.

La 1ère étape est donc de créer cette configuration dans le raid avant de procéder a l’installation via l’intelligent provisionning:

hp1

Lors de cette étape, au moment de la création de la baie, il faudra refuser la proposition de lecteur logique incluant tout l’espace et lui redéfinir la taille à 300Go.
Une fois appliquée, créez un second lecteur logique avec la capacité restante.

hp2

hp3

Une fois cette configuration réalisée, vous pouvez installer le système d’exploitation, en indiquant a l’intelligent provisionning de ne pas toucher au réglage de la carte raid.

hp4

hp5

Une fois le système d’exploitation installé, vous pouvez alors convertir votre lecteur logique dédié au données en GPT.

hp6

Puis ensuite le formater.

hp7

Et enfin, vous aurez accès a l’ensemble de l’espace de votre RAID.

hp8

Billet d’humeur: Je trouve cependant très dommage que contrairement a IBM dont les serveurs de la série X sont équipé d’uEFI  depuis plus de 5 ans, HP, partenaire étroit de Microsoft, promoteur de l’uEFI depuis 2005, ne fasse que commencer a intégrer ce standard dans la gen9 et obligent ses utilisateurs au bricolage indiqué ci dessus. Standard pourtant intégré dans de simple cartes mères de PC à 99€…

 

Montage permanent d’un dossier ftp

Suivant l’article précédent permettant de monter un partage Windows de façon permanent sous Ubuntu.

Ceci est réaliser grâce a curlftp

apt-get install curlftp

Ensuite on ajoute le point de montage dans fstab:

vi /etc/fstab et ajouter la ligne

curlftpfs#(login):(pass)@(adresse) (dossier de montage) fuse rw,user,allow_other,uid=1000,utf8,_netdev 0 0

Puis

modprobe fuse

Référence:

http://doc.ubuntu-fr.org/curlftpfs

Remerciements à Maxime pour cette information.

Ubuntu 14.04 se bloque sous hyper-v

prompt

A l’instar de Windows, Ubuntu 14.04 comporte des « fonctionnalités »… appellé « bug » par le commun des mortels. 🙂
Ubuntu 14.04 virtualisé sous hyper-v, au bout d’un certain temps « gèle » aléatoirement. Le noyau 3.13 serait en cause ce qui explique pourquoi ubuntu 12.04LTS n’a pas ce problème.

 

 

La solution en attendant un correctif du noyau  (Edit du 17/10: ce problème est aujourd’hui réglé):

cd /etc/default
sudo vi grub

ajouter "nohz=off elevator=deadline transparent_hugepage=always" dans les paramètres de la ligne "GRUB_CMDLINE_LINUX_DEFAULT"

sauvegardez puis faire:

sudo update-grub

Ensuite dans le fichier /etc/sysctl.conf

Ajouter les lignes suivante

kernel.sched_min_granularity_ns=10000000
kernel.sched_wakeup_granularity_ns=15000000
vm.dirty_ratio=10
vm.dirty_background_ratio=5
vm.swappiness=10

Sauvegardez puis redémarrez

=> le système devrait être plus stable.

 

Modification du 9 Mai 2015:

Dans sa distribution 14.04.2, Ubuntu distribue le noyau 3.16. Celui bénéfie d’une meilleur integration dans un Hyper-v sous windows 2012r2. (Windows ne signale plus l’intégration comme dégradée). Pour en bénéficier, il suffit d’installer ce noyau en utilisant la commande:

sudo apt-get install linux-image-generic-lts-utopic

Monter un partage Windows de façon permanente

120px-Human-gnome-fs-smb.svgmonter un partage Windows sous linux avec accès écriture complet

 

 

 

premier étape: Installer les utilitaires cifs

sudo apt-get install cifs-utils

deuxième étape: Créer le dossier du point de montage:

sudo mkdir /ftp

ensuite on creer le fichier contenant les identifiant réseau d’acces au partage windows:

sudo vi ~/.smbcredentials

et dedans on met:

username=(login windows de l'utilisateur)
password=(mot de passe windows de l'utilisateur)
domain=(domain de l'utilisateur)
sudo /etc/fstab

dans ce fichier on ajoute la ligne suivante:

//serveur2008/ftp /ftp cifs sec=ntlm,credentials=/home/(nomdel'utilisteur)/.smbcredentials,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0

puis

sudo mount -a

pour tester

il est conseillé de sécuriser ensuite le fichier .smbcredentials avec un chmod 0600

Mise à jour:
Dans Ubuntu 14.04, il est possible d’optimiser la connexion pour utiliser la version de SMB correspondant au montage du système de destination avec le paramètres vers=x.y

avec x.y =
2.0 pour un Windows 2008/vista
2.1 pour un Windows 2008r2/windows 7
ou
3.0 pour un Windows 2012/windows8

donc la dernière version de la ligne dans le fichier fstab serait:

//serveur2008/ftp /ftp cifs sec=ntlmssp,rw,credentials=/home/(nomdel'utilisteur)/.smbcredentials,vers=2.1,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0

 

 

 

Voir les ordinateurs inactifs dans l’active directory

Sur un active directory ayant plusieurs années, il est courant que nombreux comptes d’ordinateurs ne soit plus utilisé mais reste présent. Il n’y a pas d’option d’affichage de date de derniere connexion dans la console « utilisateur et ordinateurs active directory » mais heureusement il existe une alternative en ligne de commande:

dsquery computer -inactive 52 | sort

=> vous sortira tout les comptes ordinateur ne s’étant pas connecté depuis 1 an (le chiffre indiquant le nombre de semaine d’inactivité).

idem pour les utilisateurs:

dsquery users -inactive 52 | sort

Forcer un controleur de domaine a « monter » sysvol et netlogon

Parfois, lors d’une migration de serveur, si l’ancien contrôleur de domaine est un peu trop bancal, il se peut que la réplication de l’active directory vers le nouveau serveur échoue, le pire étant que parfois cela se produit sans que l’échec de migration soit réellement visible.

Cela se traduit par le fait que le nouveau contrôleur de domaine ne rentre pas dans ses fonctions en partageant le répertoire SYSVOL et NETLOGON, ce qui, si l’on n’a pas vu le problème avant de descendre l’ancien, mener au désastre de ne plus avoir aucun contrôleur de domaine actif.

La solution… genre kamikaze … Mais parfois pas trop le choix.

copier manuellement le répertoire SYSVOL de l’ancien serveur (ou d’un backup) sur le nouveau serveur
puis dans le registre sur la clef
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters
Mettre la valeur SysVolReady=1
puis rebooter => Le nouveau contrôleur de domaine devrais monter le sysvol et le netlogon.

Il convient alors de vérifier que si les 5 rôles FSMO ont bien été rapatriés ou pas. Et si tel n’est pas le cas, il faut les forcer a migrer avec ntdsutil.

Voir l’état d’une réplication DFS

Le système DFS de Microsoft est particulièrement puissant mais aussi beaucoup trop hermétique
En effet il n’existe pas de console permettant de visualiser clairement la file d’attente ni de voir la progression de la synchronisation entre les différents réplicats.
Heureusement une commande, dont la simplicité est égale à leurs habitudes, existe:

dfsrdiag backlog /ReceivingMember:(nom fqdn du serveur destination) /SendingMember:(nom fqdn du serveur source) /RGName:"(nom de la branche)" /RFName:"(nom du groupe de réplication)"

exemple:

dfsrdiag backlog /ReceivingMember:srv2.reseau.local /SendingMember:srv1.reseau.local /RGName:"reseau.local\partage\dossiers_communs" /RFName:"dossiers_communs"

pour voir l’état de réplication du répertoire dossiers_communs situé dans la racine partage