PowerShell on Zwindler's Reflection

Minikube sur Hyper-V part 2 : troubleshooting de l’installation

Tue, 02 Oct 2018 11:45:54 +0000

Minikube, le retour

Il y a deux semaines, j’ai fais un article sur l’installation de Minikube sur un poste Windows 10. Petite subtilité, l’article en question explique comment installer Minikube sur Hyper-V, nativement présent avec Windows 10, plutôt qu’avec Virtual Box, le choix par défaut mais qui nécessite un téléchargement et une installation complémentaire. Si vous l’avez loupé, c’est par ici.

Option 2 : Expectations meet life

On s’était arrêté dans l’article précédent à un monde merveilleux ou tout marche du premier coup.
Mais, vous vous en doutez, dans la vie (et particulièrement dans l’IT), rien ne se passe jamais comme prévu.

Voilà donc un petit florilège des problèmes que vous pourriez (ou avez) rencontrer (et leur résolution !)

VBoxManage not found

Si vous en venez à vous demander comment l’installer sur Hyper-V, c’est probablement que vous avez commencé par lancer la commande « minikube start » sans arguments… L’installeur a donc bêtement assumé que vous utilisiez Virtual Box (pourquoi ?) et vous vous retrouvez avec l’erreur suivante :

Error getting state for host: VBoxManage not found. Make sure VirtualBox is installed and VBoxManage is in the path.

Pourtant, vous avez beau forcer le start avec le flag suivant, rien y fait, ce n’est pas pris en compte.

--vm-driver hyperv

Pour trouver comment résoudre ce problème, vous pouvez jeter à œil à cette issue sur github

En réalité, une fois le premier « start » lancé, les fichiers de configuration sont générés dans C:\users[votrelogin].minikube (et en particulier dans profiles\minikube\config.json).

Impossible d’expliquer à l’installeur que vous avez changé d’avis (oui oui…), il faut donc de supprimer tout le dossier .minikube et recommencer avec les bons paramètres la prochaine fois (enfin c’est le plus simple, on va dire).

minikube-v0.xx.x.iso: Le chemin d’accès spécifié est introuvable…

minikube-v0.28.1.iso: Le chemin d’accès spécifié est introuvable...

Ok, ça ne marche toujours pas. On passe en mode verbose pour avoir l’erreur exacte :

PS C:\windows\system32> minikube start --vm-driver hyperv --hyperv-virtual-switch "Primary Virtual Switch" -v=7
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
[...]
[stderr =====>] :
Downloading D:\Users\zwindler\.minikub\cache\boot2docker.iso from file://D:/Users/zwindler/.minikub/cache/iso/minikube-v0.28.1.iso...
E0906 15:10:27.568262 14484 start.go:174] Error starting host: Error creating host: Error executing step: Creating VM.: open /Users/zwindler/.minikub/cache/iso/minikub-v0.28.1.iso: Le chemin d’accès spécifié est introuvable..
Retrying.
E0906 15:10:27.873612 14484 start.go:180] Error starting host: Error creating host: Error executing step: Creating VM.
: open /Users/zwindler/.minikube/cache/iso/minikube-v0.28.1.iso: Le chemin d’accès spécifié est introuvable.

Pourtant le fichier existe. Et c’est reparti pour un tour sur Github pour avoir plus de détails !

Ici, c’est donc tout simplement le script Minikube qui ne sait pas que vous avez un disque **D:**… Alors qu’il vient de le déposer lui même dans *D:* une ligne plus haut !!! La solution donc :

you can specify the path for the .minikub directory by setting the MINIKUBE_HOME env variable

Bon en vrai la bonne syntaxe sous Windows (dans Powershell en tout cas) c’est :

$MINIKUBE_HOME="D:\Users\[votrelogin]\"

On oublie pas de nettoyer la tentative précédente avec un :

minikube delete

FLMNH : « Error deleting machine profile config »

Si jamais en essayant de nettoyer votre environnement (pour recommencez, vous essayez un « minikube delete » et que vous vous prenez une erreur).

