Windows on Zwindler's Reflection

Hack : diminuer la taille du VMDK d’une VM Linux LVM

Wed, 14 Mar 2018 12:45:43 +0000

Réduire un VMDK

Note : cet article n’est pas écrit par moi mais par mon ami et ancien collègue Steve aka ventreachoux85 (ahahah faut assumer maintenant Steve), que j’héberge avec grand plaisir sur le blog :-)

Note 2: Comme toute opération sur des disques, des partitions, des filesystems, elles sont à faire avec des backups préalables. Cette opération est dangereuse et est à vos risques et périls => vous voilà prévenus.

Sur un serveur Linux (CentOS 6.9 pour la petite histoire) hébergé sur un serveur VMware, je souhaite réduire la taille de mon disque virtuel de 75 Go car la volumétrie ne va pas bouger. S’il est simple d’agrandir un disque virtuel sous VMware, le réduire est une autre paire de manches !

Si la machine avait été un serveur Windows, voilà ce que j’aurai fais :

Réduction du volume depuis l’utilitaire de gestion de disques
Modification de l’extent description directement sur le fichier .vmdk depuis l’ESXi (en SSH)
Migration de la VM sur un autre datastore => elle aurait eu la taille voulue à l’issue de l’opération

Je ne détaille volontairement pas cette procédure car celle qui suit est similaire et nous allons prendre le temps de tout voir.

Et donc du coup, là c’était pas pour des windows, mais pour des machines sous Linux ! J’ai demandé son avis à zwindler, qui m’a demandé en échange de rédiger une petite procédure pour le blog ;-)

Réduction du FS

Voilà donc à quoi ressemble les disques de mon serveur avant l’opération :

Dans mon cas, je n’ai pas besoin de réduire les Filesystems, j’ai déjà beaucoup de PE de disponibles. S’il avait fallut le faire, on aurait été obligé de réduire les FS à froid (dans le cas ext*), voire même de passer par un liveCD si on avait du redimensionner « / » ou un autre FS vital pour l’OS.

Réduire un VMDK partitionné pour du LVM

Le problème avec la commande pvs est que la taille utilisée et la taille disponible est arrondie pour être au format « human readable » d’Unix. Idéalement, il nous faut une mesure exacte pour redimensionner au plus juste.

Une des manières simples de le faire est d’utiliser l’unité « secteur » de la commande pvs (512 octets). Il faut faire la différence entre le PSize et le PFree pour avoir la taille définitive du disque :

Après un rapide calcul, si je veux réduire le disque de tous les PE disponibles :

209453056 – 164757504 = 44695552

La nouvelle taille du PV sera de 44965552 secteurs

Note de zwindler : Personnellement j’aurai laissé quelques PE, par habitude (limitations de LVM1 pénibles quand il n’y a plus de PE) et parce que je suis un froussard, mais a priori « ça marche ».

On redimensionne le disque

A noter, malgré le fait qu’on ait spécifié qu’il ne devait pas rester de PE de libre, a priori il en reste quand même quelques uns. Je ne sais pas si c’est une sécurité du pvresize ou si c’est lié aux arrondis et à la taille d’un PE sur ce PV. C’était une erreur de calcul (cf voir les commentaires).

Pour vérifier que tout va bien, un petit pvscan/vgscan.

Réduire la partition

A partir de là, ça se corse. On a réduit sans trop de difficulté le PV qui héberge nos LV, mais il nous reste maintenant à réduire la partition qui héberge ce PV. Même si théoriquement on peut le faire à chaud, zwindler m’a conseillé de faire ça à froid.

Pour autant, si vous vous sentez l’âme d’un aventurier et/ou avec un OS récent et/ou que vous n’avez pas le choix, vous pouvez toujours aller lire ce post sur Ask Ubuntu.

Le plus safe est quand même d’arrêter la VM puis booter sur un liveCD avec GParted.

Clic droit sur la partition à modifier – désactiver (sinon impossible de la redimensionner)

Sélectionner la partition puis Redimensionner / Déplacer

Attention : lors du premier redimensionnement, GParted ne prend ne réduit pas au maximum la partition. Il reste 2 Go qui sont inutilisés.

On lance un nouveau redimensionnement pour récupérer la place disponible !!

Note de zwindler : moi j’aurai laissé comme ça ;-)

ATTENTION

On voit que /dev/sda2 fait 21.44 Go après le pvresize (cf. screenshot précédent). En essayant de réduire au maximum la place utilisée, on peut tout casser (expérience vécue !!!). Pour plus de sécurité, je conseille de resizer à l’entier supérieur (donc dans notre exemple 22 Gio soit 22528 Mio)

Redimensionner le VMDK

Maintenant que le disque est modifié au niveau de l’OS, il faut le redimensionner au niveau de VMware.

Et là, rebelote : c’est pas « simple » à faire. En effet, VMware ne supporte pas la réduction des VMDK (que ce soit à chaud ou à froid).

Note: You cannot shrink virtual disks using vmkfstools in ESXi as the hypervisor is not aware of the file system layout and cannot ensure a safe shrink operation.

Heureusement, des petits malins ont trouvés la technique depuis bien longtemps :

Se connecter en SSH sur l’ESX qui héberge la VM, se rendre dans le dossier de la VM et faire un vi sur le fichier NomVM.vmdk, qui est un fichier texte (configuration), contrairement au fichier NomVM-flat.vmdk qui contient les données réelles.
Modifier la valeur suivante :

# Extent description
RW 209715200 VMFS "testsba-flat.vmdk"

La nouvelle valeur du paramètre extent description sera « 22 GB = 22 x 1024 x 1024 x 1024 / 512 (octets/secteur) = 46137344 secteurs »

# Extent description
RW 46137344 VMFS "testsba-flat.vmdk"

Déplacer la VM vers un autre Datastore

A partir de là, vous vous dites : « cool ! j’ai récupéré l’espace disque ». Et vous êtes déçus car rien ne se passe.

En effet, ce paramètre n’est pris en compte que lors de la création du disque, lorsque le fichier contenant réellement les données (le fameux NomVM-flat.vmdk dont je vous ai parlé plus tôt) est créé. Vous pouvez mettre n’importe quoi, ça ne changera rien du tout.

Cependant, si vous avez la licence qui va bien sur votre cluster, vous pouvez feinter le cluster pour lui faire recréer un disque à chaud de la bonne taille avec un simple Storage vMotion.

Avant le Storage vMotion :

Après le Storage vMotion :

Pourquoi ça marche ?

Petit aparté de zwindler : Pour bien comprendre ce qu’il se passe, il faut comprendre comment marche un Storage vMotion. Au moment où vous demandez à VMware de déplacer un disque d’un datastore à l’autre, voici l’enchaînement des opérations :

Prise d’un snapshot du disque initial
Création d’un disque sur le datastore cible. Ce disque est identique au disque initial au moment du snapshot via la commande vmkfstools. Cette commande relis la valeur contenu dans extent description pour savoir quelle taille le fichier doit faire physiquement, ce qui nous permet de feinter VMware et d’avoir un disque à la bonne taille._
_
L’ensemble des IO depuis le snapshot sont écrites simultanément sur les deux datastores, ce qui permet d’avoir 2 copies identiques au moment de la fin de la copie du snapshot
Migration de la VM sur le nouveau disque
Suppression de l’ancien disque hébergé par l’ancien datastore

