Ubuntu Touch – Mise-à-jour de OTA-3 à OTA-4

Ayant en ma possession une phablette (Meizu MX4), j’en ai profité pour mettre à jour le système et de passer de la version installée d’origine en 15.04 à 16.04, grâce au super boulot fait par l’équipe d’Ubports qui continue de maintenir le système que Cannonical a délaissé.

Cette mise-à-jour devrait passer comme une lettre à la poste, mais ce n’est pas le cas. Sinon, je n’aurai pas été obligé d’écrire ce blog. Le problème que j’ai rencontré, c’est qu’une fois l’installeur Ubports lancé, le téléphone a redémarré en mode de récupération (recovery mode), puis y est resté figé jusqu’à ce que je redémarre le téléphone.


Si je lance le téléphone en mode recovery et qu’il est pas branché à quoi que ce soit, le même problème se présente.

Plusieurs solutions ont été présentées sur le forum de Uports, dont je vais détailler plus bas. D’ailleurs, j’ai copié la copie d’écran ci-dessus à partir du topic « [solved] Mx4 – Installer blocked at « waiting for recovery mode »

 

Je dois avouer que je ne sais pas à quel moment j’ai réussi à débloquer la situation, mais au final la mise-à-jour s’est bien passé après avoir essayé toutes les suggestions que j’ai trouvées sur internet. De plus, je n’ai pas le temps ni l’envie de m’amuser à flasher le téléphone pour installer la version originale de Ubuntu puis refaire la manipulation. Je vous laisse le soin de laisser des commentaires en précisant ce qui marche dans votre cas.

 

I. Mise-à-jour avec Ubports

La méthode pour mettre Ubntu touch à jour est décrite sur cette page « How to manually upgrade from OTA-3 to OTA-4« . J’ai effectué toutes les manipulations sur une machine qui tourne avec Debian, qui est le seul OS qui ne m’a pas posé de soucie durant toute l’étape de la mise-à-jour.

Tout comme M et Mme Michu, j’ai juste suivi la documentation sur les étapes à suivre pour la mise-à-jour.

J’ai donc commencé par télécharger l’installeur Ubports, puis le lancer et voir ce qu’il en est.

Mon appareil a bien été détecté. Par contre, la copie d’écran ci-dessous, je l’ai effectuée après la mise-à-jour.

Initialement, à la place du bouton « Install », j’avais l’option « Switch to Ubports« . Ce n’est qu’une fois que la mise-à-jour terminée que je n’ai eu droit au bouton Install après avoir reconnecté mon téléphone à Ubports.

Sur cette page, on vous rappelle qu’il faut activer le mode développeur (System Settings > About > Developer Mode) du téléphone si ce n’est pas encore fait.

Cliquer ensuite sur « Change options ».
Comme Channel, sélectionner 16.04/stable, et ne surtout pas cocher « wipe settings » pour ne pas effacer toutes les données du téléphone. A moins que c’est ce que vous souhaitez.

Ensuite, après avoir cliqué sur « Switch to Ubports« , j’ai l’impression que mon ordinateur n’arrive pas à communiquer avec le téléphone. Au niveau de l’installer j’ai un message « Waiting for recovery mode », par contre le téléphone a bien redémarré en mode recovery, mais affiche une barre qui ne progresse pas, comme sur l’image au début de ce topic.

Comme je ne savais pas vraiment quoi faire à ce niveau, j’ai fermé l’application Ubports, puis redémarré le téléphone.

Je ne pense pas que les manipulations que j’ai effectué ci-dessous contiennent la solution à ce problmème, mais à un moment donné, et après avoir effectué une énième tentative de mise-à-jour, j’ai juste redémarré le téléphone sans fermer l’application Ubports en ayant gardé le cable USB connecté. Puis « miracle », l’application Ubports sur mon ordinateur commence à envoyer des paquets de mise-à-jour vers le téléphone que je précise, qui a juste redémarré en mode normal.

 

II. Mise-à-jour via SSH

1. OpenSSH Client

Il est possible de mettre à jour le système en mode ligne de commande sans avoir à installer l’outil Ubports.

Pour celà, il nous faut installer plusieurs outils nécessaires à la gestion d’un téléphone android: openssh, adb et Android SDK.

Pour établir une connection SSH entre votre ordinateur (côté client) et le téléphone (côté serveur), il vous faut créer une paire de clés:

  • Une clé privée à ne jamais partager avec qui que ce soit et
  • Une clé publique qu’il faut ensuite copier dans le répertoire de téléphone

 

J’ai déjà expliqué comment créer une connection SSH dans l’article sur la sécurisation d’une Raspberry Pie, mais une piqûre de rappel ne fera pas de mal.

Sur votre ordinateur, vérifier que le paquet openssh-client est bien installé. Si ce n’est pas le cas, il faut le faire.

mon@ordi$ dpkg -l | grep ssh
mon@ordi$ sudo apt-get install openssh-client

Générer une paire de clés avec l'utilitaire SSH keygen.
mon@ordi$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/matakasi/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

N’ommetez pas la passphrase, qui est une forme de sécurité supplémentaire.

Les clés générées devraient se trouver dans le répertoire ~/.ssh:
– clé privée: id_rsa (vous devez ne jamais fournir cette clé à personne)
– clé publique: id_rsa.pub.
Vérifier que vous avez bien les deux clés (id_rsa et id_rsa.pub) dans le répertoire de votre ordinateur.

~$ cd

~$ ls .ssh
config config.bak id_rsa id_rsa.pub known_hosts known_hosts.old