minikube delete
Deleting local Kubernetes cluster...
Machine deleted.
Error deleting machine profile config

Rebelotte, on supprime le dossier D:\Users[votrelogin].minikube à la main.

Error starting host: Error starting stopped host: exit status 1

Tout à l’air de fonctionner. Vous croyez que vous vous en êtes sortis ? Pauvres fous ;)

Au moment où tout se termine, le script vérifie que le cluster est opérationnel. Et après avoir boucler un moment : PAF !

Error starting host: Error starting stopped host: exit status 1

L’erreur n’est pas très explicite. En gros, vous êtes dans le cas où tout est bien installé, mais le curl pour vérifier que le cluster est UP échoue, pour un souci réseau. La plupart du temps, il s’agit de l’erreur suivante :

After some troubleshooting and head banging, it became apparent that the external network adapter had an ethernet adapter selected that was not connected to a network. (ethernet selected, instead of the wireless adapter). Of course an IP wont be allocated on an external network if none is connected.

Vérifiez donc dans les paramètres d’Hyper-V que vous ne vous êtes pas trompé d’adaptateur réseau lors de la configuration du réseau virtuel (cf l’article précédent) !

unable to authenticate, attempted methods [publickey none]

Ok, cette fois ci tout est censé être bon. Pourtant, à la fin, ça plante encore (désespoir).

Error dialing TCP: ssh: handshake failed: ssh: unable to authenticate, attempted methods [publickey none], no supported methods remain

Là je ne suis pas sûr à 100% ni de la cause, ni du fix, mais a priori, c’était un problème lié au client/serveur OpenSSH fourni par Microsoft, qui serait pourri. L’installation d’une autre version via Chocolatey semble avoir résolu le problème.

github.com/kubernetes/minikube/issues/2329

PS D:\> minikube ip
172.16.25.217

choco install openssh
Chocolatey v0.10.11
Installing the following packages:
openssh

Sécuriser l’émission de vos certificats avec un CAA (Azure)

Tue, 12 Jun 2018 11:45:10 +0000

CAA ? Azure ?!?

Et oui, je travaille sur Azure ! Je crois bien que c’est le premier article que je vais faire à ce sujet donc je commence par quelque chose de léger, créer un CAA.

Au-delà de toute considération purement dogmatique, le cloud de Microsoft fait quand même partie des plus grands, avec une richesse fonctionnelle et une API aussi riche que ce qu’on trouve chez les autres. J’aurai l’occasion de faire d’autres articles sur Azure car j’utilise énormément les modules Ansible développés par les équipes de Microsoft (qui s’appuient sur l’API d’Azure).

Et donc, le CAA ?

Mais cet article parle de CAA. Pour ceux qui ne connaitraient pas, un CAA est un « nouveau » (2017) type d’enregistrement DNS :

La CAA est une mesure de sécurité qui permet aux propriétaires d’un nom de domaine de préciser dans leur DNS (Domain Name System) les autorités de certification (AC) qui sont autorisées à émettre des certificats pour leur nom de domaine.

Global Sign (lien mort, pas disponible sur Internet Archive)

Concrètement, si je possède un domaine avec un grand nombre de sites web signés, que je n’utilise qu’une ou deux (ou un nombre fini) autorités de certifications, je peux maintenant spécifier lesquelles (parmi la centaine des AC existantes) sont autorisées à émettre un certificat pour mon domaine. Cela permettra d’éviter que des personnes mal intentionnées génèrent un certificat pour une URL dans un de vos sous domaines.

Comment ça fonctionne ?

Il existe donc un nouveau type d’entrée dans votre DNS qui devrait ressembler à ça :

Name	Type	Value
zwindler.fr.	CAA	0 issue « letsencrypt.org »
zwindler.fr.	CAA	0 iodef « mailto:zwindler@zwindler.fr »

Pour l’entrée zwindler.fr., j’ai donc un CAA qui dispose de 2 variables (issue et iodef) :