Note de zwindler : j’étais persuadé d’avoir fais un article là dessus (et en fait pas du tout) mais il est évidemment possible de faire la même chose à la main sans Storage vMotion, simplement avec vmkfstools à la main.

Boot de la machine

Pour finir, une fois la VM bootée, il reste encore une petite opération de maintenance à réaliser. Il y a une petite différence de nombre de secteurs suite au redimensionnement.

Il suffit de faire un pvresize avec le nombre de secteurs indiqué par la commande pvs précédente :

Tout est dorénavant OK :

Déployer des VM VMware avec Ansible – part 2

Tue, 14 Nov 2017 12:45:27 +0000

Où est ce qu’on en était ?

La dernière fois qu’on a parlé de [machines virtuelles déployées à l’aide d’Ansible sur une infrastructure VMware][1], on avait un playbook fonctionnel, mais il me manquait encore un petit quelque chose.

En fait, à l’issue du déploiement de la VM, je n’avais pas encore trouvé la possibilité d’enchaîner sur l’exécution d’autres playbooks permettant de configurer la VM. L’objectif ultime étant de faire en une seule étape de :

déployer la VM (que j’appellerai « déploiement »)
et de la configurer, c’est à dire modifier les fichiers de configuration de la VM, installer les logiciels, etc… (que j’appellerai « configuration »).

Premier problème, connection:local

Pour rappel, le premier problème quand on veut déployer une VM qui n’existe pas encore… est justement le fait qu’elle n’existe pas encore !

Si j’exécute un playbook deploy_vm.yml sur une VM « ma-vm » tel quel, je vais me prendre un message d’erreur (pour plus de détails, lire l’article précédent) car Ansible tente de se connecter à la machine pour récupérer des informations sur elle.

La méthode pour s’affranchir de ce genre de problèmes est de feinter Ansible en lui disant :

de ne pas récupérer les informations de la machine
d’exécuter le playbook sur une autre machine (le plus simple c’est localhost)

Pour le premier point, la solution est mettre en haut du playbook l’option gather_facts: false. Cela aura un impact mais on verra ça plus loin.

Pour le second point, il existe 2 solutions. La première, que je préconisais dans l’article précédent, consiste à utiliser en haut du playbook l’option connection: local. Cette option permet d’exécuter l’ensemble du playbook sur la machine locale et non pas la machine qu’on déploie.

En réalité, il est en fait plus simple d’utiliser l’option delegate_to, qui se limite à une seule tâche ou à un rôle, ce qui permet de déléguer la partie déploiement à localhost, puis tenter d’exécuter les autres playbooks sur la VM qu’on veut configurer.

Un problème de nom … pas si facile à résoudre

Vous avez vu le jeu de mot ? Ok, je sors…

Bien sûr, on va se heurter à plusieurs problèmes… Le premier est la résolution de nom. A moins d’avoir réalisé la mise à jour de votre DNS à l’avance (à la main du coup… c’est nul), dès que le déploiement sera terminé et qu’on passera à la partie configuration de la VM, Ansible essayera de contacter votre nouveau serveur.

Le plus propre serait d’ajouter à la partie « déploiement » une tâche permettant de mettre à jour le DNS. Dans mon environnement professionnel, le service DNS est géré par un serveur Windows Active Directory. La simple mise à jour du DNS depuis Linux est un vrai casse tête et le plus simple est d’intégrer la machine (qu’elle soit Windows ou Linux) dans le domaine Active Directory qui se charge alors de mettre à jour le DNS lui même.

C’est un gros sujet et je ferai un article à part dessus. Dans un premier temps on peut se contenter de juste mettre à jour le fichier /etc/hosts de la machine localhost.

- name: add to /etc/hosts file
lineinfile:
dest: /etc/hosts
line: '{{ custom_ip }} {{ inventory_hostname }} {{ inventory_hostname }}.zwindler.fr'
with_items: '{{play_hosts}}'
when: "hostvars[item].inventory_hostname == inventory_hostname"
delegate_to: localhost

Accès concurrents

Si vous vous y connaissez un peu en Ansible, vous remarquerez que je ne me suis pas contenté d’un simple lineinfile, mais que j’ai utilisé un with_items et un when.

En fait, on peut utiliser mon playbook pour déployer en parallèle un grand nombre de VMs en même temps. Le souci que j’ai rapidement eu a été un accès concurrent sur le fichier, et des noms de VMs ont alors manqué.

Il existe une fonction « serial » qui permet de désactiver la parallélisation des tâches, mais malheureusement, on ne peut l’appliquer qu’au playbook entier. Peut être qu’un jour la fonctionnalité sera ajoutée (la demande est référencée sur Github)

J’ai donc du passer par une boucle pour enregistrer tous les serveurs du play courant.

Clé SSH

OK, maintenant, on sait résoudre la (ou les) machine(s) qu’on vient d’ajouter. Cependant on est pas sorti de l’auberge !

En partant du principe que vous n’avez pas oublié de déposer la clé SSH du serveur localhost pour qu’Ansible puisse se connecter sur votre nouvelle machine, voilà ce qui va se passer :

TASK [gather facts] *************************************************************************************************************************************************************************
The authenticity of host 'zwindler01 (x.x.x.x)' can't be established.
Are you sure you want to continue connecting (yes/no)? The authenticity of host 'zwindler02 (x.x.x.x)' can't be established.
Are you sure you want to continue connecting (yes/no)? The authenticity of host 'zwindler03 (x.x.x.x)' can't be established.

Ansible bloque à la première connexion SSH vers votre VM nouvellement crée car il faut accepter l’empreinte de chaque VM manuellement au préalable. Même si on essaye de renseigner yes à toutes les questions, ce n’est clairement pas idéal et encore moins automatisé !

La solution temporaire, host_key_checking=False

Il existe un paramètre dans Ansible qui permet de passer outre la vérification de l’empreinte de la machine, soit en modifiant le fichier de configuration ansible.cfg, soit ajouter un flag à l’exécution de playbook, soit configurer une variable d’environnement.

ansible-playbook -l zwindler* -i hosts_deploy -e 'host_key_checking=False' deploy_vmware_guest.yml
#OU
export ANSIBLE_HOST_KEY_CHECKING=False
ansible-playbook -l zwindler* -i hosts_deploy deploy_vmware_guest.yml

Vous trouverez plus d’informations sur cette solution de contournement sur les sites suivants :

Cette solution de contournement est à proscrire en production, car elle va ignorer l’empreinte de TOUTES les machines et pour TOUS vos playbooks. Au delà du problème évident de sécurité que ça pose, si vous enlevez l’option à un moment donné, c’est retour à la case départ. Vous aurez de nouveau la question sur tous les serveurs dont vous n’avez pas explicitement accepté l’empreinte.

ssh-keyscan à la rescousse

On va donc ajouter la tâche suivante à notre playbook de déploiement :

- name: accept new ssh fingerprints
shell: ssh-keyscan {{ custom_ip }},{{inventory_hostname}} >> ~/.ssh/known_hosts
with_items: '{{play_hosts}}'
when: "hostvars[item].inventory_hostname == inventory_hostname"
delegate_to: localhost