Une fois que vous avez les clés, il ne reste plus qu’à envoyer une copie de la clé publique vers le téléphone pour que l’ordinateur puisse se connecté à l’appareil.

 

2. ADB (Android Debug Bridge)

Avant de parler des différents outils, il faut comprendre comment un système Android fonctionne.

Il faut savoir que sur système Android les trois partitions suivantes sont présentes:

  • BootLoader (chargeur de démarrage)
    C’est un script qui se lance avant même que le système d’exploitation se lance. Je dois rajouter qu’il n’y a pas vraiment de bootloader type sur un système Android, puisque chaque fabriquant de téléphone fournit une version spécifique du bootloader pour chaque carte mère. Par sécurité, le bootloader sur chaque téléphone Android n’est pas accessible par défaut.Appuyer sur le bouton « Power » et sur la touche du volume vers le Bas pour accéder au mode Bootloader. En bas de l’écran du téléphone vous devrez avoir « FASTBOOT mode… ».L’installation de l’outil Android SDK est nécessaire pour pouvoir accéder au bootloader.
  • Recovery
    Le mode recovery est le mode utilisé manipuler et pour mettre à jour la partition Android ROM.A bootable program on an Android flash memory partition that is used to perform a factory reset or restore the original OS version. In order to install a different OS version (a different ROM), the stock recovery image must be replaced with a custom version such as ClockworkMod Recovery. After rooting the Android, utilities such as ROM Manager install the custom recovery, which is then used to install the custom ROM.Appuyer sur le bouton « Power » et sur la touche du volume vers le Haut pour accéder au mode Recovery. En bas de l’écran du téléphone vous devrez avoir « Recovery mode… ».L’installation de l’outil ADB est nécessaire pour pouvoir accéder au mode recovery.
  • Andoid ROM
    Partition dans laquelle est installée le système d’exploitation, dans notre cas Ubuntu Phone. Par contre, le système Android n’a pas entièrement disparu puisqu’il est placé dans un conteneur LXC pour que le système Ubuntu Touch puisse continuer à communiquer avec, afin de pouvoir bénéficier de tous les pilotes Android pour les différents matériels (carte réseau, caméra, etc.).

Maintenant qu’on a vu comment accéder aux différentes partitions ainsi que les différents outils nécessaire pour les manipulations, il est temps de voir ce que l’on peut faire avec.

Au fait nous n’avons besoin que de l’outil ADB pour la suite, par contre l’outil Android SDK sera automatiquement installé avec ADB.

Lancer l’installation de ADB.

~$ sudo apt install adb

Brancher votre appareil à l’ordinateur, puis vérifier qu’il est bien reconnu.

~$ adb devices
List of devices attached
75HXXXXXXXXX

Créer un dossier .ssh dans le dossier /home/phablet du téléphone.

~$ adb shell mkdir /home/phablet/.ssh

Envoyer une copie de votre clé publique de l’ordinateur vers le téléphone.

~$ adb push ~/.ssh/id_rsa.pub /home/phablet/.ssh/authorized_keys

Modifier les permissions et les groupes des dossiers et sous-dossiers de .ssh

~$ adb shell chown -R phablet.phablet /home/phablet/.ssh

~$ adb shell chmod 700 /home/phablet/.ssh

~$ adb shell chmod 600 /home/phablet/.ssh/authorized_keys

Récupérer l’adresse IP du téléphone à partir du System Settings>Wi-fi> »Votre_réseau_wifi »>IP address (dans mon cas, 192.168.1.6), puis connectez vous en SSH au téléphone.

~$ ssh phablet@192.168.1.6
Welcome to Ubuntu 15.04 (GNU/Linux 3.10.35+ armv7l)

* Documentation: https://help.ubuntu.com/

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

Pour avoir la liste des canaux disponible,

phablet@ubuntu-phablet:~$ sudo system-image-cli –list-channels
[sudo] password for phablet:
b'75HXXXXXXXXX\n'
Available channels:
15.04/devel
15.04/rc
15.04/stable
16.04/community/walid/devel
16.04/devel (alias for: ubports-touch/16.04/devel)
16.04/rc (alias for: ubports-touch/16.04/rc)
ubports-touch/15.04/devel
ubports-touch/15.04/rc
ubports-touch/15.04/stable
ubports-touch/16.04/devel
ubports-touch/16.04/rc
ubports-touch/16.04/stable
ubports-touch/legacy
ubuntu-touch/devel
ubuntu-touch/devel-proposed
ubuntu-touch/devel_rc-propoed
ubuntu-touch/devel_rc-proposed
ubuntu-touch/devel_stable
ubuntu-touch/rc-proposed
ubuntu-touch/stable
phablet@ubuntu-phablet:~$

 

Pour la mise-à-jour vers 16.04 en version stable, il faut utiliser le canal 16.04/stable au lieu de ubports-touch/16.04/stable. Apparement, la liste de canaux n’est pas vraiment à jour.

phablet@ubuntu-phablet:~$ sudo system-image-cli -vvvv --switch 16.04/stable

L’option -vvvv permet d’avoir la mise-à-jour en mode verbeux.

Et voilà, tout devrait être bon maintenant.

 

Sources

How to manually upgrade from OTA-3 to OTA-4
[ADB | FASTBOOT | LINUX COMMANDS] BootLoader, Kernel, Recovery, ROM, Root, Backup
[solved] Mx4 – Installer blocked at « waiting for recovery mode »

 

Publicités

Tout ce qu’il faut savoir sur la gestion des certificats dans vSphere 6.X