La première indiquant que seul letsencrypt.org peut générer des certificats pour mon domaine. On peut en avoir plusieurs si on a plusieurs autorités de certification.
La seconde indiquant qu’il faut m’envoyer un email si jamais quelqu’un qui n’a pas les droits essaye de générer un certificat.

A noter : iodef n’est pas respecté par toutes les autorités de certifications, donc vous n’aurez potentiellement pas d’emails en cas de tentative de génération de certificat chez une AC non autorisé.

Ok, comment je créé un CAA ?

Normalement, c’est trivial. Il s’agit d’un enregistrement DNS comme un autre. Par exemple chez OVH, vous pouvez directement le créer depuis l’interface :

Et sur Azure ?

Il faut bien que ce soit rigolo. Dans le portail d’Azure, il n’est pas possible de créer (ni même de voir !!!) les champs de types CAA, pourtant disponibles depuis mi 2017.

La seule solution est d’utiliser l’API REST, la CLI azure, ou Powershell :

Page de documentation azure cli (record-set)
Gérer les enregistrements DNS avec Powershell

Avec Azure cli

Du coup je suis parti de la doc pour faire ça :

En partant du principe que vous avez un compte sur Azure, que vous gérez les DNS de la zone zwindler.fr depuis Azure DNS (dans un resource group appelé dns-rg), voilà ce qu’il faut faire pour créer une protection pour le sous domaine *.test.zwindler.fr.

az network dns record-set caa add-record --resource-group dns-rg --zone-name zwindler.fr --record-set-name test --flags 0 --tag "issue" --value "letsencrypt.org"
az network dns record-set caa add-record --resource-group dns-rg --zone-name zwindler.fr --record-set-name test --flags 0 --tag "iodef" --value "zwindl3r@zwindler.fr"
az network dns record-set caa list --resource-group dns-rg --zone-name zwindler.fr
{
"caaRecords": [
{
"flags": 0,
"tag": "iodef",
"value": "zwindl3r@zwindler.fr"
},
{
"flags": 0,
"tag": "issue",
"value": "letsencrypt.org"
}
],
"etag": "aaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa",
"fqdn": "test.zwindler.fr.",
"id": "/subscriptions/aaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa/resourceGroups/dns-rg/providers/Microsoft.Network/dnszones/zwindler.fr/CAA/test",
"metadata": null,
"name": "test",
"resourceGroup": "dns-rg",
"ttl": 3600,
"type": "Microsoft.Network/dnszones/CAA"
}

Et si je veux le domaine entier ?

Et là c’est la blague !

Si vous créez un record-set « test« , il va vous créer un CAA pour test.zwindler.fr (voire le champ fqdn dans la réponse du list). Vous n’avez pas la main sur le fqdn directement (que ce soit en création ou en mise à jour), il est créé à partir du nom.

Or, vous avez très probablement envie de protéger zwindler.fr, pas seulement test.zwindler.fr, car ça n’aurait pas vraiment de sens (on rappelle que le but de la manœuvre et d’empêcher des gens de générer des certificats pour des sous domaine de votre domaine) sinon.

Créer une liste exhaustive de tous les sous domaines possibles me semble complexe ;-).

L’astuce, que vous ne trouverez pas dans la documentation (en tout cas dans les pages que j’ai lues), est de créer un recordset avec comme nom « @ » (j’avais testé, vide, « * », « . », mais pas « @ »…).

Et là, un recordset sera créé pour l’ensemble de votre zone DNS (zwindler.fr dans mon exemple).

Magie-magie…

Liens utiles

Utiliser PowerCLI pour créer un template de VM VMware

Tue, 07 Mar 2017 13:00:52 +0000

VMware et PowerCLI

Ça fait un long moment que j’ai cet article dans les tiroirs et aujourd’hui je n’ai plus vraiment l’intention d’utiliser PowerCLI pour automatiser ce genre de choses.

Pour autant, il y a quelques années, on m’a demandé de réaliser une copie complète quotidienne d’une machine virtuelle donnée. N’ayant à l’époque qu’une vieille version de DataProtector (youpi…) sur site, je n’avais pas d’outil pour sauvegarder simplement une machine complète, et encore moins donner les moyens de la restaurer rapidement en cas de crash.

