Mac OS X ne résout pas les noms d’hôtes .local

Si votre domaine local a un FQDN se terminant par « .local », sur les version 10.10 et supérieur, il est fréquent d’avoir des problème de résolution de nom sous Mac OS X car Apple semble s’être appropriée de ce suffixe et passe la résolution de celle-ci via mDNS (multicast port 5353) et non par DNS (unicast port 53 vers serveur DNS) . Le problème c’est que si votre domaine Windows est construit avec ce suffixe, il est très difficile de le changer.

Pour permettre au mac de résoudre les noms portant ce suffixe, lancer la commande suivant depuis un terminal:

sudo discoveryutil mdnsactivedirectory yes

 

=> Les nom d’hôte se terminant par .local pourront alors être résolus comme les autres.

 

Note: Cette astuce ne fonctionne pas dans la version 10.13 car la commande discoveryutil semble avoir été supprimée ou rendue inaccessible…

 

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