Depuis la version 6.x, VMware a simplifié l’utilisation et la gestion des différents certificats dans l’environnement vSphere. Deux composants principaux y ont été introduits:

  • VMCA (VMware Certificate Authority) qui est l’autorité de certification VMware
  • VECS (VMware Endpoint Certificate Services) stocke les certificats et les clés privées

Ces deux composants se trouvent dans vCenter si le PSC y est imbriqué. Par contre, si le PSC est externe au vCenter, VMCA sera installé dans le PSC et VECS dans le vCenter.

Bien que VMCA soit optionnel, VECS par contre est nécessaire pour le bon fonctionnement de l’environnement vSphere. Il n’est pas possible de se passer du VECS.

 

I. VMCA (VMware Certificate Authority)

Le principal risque associé à l’utilisation de SSL et TLS est le détournement des certificats. Afin de parer ce risque, il importe de se doter d’autorités de certifications destinées à valider ou invalider les certificats.

Pour en savoir plus sur les certificats, je vous recommande de lire l’article Protocole SSL et TLS dont j’ai extrait la citation ci-dessus.

En tant qu’autorité de certification (Root CA), VMCA peut fournir quatre types de certificats.

    • « Machine SSL Certificate » utilisé pour créer des sockets SSLs côté serveur, pour assurer une connexion sécurisée de type HTTPS, LADPS etc. entre clients et les différents nodes (vCenter, PSC externe)
    • « Solution User Certificates » pour l’authentification des différents services au vCenter Single Sign-On (SSO) grâce à l’échange de jetons SAML
    • « ESXi Certificates » sont créés automatiquement sur chaque hôte après installation de ESXi. Par contre, une fois l’hôté ajouté au vCenter, VMCA se chargera de lui fournir de nouveaux certificats
    • « Internal Certificates » qui regroupe « vCenter Single Sign-On Signing Certificate », « VMware Directory Service SSL Certificate » (remplacé par Machine SSL Certificate à partir de vSphere 6.5) et « vSphere Virtual Machine Encryption Certificates »

Il faut savoir que VECS ne stocke pas tous les certificats.

  • Les certificats de l’hôte ESXi se trouvent localement dans /etc/vmware/ssl
  • Les certificats internes (Internal Certificates) se trouvent sur le disque de l’utilisateur
  • Les certificats SSLs de machine (Machine SSL Certificates) sont utilisé comme certificat vmdir (vSphere 6.5)

Selon vos besoin, VMware vous propose quatre options pour gérer vos certificats.

  • VMCA Default, VMCA comme Root CA (option proposée par défaut)
  • VMCA Enterprise, utilise VMCA comme CA intermédiaire (Subordinate CA)
  • Custom, désactive VMCA et utilise des certificats personnalisés. Cette option n’est pas recommendée
  • Hybrid, utilise un certificat externe (créé par la companie ou  par un CA tierce) pour gérer les « Machine SSL ». VMCA s’occupera de fournir les certificats aux « Solution Users » et « ESXis »

Les options recommendées par VMware seraient d’utiliser les certificats VMCA par défaut avec ou sans certificats SSL externes (mode hybride) .

Je voudrai rajouter à cette partie que l’intégration des certificats est tellement profonde qu’un problème même mineur au niveau d’un de ces certificats peut rendre votre environnement totalement inutilisable. Il est donc très important de comprendre les concepts de gestion des certificats dans un environnement vSphere afin de pouvoir régler les problèmes basiques très rapidement.

 

II. VECS (VMware Endpoint Certificate Services)

Nous venons de voir quelles sont les différentes options pour générer des certificats pour votre environnement vSphere. VECS se chargera de les placer dans un « magasin de clés » ainsi que les clés privées et d’autres certificats non forcément générés par VMCA lui même.

Dans le VECS il y a plusieurs « Stores ».

  • Machine Endpoint (MACHINE_SSL_CERT), utilisé par le service de proxy inverse sur chaque nœud vSphere (vCenter, PSC externe), mais aussi par vmdir
  • Root CA (TRUSTED_ROOTS, TRUSTED_ROOT_CRLS) contient les tous certificats racines approuvés
  • Solution User, utilisés pour l’authentification avec vCenter Single Sign-On
  • Backup, permet au VMCA de restaurer les certificats juste avant leurs modifications si nécessaire
  • Other, d’autres Stores peuvent y être ajouté dans VECS

Je vous invite à lire l’article « Présentation du magasin de certificats VMware Endpoint » pour en savoir un peu plus sur le sujet.

En ce qui concerne les Solution Users, il faut retenir qu’il y en a quatre quand le PSC est intégré au vCenter.

  • machine
  • vsphere-webclient
  • vpxd
  • vpxd-extension

Quand le PSC n’est pas intégré au vCenter, ce dernier présente toujours quatre Solution Users. Par contre le PS ne présentera que 2.

  • machine
  • vsphere-webclient

Aussi il faut savoir que VPXD est le service de vCenter. VPXD a son propre Store. Dans VPXD-EXTENSION est inclu le reste des services de l’environnement vSphere (Auto Deploy, Inventory Service etc.).

 

III. Gestion des services et des certificats en ligne de commande

VMCA est aussi l’un des trois composant du service d’identité de base VMware et qui sont,

  • Service d’annuaire VMware (VMDIR)
  • Autorité de certification VMware (VMCA)
  • Démon VMware Authentication Framework (VMAFD)

 

1. VMCA

Par défaut, VMCA s’occupe de signer les certificats générés par l’outil CERTOOL du PSC qui se trouve à l’emplacement /usr/lib/vmware-vmca/bin/certool. Cet outil sert particulièrement à effectuer des opérations de gestion de certificats en mode CLI (ligne de commande).