Ayant déjà bidouillé avec GhettoVCB, qui permet notamment de sauvegarder à chaud des machines virtuelles VMware même quand on a pas de vCenter, je savais qu’il y avait des possibilités.

Dans mon cas précis, il y avait un cluster vSphere avec un vCenter installé sur un serveur Windows (à l’ancienne). Et comme je souhaitais automatiser cette tâche de copie depuis le vCenter, je ne voulais pas utiliser le VIPerl. A ce moment là, Microsoft mettait en avant Powershell, ce qui incitait les éditeurs à fournir leurs modules compatibles. C’est ainsi que naquit PowerCLI.

A noter, dans le cas présent, il sera nécessaire d’avoir le vCenter car le module PowerShell PowerCLI se base sur la même API fournie par VMware que celle utilisée par VIPerl.

Quand on a un vCenter, on peut faire beaucoup de choses via l’API (et donc via PowerCLI). Le plus simple pour résoudre le problème posé était de déclencher chaque jour la création d’un clone ou d’un template. Et c’est donc ce que j’ai fais !

Bon… du coup, je n’ose pas vraiment parler de « sauvegarde » car il s’agit de tout sauf ça. Mais ça permettait aux administrateurs de disposer rapidement d’une machine à J-1 en cas de corruption, sans passer une sauvegarde réelle, ce qui était le besoin.

Installation de PowerCLI

Oui parce que bon. Ce n’est pas si simple ! Le VIPerl était casse pied à installer avec toutes les dépendances Perl, il n’y avait pas de raisons que le PowerCLI le soit plus. Merci VMware… ou Microsoft je ne sais pas ;-). Voici la marche à suivre

Récupérez l’installer sur le site de VMware (ex VMware-PowerCLI-5.1.0-793510.exe)
Exécutez l’installation en tant qu’administrateur de la machine.

Une fois installé, ouvrez le panneau de configuration pour désactiver la révocation des certificats :

Panneau de configuration/Options Internet/Onglet Avancé/Section Sécurité/Décocher Vérifier la révocation du certificat des éditeurs

A partir de là PowerCLI est « utilisable ». Pour autant, à l’époque sur les serveurs 2008 R2 (ça date !) il y avait un gros soucis de performance sur PowerCLI (VMware ou Microsoft, je n’ai jamais su), qui mettait plusieurs secondes (voire dizaines) avant de s’exécuter. La seule méthode permettant de gagner du temps était de précompiler le module PowerCLI (…) :

C:\Windows\Microsoft.NET\Framework\v2.0.50727\ngen.exe install "VimService51.XmlSerializers, Version=5.1.0.0, Culture=neutral, PublicKeyToken=10980b081e887e9f"
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\ngen.exe install "VimService51.XmlSerializers, Version=5.1.0.0, Culture=neutral, PublicKeyToken=10980b081e887e9f"

Et avant de pouvoir exécuter des scripts PowerShell personnels, il faut modifier la politique de sécurité bloquant l’exécution dédits scripts. Personnellement je vous conseille de laisser en RemoteSigned mais à vous de voir.

Attention, comme il y a une partie x86 et une partie x64, il faudra lancer un prompt PowerShell en 32 bits et un en 64 bits avec les droits Administrateur (clic droit, lancer en tant qu’administrateur), puis exécuter la commande suivante dans les 2 terminaux :

Set-ExecutionPolicy RemoteSigned

Enfin, pour contourner 2 problèmes rencontrés IRL, on doit également lancer un prompt PowerCLI en 32 bits et un en 64 bits avec les droits Administrateur, puis exécuter les commandes suivantes (méthodes de contournement respectivement pour des problèmes de connexions dans les scripts et les problèmes de certificats) :

Set-PowerCLIConfiguration -ProxyPolicy NoProxy -Confirm:$False
Set-PowerCLIConfiguration -InvalidCertificateAction ignore -Confirm:$False

