En voulant monter un failover cluster Windows Server 2008 R2:
Pour corriger le problème, il faut assigner temporairement une lettre de lecteur à la partition bitlocker (FAT32 / 2Go) (créée automatiquement par Windows):
et voilà 🙂
serveur
TMG 2010: joindre une array: no such interface supported…
En voulant joindre un TMG 2010 à un autre pour former un array (une ferme quoi), j’ai obtenu le message d’erreur suivant très explicite:
Cela était dû au fait que l’autre noeud avait le Service pack 1 de TMG 2010, et pas celui ci…En essayant la jonction dans l’autre sens, le message d’erreur met au moins un peu sur les rails avec un problème de version du fichier de configuration.
Dedibox: port cisco down & idrac: la double peine
Faisant face à quelques difficultés avec Dedibox, je souhaitais partager avec vous mon analyse.
La nouvelle offre Dedibox s’appuie sur des serveurs Dell, et propose un accès à l’idrac de votre serveur. Cela permet de faire l’installation de l’OS soit même (par exemple Windows en montant l’iso à travers l’idrac).
Dell propose 2 méthodes pour connecter l’idrac:
- Dédié: l’accès se fait à travers un port Ethernet.
- Partagé: l’accès se fait à travers les cartes réseaux normales du serveur.
C’est cette deuxième solution que Dedibox a retenue. Elle leur permet évidemment une grosse économie:
- de câblage réseau (surtout vu la quantité de serveurs),
- De ports sur les commutateurs (1 par machine).
Cela ne me pose pas de problème au demeurant, mais cela se complique avec leur politique de gestion du réseau et de sa sécurité. La couleur est annoncée tout de suite: en cas de problème détecté, le switch coupe le port réseau associé. Il faut alors ouvrir un ticket pour être débloqué.
Impact: quand le port est coupé par le switch, on perd également l’accès à l’idrac. D’où la double peine: le serveur n’est plus joignable, et on ne peut même pas réparer via l’idrac.
La connexio à l’idrac se passe en plusieurs phases:
- Connexion à la console de gestion Dedibox
- Accès au menu idrac
- Génération d’une URL d’accès (idrac.online.net qui fait office de reverse proxy) contenant un token d’accès unique
- Depuis l’interface idrac de Dell, accès à la console virtuelle (uniquement via Java, activeX est désactivé)
- Téléchargement d’un Java Webstart (fichier jnlp)
- Lancement de l’applet Java
Sécuriser son Windows dans le cloud (Dedibox/Amazon…)
Suite à mon retour vers Dedibox, et le fait que j’y installe du Windows, je me suis demandé ce que je pouvais faire pour la sécuriser.
Voici les pistes envisagées:
- Pas de port TCP accessible directement. Passer donc par exemple avec LogMeIn, au moins pendant la configuration. L’accès idrac n’est pas assez fluide et simple d’accès.
- Renommer le compte Administrateur via GPedit
- Interdire l’affichage du dernier compte authentifié via GPedit.
- Ajouter un disclaimer, toujours via GPedit. Cela n’arrêtera pas un pirate motivé, mais peu suffire à bloquer certains logiciels de brute force RDP.
- Autoriser RDP mais:
- Sur un port TCP non standard. Procédure Microsoft : http://support.microsoft.com/kb/306759/en-us/
- Utiliser le firewall Windows pour autoriser l’accès uniquement depuis certaines IP fixes. Pour y accéder depuis ailleurs, d’abord se connecter en LogMeIn pour modifier la règle firewall.
- Autoriser uniquement les clients permettant une authentification réseau.
- Scanner régulièrement les adresses IP depuis l’extérieur avec nmap pour vérifier ce qui est visible.
- Appliquer les mises à jour Windows dès leur sortie.
Dedibox: Nat de VM Hyper-V
Suite au retour sur Dedibox, j’ai décidé d’utiliser Hyper-V plutôt que VMware pour la virtualisation. Les adresses IP publiques sont facturées chez Online.net, et d’autre part je ne veux pas que certaines VM soient exposées sur Intrenet (DC, Exchange…).
Par défaut, Hyper-V ne permet pas de faire du Nat, et donc cacher tout se beau monde tout en leur donnant accès à Internet.
Voici les grandes étapes:
- Installer le rôle Network Policy and Access Services
- Créer un réseau interne dans Hyper-V
- Assigner une adresse IP fixe (ex 192.168.1.1) sur la carte réseau du réseau ainsi crée (carte virtuelle Hyper-V)
- Configurer Routing and Remote Access pour faire du NAT
- Configurer les VM afin d’utiliser le réseau virtuel Hyper-V et de passer en DHCP ou IP fixe suivant vos souhaits.
Ajouter le rôle
Configurer le NAT
SCOM 2007 R2: superviser une VM Linux Amazon EC2
Quelle drôle d’idée vous allez me dire… Mais avoir une ou plusieurs VM dans le cloud ne justifie pas d’avoir une supervision « à part ». Cependant le défi est pas mal:
- Les Managements Pack Microsoft ne sont pas prévu pour Fedora
- L’authentification par défaut sur les VM Amazon est à base de certificat
Lorsque SCOM détecte Fedora, il bloque directement: 
Pour détecter la version, SCOM exécute le script Shell qui se trouve ici: 
Par ailleurs, le dossier comprend aussi les RPM qui sont installés par la suite (démon). Arriver à notre fin va nécessiter de l’huile de coude à plusieurs endroits…
Pour vous encourager, voici le résultat: 
Vous l’aurez compris, il s’agit notamment de faire croire à SCOM que nous avons une Red Hat. Il y a en fait deux possibilités:
- Créer un Management Pack pour Fedora.
- Maquiller la VM pour paraitre comme une Red Hat.
La première solution est la plus élégante, mais elle va être longue à mettre en place, et à maintenir ensuite. J’ai donc préféré la seconde, surtout qu’une Fedora n’est pas très éloignée…
Modifications sur le Linux Amazon EC2
Autoriser la connexion SSH sans certificat
dans /etc/ssh/sshd_config:
PasswordAuthentication yes PermitRootLogin no #Supprimer également la dernière ligne du fichier qui permet un logon root sans mot de passe
Il faut ensuite donner un mot de passe au compte root:
passwd root
puis recharger la configuration:
/etc/init.d/sshd reload
Puis créer un compte utilisateur pour SCOM:
useradd scom passwd scom
Vérification du hostname
Par défaut, la VM a pour hostname son adresse IP interne. SCOM va déployer un rpm afin d’avoir un démon sur la VM, et génèrera un certificat pour s’authentifier.
Il est impératif que le hostname corresponde au nom utilisé par SCOM pour joindre son agent. Le plus simple est de changer le hostname par un nom accessible via les dns publiques, par exemple www.lotp.fr:
hostname www.lotp.fr
Afin de résister à un reboot, il faut également modifier /etc/sysconfig/network an ajoutant:
HOSTNAME=www.lotp.fr
Dépendances
Le package RPM de Microsoft a des dépendances, notamment sur deux librairies:
- /usr/lib/libssl.so.6
- /usr/lib/libcrypto.so.6
Si votre système a une version plus récente (so.8 …), il suffit de faire des liens symboliques (ln -s cible fichierquiexiste): 
Si vous ne le faites pas, vous aurez les messages d’erreurs suivants à l’installation du RPM (d’abord libssl puis libcrypto une fois le premier corrigé):
Au final, j’ai les liens symboliques suivants:lrwxrwxrwx 1 root root 16 Feb 16 16:19 libssl.so.6 -> libssl.so.0.9.8k lrwxrwxrwx 1 root root 12 Feb 16 16:23 libcrypto.so.6 -> libcrypto.so
Je vous invite à copier le rpm (scx-1.0.4-248.rhel.5.x86.rpm), afin de valider la bonne installation. Sinon c’est SCOM qui le fera pendant le déploiement, et les messages de retour ne sont pas toujours explicite.
Par ailleurs, cela permet de voir le nom avec lequel le certificat est crée:
Il est toujours possible de le désinstaller:
rpm -e scx-1.0.4-248.i386
Ports TCP
SCOM va se connecter par deux moyens:
- SSH
- port 1270 (agent scom sur Linux)
Il faut configurer le parefeu Amazon afin que ces deux accès soient possibles. Si le port 1270 n’est pas joignable, SCOM remonte une erreur de timeout pas explicite. Le trafic vers ce port est confirmé par une trace réseau: 
NB: si vous ne connaissez pas Wireshark, j’ai fait une vidéo/tutoriel dessus, elle est disponible ici.
/etc/redhat-release
Par défaut, Fedora crée un lien symbolique de /etc/fedora-release vers /etc/redhat-release. il faut casser ce lien symbolique, et créer le fichier redhat-release avec comme donnée Red hat…:
rm /etc/redhat-release echo "Red Hat Enterprise Linux Server release 5" > /etc/redhat-release
Modifications sur SCOM 2007 R2
Les actions à mener seront les suivantes:
- Autoriser WinRM à faire de l’authentification basique
- Importer les Managements Pack Linux/Unix génériques et Red Hat en particulier
- Ajouter un compte de type Authentification basique pour se connecter au Linux (non root)
- Ajouter un compte de type Authentification basique pour se connecter au Linux (root)
- Associer les comptes ajoutés aux profiles Unix Action Account et Unix Privileged Account
- Découvrir la VM Linux et signer le certificat
Ajouter la VM est passe comme une lettre à la poste si vous respectez bien les différents pré requis. Je vais donc m’attarder sur les problèmes que j’ai rencontré. Autoriser WinRM à faire une authentification basique: 
Si vous n’avez pas mis le bon hostname, le certificat est refusé au moment de le signer: 
Si vous ne déclarez pas de comptes, les workflow ne fonctionnent pas: 
Au départ, la VM n’est pas encore supervisée et marquée « unknown »:
Puis elle passe ensuite au vert:
Voilà, à ce stade, votre VM est supervisée par SCOM 2007 R2. Voici quelques écrans de SCOM 2007 R2 une fois tout opérationnel:
Windows Server 2008 R2 – Administration avancée est sorti!
La nouvelle version du livre pour Windows Server 2008 R2 est disponible chez ENI, toujours à la fois en livre papier et numérique
Il s’applique toujours à la version précédente, car on a spécifié quand c’est R2 seulement. Il inclut également un nouveau chapitre dédié à la haute disponibilité
Amazon EC2: version de fedora trop ancienne!
Je ne me suis pas vraiment méfié au départ. Faut dire que je n’ai jamais installé de Fedora, et donc je ne connais pas l’historique des versions, ni la version « actuelle »… J’ai pêché par excès de confiance dans Amazon.
Comment imaginer qu’il propose d’installer une version qui a plus de 2 ans ? Pour rappel, ils proposent:
Donc la version 8 est suffisamment ancienne, pour qu’il faille passer par une upgrade intermédiaire avec la version 10 pour pouvoir ensuite passer en version 11. Je m’en suis aperçu en cherchant nagios version 3 sans pouvoir le trouver…
J’ai trouvé la procédure dans les forums Amazon:
http://developer.amazonwebservices.com/connect/message.jspa?messageID=141707
En résumé:
Passer à la version 10:
yum update -y yum clean all yum update -y yum clean all rpm -Uhv http://mirrors.kernel.org/fedora/releases/10/Fedora/i386/os/Packages/fedora-release-10-1.noarch.rpmhttp://mirrors.kernel.org/fedora/releases/10/Fedora/i386/os/Packages/fedora-release-notes-10.0.0-1.noarch.rpm yum clean all yum update -y yum clean all yum update -y yum clean all
Passer à la version 11:
rpm -Uhv http://mirrors.kernel.org/fedora/releases/11/Fedora/i386/os/Packages/fedora-release-11-1.noarch.rpmhttp://mirrors.kernel.org/fedora/releases/11/Fedora/i386/os/Packages/fedora-release-notes-11.0.0-2.fc11.noarch.rpm yum clean all yum update -y yum clean all yum update -y yum clean all
Je vous recommande plus que vivement de commencer par là. M’en étant rendu compte en bout de course, j’ai eu droit à plusieurs problèmes de packages, que j’ai désinstallé pendant l’upgrade!
Mysql
Au moins la commande flush privileges ne fonctionnait plus:
mysql> flush privileges;
ERROR 1146 (42S02): Table 'mysql.servers' doesn't exist
J’avais fait une sauvegarde avant de jouer les mises à jour, cette table n’existait pas. J’ai donc fait une réparation automatique et l’upgrade:
mysqlcheck --all-databases --repair -u root -p mysql_upgrade -u root -p
et voilà 🙂
Yum
Depuis l’upgrade, appeler la commande yum donne ces messages juste avant de continuer:
Loaded plugins: dellsysidplugin2, fastestmirror
ERR_OUT: : Bad address
ERR_OUT: : Bad address
ERR_OUT: : Bad address
ERR_OUT: : Bad address
ERR_OUT: : Bad address
J’ai trouvé la solution sur ce blog: http://d.hatena.ne.jp/const/20090909
il s’agit du package smbios-utils et smbios-utils-python, qui servent à récupérer des informations sur le bios. Vu que c’est une machine virtuelle, asta luego:
yum remove smbios-utils-python
(enlève l’autre par dépendance)
Et voilà 🙂
Amazon EC2: Migration effectuée!
Si vous voyez ce message, c’est que la propagation dns s’est faite 🙂
La migration n’a finalement pas été si simple, je posterai prochainement les différents sujets !
Migration de Dedibox vers Amazon EC2
Je suis entrain de préparer ma migration depuis Dedibox pro vers Amazon EC2 (Elastic Cloud Compute). Voici mes premières impressions du nuage Amazon.
Pourquoi je migre
Dedibox a un positionnement étrange. Ils proposent des serveurs performants (Dedibox Pro), mais ils empêchent l’utilisation de leur serveurs comme hyperviseur, ce qui en réduit fortement l’intérêt. Leurs switches coupent les ports qui présentent plus d’une adresse mac, ce qui est le cas avec VMware ESXi ou Hyper-V. Je m’étais rabattu sur un Linux avec VMware Server, mais les VM sont très (trop) lentes. Il en résulte une très bon serveur matériel, mais inexploitable pour de la virtualisation décente. Nul doute que ce soit du hasard, la virtualisation étant le moyen principal de consommer les ressources sur ce type de serveur. OVH propose ESXi, mais le coût est plus fort (notamment avec les 15€/mois pour avoir droit à plusieurs IP publiques, sans parler du raid matériel).
Comme de toute façon mon objectif c’est d’avoir des environnements à la demande, et que c’est la cible d’Amazon EC2, leur offre m’a intéressé rapidement. Au pire, cela va me coûter autant que Dedibox, mais au moins j’en aurai pour mon argent!
Etape 1: Le calculateur Amazon
En parlant d’argent, la première difficulté est de savoir combien ça va coûter! Bon en fait, la première difficulté est de savoir le type d’instance qui convient:
- A la demande: aucun engagement, vous ne payez que la consommation,
- Réservée: vous payer une fois une somme, et ensuite la consommation coûte très peu,
- Spot: vous ne savez pas quand la VM sera démarrée, mais elle coûtera peu (moins qu’à la demande, mais plus que réservée). Il s’agit d’enchère où Amazon solde les ressources non utilisées.
De façon logique, avoir une VM à la demande allumée tout le temps coûte beaucoup plus cher qu’une VM réservée allumée tout le temps.
Le calculateur a un problème d’ergonomie. Par défaut, il inclut dans le prix mensuel (1er mois), les frais qu’on ne paye qu’une fois. Machinalement, on multiplie par 12 et on prend peur!
Pour calculer le coût par mois il faut donc faire (pour une instance small, réservée et allumée en permanence):
(227.50$ + 29.28$ * 12)/12 = 48.23$ / mois
Le coût moyen d’un VM est donc de 34€ par mois en lissé. Car les 227.50$ sont à payer tout de suite. Pour cette somme, on a donc un linux 32 bit, sur une VM ayant les capacités suivantes:
- Processeur: 1VCPU 1,7Ghz : 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit)
- Mémoire: 1,7Go
- Stockage: 160Go de disque
Le truc bizarre, c’est les 44$ de taxes sur la facture (voir tout en bas de l’article)…
Etape 2: Réserver une instance
C’est le moment de se jeter à l’eau!! Avant, j’ai tout de même démarré une VM à la demande pendant une 1/2 heure pour être sûr des performances. On choisi la taille de la VM (small en ce qui me concerne), et le lieu où elle sera instanciée (2 sites aux USA, 1 site en Europe (Irelande). J’ai choisi l’Irlande, afin de m’épargner la latence transatlantique. Après 5 cliques de mulot, on est en pending. Après 10 minutes, le statut passe à active.
Il s’en suit un grand moment de solitude, où l’on cherche sa VM tant attendue sans la trouver! L’aide n’est pas très explicite. Il faut en fait créer une VM à la demande sur le même site géographique, dans la même zone (2 possibles en Irelande). On ne voit nulle part que s’est rattaché à notre réservation, il faut faire confiance au système. On a juste la confirmation au bout de quelques heures, dans le suivi de facturation en voyant qu’elle est facturée à 0,04$ par heure où elle est allumée.
A ce jour, une VM réservée ne peut héberger qu’un Linux. Windows est cantonné aux VM à la demande, et son taux horaire est un peu plus élevé, car la licence Windows est fournie par Amazon.
Le choix de l’architecture (32/64 bit) dépend de la taille de VM.
Etape 3: Créer la VM
Maintenant que j’ai compris qu’il faut créer une VM à la demande et faire confiance, cela est très facile (5 écrans + 5 minutes de patience). On n’installe pas son système d’exploitation, mais on choisit une image toute prête parmi plusieurs centaines. Amazon met en avant 5 Fedora (4 en 32bit et 1 en 64bit), et 3 Windows. L’onglet Community AMIs permet d’élargir le choix à 971 images.
Le découpage du stockage pour Linux sur les images Amazon est 10Go pour le système et 150Go pour le reste. La VM voit deux partitions (/dev/sda1 et /dev/sda2):
Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 10321208 1383500 8413420 15% / /dev/sda2 153899044 6793004 139288416 5% /mnt none 870472 0 870472 0% /dev/shm
Lors de la création de la VM et ultérieurement, Amazon propose inclus un Firewall externe à la VM. Vous pouvez ainsi définir les flux entrant autorisés. C’est très pratique, car on évite un iptable:
Etape 4: Accès à l’instance
Maintenant que l’instance est running, il est temps d’y accéder. Un clic droit sur l’instance propose le menu suivant:
L’option Connect donne l’écran suivant:
Vous l’aurez compris:
- pas d’accès de type console (Get System Log permet de voir le log du boot),
- Pas de mot de passe root, mais l’utilisation d’un certificat (obtenu à la création de la VM).
Sur Windows, un client gratuit pour faire du ssh est Putty. Le problème est que Putty ne reconnait pas le certificat fourni par Amazon. Ce dernier documente la procédure pour le faire fonctionner:
http://docs.amazonwebservices.com/AmazonEC2/gsg/2007-01-19/putty.html
En résumé, il faut utiliser PuttyGen, fourni par les même que Putty, afin de loader le certificat Amazon et le convertir dans le format Putty. Après, ça fonctionne nickel:
Etape 5: Performances
Cet aspect est critique en général et en particulier quand on parle de VM. Bonne nouvelle, je suis très satisfait des performances:
- Réseau: on tire facilement 20Mb/s
- Disque: 121Mo/s en écriture (dd if=/dev/zero of=dd.dd bs=1M)
Pourquoi est-ce qu’Amazon fournie de telles performances ? Parce qu’il facture la consommation réseau (0.170$ par Go de data)! Contrairement aux hébergeurs classique qui facture tout compris, Amazon facturant à la consommation, ne perd pas d’argent si de gros consommateurs utilisent son service. Sur Dedibox, vous pouvez consommer du 100Mb/s non stop sans payer pour autant. Ils mutualisent donc plus fortement les connexions afin de réduire les coûts (avez-vous déjà remarqué qu’au dessus de 50Mb/s il y a un trait rouge sur votre graphe de consommation ?).
Je préfère payer un peu plus cher quand je consomme plus mais avoir cette qualité. On peut suivre presque en temps réel sa facturation à venir:
Etape 6: Les options Amazon
Ils ne sont pas en restent pour vous inciter à prendre plus de service:
- Répartiteur de charge entre vos VM, avec détection de panne sur les VM (facturé au Go de data)
- Stockage supplémentaire utilisable par une VM avec des snapshots (mais indépendant de celle-ci) (facturé au Go et million de IO)
- Adresse IP publique supplémentaire que vous pouvez rattacher à n’importe quelle VM (1/VM) (facturée si non utilisée)
- …