Un autre outil beaucoup plus facile à manipuler pour la gestion des certificats, CERTIFICATE-MANAGER se trouve dans /usr/lib/vmware-vmca/bin/certificate-manager.

 

2. VMAFD

Pour la gestion des certificats dans VECS, vous pouvez utiliser l’outil VECS-CLI du PSC à l’emplacement /usr/lib/vmware-vmafd/bin/vecs-cli.

Pour afficher la liste des Store en ligne de commande, taper

/usr/lib/vmware-vmafd/bin/vecs-cli store list

Si la commande pour gérer le VECS se trouve dans le sous dossier de vmware-vmafd, ce n’est pas un hasard puisque le VECS dépend du démon VMAFD (VMware Authentication Framework Daemon).

 

Un autre outil, DIR-CLI nous permet de gérer les certificats et les mots de passe dans stocké dans vmdir (VMware Directory Service). Le chemin d’accès pour lancer dir-cli se trouve dans /usr/lib/vmware-vmafd/bin/dir-cli.

Pour précision, dir-cli ne fait pas que gérer les certificats. Pour la liste des options, je vous renvoie au «  Référence des commandes dir-cli« .

 

3. VMDIR

Vmdir est un service d’annuaire LDAP de VMware. Non seulement il stocke les informations relatives à l’authentification des utilisateurs et des différents services, mais vmdir est également utilisé pour la gestion des certificats, entre autre ceux utilisés pour autoriser la connection entre plusieurs PSCs.

De ce fait, dans un environnement avec plusieurs PSCs, les connections entre plusieurs nœuds (vCenter et PSCs externe ou non) se fait grâce à l’authentification de chacun de ces nœuds  via des certificats instaurés dans vmdir.

 

4. Résumé sur les outils de gestion des certificats VMware en ligne de commande

Dans /usr/lib/vmware-vmca/bin/

certool, gère les certificats VMware
certificate-manager; Gère les certificats des serveurs PSC et vCenter

Dans /usr/lib/vmware-vmafd/bin/

vecs-cli, gèrer le magasin de certificats VMware (VECS)
dir-cli, gère les Solution Users, les certificats et les mots de passe stockés dans vmdir

 

Références

Protocole SSL et TLS
Where vSphere Uses Certificates
Everything You Should Know About Certificate Management in vSphere 6
Configure and manage VMware Endpoint Certificate Store
VMware Certificate Authority overview and using VMCA Root Certificates in a browser
Qu’est-ce que l’authentification basée sur les certificats ? Pourquoi l’utiliser ?

Topologie complète avec les icones de VMware

Chap 1. Configuration d’un serveur DNS-DHCP avec Zentyal
Chap 2. Installation de vSphere 6.5 dans Proxmox
Chap 3. Nested ESXi – ESXi imbriqué dans un autre ESXi
Chap 4. Configuration du réseau et de pfSense dans vSphere 6.5
Chap 5. FreeNAS – Configuration d’un serveur NFS avec VMware vSphere 6.5
Chap 6. FreeNAS – Configuration d’un SAN iSCSI avec VMware vSphere 6.5
Annexe. Topologie complète avec les icones de VMware

ANNEXE. Topologie complète avec les icones de VMware

Pour les adeptes des belles icônes, ci-dessous la topologie complète de mon lab avec les icônes officiles de VMware que vous pouvez récupérer ici.

A chaque fois que vous utilisez ces icônes, vous êtes dans l’obligation de faire mention des conditions d’utilisation de VMware.

This document was created using the official VMware icon and diagram library. Copyright © 2012 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents.

VMware does not endorse or make any representations about  third party information included in this document, nor does the inclusion of any VMware icon or diagram in this document imply such an endorsement.

C’est pour celà que je m’en suis passé pour les articles précédents.

FreeNAS – Configuration d’un SAN iSCSI avec VMware vSphere 6.5

Chap 1. Configuration d’un serveur DNS-DHCP avec Zentyal
Chap 2. Installation de vSphere 6.5 dans Proxmox
Chap 3. Nested ESXi – ESXi imbriqué dans un autre ESXi
Chap 4. Configuration du réseau et de pfSense dans vSphere 6.5
Chap 5. FreeNAS – Configuration d’un serveur NFS avec VMware vSphere 6.5
Chap 6. FreeNAS – Configuration d’un SAN iSCSI avec VMware vSphere 6.5
Annexe. Topologie complète avec les icones de VMware

Chap 6. FreeNAS – Configuration d’un SAN iSCSI avec VMware vSphere 6.5

Cette partie requiert un peu plus d’attention si vous n’êtes pas familier avec le domaine. Avant de suivre étape par étape la configuration de FreeNAS et du vCenter, je vais vous demander de lire et même de relire l’article en entier afin de comprendre où l’on veut arriver.

Commençons par la topologie du réseau.


Je vous fait un zoom sur la partie dont je vais consacrer ce chapitre.

I. Configuration de FreeNAS

1. Réseau

Configurer les deux interfaces réseaux dans Network > Interface > Add Interface, comme suit.


N’oubliez pas de rajouter la MTU à 9000 pour la jumbo frame.

On se place ensuite dans Sharing > Block (iSCSI).

Ensuite, il faut ajouter les éditer et ajouter les informations pour accéder à notre stockage de données dans l’ordre suivante.

 

2 Stockage de données

2.1. Target Global Configuration

Pour qu’une communication entre l’hôte ESXi et le storage SAN ait lieu, il nous faut un Initiateur et un Target.