Commandes à exécuter manuellement, pour voir

Dans un premier temps (c’est à dire avant d’exécuter un script en priant pour que ça marche), le mieux est quand même de lancer les commandes à la main pour vérifier qu’on arrive à le faire au moins une fois manuellement.

Exemple de connexion au serveur vCenter (windows_vcenter) avec le login compte_privilegie présent dans le même domaine AD le vCenter.

Connect-VIServer -server windows_vcenter
Name Port User
---- ---- ----
windows_vcenter 443 DOMAINEAD\compte_privilegie

Normalement, après quelque s secondes la connexion devrait se faire. A partir de là, toutes les commandes suivantes seront authentifiées sur le vCenter.

Maintenant qu’on a réussi à se connecter, on démarrage d’une copie d’une VM vers un template. Ici je prends l’exemple du serveur vm_a_copier.

New-Template -Name vm_copie -VM vm_a_copier -Datastore DATASTORE_COPIE -Location VMWARE
Name
----
vm_copie

Dans la console, la copie devrait être en cours. Mission accomplie !

Je vous invite à aller sur le site de documentation VMware pour plus d’informations sur cette commande (lien mort, j’utilise Internet Archive).

Mise en place de la copie de la VM à proprement parler

Le script PowerShell

Ce sera donc un script PowerShell qui gèrera la copie de la VM (C:\scripts\vm_copie.ps1). Voici les étapes de ce script « exemple », à adapter à votre besoin.

Chargement du module PowerShell pour VMware

Add-PSSnapin -Name "VMware.VimAutomation.Core"

Connexion au vCenter en local (pas d’authentification nécessaire dans ce cas là)

$Server = Connect-VIServer -Server windows_vcenter -User vmwaresvc -Password mot_de_passe

Vérification préalable de l’existence ou non du template en question (on l’exécute tous les jours) et suppression le cas échant. Attention à ce que vous faites ici, en fonction de votre contexte !

$BackupTemplate = Get-Template -Name backup_srsmvm-supervision01 -Location VMWARE
If ($BackupTemplate){
Remove-Template -Template vm_copie -DeletePermanently -Confirm:$false
}
New-Template -Name vm_copie -VM vm_a_copier -Datastore DATASTORE_COPIE -Location VMWARE
Start-Sleep -s 10
Disconnect-VIServer -Server $Server -Confirm:$false

Et on se déconnecte proprement parce qu’on est sympa (et propres).

Permettre l’exécution automatique

On est contents, on a notre script. Pour autant ce n’est pas encore totalement terminé… Si vous connaissez un peu PowerShell (à voir si c’est toujours vrai sur les Windows Server récent, j’ai un doute…), vous savez qu’il était nécessaire de passer par un .bat ou un .vbs pour l’exécuter, ce qui n’était pas très pratique.

Avant de pouvoir créer une tâche planifiée Windows pour pouvoir automatiser notre copie, il va donc falloir créer un fichier vbs C:\scripts\vm_copie.vbs qui ne fera que lancer le fichier .ps1.

'Script VBScript de lancement des backups de VM
Set objShell = CreateObject("Wscript.Shell")
objShell.Run("powershell.exe C:\scripts\vm_copie.ps1")

Ce script vbs sera lancé par un compte de service (vmwaresvc par exemple) dans une tâche planifiée. Ce compte de service devra donc préalablement être autorisé à se connecter au vCenter et à réaliser des créations de templates.

Création d’un profil de sécurité et d’un compte pour la copie

Pour se faire, connectez vous au vCenter avec un compte administrateur VMware, puis créez un rôle disposant uniquement des autorisations nécessaires.

Menu Administration/Rôle/Ajouter…

Nom **« Compte de service copie_template »
**

Sélectionnez les privilèges suivants

Banque de données/Allouer espace
Machine virtuelle/Provisionnement/Créer un modèle à partir d’une machine virtuelle
Machine virtuelle/Inventaire/Créer à partir d’un modèle/d’une machine virtuelle existante
Machine virtuelle/Inventaire/Supprimer (attention danger !)