Je sais… c’est terrible : la solution que j’ai à l’heure actuelle, bien que fonctionnelle, N’EST PAS IDEMPOTENTE… :-( mais elle fonctionne.

Et on fini par un petit setup pour récupérer les facts.

- name: gather facts
setup:

Et maintenant ?

Et bien ! Maintenant, ça marche ! Vous pouvez enchainer d’autres tâches (ou des rôles) en ne mettant plus delegate_to, et ces tâches de « configuration » seront bien lancées sur le serveur que vous venez de déployer, dans un seul et même playbook.

---
- hosts: all
gather_facts: false
vars_prompt:
- name: "vsphere_password"
prompt: "vSphere Password"
- name: "esxi_host"
promt: "ESXi host"
private: no
- name: "notes"
prompt: "VM notes"
private: no
default: "Deployed with ansible"
roles:
- deploy_vmware_guest
- other_role_for_configuration

Pari réussi !

Et le playbook, il est où ?

Une fois de plus, je suis sympa, je vous donne un exemple de code sur mon Github !

Problème de pointeur souris sur la console dans OracleVM 3.4

Thu, 09 Feb 2017 13:00:44 +0000

OracleVM, quelques faiblesses sur la console, comme les autres…

Dans la série des articles sur OracleVM avant que je n’en reparle plus (le PoC est ~~terminé~~ enterré chez nous), voici un petit retour sur un des problèmes que j’ai pu rencontrer.

Comme beaucoup de technologies de visualisation d’écrans consoles pas totalement maîtrisées (ça vaut pour les vieux ILO en Java ou autres : que de bons souvenirs), le pointeur de la souris fait littéralement n’importe quoi. Généralement c’est décalé mais pas de manière linéaire sur tout l’écran pour bien qu’on se marre.

Crédits : GameDev.net

Le problème vient du client web VNC proposé par Oracle VM Manager et est un problème archi-connu mais pour autant pas totalement résolu.

Accéder directement au flux VNC

Comme je l’explique juste avant, il arrive couramment que les technologies de virtualisations intégrées vers l’écran (virtuel) de la machine virtuelle soient mal calibrées. Mais c’est encore plus courant lorsque ce déport d’écran est réalisé avec un connexion VNC elle même affichée dans une console HTTP.

Un moyen de contourner le problème de ce type de clients VNC web (et ça vaut pour d’autres outils qui utilisent les mêmes techniques) est de simplement se « brancher » sur le flux VNC sans passer par la console web. A priori sur les versions précédentes de OVMM, il était possible de se brancher directement sur le flux VNC, tout simplement parce que le serveur VNC était en écoute sur l’interface LAN.

Au delà du fait que ce soit du bidouillage, cette technique n’est aujourd’hui plus permise depuis OVMM 3 et il faut donc … bidouiller encore plus ! Voici ce que propose le support d’Oracle :

You can redirect the remote port to local using the ssh(1) command. For example, the VM guest vnc port is 5900 on Oracle VM Server and listening on localhost:

# xm list -l 2|grep 59
(location 127.0.0.1:5900)

Then you can run this to redirect the port to your desktop:

$ ssh -L 12345:localhost:5900 root@OVS

The « 5900 » port will be redirected to « 12345 » of your local desktop, so that you can run the following command to connect the guest console:

$ vncviewer localhost:12345

En gros, ce qu’il faut en comprendre, c’est que le serveur VNC n’est maintenant plus disponible depuis autre part que localhost et qu’on peut contourner la limitation en faisant un tunnel SSH. Rien de bien sorcier, mais est ce qu’il n’y a pas un peu plus simple ?

La vraie solution

En fait si.

Au début, je n’ai même pas cherché à appliquer cette solution car elle ne s’applique normalement que pour les machines virtuelles Windows.

Si vous avez un problème du type de celui que je décris sur une VM Windows, on vous conseille chez Oracle d’ajouter un paramètre à la machine virtuelle qui permet de mieux suivre les mouvements de la souris.

Add below your config to force the device model to use absolute (tablet) coordinates:

usbdevice=’tablet’

Mais sur le papier, la solution est bien indiquée « For Windows virtual machines (guests) ». Mon problème moi, c’était sur les machines virtuelles CentOS, indiquées comme pas impactées par ce genre de problèmes.

Bon j’ai bien compris ou tu veux en venir. Comment on modifie ce paramètre ?

En fait, c’est TRES mal indiqué dans la documentation. Il s’agit de la configuration de la machine virtuelle, VM éteinte, mais où faire la modification ? Ahah ! Mystère !

La documentation fait elle état d’un fichier de configuration de la machine virtuelle mais je n’ai pas su trouver ce fichier. Cependant, et ce n’était pas dit dans la documentation on peut modifier ce paramètre directement depuis la GUI de Oracle VM Manager !

Dans les paramètres de la machine virtuelle, dans l’onglet Configuration, on trouve le paramètre Mouse Device Type. Sur les machines Windows, comme le problème est connu, il me semble d’ailleurs que le paramètre est passé à « tablet » par défaut.

Une fois validé, on peut vérifier que cette configuration a effectivement été modifiée en affichant ce fameux VM Config File que je ne sais pas où trouver :

A partir de là, la souris ne devrait plus vous faire de blagues. Même si avec Oracle VM, on ne sait jamais trop ;-) #Troll

Source

Administrer des serveurs Windows avec Ansible

Tue, 15 Nov 2016 13:00:11 +0000

Ansible sur Windows

Depuis que j’ai découvert Ansible, ma vie d’Ops a changée.

Tout doit pouvoir être géré par Ansible. Tous les playbooks doivent être idempotent (je reviendrais la dessus très probablement). Et du coup, ça vaut aussi pour les serveurs Windows qu’il nous reste !

Il n’existe pas encore de version compatible Windows pour l’exécution locale des playbooks. Cependant, il existe tout de même des modules pour administrer via PowerShell remoting des serveur Windows.

La liste des modules pour Windows est disponible sur cette page. La plupart ne sont pas intégrés au cœur d’Ansible mais font partis des extra-modules.

Prérequis côté serveur

Configuration de base (connexion distante avec des comptes locaux)

Il est nécessaire d’installer un module Python permettant la connexion aux Windows via PowerShell sur le serveur Linux qui servira a exécuter les playbooks.

pip install "pywinrm>=0.1.1"

Configuration Kerberos (connexion distante avec des comptes de domaine AD)

La configuration de base ne permet pas d’utiliser des comptes de domaine. Dans un environnement d’entreprise, la plupart des serveurs Windows sont intégrés à un domaine Active Directory.

Il est donc intéressant d’installer les clients kerberos qui permettront au serveur Linux avec Ansible de s’authentifier sur un domaine AD.

yum -y install python-devel krb5-devel krb5-libs krb5-workstation
pip install kerberos

On peut ensuite configurer le fichier /etc/krb5.conf en fonction du contexte. Voici les variables à renseigner :

[...]
[realms]
ZWINDLER.INFO = {
kdc = dc01.zwindler.info
kdc = dc02.zwindler.info
kdc = dc03.zwindler.info
}
[domain_realm]
.zwindler.info = ZWINDLER.INFO