Le rôle d’Initiateur est attribué à l’hôte ESXi, tandis que celui de Target (ou cible) est attribué au SAN. Pour identifier un node iSCSI, il lui faut attribuer un nom: un du côté de l’hôte et un autre du côté du SAN.

Par convention, le nom des nodes devraient commencer par IQN ou EUI.

Côté cible, on a: iqn.2005-10.org.freenas.ctl.

Côté initiateur, qu’on verra plus loin, on a: iqn.1998-01.com.vmware.

2.2. Portals

Ajouter le ou les adresses IPs pour contacter le serveur SAN.

2.3. Initiators

Configurer les règles d’accès au SAN. Ici, j’ai choisi l’option la plus simple en autorisant tout node contactant le serveur SAN à accéder à toutes les ressources disponibles.

 

2.4. Targets

Donner un nom au Target, puis sélectionner le portal créé plus haut.

2.5. Extents

Sélectionner le disque à partager.

2.6. Associated target

Associer au target le disque qu’on vient de créer.

II. Configuration des ESXis

1. Réseau

Pour la partie réseau, je vous renvoie au Chap 4. dans lequel j’ai détaillé toutes les étapes à suivre pour configurer le vswitch approprié.

2 Stockage de données

2.1. Ajout d’un adapter iSCSI

Pour atteindre le SAN, il nous faut un Initiator et un Target. L’initiator transporte les requêtes SCSI, initié par l’ESXi hôte. Et le target c’est le FreeNAS.

Il faut savoir que dans un environnement vSphere, on distingue deux types d’adapter iSCSI:

  • Software iSCSI adapter
  • Hardware iSCSI adapter

Comme le nom l’indique, le Software adapteur est un adapteur qui est géré directement par le vmkernel et utilise votre carte réseau LAN pour faire passer le traffic.

Concernant l’adapteur physique, ici encore il y a deux types:

  • Independent Hardware iSCSI adapter (exemple, QLogic QLA4052 adapter)
  • Dependent Hardware iSCSI adapter (exemple, iSCSI licensed Broadcom 5709 NIC)

Ceux sont deux cartes dédiés aux traffics SCSI, le premier est un HBA alors que le second est un Accélérateur de trafic.

Dans mon lab, je n’ai pas besoin d’une carte dédiée pour accéder à mon storage SAN.

Commençons par ajouter l’adapteur de type Software iSCSI.

Sélectionner Storage Adapters > Add new storage adapter > Software iSCSI adapter.


Vérifier que l’initateur est bien créé, et que le status de l’adapteur affiche bien qu’il est activé (enabled) dans les propriétés de l’adapteur.

2.2 Ajout de l’entrée vers l’iSCSI SAN

Maintenant que l’initiateur est configuré, il faut ajouter le lien pour accéder au Target.

Dans l’onglet Target, sélectionner Dynamic Discovery > Add.

Ajouter les addresses IPs pour accéder au storage SAN,


Puis valider l’ajout en fesant un scan du Storage adapter de l’hôte concerné, ou tout simplement en rescannant tous les hôtes.

Vérifier ensuite que le target s’affiche bien dans l’onglet Static Discovery.


Les chemins d’accès au storage SAN devraient s’afficher comme actifs.


Dans l’onglet Devices, on devrait voir les informations du FreeNAS.

Dernière étape, le network binding. Vous devriez pouvoir ajouter les deux network adapteurs pour le traffic SCSI.

FreeNAS – Configuration d’un serveur NFS avec VMware vSphere 6.5

Chap 1. Configuration d’un serveur DNS-DHCP avec Zentyal
Chap 2. Installation de vSphere 6.5 dans Proxmox
Chap 3. Nested ESXi – ESXi imbriqué dans un autre ESXi
Chap 4. Configuration du réseau et de pfSense dans vSphere 6.5
Chap 5. FreeNAS – Configuration d’un serveur NFS avec VMware vSphere 6.5
Chap 6. FreeNAS – Configuration d’un SAN iSCSI avec VMware vSphere 6.5
Annexe. Topologie complète avec les icones de VMware

Chap 5. FreeNAS – Configuration d’un serveur NFS avec VMware vSphere 6.5

Maintenant que la partie réseau est configurée, attaquons la partie  stockage de données.

Dans cette partie, je vais utiliser freeNAS comme serveur NAS.


I. Configuration de la machine virtuelle

Dans le réseau, il me faut juste connecter les deux hôtes ESXi virtuels au serveur NAS.


Concernant les différents disques, il faut:
– un disque de 8 Go pour installer le système d’exploitation
– un disque de 50 Go pour NFS
– un autre disque de 50 Go pour iSCSI

Pour l’installation de freeNAS, c’est aussi simple que celle de l’installation de pfSense. Accepter les configurations par  défaut, et si vous n’êtes pas sur de vous, jettez un coup d’oeil à la documentation.

II. Configuration du serveur NAS

1. Système

Dans cette fenêtre, vous pouvez ajouter le nom d’hôte (FQDN)

Ou modifier le mot de passe root.

2. Réseau

Dans Global config, vous pouvez ajouter le nom de la machine ainsi que l’adresse IP de la passerelle.

Sélectionner ensuite Interfaces pour configurer les différentes interfaces.

Une option que j’ai trouvé afin d’être sur de tomber sur la bonne interface est de supprimer toutes les cartes réseaux du VM, de n’en garder que deux puis de rajouter un nouvel interface quand il y a besoin.
Pour information, le rajout d’une nouvelle carte doit être suivit d’un reboot du VM, sinon vous ne verrez par cette carte dans l’interface du serveur freeNAS.