[Clic droit]Ajouter une autorisation

Ajouter…

Dans le menu déroulant Domaine, sélectionner VMWARE, puis ajouter l’utilisateur vmwaresvc. Dans Rôle assigné, sélectionner « Compte de service copie_template », et valider.

Et si vous avez bien suivi la logique, vous irez de vous même vous connecter au vCenter avec le compte vmwaresvc pour vérifier par vous même que l’opération fonctionne manuellement (car vous ne croyez que ce que vous voyez, et vous avez bien raison).

Restauration

Je ne pouvais pas terminer l’article sans au moins dire comment revenir en arrière une fois que vous avez besoin de repartir du template.

Comme il ne s’agit pas vraiment d’une VM mais d’un template, pour « restaurer » la machine virtuelle, il faut cliquer sur le template créé par le script et sélectionner Convertir en machine virtuelle ou Déployer machine virtuelle à partir de ce modèle.

Et voilà ! Je vous laisse le soin d’aller plus loin dans PowerShell / PowerCLI. Soyez créatifs ;-)

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

Installer le pilote ODBC d’Oracle 11g 12c sur Windows 2k8/2k12

Thu, 02 Jul 2015 10:45:02 +0000

Lorsqu’un progiciel installé sur un serveur Windows nécessite une connexion à une base Oracle, il n’est pas toujours nécessaire d’installer un client Oracle (même Runtime). Des fois, c’est simplement le pilote ODBC qui est nécessaire.

Seulement, pour ceux qui comme moi ne sont ni à l’aise avec Windows 2012, ni à l’aise avec ce genre de considérations, j’ai trouvé que c’était un peu nébuleux.

Voici la page où on peut télécharger tous les bouts de clients Oracle pour Windows qu’on veut ici.

Quoi faire avec? A vous de le savoir (ou alors, il faut trouver la bonne doc, ce qui n’a pas été mon cas pour l’instant) ! [Edit]En fait c’est écrit touuuuuut en bas de la page, après la longue liste de téléchargements[/Edit]

Il ne faut pas se contenter de télécharger l’archive, qui est insuffisante en soit, il faut aussi récupérer l’archive « basic », qui contient grosso modo le cœur du pilote ODBC. Dans mon cas il me fallait un pilote en version Oracle 11.2, mais le principe reste le même pour d’autres versions.

instantclient-basic-windows.x64-11.2.0.4.0.zip
instantclient-odbc-windows.x64-11.2.0.4.0.zip

Dézipppez dans le MÊME dossier les deux archives. Dans mon cas, je les ai mis dans C:\Program Files\instantclient_11_2

Enfin, lancez un shell PowerShell en tant qu’administrateur, puis, dans le dossier en question, exécutez la commande odbc_install (.exe).

Pour finir, avant que le pilote soit totalement opérationnel, il faut aussi modifier la variable d’environnement globale de Windows « Path » pour y ajouter le chemin vers le pilote ODBC.

Une fois toutes ces opérations réalisées, le pilote ODBC devrait être visible dans l’administrateur de sources de données, via le binaire « C:\Windows\SysWOW64\odbcad32.exe »

Quelques infos trouvées sur les sites suivants :

SQL Server 2005 : PowerShell > Batch – Episode 3

Wed, 28 Apr 2010 16:52:16 +0000

Batch – Episode 3" />

Dernier article là-dessus et on en parle plus (jusqu’à ce que je change d’avis). Dans l’article précédent, je vous indiquais mon désespoir quand j’ai découvert que je faisais tout mal (lien mort, j’utilise Internet archive). En regardant de plus près, je me suis aperçu que ça ne marchait pas vraiment comme il le disait, surtout pour ce qui est des sauvegardes incrémentales, et je me suis empressé d’écrire une nouvelle version de mon script pour qu’il soit plus beau, plus fort, plus efficace…