On peut tester que la configuration fonctionne avec la commande kinit

kinit zwindler@ZWINDLER.INFO
Password for zwindler@ZWINDLER.INFO:

ATTENTION : Il faut obligatoirement donner le nom du domaine en majuscules, et indiquer le nom complet du domaine et pas le nom Netbios. Ca vaut pour le fichier de configuration krb5.conf ET lors de l’appel de la commande kinit.

La commande ne doit pas retourner d’erreur et on peut vérifier que tout fonctionne avec la commande klist

klist
Default principal: zwindler@ZWINDLER.INFO
Valid starting Expires Service principal
23/08/2016 15:15:33 24/08/2016 01:15:33 krbtgt/ZWINDLER.INFO@ZWINDLER.INFO
renew until 30/08/2016 15:15:30

Ajout d’un serveur Windows

Méthode 1 : Compte local, variables de connexion dans un fichier chiffré

A la différence d’Ansible sous Linux où l’authentification peut se faire sans mot de passe à l’aide de certificats, sous Windows, il sera nécessaire de stocker à un moment donné le mot de passe d’un compte qui pourra se connecter sur les serveurs Windows.

On ajoute d’abord les serveurs windows dans le fichiers hosts dans un groupe séparé

[zwindler_windows_prod]
antivirus
wsus
[zwindler_prod:children]
zwindler_ansible_prod
zwindler_linux_prod
zwindler_windows_prod
[zwindler_windows:children]
zwindler_windows_prod

On sécurise l’accès au fichier des variables qui contiendra les comptes d’accès aux machines Windows avec l’utilitaire ansible-vault. Le fichier ne pourra alors être lu/édité qu’avec le mot de passe.

ansible-vault create group_vars/zwindler_windows.yml
New Vault password:
cat group_vars/zwindler_windows.yml
$ANSIBLE_VAULT;1.1;AES256
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
1111
ansible-vault edit group_vars/zwindler_windows.yml
Vault password:
---
ansible_user: local_admin
ansible_password: xxxxxxxx
ansible_port: 5986
ansible_connection: winrm
#Decommenter si vous utiliser Python 2.7.9+ et des certificats WinRM autosignes (defaut)
#ansible_winrm_server_cert_validation: ignore

Comme les serveurs qui ont été ajoutés dans le groupe zwindler_windows_prod héritent des variables définies pour zwindler_windows dans group_vars/zwindler_windows.yml, Ansible les utilisera pour s’y connecter.

Méthode 2 : utiliser kinit pour la connexion

Plutôt que d’utiliser un compte local et stocker le mot de passe dans des variables (de préférence chiffré donc) mais quand même devoir taper le mode de passe du vault à chaque fois, il est possible d’utiliser le binaire kinit pour gérer l’authentification AD via un ticket Kerberos.

# kinit domain_admin@ZWINDLER.INFO
Password for domain_admin@ZWINDLER.INFO:
# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_B82OOxI
Default principal: domain_admin@ZWINDLER.INFO
Valid starting Expires Service principal
23/08/2016 16:37:37 24/08/2016 02:37:37 krbtgt/ZWINDLER.INFO@ZWINDLER.INFO
renew until 30/08/2016 16:36:57

Cependant ce n’est pas suffisant. Pour que l’authentification Kerberos soit tentée par Ansible, il est tout même nécessaire que les variables ansible_user, ansible_port et ansible_connection soient renseignées (bizarrement…).

On doit dont créer un fichier de variable similaire à celui de la méthode précédente, mais sans pour autant nécessiter de le chiffrer puisqu’on ne stockera pas le mot de passe.

vi group_vars/zwindler_windows.yml
---
ansible_user: auth@by.kerberos
ansible_port: 5986
ansible_connection: winrm
#Decommenter si vous utiliser Python 2.7.9+ et des certificats WinRM autosignes (defaut)
#ansible_winrm_server_cert_validation: ignore

A noter, la valeur ansible_user n’est pas du tout utilisée. C’est écrit sur le site d’Ansible :

Ansible will first attempt Kerberos authentication. This method uses the principal you are authenticated to Kerberos with on the control machine and not ‘ansible_user’.

Prérequis côté client

Pour pouvoir se connecter il est également nécessaire de réaliser des modifications sur les serveurs que l’on souhaite administrer avec Ansible.

La commande win_ping permet de vérifier la connectivité avec les serveurs Windows. Ici la commande échoue car l’exécution de commande PowerShell à distance nécessite l’autorisation explicite sur l’ensemble des serveurs concernés.

ansible wsus03 -m win_ping --ask-vault-pass
Vault password:
wsus03 | UNREACHABLE! => {
"changed": false,
"msg": "kerberos: 500 WinRMTransport. [Errno 111] Connection refused, ssl: 500 WinRMTransport. [Errno 111] Connection refused",
"unreachable": true
}

De plus, les serveurs dont le pare-feu est activés doivent laisser passer les connexions vers le port 5986 défini dans le fichier group_vars/zwindler_windows.yml

Powershell 3 (pour Windows 2008)

Sur les serveurs antérieurs à Windows 2012, seul Powershell 2 est installé et c’est Powershell 3 qu’il faut !

Ansible fournit un script pour aider à l’installation si la machine a accès à Internet

powershell https://raw.githubusercontent.com/cchurch/ansible/devel/examples/scripts/upgrade_to_ps3.ps1

(Optionnel) ajouter une exception au pare-feu pour le port 5986

Cette exception n’est plus nécessaire car le script Ansible qui suit l’ajoute de lui même. Cependant si vous souhaitez gérer cela vous même, voici quoi faire.

Se connecter sur le serveur, puis lancer un prompt Powershell avec les droits administrateurs

netsh advfirewall firewall add rule name="WinRM pour Ansible" dir=in localport=5986 protocol=TCP action=allow

Autoriser Ansible à réaliser des actions à distance (WinRM)

Récupérer le script disponible sur la branch « devel » et l’exécuter sur le serveur en question via un prompt Powershell administrateur.

github.com/ansible/ansible-documentation/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1

Autoriser l’exécution de script Powershell si nécessaire.

Set-ExecutionPolicy Unrestricted

Tests et troubleshooting

ansible wsus03 -m win_ping --ask-vault-pass
Vault password:
wsus03 | SUCCESS => {
"changed": false,
"ping": "pong"
}

Dans le cas où on souhaite réinitialiser les tickets kerberos pour valider le bon fonctionnement, on peut utiliser les commandes klist et kdestroy

klist
Ticket cache: KEYRING:persistent:0:krb_ccache_B82OOxI
Default principal: domain_admin@ZWINDLER.INFO
Valid starting Expires Service principal
23/08/2016 16:38:45 24/08/2016 02:37:37 HTTP/wsus03.zwindler.info@ZWINDLER.INFO
renew until 30/08/2016 16:36:57
23/08/2016 16:37:37 24/08/2016 02:37:37 krbtgt/ZWINDLER.INFO@ZWINDLER.INFO
renew until 30/08/2016 16:36:57
kdestroy -A
klist

Have fun !

Sources

[Tutoriel] Installation d’Oracle VM for x86 – partie 2

Tue, 18 Oct 2016 12:00:57 +0000