L’option de déconnecter ces cartes pour le VM concerné ne résoud pas le problème puisque l’interface de freeNAS arrive quand même à retrouver toutes les cartes disponibles pour cette VM.

Pour ajouter une interface, cliquez sur Add interface puis d’ajouter les informations demandées.

Assigner une adresse IP à l’interface puis lui donner un nom afin que vous sachiez à quoi correspond chaque interface.


Laisser les autres options par défaut. Vous devriez avoir quelque chose de similaire, ici j’ai aussi configuré les deux autres interfaces iSCSI, mais ce n’est pas l’objet de ce topic.


Pinger ensuite cette interface à partir d’un des ESXi embarqués ou à partir d’une autre VM du même réseau, pour vérifier que c’est la bonne interface qui est configurée.

3. Stockage de données (storage)

Volume name: Datastore1 (vous pouvez lui donner un autre nom)
Volume to extend: choisissez l’un des deux disques de 50 Go
Drag and drop this to resize: tirez le curseur au maximum pour utiliser la totalité du disque

Cliquer  ensuite sur Add volume pour valider.

4. Partage des données

Sélectionner Share > UNIX (NFS) > Add Unix (NFS) share.


Si vous n’êtes pas sûre du chemin où se trouve votre datastore, cliquez sur Browse, sélectionner le dossier au plus bas niveau après avoir cliqué sur +, puis valider.

Cliquer ensuite sur Advanced Mode pour sélectionner le Maproot User: root.

III. Configuration de vCenter

L’ajout d’un datastore NFS ne demande pas trop d’effort.

Une fois que vous avez Storage > New Datastore, accepter toutes les options par défaut.

Ici, choisissez l’option NFS.

Entrez les informations pour se connecter au serveur NFS.

Il nous faut l’adresse IP du serveur (192.168.1.2), ainsi que le chemin pour accéder au datastore. C’est ce qu’on a rajouté dans Partage de donnée (/mnt/Datastore1) dans freeNAS.

Sélectionner le ou les ESXi qui auront accès au datastore.

Et voilà, le tour est joué.
Ne prenez pas en compte le Datastore-iSCSI, puisque je vais en parler au prochain chapitre.

Configuration du réseau et de pfSense dans vSphere 6.5

Chap 1. Configuration d’un serveur DNS-DHCP avec Zentyal
Chap 2. Installation de vSphere 6.5 dans Proxmox
Chap 3. Nested ESXi – ESXi imbriqué dans un autre ESXi
Chap 4. Configuration du réseau et de pfSense dans vSphere 6.5
Chap 5. FreeNAS – Configuration d’un serveur NFS avec VMware vSphere 6.5
Chap 6. FreeNAS – Configuration d’un SAN iSCSI avec VMware vSphere 6.5
Annexe. Topologie complète avec les icones de VMware

Chap 4. Configuration du réseau et de pfSense dans vSphere 6.5

 

I. Reconfiguration des différents serveurs, physique et virtuels

Le chapitre précédent présente la base du lab à créer. Cependant, je ne le trouve pas parfait et il y a encore quelques améliorations qu’on peut y ajouter. Entre autre, il n’y a plus besoin d’accéder à vCenter directement en dehors du lab et se fier à notre parefeux qui fait office de passerelle (pfSense).

Concernant l’installation de pfSense, je vous recommande de lire la documentation. Il n’y a pas grand chose à faire, à part accepter toutes les options proposées, et de les laisser tel quelles en gardant tout par défaut.

1. Ajout d’un nouvel adapter pour l’ESXi physique

Jusqu’ici, la gestion de l’ESXi host se fait à partir du réseau physique en 127.X.Y.Z. Afin d’éviter au vCenter de passer par multiple réseau afin de gérer cet hôte, j’ai décidé d’ajouter ce dernier dans le même réseau que le vCenter.

L’hôte physique ESXi a donc besoin d’un adapteur (carte réseau virtuelle) pour pouvoir communiquer avec le réseau du lab en 192.168.1.0/24.

Pour celà,

  • Créer un nouveau port group que j’ai appelé « ESXi host mgt », dans vSwitch1. Vous pouvez l’appeler autrement
  • Ne pas attacher une carte physique au port nouvellement créé. Il n’y en a pas besoin vu que tout le traffic passera par pfSense

Pour rappel, toutes les machines virtuelles se trouvent aussi dans le réseau géré par vSwitch1, c’est pour celà que j’ai choisi cette option pour ajouter notre hôte auquel j’ai assigné l’adresse IP 192.168.1.111.

Verifier que vous pouvez y acceder à la gestion de l’ESXi physique à partir de n’importe quel VM du réseau 192.168.1.0.

Une fois que l’hôte est joignable par le vCenter, il faut le supprimer de l’inventaire de ce dernier pour l’ajouter avec l’adresse IP dans le même réseau que le vCenter lui même.

2. Déconnecter l’hôte

Pour ce faire, sélectionner l’ESXi physique puis sélectionner Déconnecter avant de cliquer sur Supprimer de l’inventaire du vCenter.

3. Reconnecter l’hôte

Une fois c’est fait, rajouter l’hôte en utilisant l’adresse IP du réseau du lab, ici 192.168.1.111.

4. Supprimer les adapteurs non utilisés des différents VMs

Vu que tout notre traffic passera par pfSense, vous pouvez supprimer l’adapter VM network pour chacunes des VMs qui l’utilisent.

Dans vSwitch0, pfSense devrait être la seule machine virtuelle à y être présente.