Une petite note aussi, les problèmes que j’ai eu avec le script du monsieur de databasejournal est peut-être dû au fait que j’ai une version Express et non pas complète comme je le pensais au début.

En fait, quand vous faites un backup complète, un fichier .bak est créé, et celui ci est autosuffisant et peut être restauré facilement. Cependant, pour pouvoir utiliser les sauvegardes incrémentales, il faut que la sauvegarde soit faite dans le même fichier, qui est concaténé (en quelque sorte). Or, le script donné à la fin de l’article créé des backups .diff qui sont séparées de leur backup complète, que je n’ai pas réussi à réimporter avec MS SQL Server 2005 Express.

Pour ceux d’entre nous qui ont les mêmes problèmes que j’ai eus avec les « differential backups », voici un nouveau script qui permet de faire proprement ce que je voulais faire depuis le début, c’est-à-dire:

disposer d’un script qui automatise la sauvegarde de la base de donnée de mon vCenter (mais aussi de n’importe quelle autre base de données compatible MS SQL Server 2005)
avoir la possibilité de faire des backups complètes, datées pour pouvoir être différenciées
avoir la possibilité de faire des backups incrémentales
toutes les opérations et éventuelles erreurs sont journalisées (ça se dit?)

Pour ce qui est des contrôles du script:

dans le cas où une backup complète n’est pas trouvée, le script fait une backup complète plutôt qu’une incrémentale
dans le cas où plusieurs backup complètes existent, la backup incrémentale se greffe sur la backup complète la plus récente (ça m’a paru assez logique comme façon de faire, mais vous n’êtes pas obligés d’être d’accord)

Il s’utilise de la façon suivante :

powershell.exe C:\Scripts\MSSQLBackup2.ps1 HOMESQLSERVER MyDB \\SERVER\BackupFolder FULL
powershell.exe C:\Scripts\MSSQLBackup2.ps1 HOMESQLSERVER MyDB C:\Backup DIFF

La première ligne exécute le script pour une backup complète de MyDB depuis l’ordinateur HOME (en local svp, je n’ai pas testé à distance, mais il doit y avoir des problèmes d’authentification) qui dispose d’un serveur SQLSERVER vers un dossier partagé BackupFolder sur le réseau par l’ordinateur SERVER. La seconde ligne fait plus ou moins là même chose (sauvegardé localement et pas dans un dossier partagé) mais avec une sauvegarde incrémentale.

Je suis vengé :-D

Internet 1 - Zwindler 1

SQL Server 2005 : PowerShell > Batch – Episode 2

Tue, 27 Apr 2010 13:09:43 +0000

Batch – Episode 2" />

A quoi ça sert de faire du PowerShell si on continue à utiliser de vieux exécutables tout pourris ?

Dans le précédent article, je vous ai donné un script home-made qui permet de faire une backup automatisée d’une base de données SQL Server 2005, en me basant sur l’appel du mécanisme de backup par l’interpréteur de T-SQL (beurk!) SQLCMD.EXE. Ceci est un bon exemple des dangers d’être autodidacte. Si seulement j’avais gratté un peu plus avant de foncer tête baissée, j’aurai découvert (ce que je viens de faire par hasard) qu’il existe des objets pour ça : SMO!

SMO?

La collection d’objets SMO (SQL Server Management Objects) est conçue pour la programmation de tous les aspects de la gestion de Microsoft SQL Server. La collection d’objets RMO (SQL Server Replication Management Objects) encapsule la gestion de la réplication SQL Server.

En fouillant un peu sur cette piste, je suis tombé sur cet article de Database journal (lien mort, j’utilise Internet archive). Il nous explique cordialement que toute cette ligne de commande moche que j’utilisais pour enclencher la backup peut être évité en utilisant des objets manipulables dans PowerShell. « Cool, me dis-je, je vais pouvoir proprifier mon script. C’est dommage de ne pas avoir trouvé ça dès le début! »

En fouillant un peu plus, je suis tombé sur le dernier article (lien mort, j’utilise Internet archive). En gros, tout l’article explique pas à pas comment faire pour faire mieux en moins de lignes (backups incrémentales for dummies).