Cet article fait suite à l’article Installation d’Oracle VM for x86 - partie 1 dans lequel j’ai introduis Oracle VM et installé la console de management Oracle VM Manager. Je vous conseille de commencer par là ;-).

Connexion du serveur Oracle VM avec la console OVMM

Maintenant que la console OVMM est opérationnelle et qu’on a pu s’y connecter, on remarque que les menus sont assez intuitifs bien qu’un peu austères !

Un onglet Health donne l’état général de la plateforme, puis les autres onglets permettent de configurer les différents aspects attendus d’une console d’administration de virtualisation x86.

La première étape pour nous est donc bien entendu d’ajouter dans OVMM le serveur Oracle VM préalablement installé, au même titre qu’on pourrait le faire avec un ESXi dans un vCenter.

Hormis les icônes pas forcément très parlantes, le menu de « découverte » de nouveaux serveurs est très simple. On a juste besoin de l’IP et du compte OVM Agent créé lors du déploiement de l’ISO d’installation.

En bas de l’écran, un bandeau vous donne l’état des dernières opérations déclenchées sur le cluster.

Un bref coup d’œil permet de voir que le serveur est bien ajouté. Des informations sur sa configuration s’affichent.

Créer un groupe de serveurs « server pool »

Vous aurez peut être remarqué que votre serveur de virtualisation a été ajouté dans le groupe de serveurs « Unassigned ». Intellectuellement ça me gène, et j’ai donc voulu créer un groupe de serveurs, pour « faire propre ».

Au delà de ça, c’est notamment via la création de ces groupes (clusters dans VMware) que l’on peut gérer la haute disponibilité et les clusters de machines. C’est donc plutôt important ;-).

Ce groupe peut se créer via l’icône située juste à droite de celle sur laquelle nous avons cliqué pour « découvrir » le serveur Oracle VM.

Cependant, lorsque j’ai tenté de créer mon groupe de serveurs, j’ai reçu l’erreur suivante :

OVMAPI_4010E Attempt to send command: create_server_pool to server: lab01 failed.
OVMAPI_4004E Sync command failed on server: x.x.x.32.
Command: create_server_pool, Server error: org.apache.xmlrpc.XmlRpcException: <type 'exceptions.Exception'>:
Invalid hostname resolution: lab01 -> 127.0.0.1 [Wed Jul 20 16:30:40 CEST 2016]

Lors de l’installation automatique de l’ISO Oracle VM, le hostname lab01 a été ajouté par défaut dans le fichier /etc/hosts. Or, ceci pose problème.

Connectez vous en SSH sur le serveur et retirez le hostname (ici lab01) du fichier /etc/hosts :

vi /etc/hosts
127.0.0.1 lab01 localhost localhost.localdomain localhost4 localhost4.localdomain4

Création de pools de stockage

La seconde opération consiste à ajouter du stockage au cluster.

Avec Oracle VM, on peut utiliser du stockage local via des disques inutilisés. La procédure est détaillée à l’adresse suivante.

On peut également découvrir des cibles iSCSI ou éventuellement utiliser l’espace disponible sur le filesystem local. Pour ce dernier choix, l’espace ne sera cependant bien entendu uniquement visible depuis le serveur local uniquement.

Pour l’exemple, j’ai créé un disque de test de 200 Go sur un NAS Windows.

La procédure est la suivante. On commence par ouvrir l’onglet « Storage ». Dans SAN Servers, il n’y a encore aucun serveur déclaré. Au même titre que pour le serveur de virtualisation, il y a un bouton « Discover SAN Server ».

On peut déclarer un ou plusieurs hôtes, avec ou non de l’authentification. J’ai rarement vu des contextes où l’authentification CHAP (côté client ou serveur) était activée, mais je trouve ça bien en production. Pour autant, dans le cas du PoC je n’en ai pas mis.

Editer les access groups

Et enfin, on ajoute les serveurs qui peuvent avoir accès aux périphériques de stockage. Ici lab01.

Cliquer sur Finish pour valider.

Dans mon cas, juste avec la configuration de cet article, je suis tombé sur l’erreur suivante. A l’écran d’avant j’avais loupé la modification des access groups et en particulier l’onglet storage initiators. Si vous avez une erreur, c’est surement le même problème.

Le stockage nouvellement intégré apparait maintenant avec les volumes disponibles

Créer des repositories pour stocker des images

Une fois les périphériques de stockage déclarés auprès de vos serveurs de virtualisation, on peut maintenant créer des pools appelés repositories.

L’ensemble des opérations qui suivent sont a effectuer dans l’onglet Repositories. Ces pools logiques de stockage vous permettent de stocker vos fichiers ISO, mais aussi vos templates et vos disques durs virtuels pour vos machines virtuelles. Sur VMware on parlerait de Datastores.

Avec le disque local

Comme indiqué précédemment, ce type de stockage aura l’inconvénient de n’être accessible que d’une seule machine. Cependant c’est le plus simple à utiliser.

Cliquer sur le logo « + » pour créer un nouveau repository.

On doit d’abord renseigner quelques informations descriptives et d’appartenance.

Enfin, on sélectionne le disque (Physical Disk) sur lequel placer le repository.

La dernière étape consiste à ajouter les serveurs qui verront ce stockage. Dans ce cas précis, seul lab01 pourra le voir.

Après validation, le nouveau repository apparait dans la liste des repositories.

Avec le disque SAN

Le principe est le même pour les disques SAN, à ceci près que celui ci pourra bien être partagé entre plusieurs serveurs d’un même cluster (pour peu que les serveurs concernés aient bien été autorisés à voir ce stockage lors de l’étape précédente).

Gestion du réseau

Vous l’aurez deviné, pour la gestion du réseau, tout se passe dans l’onglet « Network » de la console OVMM.

Petite subtilité, par défaut, le réseau de management ne peut pas être utilisé par les VMs. Vous ne pourrez donc pas affecter de réseaux virtuels aux machines virtuelles en l’état actuel des choses.

Dans mon cas (PoC), je ne souhaite pas créer un nouveau réseau pour me simplifier la vie, et j’ai donc ajouté « Virtual Machine » au réseau de management créé par défaut lors de l’installation du serveur OracleVM.

Dans un contexte de production, on préfèrera en ajouter un nouveau et lui affecter des interfaces réseaux et des VLANs (comme on le ferait sur VMware ou RHEV).

Créer une nouvelle VM

Maintenant que les aspects stockage et réseau ont été réglés, on peut enfin créer une machine virtuelle. La documentation officielle donne quelques informations utiles sur le sujet.

Le début de la création de machine virtuelle est similaire à n’importe quel outil de virtualisation.

HVM, HVM + PV, PVM

Cependant, par rapport aux autres hyperviseurs (full virtualisation vs paravirtualisation, différences que j’aborde dans cet article), Xen et donc OracleVM apporte une subtilité dans la méthode de virtualiser : la paravirtualisation (PVM). On a le choix entre HVM, HVM + PV et PVM.

En réalité il s’agit de :

Xen HVM: Hardware virtualization, or fully virtualized
Xen HVM, PV Drivers: Identical to Xen HVM, but with additional paravirtualized drivers for improved performance
Xen PVM: Paravirtualized