Pourquoi s’embêter à faire toutes ces étapes, alors qu’on aurait pu le faire depuis le précédent chapitre? Je vous rappelle que ceci est une initiation à l’utilisation de l’environement vSphere. En passant par toutes ces étapes, celà m’a permis de mieux comprendre comment s’y prendre pour créer un lab fonctionnel.

II. Configurer pfSense

Une fois pfSense installé, il s’autoconfigure en questionnant votre DHCP.

S’il n’arrive pas à récupérer une adresse IP, ce n’est pas grave. Vous pouvez le faire manuellement.

Un petit conseil, vu qu’il y a deux cartes et que vous ne saurez pas laquelle qui est attachée à quelle interface, je vous conseille de ne configurer qu’une interface à la fois. Une fois ceci fait, et que tout marche bien, vous pouvez ensuite configurer en toute sécurité l’autre interface.
Un autre conseil, si ce n’est pas la bonne carte qui est attachée à l’interface du pfSense, au lieu de configurer l’interface avec l’option 1, modifier l’interface directement au niveau de la configuration de la machine virtuelle. C’est comme çà que vous devrez procéder pour tout problème d’interface.

Une fois que vous avez accès à l’interface de gestion du pfSense, les identifiants par défaut sont: admin/pfsense.

1. Système

Dans System>General Setup,

  • Dans le champ hostname, j’ai donné le nom de la VM, avec pour domaine « mylab.local » qui est le nom de domaine que j’utilise via Zentyal
  • Pour la partie DNS Serveurs, vu que j’utilise un des labs de mon entreprise, je dois ajouter l’adresse IP du DNS forwarder qui est un serveur DNS dans le même réseau que l’ESXi physique, sans oublier de rajouter mon domaine local. Aussi je dois préciser la passerelle pour accéder à internet.

2. Interfaces

Configurer l’interface WAN, avec l’adresse IP que vous voulez utiliser pour accéder à pfSense sur le réseau local du lab.

Très important, décocher l’option « block private network », sinon vous n’aurez pas accès au pfsense en dehors de votre lab.

En ce qui concerne l’interface LAN, il n’y a pas grand chose à modifier à part qu’il faut choisir une interface statique.

3. Parefeux

Je vais simplifier les règles du parefeux pour avoir accès à mon environment. En entreprise, il faut prendre toutes les précautions afin de ne pas exposer votre réseau par inadvertance à d’enventuel accès de l’extérieur.

Une fois ces règles appliquées, vous devriez avoir deux règles au total.

 

III. Configuration de réseau pour la préparation à la connection avec freeNAS

Dans cette partie, je vais préparer et configurer les différents switchs des ESXi embarqués (nested ESXi) afin de pouvoir accéder au serveur de données freeNAS.

Après l’installation de l’ESXi, vous ne devriez avoir qu’un seul switch de disponible (vswitch0). Je vais garder ce switch pour la communication des différents VM que je vais ajouter à cet hôte embarqué.

De ce fait, je vais créer un nouveau switch pour la communication entre l’hôte embarqué et freeNAS.

Dans les configurations au niveau du Virtual Switch, sélectionner Add Host networking.

Ensuite, choisissez l’option VMkernel Network Adapter.

Et c’est à ce niveau que vous pouvez créer un nouveau switch virtuel.

Sélectionner ensuite les trois carters réseaux, un pour NFS et les deux autres pour le traffic iSCSI.

1. Création d’un switch virtuel et ajout du premier port group pour les traffics iSCSIs

Vu qu’il y a deux cartes pour les traffics iSCSI, il va falloir ajouter deux ports groupes, iSCSI1 et iSCSI2.

Appliquer une adresse IP statique à ce port.

Le traffic iSCSI1 passera par le réseau 172.16.10.0/24, et celui de iSCSI2 par 172.16.20.0/24.


Vérifier que tout est bon avant de valider la création de vswitch1 ainsi que du port group iSCSI1.


Assigner l’un des adapteurs physiques au port group nouvellement créé.

L’idée ici est de ne faire passer qu’un type de traffic par adapteur physique.

Editer les configurations de l’iSCSI1.


Garder toutes les options par défaut, par contre au niveau du Teaming and Failover, sélectionner Override, puis déplacer les adapteurs non utilisé pour ce traffic dans Unused Adapter.


Vérifier ensuite que le port groupe iSCI1 n’est connecté qu’à un seul adapteur physique.

Ce n’est pas tout, éditer ensuite la configuration de l’adapteur physique pour changer la MTU en 9000 (jumbo frame), puisqu’on va configurer de même les interfaces de freeNAS.


Modifier de ce fait le vmkernel adapteur de l’iSCSI1 afin d’accepter les jumbo frames.

2. Ajout du deuxième port group pour traffic iSCSI et du troisième pour le traffic NFS

Il suffit de suivre les mêmes étapes que précédement.


Par contre, il n’y a plus besoin de créer un nouveau switch virtuel. On va utiliser vswitch1.


Je ne vais pas refaire toute les étapes pour ajouter le port groupe iSCSI2. Revoyez les étapes ci-dessus.

Créer le port group NFS pour les traffics NFS.


Tous les serveurs qu’un réseau devrait avoir une adresse IP statique et non dynamique.

Le traffic NFS passera par le réseau 172.31.255.0/24.


Editer ensuite le port group NFS pour utiliser l’adapteur qui lui est dédié.


Configurer le vmkernel (vmk3) avec un MTU de 9000 pour les jumbo frames.

 

Et voilà, je pense que c’est l’une des parties les plus « dure » du lab. Une fois le réseau est configuré comme il faut, vous devriez être bon pour la suite.