Pour garder la tête haute, je vais quand même héberger une nouvelle version du script, qui proposera de faire des backups incrémentales ou non, en m’inspirant fortement du code disponible sur databasejournal pour améliorer le mien.

Zwindler 0 - Internet 1

SQL Server 2005 : PowerShell > Batch

Fri, 23 Apr 2010 17:38:58 +0000

Batch" />

Il y a quelques jours, j’ai commencé la rénovation de notre vCenter (il tournait en machine virtuelle avec très peu de RAM sur un vieux VMWare server 2.0, lui même hébergé par un PC toussotant).

Outre les opérations de migration, je me suis penché sur les conséquences de la perte de ce vCenter, et donc les moyens à mettre en œuvre pour s’assurer de vite pouvoir remettre le système en marche. Si on met de côté le débat machine physique/machine virtuelle pour héberger le vCenter, la communauté semblait unanime sur le fait que pour le vCenter, les 2 choses importantes à sauvegarder sont les fichiers de licences et la base de données.

Dans notre cas, la base de données est simplement un Microsoft SQL Server 2005 (configuration des plus classiques). La version complète du SQL Server Management Studio permet en quelques clics de programmer une sauvegarde. N’étant pas capable de mettre la main sur les fichier d’installation de la version complète du Manager, j’ai cherché une solution alternative.

J’ai trouvé assez facilement un script batch qui utilise sqlcmd.exe, un programme fournit dans toutes les versions de SQL Server 2005 (même la version Express) et qui est en fait un interpréteur de requête T-SQL (si j’ai bien compris). La solution pour automatiser la sauvegarde de la base de données du vCenter (où de n’importe quelle autre base SQL Server d’ailleurs) consiste simplement à créer une tâche planifiée qui lance ce script aussi souvent que vous le souhaitez.

J’aurai pu m’arrêter là, mais pour plusieurs raisons, j’ai préféré réécrire ce script :

D’abord, batch, ça commence à dater un peu, il serait temps de passer à autre chose!
Ensuite, je ne suis pas du tout à l’aise avec les scripts batch. Comme je voulais améliorer ce script, cela impliquait que je m’y mette sérieusement, et je n’avais pas vraiment envie :-p
Enfin, certaines actions relativement complexe en batch sont grandement simplifiées par les usines à gaz que sont VBScript et PowerShell.

Les deux problèmes majeurs de ce script batch sont le gaspillage d’espace disque et l’absence de contrôle sur ce qui est fait. Certes, on vérifie certaines choses pour éviter des erreurs bêtes lors de l’exécution, mais bon, j’en attendais un peu plus.

J’ai donc sorti mon interpréteur PowerShell, un papier et un crayon, et je me suis créé un petit script qui permet de sauvegarder une base de données MS SQL exactement de la même manière, mais également qui ne garde que les fichiers backups de la veille et des 2 derniers « 1er jour du mois », qui vérifie que le fichier a bien été copié, et qui journalise le tout.

Ainsi, pas de gaspillage avec 200 versions pratiquement similaires de la base de données (le vCenter n’en a pas besoin, et on pourrait même se contenter d’une seule backup du mois dernier), et un contrôle un peu plus « propre » de ce qui se passe lors de l’exécution de la tâche planifiée.

Alors forcément, c’est sûr que c’est loin d’être aussi bien qu’une sauvegarde incrémentale planifiée par un outil tiers ou par le SQL Server Management Studio (je ne sais pas si il le fait, mais j’ai du mal à imaginer que non). C’est sûr aussi qu’on pourrait contrôler de façon encore plus complète tout ce qui se passe lors de l’exécution du script (plutôt que simplement vérifier que le fichier existe), notamment en traitant les éventuelles erreurs renvoyées par SQLCMD (qui ne sont pas vraiment prises en compte).

J’ai voulu écrire rapidement un petit script, et je n’ai pas besoin de plus que ce que j’ai déjà fais. On ne peut pas tout gérer non plus…