En théorie, vous aurez donc de meilleures performances lorsque vous disposerez d’un OS capable d’être paravirtualisé (mode Xen PVM) que lorsque vous aurez une HVM.

Ça c’est la théorie. En fait en pratique, certains OS, même Linux, seront plus performants en HVM + PV selon Oracle. Pour plus d’informations, voir la page de documentation officielle qui traite du sujet

La liste des OS supporté pour chaque mode est disponible dans les release notes.

Créer des interfaces virtuelles

La seconde étape du wizard permet de configurer les interfaces virtuelles et les réseaux qui y sont associés.

Ajouter des disques virtuels

L’étape d’après permet de configurer les différents périphériques qui sont associés à la VM. Dans le cas du disque dur virtuel, il faut le créer ou en réutiliser un existant.

Lorsqu’on clique sur le « + », on peut créer un nouveau disque virtuel qui sera stocké sur le repository choisi.

Enfin, on peut affecter ou non les différents périphériques éligibles à la séquence de boot et les ordonner.

Une fois la VM créée, on peut la démarrer et ouvrir sa console.

Boot

Dans l’état actuel des choses, la VM démarre mais n’a aucun disque bootable (CD ou HDD). En effet, il faut monter un ISO sur la VM, mais pour ça on doit l’uploader dans un premier temps sur un des repositories précédemment créés.

A priori, dans le menu d’import du repository, on ne peut uploader que des ISO depuis un partage web HTTP. Une solution alternative probable est que l’on peut simplement aller déposer le fichier en SSH mais je trouve que clairement il manque une fonctionnalité à la console d’upload en directe depuis un navigateur !

Une fois qu’on dispose d’un ISO pour booter notre VM, on peut éditer la machine virtuelle et y ajouter l’ISO.

On redémarre la machine virtuelle qui boote sur l’ISO comme souhaité.

Sources

Mise à jour Windows 10 pour les professionnels : gratuit ou payant ?

Thu, 23 Jun 2016 11:30:06 +0000

A l’approche de la fin du compte à rebours (prévue pour le 29 juillet 2016) de la promotion de Microsoft pour Windows 10 qui permet aux propriétaires de licences Windows 7 et Windows 8, la question est relancée :

Est ce que seuls les particuliers sont concernés par la promotions Windows 10 ou est ce que les professionnels peuvent aussi en profiter ?

L’origine

Revenons un peu en arrière.

Fin janvier 2015, c’est l’effervescence. Microsoft vient d’annoncer à la surprise générale que les possesseurs de licences Windows à partir de la version 7 auraient droit à une mise à jour gratuite pendant un an de leur système vers Windows 10.

Rétrospectivement, c’est assez malin de la part de Microsoft, après une mort de Windows XP dans la douleur, entre autre provoquée par un Vista détesté qui a fait camper beaucoup d’utilisateurs (et de professionnels) sur leurs positions. La décision est saluée et tout le monde a hâte (sauf les libristes).

Mais rapidement, des questions existentielles secouent la bloguosphère, la twittosphère, … : Dans quel conditions ? Est ce que les licences « pirates » seront concernées ? Et Windows phone ? Et Windows RT ?

Et les pro ???

C’est la panique, tout le monde informatique ne parle plus que de ça ;-).

La confusion

Rapidement, Microsoft met les points sur les I. Les versions concernées sont Windows 7 Home et Pro et Windows 8.1 Home et Pro. Les détenteurs de Windows 8 devront migrer préalablement vers Windows 8.1. Toutes les autres licences ne sont pas concernées : RT, Mediacenter et donc … Entreprise.

Deuxième vent de panique. Le plutôt sérieux Monde Informatique (loin d’être une exception) titre alors Windows 10 ne sera pas gratuit pour les entreprises 11111!!!!1!!

On y lit même

Pour les entreprises en revanche, c’est la douche froide. Ou tout du moins un dur retour à la réalité. Car la firme de Redmond a fait savoir dans un blog daté de vendredi que la gratuité de la mise à jour vers Windows 10 ne sera pas de la partie.

Ça me fait encore rire.

Pour autant, Le Monde Informatique et tous les autres n’ont pas écrit d’erreurs à proprement parler (ou alors ils l’ont corrigé). Le version Entreprise des OS Windows (tout comme RT) ne seront bien pas gratuitement mises à jour.

Cependant, il faut savoir que ces versions Entreprise, spéciales, sont bien à distinguer des versions Home et Pro qui sont livrées avec nos PC. Ces versions sont souvent acquises par les très grands groupes, notamment dans le cadre d’une souscription « Software assurance ». Une rente annuelle pour Microsoft que vous payez au volume et qui vous donne bien évidemment le droit d’accéder aux nouvelles versions lorsqu’elles sortent.

Et donc ?

Ainsi, les personnes ayant acquis des Windows 7 ou 8 Entreprise payent donc probablement de manière annuelle un volume de licence. Si leurs cotisations sont à jour elles peuvent donc gratuitement mettre à jour leur parc vers les nouvelles versions de Windows et donc vers Windows 10, puisque c’est inclus dans leur contrat. C’est pareil pour l’ensemble des logiciels édités par Microsoft, dont les Windows Server par exemple.

Pour les autres, que ce soient des particuliers, des PME ou même de plus grosses entreprises, qui ont des licences Windows Home ou Pro, soit acquises séparément du terminal, soit achetée avec, la promotion est bien applicable (tant que vous migrez avant la fin du compte à rebours bien sûr !).

Amis professionnels, vous pouvez donc vous rassurer et faire la mise à jour vers Windows 10 gratuitement si vous le souhaitez sans vous mettre hors la loi ;-).

Quelques lectures complémentaires pour vous rassurer :

Une erreur grave s’est produite lors de l’exécution de sysprep sur l’ordinateur

Sat, 05 Mar 2016 13:00:52 +0000

Dépassement du nombre de sysprep autorisé

A force d’(ab)user de virtualisation de serveurs, on prend forcément gout aux fonctionnalités offertes par l’infrastructure. Hormis VMware qui fait encore payer les templates (tacle gratuit, même si on peut s’en sortir comme ceci), la plupart des éditeurs d’hyperviseurs proposent gratuitement la fonctionnalité qui permet, à partir d’une machine virtuelle existante, de créer un modèle qui servira de socle pour les déploiement futurs.

On gagnera un temps fou en s’évitant l’installation de l’OS à chaque fois (même si ça s’automatise d’autres façons je l’accorde) et surtout à toujours reparametrer les mêmes choses comme les DNS, le NTP, le client de supervision, …

Ça marchera plutôt bien sur vos bons vieux Linux (sauf dans pour la gestion du réseau CentOS/RHEL6, corrigé en 7), mais Microsoft, lui, ne l’entendra pas de cette oreille !

Lorsque vous déployez un serveur ou un poste de travail sous Windows, vous êtes limités dans le nombre de sysprep consécutifs que vous pouvez exécuter pour réinitialiser les variables de types SID dans le registre de la machine.

Or, pour des raisons de stabilité et de sécurité, de nombreux administrateurs réalisent un sysprep une fois que leur template est terminé, ce qui permet de réinitialiser le SID du modèle, ce qui rendra par la suite la future VM unique au moment de son déploiement. Et si vous modifiez régulièrement vos templates, la limite peut arriver vite.

