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€…

 

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

Régénérer les fichiers de stratégie par défaut

Par exemple suite a l’effacement accidentel du dossier Policies ou un dommage sur l’un des fichiers contenu dedans…

J’ai eu l’occasion de voir a plusieurs reprises ce problèmes. Il en résulte un fonctionnement hasardeux du domaine (parce qu’il n’y a plus les réglages effectués par défaut), des centaines, voire des milliers de messages d’erreurs dans les événements… bref le chaos !!!

La meilleur action est la restauration mais malheureusement, beaucoup de PME ne sauvegardent que leurs documents… Donc si on ne dispose pas d’une sauvegarde suivre cette méthode:

1) s’assurer de l’arborescence (et recréer si besoin les dossiers manquants):

 C:\windows\SYSVOL
 C:\windows\SYSVOL\domain
 C:\windows \SYSVOL\staging\domain
 C:\windows \SYSVOL\staging areas
 C:\windows \SYSVOL\domain\Policies
 C:\windows \SYSVOL\domain\scripts
 C:\windows \SYSVOL\SYSVOL

Ensuite il faut recréer les liens symbolique existants avec la commande mklink:

 cd c:\windows\SYSVOL
 mklink /J votrenomdedomainefqdn c:\windows\SYSVOL\domain
 cd "staging areas"
 mklink /J votrenomdedomainefqdn c:\windows\SYSVOL\staging\domain

exemple si votre domaine s’appelle « reseau.local »:

 cd c:\windows\SYSVOL
 mklink /J reseau.local c:\windows\SYSVOL\domain
 cd "staging areas"
 mklink /J reseau.local c:\windows\SYSVOL\staging\domain

ce qui recréera les liens symboliques nécessaires.

Terminez par:

dcgpofix /ignoreschema

Les stratégies systèmes « default domain policies » et « default domain controlers policies » sont recrées.

Récuperer le modèle et le numéro de série d’un ordinateur

Si par exemple lors d’une télémaintenance vous devez récupérer le numéro de série d’un ordinateur, pour faire appel au constructeur ou pour commandé une pièce détachée, il n’est pas toujours évident de demander au client de vous le dicter si vous ne l’avez pas sur la facture de vente. Il existe une façon de l’obtenir en commande msdos:

Pour le modèle:

wmic csproduct get name,vendor,identifyingNumber

Pour le numéro de série

wmic bios get serialnumber

Pour la liste des adresses mac (bien qu’on peu aussi les obtenir avec ipconfig /all)

wmic nic get macaddress,description