vSphere 6.5 – Désactivation de TLS 1.0 et 1.1

Un petit sujet pour vous aider à désactiver les versions obsolètes de TLS pour votre environement vSphere 6.5. Ce topic n’apporte rien de plus qu’un éclaircissement de l’article KB2147469, ainsi que quelques astuces qui pourraient vous aider à mener à bien cette opération.

Pour information, TLS 1.0 et 1.1 seraient automatiquement désactivés à partir de vSphere 6.7.

Je vous propose de lire cet article qui explique pour quelles raisons désactiver ces versions, ainsi que celui-ci qui explique ce que c’est que TLS/SSL.

Avant d’aller plus loin, noter que vous ne pouvez désactiver TLS qu’à partir d’un environment qui tourne avec la même version. En gros, si vous avez un vCenter en 6.5, vous ne pouvez désactiver TLS que pour ESXi 6.5, et non avec ESXi 6.0 ou 5.5.

Cependant, il y a une petite exception.
Avec un vCenter en 6.5 U2, vous pouvez désactiver TLS sur un ESXi en 6.0 U3.

Les ordres de suppressions de TLS dans le cas de l’utilisation de l’Appliance:
1. vCenter
2. ESXi
3. PSC

 

Commencer par télécharer le packet RPM vSphereTlsReconfigurator que vous allez placer dans le dossier /tmp du vCenter, puis lancer l’installation du packet.

cd /tmp

rpm -Uvh VMware-vSphereTlsReconfigurator-version-build_number.x86_64.rpm

Une fois le paquet installé, les scripts devraient se trouver dans:

/usr/lib/vmware-vSphereTlsReconfigurator/VcTlsReconfigurator

/usr/lib/vmware-vSphereTlsReconfigurator/EsxTlsReconfigurator

 

I. VCSA et PSC

La désactivation de TLS du VCSA (vCenter Appliance) et du PSC se procède de la même façon. Je l’ai déjà dit plus haut, mais je le répète encore une fois. Il ne faut pas désactiver TLS sur le PSC tant que ce n’est pas fait sur VCSA et les différents ESXis.

 

Garder une copie de vos configurations.

cd /usr/lib/vmware-vSphereTlsReconfigurator/

cd VcTlsReconfigurator

./reconfigureVc backup

 

Désactiver les versions TLS v1 et 1.1.

./reconfigureVc update -p TLSv1.2

 

Une fois c’est fait, vous devrez avoir.

 

II. ESXi

Placer vous dans le dossier EsxTlsReconfigurator.

cd /usr/lib/vmware-vSphereTlsReconfigurator/EsxTlsReconfigurator

Vous avez le choix entre la désactivation du TLS par server ou au niveau du cluster.

Dans le cas où vous souhaitez faire la manipulation par server,

./reconfigureEsx vCenterHost -h <ESXi_Host_Name> -u <Administrative_User> -p TLSv1.2

Pour la désactivation au niveau du cluster, il suffit de remplacer vCenterHost par vCenterCluster.

./reconfigureEsx vCenterCluster -c <Cluster_Name> -u <Administrative_User> -p TLSv1.2

 

N’oubliez pas de redémarrer les serveurs ESXi pour que les modifications prennent effet.

III. Combinaison ESXi 6.0u3 avec VCSA 6.5u2

Vous allez remarquer vous le même script utilisé pour désactiver TLS sur VCSA 6.5 ne fonctionnera pas avec un ESXi 6.0.

Validating product version at: "localhost".
Validating ESXi host: "HOST NAME".
Host "HOST NAME" is of unsupported version: "6.0".
Least supported version: "6.5".
Skipping reconfiguration of ESXi host "HOST NAME"

1. Télécharger cette fois ci TLS Reconfigure 6.0 U3

2. Désinstaller l’utilitaire pour 6.5 dans VCSA

rpm -e VMware-vSphereTlsReconfigurator-6.5.0-7766806.x86_64

3. Installer l’utilitaire TLS reconfiguration utility 6.0 dans un dossier /tmp du VCSA

rpm -Uvh VMware-vSphereTlsReconfigurator-6.0.0-5051284.x86_64

4. Déconnecter l’hôte ESXi à reconfigurer (n’enlevez surtout pas l’hôte de l’inventaire du vCenter)

5. Remplacer « vCenterHost » par « ESXiHost » dans la commande vue plus haut.

./reconfigureEsx ESXiHost -h <ESXi_Host_Name> -u root -p TLSv1.2

6. Reconnecter ESXi à vCenter

7. Placer l’hôte en maintenance mode

8. Rebooter le server

 

IV. Vérification

Vérifier que TLS est bien désactivé. Pour celà, à partir de n’importe quelle machine qui tourne sous linux, et même à partir du vCenter, lancer la commande ci-dessous.

openssl s_client -connect <ESXi_Host_Name>:443 -tlsX

Remplacer X par 1, 1_1 ou 1_2.

 

openssl s_client -connect <ESXi_Host_Name>:443 -tls1

openssl s_client -connect <ESXi_Host_Name>:443 -tls1_2

Vous devriez avoir une erreur « ssl handshake failure » si la version du TLS n’est pas supportée ou, est désactivée.

 

Sources:

Protocole SSL et TLS
Dépréciation de TLS v1.0/1.1 et application de TLS v1.2
Ports That Support Disabling TLS Versions
Managing TLS protocol configuration for vSphere 6.5/6.7 (2147469)
How can I verify if TLS 1.2 is supported on a remote web server from the RHEL/CentOS shell?