L’erreur et sa solution

Lorsque l’on déploie une image sur un poste ou un serveur et qu’on reçoit le message d’erreur suivant :

Une erreur grave s’est produite lors de l’exécution de sysprep sur l’ordinateur

A fatal error occurred while trying to sysprep the machine

La procédure pour contourner le compteur de Microsoft se passe en plusieurs étapes.

Regedit

Premièrement, il faut commencer par modifier les trois chaînes regedit suivantes :

HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus\CleanupState:2
HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus\GeneralizationState:7
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\SkipRearm:1

Éventuellement, on peut préférer exécuter un fichier .reg contenant les lignes suivantes :

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus]
"GeneralizationState"=dword:00000007
"CleanupState"=dword:00000002
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform]
"SkipRearm"=dword:00000001

Deuxièmement, effectuer deux commandes (dans l’invité de commandes ou exécuter Powershell en tant qu’administrateur), en attendant 5 à 10 secondes entre chaque commandes. Cette opération est réellement nécessaire car j’ai eu des échecs en essayant de ne pas le faire, pour voir.

msdtc -uninstall
msdtc -install

Dernière étape avant le sysprep : le skiprearm.xml

Attention, ce fichier dépend de votre version. Suite à un commentaire je me suis rendu compte que le fichier que je fournissais ne fonctionne plus sur les versions « récentes » de Windows.

Pour les vielles versions (2003 jusqu’à 2008 mais pas trop à jour?)

Troisièmement, créer un fichier nommé c:\Windows\system32\sysprep\skiprearm.xml contenant le texte suivant :

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="generalize">
<component name="Microsoft-Windows-Security-Licensing-SLC" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SkipRearm>1</SkipRearm>
</component>
</settings>
</unattend>

Pour les versions plus récentes et à jour

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="generalize">
<component name="Microsoft-Windows-Security-SPP" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SkipRearm>1</SkipRearm>
</component>
</settings>
</unattend>

Le sysprep

Une fois que ces trois étapes ont été réalisées, on reboot le serveur et on peut exécuter le sysprep en ligne de commande à la suite.

cd c:\windows\system32\sysprep
sysprep /generalize /oobe /shutdown /unattend:c:\Windows\system32\sysprep\skiprearm.xml

Dans mon exemple, je ne fais que couper la machine en fin de processus, il n’y a pas de reboot. Ceci me permet de transformer ma machine virtuelle en modèle à la suite. Ainsi, les VMs qui seront déployées avec ce modèle auront déjà eu leur sysprep au moment du premier boot, ce qui me gagne du temps.

Note complémentaire

Il y a débat sur le fait que le sysprep soit toujours nécessaire aujourd’hui, surtout depuis l’article du TechNet « The Machine SID Duplication Myth (and Why Sysprep Matters) » de Mark Russinovich, auteur de NewSID.exe, l’Utilitaire (avec un grand U) utilisé pour réinitialiser les SID sous XP/2003.

On y apprend en gros qu’il n’y a aucun risques à cloner des machines Windows sans réinitialiser les SID et que dans la grande majorité des cas, le sysprep n’est donc pas nécessaire depuis 2008. C’est d’ailleurs pour cela que l’auteur indique ne plus maintenir son NewSID.exe.

Pour autant, je peux attester personnellement de deux contextes en Windows 2008 et pour lesquels la duplication du SID a provoqué un dysfonctionnement majeur du fonctionnement des applications Microsoft (notamment l’installation d’un domaine Active Directory). Donc jusqu’à preuve du contraire, je continuerai à faire des sysprep sur mes clones/templates Windows Server.

Nombre de sysprep restants

Il existe une commande pour vérifier le nombre de sysprep qu’on peut encore refaire (trouvé sur Power Shell) :

slmgr.vbs /dlv

Sources additionnelles

Debug : Client NTP Linux vers NTP Windows Server

Sat, 05 Sep 2015 10:30:12 +0000

Si vous travaillez comme moi dans un contexte mixant les serveurs Linux et des serveurs Windows, vous avez probablement un serveur Active Directory pour gérer votre annuaire d’entreprise (ou au moins gérer vos serveurs Windows dans un ensemble cohérent).

Et comme les serveurs Windows dans un domaine Active Directory sont tous automatiquement synchronisés sur le temps du serveur maitre de l’AD, vous vous êtes probablement dit que ça serait une bonne idée de synchroniser tout le monde sur le même serveur.

Ou alors, vous avez un vieux serveur Windows connecté à une horloge hertzienne (ou autre, GPS, etc) et vous voudriez qu’il serve de source de temps fiable.

Mais rien n’y fait, ces fichus linux refusent de se mettre à jour ! Pourquoi ?

Configurer notre NTP Windows

w32time est il un serveur NTP ?

D’abord, avant de vous lancer, il faut que vous sachiez que Microsoft n’a pas fait un boulot terrible avec w32time. On ne peut pas vraiment qu’il s’agit d’un « vrai » serveur NTP. En fait, il s’agit plutôt d’une adaptation du service du temps w32time pour servir de serveur aux éventuels clients assez fous pour demander l’heure.

A ma connaissance, w32time n’a même pas de « driftfile » : si la source de temps n’est pas disponible et que l’horloge interne du serveur dérive, le serveur sera incapable de se corriger de lui même et votre heure se décalera de plus en plus.

Pour en terminer avec ce démontage en règle, c’est tellement du bidouillage qu’une des méthodes les plus répandues pour configurer le « serveur de temps » Windows consiste à modifier des clés de registre. Moi je vous donne la version « lignes de commandes », mais bon, tout est dit…

Méthode ligne de commandes

Si le serveur Windows en question est un serveur Active Directory, vous pouvez passez à l’étape « Linux » de l’article, car le serveur w32time est déjà configuré

Toutes les commandes sont à entrer dans un prompt « administrateur »

Couper le temps windows

net stop w32time

Synchroniser le serveur par rapport à une source de temps (soit un autre serveur NTP, soit l’horloge locale)

w32tm /config /syncfromflags:manual /manualpeerlist:[hostname] #si on souhaite connecter ce serveur à un autre serveur (sur Internet ou local)

w32tm /config /syncfromflags:manual #s'il n'y a pas de "père" et qu'on veut prendre la "local clock" comme source de temps

Pour information, on peut spécifier plusieurs serveurs dans [hostname], il faut juste les séparer par des virgules

Définir le serveur en tant que source de temps fiable

w32tm /config /reliable:yes

Relancer le temps windows

net start w32time

Afficher la configuration

w32tm /query /configuration

Resynchronisation (dans le cas où vous avez spécifié un serveur dans manualpeerlist)

w32tm /resync /rediscover

Et la méthode regedit alors ?

Les clés de registre à modifier se situent dans le noeud de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config. Principalement, vous devrez modifier AnnounceFlags et NTPServer pour indiquer que vous êtes serveur NTP

Vous trouverez les valeurs des clés de registre sur la page officiel du support à l’adresse suivante :

support.microsoft.com/fr-fr/kb/223184

Mais rien n’y fait, ces fichus Linux refusent de se mettre à jour ! Pourquoi ?

Je ne vais pas couvrir ici comment installer le client NTP sur les serveurs Linux, il y a suffisamment de documentations et de blogs qui traitent du sujet. Ce qu’ils expliquent plus rarement en revanche, c’est comment ça se fait que les clients NTP Linux refusent le temps provenant d’un serveur Windows.

Assurez vous déjà de ne pas avoir laissé plus de « restrict » que nécessaire. En effet, pas sécurité, les clients NTP sont souvent paramétrés de manière très sécurisée, ce qui est bien mais génère souvent des erreurs.

Voici un exemple de fichier de configuration minimaliste pour un client NTP sur un serveur RedHat Entreprise Linux

cat /etc/ntp.conf
server ntp1.mondomaine.fr iburst #enlever iburst hors debugging
server mondomaine.fr
server serveurntp.de.linternet.fr
driftfile /var/lib/ntp/drift

Et c’est tout. Dans la plupart des contexte, vous n’aurez pas besoin de plus. Et comme le mieux est l’ennemi du bien …

Je n’ai pas de restrict, et ça ne fonctionne toujours pas !

Tout à l’air correct, votre client Linux est paramétré pour se connecter sur les serveurs Windows, le démon tourne, mais ça ne fonctionne pas.

C’est la que le « fun » commence vraiment : on va débuguer NTP.

Pour ça, je vous propose d’utiliser la commande ntpq et ses nombreuses fonctions, qui soyons honnête, n’est pratiquement jamais utile, à part dans des cas comme ça !

# ntpq
ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
ntp1.mondom 111.0.111.151 4 u 34 64 377 0.272 -184.31 9.019

Ici, j’affiche les serveurs NTP avec la fonction peers. Je n’ai paramétré que le serveur Windows ntp1.mondomaine.com pour simplifier le diagnostic.

Normalement, tout à gauche, juste avant le nom, je devrais avoir un symbole * qui indique que le client s’est connecté à ce serveur, ou éventuellement + pour annoncé que le serveur est utilisable (si vous avez plusieurs serveurs).

Ici ce n’est pas le cas. Avec la fonction as, on peut obtenir plus d’informations.

ntpq> as
ind assID status conf reach auth condition last_event cnt
===========================================================
1 8950 9014 yes yes none reject reachable 1

Mon serveur ntp1 avec l’ID assID=8950 est en condition reject, malgré qu’il soit reachable. Ce n’est donc pas un souci réseau ou pare-feu. Pour avoir plus de détails, on peut utiliser la fonction rv, qui prend en argument l’assID du serveur

ntpq> rv 8950
assID=8950 status=9014 reach, conf, 1 event, event_reach,
srcadr=ntp1.mondomaine.com, srcport=123, dstadr=111.0.111.130,
dstport=123, leap=00, stratum=4, precision=-6, rootdelay=93.750,
rootdispersion=10329.788, refid=111.0.111.151, reach=377, unreach=0,
hmode=3, pmode=4, hpoll=6, ppoll=6, flash=400 peer_dist, keyid=0, ttl=0,
offset=-184.319, delay=0.272, dispersion=17.890, jitter=7.364,
reftime=d58e6c8b.deb41e80 Mon, Jul 15 2013 14:41:47.869,
org=d58e6cf5.7eb41e80 Mon, Jul 15 2013 14:43:33.494,
rec=d58e6cf5.adb21a64 Mon, Jul 15 2013 14:43:33.678,
xmt=d58e6cf5.ad9d86ac Mon, Jul 15 2013 14:43:33.678,
filtdelay= 0.31 0.30 0.29 0.27 0.36 0.35 6.65 1.05,
filtoffset= -183.41 -183.41 -183.98 -184.32 -185.32 -192.70 -173.01 -170.95,
filtdisp= 15.63 16.57 17.56 18.51 19.45 20.40 21.37 22.33

Qu’est ce qu’il faut comprendre là dedans ?

Ce qui va vraiment nous aider à comprendre le souci ici, c’est le code flash, qui peut d’ailleurs vous servir si vous avez d’autres problème de NTP complexes à débuguer :

The flash status word is displayed by the ntpq program rv command. It consists of a number of bits coded in hexadecimal as follows:
Code Tag Message Description
0001 TEST1 pkt_dup duplicate packet
0002 TEST2 pkt_bogus bogus packet
0004 TEST3 pkt_unsync server not synchronized
0008 TEST4 pkt_denied access denied
0010 TEST5 pkt_auth authentication failure
0020 TEST6 pkt_stratum invalid leap or stratum
0040 TEST7 pkt_header header distance exceeded
0080 TEST8 pkt_autokey Autokey sequence error
0100 TEST9 pkt_crypto Autokey protocol error
0200 TEST10 peer_stratum invalid header or stratum
0400 TEST11 peer_dist distance threshold exceeded
0800 TEST12 peer_loop synchronization loop
1000 TEST13 peer_unreach unreachable or nonselect

Ici, 400 peer_dist signifie que le « distance threshold » du serveur Windows (un paramètre à priori arbitraire puisqu’on peut le changer comme on le souhaite) est considéré comme trop important par le client NTP. Il y a donc deux méthodes pour résoudre ce problème :

Les solutions

Côté Linux

Dans votre configuration NTP, vous pouvez ajouter la ligne suivante, puis redémarrer le client NTP.

cat /etc/ntp.conf
[...]
tos maxdist 20 #utile pour les serveurs windows qui par défaut on un localclockdisp à 10 secondes par défaut
#sinon le débuging NTP loguera un condition reject sans plus de détails
#Ce paramètre windows est d'ailleurs modifiable avec un w32tm /config /localclockdisp X

Au bout de quelques secondes il devrait se synchroniser (vous pouvez vérifier avec ntpq -p ou ntpstat)

watch "ntpq -p"

ntpstat ntp2.mondomaine.com
synchronised to NTP server (111.0.111.13) at stratum 2
time correct to within 10100 ms
polling server every 64 s

Côté Windows

A l’inverse, vous pouvez tout à fait décider d’abaisser la dispersion au maximum (sous 3 secondes, je crois que ça fonctionne) sur le serveur Windows.

w32tm /config /localclockdispersion:3 /update
w32tm /resync /rediscover

Le client Linux devrait alors se montrer plus coopératif

ntpstat
synchronised to NTP server (111.0.111.147) at stratum 2
time correct to within 3046 ms
polling server every 64 s

Ressources utiles

Pour en arriver à écrire cet article, je peux vous dire que j’ai passé pas mal de temps à fouiller Internet. Voici l’ensemble des ressources qui m’ont aidé à trouver la solution :

NTP 4 pour Windows

www.eecis.udel.edu/~mills/ntp/html/hints/winnt.html (lien mort, j’utilise Internet Archive)

Debuguer NTP

Wiki du support NTP officiel

support.ntp.org/bin/view/Support/ConfiguringNTP NTP serveur pour Windows (interaction avec Linux)
yadhutony.blogspot.fr/2012/10/ntp-time-server-configuration-in.html
blog.galsungen.net/?tag=ntp
inf0blog.canalblog.com/archives/2010/07/27/18679194.html

Codes NTP

www.eecis.udel.edu/~mills/ntp/html/decode.html#flash (lien mort, j’utilise Internet Archive)