Différences

Ci-dessous, les différences entre deux révisions de la page.

--- wiki:documentation:groupadmin [2018/03/09 21:57]
abelard-a [Cas particulier de Windows]
+++ wiki:documentation:groupadmin [2020/02/13 10:06] (Version actuelle)
abelard-a [Modifier les règles de sécurité réseau d'une VM préalablement créée]
@@ Ligne 1: / Ligne 1: @@
 ====== Guide de l'administrateur de groupe ======
-A chaque composantes qui en fait la demande est affecté un groupe dyna permettant l'accès à la plateforme IaaS: ''DSIN-ACL-IAAS-<composante>'':
+À chaque composante qui en fait la demande est affecté un groupe dyna permettant l'accès à la plateforme IaaS : ''DSIN-ACL-IAAS-<composante>'' :
   * DSIN-ACL-IAAS-BU
   * DSIN-ACL-IAAS-TERTRE
@@ Ligne 8: / Ligne 8: @@
   * ...
   *
-A chaque groupe dyna correspond un groupe sur la plateforme IaaS auquel est affecté un certain nombre de ressources (quota).
+À chaque groupe dyna correspond un groupe sur la plateforme IaaS, auquel est affecté un certain nombre de ressources (quota).
 <alert type="info">
-Actuellement il est prévu que chaque composante puisse bénéficier de base des ressources suivantes:
+Actuellement, il est prévu que chaque composante puisse bénéficier de base des ressources suivantes :
   * 10 VM
@@ Ligne 17: / Ligne 17: @@
   * 1To de stockage
 </alert>
-Dans chaque groupe IaaS un administrateur est responsables de l'affectation des ressources à ses utilisateurs.
+Dans chaque groupe IaaS, un administrateur est responsable de l'affectation des ressources à ses utilisateurs.
 ===== Le rôle de l'administrateur de groupe =====
-En ajoutant au groupe dyna un de ses utilisateur (enseignant, chercheurs, etc.), l'administrateur lui donne automatiquement accès à la plateforme IaaS. Il peut ensuite lui affecter des ressources (VM, disque, CPU, etc.). L'utilisateur peut alors créer et gérer son ou ses serveur(s) virtuel(s).
+En ajoutant au groupe dyna un de ses utilisateurs (enseignant, chercheur, etc.), l'administrateur lui donne automatiquement accès à la plateforme IaaS. Il peut ensuite lui affecter des ressources (VM, disque, CPU, etc.). L'utilisateur peut alors créer et gérer son ou ses serveur(s) virtuel(s).
 L'administrateur assiste ensuite ses utilisateurs dans la gestion de leurs ressources.
-L'administrateur de groupe a accès à une interface dediée: l'interface "groupadmin"
+L'administrateur de groupe a accès à une interface dédiée : l'interface "groupadmin".
 ===== L'interface groupadmin =====
-l'interface groupadmin n'est utile que pour gérer les utilisateurs du groupe. Au quotidien, la vie "Utilisateur" est plus complète.
+L'interface groupadmin n'est utile que pour gérer les utilisateurs du groupe. Au quotidien, la vue "Utilisateur" est plus complète.
 ===== L'interface utilisateur =====
@@ Ligne 35: / Ligne 35: @@
 ==== Modifier les règles de sécurité réseau d'une VM préalablement créée ====
-Lorsqu'une VM est instanciée, si l'utilisateur n'a pas modifié les groupes de sécurité, les règles par défaut s'appliquent (au moment de la rédaction de cette documentation celles-ci n'autorisent que le 22 et l'icmp en entrée). L'utilisateur peut donc décider à posteriori de modifier ces règles pour adapter la sécurité de sa VM à l'usage qu'il fait de celle-ci.
+Lorsqu'une VM est instanciée, si l'utilisateur n'a pas modifié les groupes de sécurité, les règles par défaut s'appliquent (au moment de la rédaction de cette documentation, celles-ci n'autorisent que le 22 et l'icmp en entrée). L'utilisateur peut donc décider a posteriori de modifier ces règles pour adapter la sécurité de sa VM à l'usage qu'il fait de celle-ci.
-Malheureusement, une limitation de l'interface web fait qu'il n'est pour l'instant pas possible d'ajouter simplement des règles de sécurité à une VM qui a déjà été instanciée. Pour pouvoir modifier, ajouter ou supprimer les règles existante, il faut détacher l'interface réseau puis la réattacher en y ajoutant les règles de sécurité voulues.
+Malheureusement, une limitation de l'interface web fait qu'il n'est pour l'instant pas possible d'ajouter simplement des règles de sécurité à une VM qui a déjà été instanciée. Pour pouvoir modifier, ajouter ou supprimer les règles existantes, il faut détacher l'interface réseau, puis la réattacher en y ajoutant les règles de sécurité voulues.
-Sur une VM ayant les règles par défaut:
+Sur une VM ayant les règles par défaut :
 {{ :wiki:documentation:ajouter-regle-secu0.png |}}
-Il faut donc commencer par détacher l'interface réseau active. Pour ce faire, il n'est pas nécessaire d'interrompre le fonctionnement de la VM, la modification peut se faire à chaud. Il faut donc cliquer sur le lien ''Détacher'' :
+Il faut donc commencer par détacher l'interface réseau active. Pour ce faire, il n'est pas nécessaire d'interrompre le fonctionnement de la VM. La modification peut se faire à chaud. Par contre, une fois le processus achevé, il faut redémarrer la VM pour prendre en compte la modification. Il faut donc cliquer sur le lien ''Détacher'' :
 {{ :wiki:documentation:ajouter-regle-secu1.png |}}
-Une fois l'interface réseau supprimer, il faut donc en réattacher une nouvelle en cliquant sur le bouton ''Attacher une interface réseau''
+Une fois l'interface réseau supprimée, il faut donc en réattacher une nouvelle en cliquant sur le bouton ''Attacher une interface réseau''.
 {{ :wiki:documentation:ajouter-regle-secu2.png |}}
-Il faut ensuite choisir le réseau dans lequel sera l'interface **puis déplier les options avancées** puis scroller jusqu'en bas de celles-ci pour enfin choisir les règles de sécurité à appliquer à l'interface:
+Il faut ensuite choisir le réseau dans lequel sera l'interface, **puis déplier les options avancées**, puis scroller jusqu'en bas de celles-ci pour enfin choisir les règles de sécurité à appliquer à l'interface :
 {{ :wiki:documentation:ajouter-regle-secu3.png |}}
+<alert type="warning">
+Si l'ajout d'un groupe de sécurité oblige de détacher et réattacher l'interface réseau, la modification d'un groupe de sécurité est transparent. Il est donc fortement conseillé de prévoir un groupe de sécurité par VM en production dans lequel des règles supplémentaires pourront être ajoutées sans avoir à interrompre la connectivité de la VM.
+</alert>
 ===== Gérer les utilisateurs de sa composante =====
-L'administrateur de composante a la résposabilité de la gestion des utilisateurs de sa composante. Il a donc à sa charge les autorisation d'accès et les quotas de ses utilisateurs.
+L'administrateur de composante a la responsabilité de la gestion des utilisateurs de sa composante. Il a donc à sa charge les autorisations d'accès et les quotas de ses utilisateurs.
 ==== Autoriser un utilisateur à accéder au service ====
-Le contrôle d'accès se fait grâce à un groupe Dyna pour chaque composante. Les groupes sont nommés de la façon suivante:
+Le contrôle d'accès se fait grâce à un groupe Dyna pour chaque composante. Les groupes sont nommés de la façon suivante :
 **DSIN-ACL-IAAS-<composante>**
-Par exemple: DSIN-ACL-IAAS-BU, DSIN-ACL-IAAS-EPUN, etc.
+Par exemple : DSIN-ACL-IAAS-BU, DSIN-ACL-IAAS-EPUN, etc.
-Ces groupes sont affectés, dans dyna, aux différentes structures permettant ainso aux correspondants dyna de cette structures d'ajouter et supprimer des utilisateurs en toute autonomie.  Dès qu'un utilisateur est ajouté dans un groupe dyna IaaS il est automatiquemen affecté au bon groupe sur la plateforme IaaS. Il est donc possible de lui affecter une part du quota de la composante.
+Dans dyna, ces groupes sont affectés aux différentes structures, permettant ainsi aux correspondants dyna de cette structure d'ajouter et supprimer des utilisateurs en toute autonomie. Dès qu'un utilisateur est ajouté dans un groupe dyna IaaS, il est automatiquement affecté au bon groupe sur la plateforme IaaS. Il est donc possible de lui affecter une part du quota de la composante.
 ==== Affecter un quota à un utilisateur ====
-L'administrateur de la composante peut donner un sous ensemble des ressources de la composante, par exemple pour le rendre autonome. Pour ce faire, l'administrateur doit se trouver en vue "admingroup" puis déplier le menu "système" puis cliquer sur "utilisateurs" pour avoir la liste des utilisateurs qu'il gère:
+L'administrateur de la composante peut donner un sous-ensemble des ressources de la composante, pour par exemple le rendre autonome. Pour ce faire, l'administrateur doit se trouver en vue "admingroup", déplier le menu "système" puis cliquer sur "utilisateurs" pour avoir la liste des utilisateurs qu'il gère :
 {{ :wiki:documentation:screenshot-2018-3-6_opennebula_sunstone_cloud_operations_center.png |}}
-En sélectionnant l'utilisateur auquel il faut affecter un quota, il accède aux informations de celui-ci, notamment à son quota via l'onglet "Quotas":
+En sélectionnant l'utilisateur auquel il faut affecter un quota, il accède aux informations de celui-ci, notamment à son quota via l'onglet "Quotas" :
 {{ :wiki:documentation:screenshot-2018-3-6_opennebula_sunstone_cloud_operations_center_1_.png |}}
-En cliquant sur le bouton "editer" il est possible de créer ou de modifier le quota de l'utilisateur en lui affectant des limites sur:
+En cliquant sur le bouton "editer", il est possible de créer ou de modifier le quota de l'utilisateur en lui affectant des limites sur :
   * le nombre de machine virtuelle qu'il peut instancier
   * le nombre de CPU
@@ Ligne 88: / Ligne 91: @@
 {{ :wiki:documentation:screenshot-2018-3-6_opennebula_sunstone_cloud_operations_center_2_.png |}}
-===== Manipuler les ressources en ligne de commande =====
-Opennebula offre une API de type REST, accessible en http (http://iaas.intra.univ-nantes.fr:2633/RPC2) et un jeu de commande CLI (command line interface) qui permettant de gérer ses ressources comme il est possible de le faire avec l'interface web. Cette interface est particulièrement intéressante pour scripter des déploiements.
-==== installation de la CLI ====
-Il faut tout d'abord installer les outils opennebula en commencant par installer le repository:
-<cli prompt="$">
-abelard-a@UN-5CG54835CN:~$ cat /etc/apt/sources.list.d/opennebula.list
-deb http://downloads.opennebula.org/repo/5.4/Ubuntu/17.04 stable opennebula
-</cli>
-Puis il faut importer la clé de signature du repository:
-<cli>
-root@UN-5CG54835CN:~$ gpg --keyserver pool.sks-keyservers.net --recv-key 592F7F0585E16EBF
-gpg --keyserver pool.sks-keyservers.net --recv-key 592F7F0585E16EBF
-gpg: requesting key 85E16EBF from hkp server pool.sks-keyservers.net
-gpg: key 85E16EBF: public key "OpenNebula Repository <contact@opennebula.org>" imported
-gpg: no ultimately trusted keys found
-gpg: Total number processed: 1
-gpg:               imported: 1  (RSA: 1)
-root@UN-5CG54835CN:~$ gpg -a --export 592F7F0585E16EBF | sudo apt-key add -
-OK
-</cli>
-Et enfin, il faut installer le paquet ''opennebula-tools'':
-<cli>
-abelard-a@UN-5CG54835CN:~$ sudo http_proxy=http://cache.ha.univ-nantes.fr:3128 apt-get install  opennebula-tools
-Reading package lists... Done
-Building dependency tree
-Reading state information... Done
-The following package was automatically installed and is no longer required:
-  libjpeg62:i386
-Use 'sudo apt autoremove' to remove it.
-The following NEW packages will be installed:
-  opennebula-tools
-upgraded, 1 newly installed, 0 to remove and 152 not upgraded.
-Need to get 108 kB of archives.
-After this operation, 677 kB of additional disk space will be used.
-WARNING: The following packages cannot be authenticated!
-  opennebula-tools
-Install these packages without verification? [y/N] y
-Get:1 http://downloads.opennebula.org/repo/5.4/Ubuntu/17.04 stable/opennebula amd64 opennebula-tools all 5.4.1-1 [108 kB]
-Fetched 108 kB in 0s (111 kB/s)
-Selecting previously unselected package opennebula-tools.
-(Reading database ... 329741 files and directories currently installed.)
-Preparing to unpack .../opennebula-tools_5.4.1-1_all.deb ...
-Unpacking opennebula-tools (5.4.1-1) ...
-Processing triggers for man-db (2.7.5-1) ...
-Setting up opennebula-tools (5.4.1-1) ...
-Please remember to execute /usr/share/one/install_gems to install all the
-required gems.
-</cli>
-Il est désormais possible d'utiliser la CLI, par exemple:
-<cli>
-abelard-a@UN-5CG54835CN:~$ oneuser list --user abelard-a --password '---------------------' --endpoint http://iaas.intra.univ-nantes.fr:2633/RPC2
-ID NAME            GROUP      AUTH           VMS            MEMORY         CPU
-abelard-a       users      ldap       1 /   5    256M /    9.8G   0.2 / 8.0
-</cli>
-<alert type="warning">
-Si la commande oneuser ne parvient pas à joindre la plateforme IaaS, veuillez contacter l'administrateur du firewall de votre composante pour qu'il autorise la connexion vers **iaas.intra.univ-nantes.fr:2633**.
-</alert>
-Devoir préciser ses identifiants à chaque commande est fastidieux et contre productif. Il est donc nécessaire de configurer son poste pour ne pas avoir à les saisir systématiquement.
-==== Configuration de la CLI ====
-Bien qu'il soit possible de préciser l'url de gestion de la CLI ("endpoint") à chaque commande avec le flag ''--endpoint'' il est préférable de configurer celui-ci une fois pour toute. Pour ce faire il faut préalablement créer le dossier ~/.one et y créer le fichier ''one_endpoint'' contenant la bonne url:
-<cli>
-abelard-a@UN-5CG54835CN:~$ echo http://iaas.intra.univ-nantes.fr:2633/RPC2 > ~/.one/one_endpoint
-</cli>
-Il faut ensuite générer un token qui permettra de ne pas avoir à saisir ses identifiants à chaque commande (il faut saisir son identifiant même s'il est préciser dans la ligne de commande):
-<cli>
-abelard-a@UN-5CG54835CN:~$ oneuser token-create abelard-a --time -1  --user abelard-a --password '---------------'
-Password:
-Authentication Token is:
-abelard-a:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-</cli>
-Un nouveau token est créé et le fichier ~/.one/one_auth est automatiquement créé.
-Il est désormais possible de manipuler ses VM dans préciser d'identifiants:
-<cli>
-abelard-a@UN-5CG54835CN:~$ onevm list
-    ID USER     GROUP    NAME            STAT UCPU    UMEM HOST             TIME
-abelard- DSI-IRTS test            runn  0.0  497.4M iaas-vm-1.  23d 22h59
-</cli>
-==== instancier une VM ====
-Il est possible est très utile de pouvoir instancier une VM à partir d'un modèle en ligne de commande. Cela se fait avec la commande ''onetemplate instantiate <id_modele> --nic <nomreseau>''.
-Pour obtenir l'id du modèle à utiliser, il faut préalablement lister les modèles disponibles:
-<cli>
-abelard-a@UN-5CG54835CN:/tmp$ onetemplate list
-  ID USER            GROUP           NAME                                REGTIME
-oneadmin        DSI-IRTS        windows 2008R2               01/23 15:47:23
-oneadmin        oneadmin        Ubuntu 16.04 (LTS) - univna  11/10 20:56:14
-oneadmin        oneadmin        CentOS 7.2 - univnantes      11/16 17:26:01
-oneadmin        oneadmin        Machine avec disque vierge   03/22 15:10:15
-oneadmin        oneadmin        Serveur LAMP (linux, apache  05/16 15:46:37
-feufeu-jc       IUTNA           Debian 8.4 (Jessie) - IUT    05/30 14:46:54
-oneadmin        oneadmin        Debian 8 (Jessie) - univnan  06/19 16:45:55
-oneadmin        oneadmin        Debian 9 (Stretch) - univna  06/20 09:59:03
-</cli>
-La commande ''onevnet'' nous permet d'avoir la liste des réseaux virtuel (vnet) disponibles:
-<cli>
-abelard-a@UN-5CG54835CN:~$ onevnet list
-  ID USER            GROUP        NAME                CLUSTERS   BRIDGE   LEASES
-oneadmin        oneadmin     IRTS_UNIV           0          IRTS_UNI     11
-oneadmin        oneadmin     IRTS_INTRA          0          IRTS_INT     14
-</cli>
-Nous allons instancier un nouveau serveur web, nous allons donc utiliser le patron "Serveur LAMP" qui a l'id 65 et démarrer la VM sur le réseau IRTS_INTRA qui a l'id 67:
-<cli>
-abelard-a@UN-5CG54835CN:/tmp$ onetemplate instantiate 65 --nic 67
-There are some parameters that require user input. Use the string <<EDITOR>> to launch an editor (e.g. for multi-line inputs)
-  * (ROOT_PASSWORD) root password
-    Password:
-  * (SET_HOSTNAME) nom de l'utilisateur (qui determine aussi le hostname et le nom de la base donnée)
-    toto
-  * (USER_PASSWORD) mot de passe de l'utilisateur
-    Password:
-VM ID: 1142
-</cli>
-Notre nouvelle VM est désormais démarrée:
-<cli>
-abelard-a@UN-5CG54835CN:/tmp$ onevm list
-    ID USER     GROUP    NAME            STAT UCPU    UMEM HOST             TIME
-abelard- DSI-IRTS test            runn  0.0  497.4M iaas-vm-1.  23d 23h27
-abelard- DSI-IRTS é en main-1142  runn  0.0    512M iaas-vm-6.   0d 00h01
-</cli>
-==== Voir les informations d'une VM ====
-La commande onevm permet de manipuler vos VM, notamment d'afficher les informations complètes concernant une VM:
-<cli>
-abelard-a@UN-5CG54835CN:~$ onevm show 1147
-VIRTUAL MACHINE 1147 INFORMATION
-ID                  : 1147
-NAME                : Serveur LAMP (linux, apache, mysql, php)  clé en main-1147
-USER                : abelard-a
-GROUP               : DSI-IRTS
-STATE               : ACTIVE
-LCM_STATE           : RUNNING
-RESCHED             : No
-HOST                : iaas-vm-5.u07.univ-nantes.prive
-CLUSTER ID          : 0
-CLUSTER             : ERROR
-START TIME          : 03/06 12:28:05
-END TIME            : -
-DEPLOY ID           : one-1147
-VIRTUAL MACHINE MONITORING
-PERMISSIONS
-OWNER               : um-
-GROUP               : ---
-OTHER               : ---
-VM DISKS
- ID DATASTORE  TARGET IMAGE                               SIZE      TYPE SAVE
-ceph-image vda    debian8-univnantes-v7-lamp-v9       -/2G      rbd    NO
--          hda    CONTEXT                             -/-       -       -
-VM NICS
- ID NETWORK              BRIDGE       IP              MAC               PCI_ID
-IRTS_INTRA           IRTS_INTRA   172.26.78.17    1a:a5:78:01:00:07
-SECURITY
-NIC_ID NETWORK                   SECURITY_GROUPS
-IRTS_INTRA                0
-SECURITY GROUP   TYPE     PROTOCOL NETWORK                       RANGE
-  ID NAME                          VNET START             SIZE
-Ssh et ping inbound  TCP                                    22
-Ssh et ping inbound  ICMP-8
-Ssh et ping outbound UDP           172.26.4.20       1      53
-Ssh et ping outbound UDP           172.20.12.31      1      123
-Ssh et ping outbound UDP           193.52.101.123    1      123
-Ssh et ping outbound TCP           193.52.104.20     1      3128
-Ssh et ping outbound TCP           172.20.12.34      1
-Ssh et ping outbound TCP           172.20.12.55      2      25
-VIRTUAL MACHINE HISTORY
-SEQ UID  REQ   HOST         ACTION       DS           START        TIME     PROLOG
--    -     iaas-vm-5.u0 none          0  03/06 12:28:33  -1d 23h58m   0h00m00s
-USER TEMPLATE
-DESCRIPTION="Serveur en debian 8 avec autoconfiguration du hostname, du compte utilisateur et de la base de données. Accès utilisateur en sftp only.
-20160623: image v8 : sshd PermitRootLogin: Yes"
-INPUTS_ORDER="ROOT_PASSWORD,SET_HOSTNAME,USER_PASSWORD"
-LABELS="DSIN"
-LOGO="images/logos/debian.png"
-ROOT_PASSWORD="*****"
-SET_HOSTNAME="toto"
-USER_INPUTS=[
-  ROOT_PASSWORD="M|password|root password",
-  SET_HOSTNAME="M|text|nom de l'utilisateur (qui determine aussi le hostname et le nom de la base donnée)",
-  USER_PASSWORD="M|password|mot de passe de l'utilisateur" ]
-USER_PASSWORD="*****"
-VIRTUAL MACHINE TEMPLATE
-AUTOMATIC_DS_REQUIREMENTS="\"CLUSTERS/ID\" @> 0"
-AUTOMATIC_REQUIREMENTS="(CLUSTER_ID = 0) & !(PUBLIC_CLOUD = YES)"
-CONTEXT=[
-  DISK_ID="1",
-  ETH0_CONTEXT_FORCE_IPV4="",
-  ETH0_DNS="172.26.4.20",
-  ETH0_GATEWAY="172.26.78.1",
-  ETH0_GATEWAY6="",
-  ETH0_IP="172.26.78.17",
-  ETH0_IP6="",
-  ETH0_IP6_PREFIX_LENGTH="",
-  ETH0_IP6_ULA="",
-  ETH0_MAC="1a:a5:78:01:00:07",
-  ETH0_MASK="255.255.255.128",
-  ETH0_MTU="",
-  ETH0_NETWORK="",
-  ETH0_SEARCH_DOMAIN="",
-  ETH0_VLAN_ID="781",
-  ETH0_VROUTER_IP="",
-  ETH0_VROUTER_IP6="",
-  ETH0_VROUTER_MANAGEMENT="",
-  FILES_DS="/var/lib/one//datastores/2/d759a1dd941f7f5c66e06e235493f635:'context-lamp.sh' ",
-  INIT_SCRIPTS="context-lamp.sh",
-  NETWORK="YES",
-  ONEGATE_ENDPOINT="http://one-ctrl-1.dprv.univ-nantes.prive:5030",
-  ROOT_PASSWORD="*****",
-  SET_HOSTNAME="toto",
-  SSH_PUBLIC_KEY="ssh-rsa AAAAB3NzaC1yc2EAAAAFAPNxT6kAAAEBAIasOBPjKxfO625U92lYkw7phh1YyKk+v3Xq7ko7ID1S0GshjtrAdaQ+ihQvem3Ux6lb0LyXGRpk6I2DmaWVV87qWCB4SblgqRrtf2YBg5bMPlV6DcFapMbUUXzjZ5gwuvXJFL5AYzGnlv61OYIT8gr5+HifG/VCEcoYeWYejDlyhrzVIOJcgdnW2sm4yoaBEWncOPwCHye9+pwMqaOVRaByZE8zul+rSTVsrKdwdbpqhhw9ELg4sLjQQWkoHjkWlHEwfWEtynqU1Dcmaw6EJY1iewHCR95w+jK6zD7vS42bsnecLeAnGBDhuemDb0isHjzQOuwhYa1rnTWd1O0kQRU=",
-  TARGET="hda",
-  TOKEN="YES",
-  USER_PASSWORD="**********",
-  VMID="1147" ]
-CPU="0.2"
-CPU_COST="11.11"
-CREATED_BY="5"
-GRAPHICS=[
-  KEYMAP="fr",
-  LISTEN="0.0.0.0",
-  PORT="7047",
-  TYPE="VNC" ]
-MEMORY="256"
-MEMORY_COST="6"
-OS=[
-  ARCH="x86_64",
-  BOOT="" ]
-TEMPLATE_ID="65"
-VMID="1147"
-</cli>
-==== Arrêter ou démarrer une VM ====
-Une fois instanciée, une VM peut se manipuler avec la commande ''onevm''. Par exemple pour arrêter une VM:
-<cli>
-abelard-a@UN-5CG54835CN:/tmp$ onevm poweroff 1142
-abelard-a@UN-5CG54835CN:/tmp$ onevm list
-    ID USER     GROUP    NAME            STAT UCPU    UMEM HOST             TIME
-abelard- DSI-IRTS test            runn  0.0  497.4M iaas-vm-1.  23d 23h36
-abelard- DSI-IRTS é en main-1142  shut  1.0    512M iaas-vm-6.   0d 00h10
-</cli>
-Pour démarrer une VM arrêtée:
-<cli>
-abelard-a@UN-5CG54835CN:/tmp$ onevm resume 1142
-abelard-a@UN-5CG54835CN:/tmp$ onevm list
-    ID USER     GROUP    NAME            STAT UCPU    UMEM HOST             TIME
-abelard- DSI-IRTS test            runn  0.0  497.4M iaas-vm-1.  23d 23h45
-abelard- DSI-IRTS é en main-1142  runn  0.0      0K iaas-vm-6.   0d 00h19
-</cli>
-===== Création d'un nouveau modèle =====
-Il peut être utile de créer un nouveau modèle de VM afin de déployer des instances spécifiquement taillées pour vos besoins. Le principe d'un modèle est de proposer une base fixe (OS + applicatif déjà installé) et de demander à l'utilisateur un jeu de données variables (nom d'utilisateur, mot de passe, etc.) Le but étant d'avoir une modèle qui demande à l'utilisateur le minimum de manipulation tout en restant configurable simplement.
-Pour ce faire, il faut disposer d'une image (un "patron" d'OS). Il est possible par exemple d'utiliser les images des modèles de VM existant.
-Nous allons, par exemple, créer un modèle de serveur de fichier avec samba. Pour obtenir un serveur de fichier utilisable il faut donc prévoir:
-- d'installer le serveur samba
-- de le configurer (utilisation de ldap? créer les partages par defaut?)
-- de configurer l'OS (mot de passe root, hostname, etc)
-Nous allons donc repartir de l'image "Debian 9 (Stretch) - univnantes" qui est assez générique pour nos besoins.
-Les étapes que nous allons suivres sont les suivantes:
-  - créer notre patron à partir de l'image générique
-  - créer une nouvelle image à partir de notre patron
-  - créer un modèle
-==== Adapter une image générique ====
-Le plus simple pour adapter une image existante est d'instancier une nouvelle VM, temporaire, à partir d'un modèle existant, de le configurer comme voulu, puis d'enregistrer les modifications dans une nouvelle image qui deviendra la base de notre nouveau modèle.
-L'instanciation d'une VM est expliquée ci-dessus. Une fois la VM fonctionnelle, il faut procéder à la suite, c'est à dire à l'installation du serveur samba (apt-get update && apt-get install samba, etc).
-il est possible à ce stade là de customiser autant que possible le futur patron, par exemple en préconfigurant le serveur samba pour proposer des partages par défaut ou en supprimant toute trace de cette préconfiguration (suppression des logs, de l'historique, etc.)
-Une fois notre VM configurée comme prévue, il est nécessaire de l’arrêter **proprement** en utilisant la commande "Éteindre" dans l'interface web du service.
-Nous allons donc maintenant procéder à la création de l'image en sauvegardant le disque de notre VM dans une nouvelle image. Pour ce faire, il faut passer par l'onglet "Stockage" de la VM puis en cliquant sur l'icone "Saveas" au niveau du disque:
-{{ :wiki:documentation:saveas.png |}}
-Il faut ensuite donner un nom à notre nouvelle image:
-{{ :wiki:documentation:screenshot-2018-3-6_opennebula_sunstone_cloud_operations_center_3_.png |}}
-La nouvelle image apparait désormais dans la liste des images disponibles, dans "Storage" puis "Images":
-{{ :wiki:documentation:screenshot-2018-3-6_opennebula_sunstone_cloud_operations_center_4_.png |}}
-Nous allons donc passer à l'étape suivante, la création du modèle.
-==== Création du modèle ====
-La création d'un nouveau modèle se fait dans le menu "Modèles" puis "Machines Virtuelles". Il faut ensuite cliquer sur l'icone "+" :
-{{ :wiki:documentation:screenshot-2018-3-6_opennebula_sunstone_cloud_operations_center_5_.png |}}
-L'utilisateur est donc invité à saisir les informations nécessaire à la création de son nouveau modèle.
-Tout d'abord les informations générales:
-  - le nom : "Modèle de Serveur Samba"
-  - la description : "Modèle de serveur samba pour automatiser le déploiement de serveurs de fichiers"
-  - La taille de la mémoire allouée à la VM par defaut: 2Go.
-  - Le nombre de CPU : 0.5
-  - le nom de CPU virtuels : 2
-  - l'hyperviseur: KVM (seul hyperviseur supporté par la plateforme)
-Les informations concernant le stockage:
-  - l'image : c'est la que nous sommes amené à choisir l'image créée à l'étape précédente "patron-serveur-samba-debian9"
-  - un disque de donnée: il est possible de rajouter un disque vierge, par exemple pour séparer le volume de données du volume de OS. Il faut pour cela cliqeur sur le "+" sous le 1er disque puis choisir, par exemple, "Disque Vierge (IDE)".
-Les informations concernant le réseau:
-  - le nombre d'interface réseau et le réseau dans lequel les mettre. Il est tout à fait possible de ne rien préciser et l'utilisateur pourra choisir son réseau au moment de l'instanciation.
-Une fois ces informations saisie, il faut rengistrer le nouveau patron en cliquant sur le bouton "Créer".
-Le nouveau modèle est désormais disponible:
-{{ :wiki:documentation:screenshot-2018-3-6_opennebula_sunstone_cloud_operations_center_6_.png |}}
-Il est donc possible d'instancier une nouvelle VM a partir de celui-ci mais vous remarquerez que les informations demandées à l'instanciation se limite au nom de la VM et à la configuration matérielle. Il n'y a rien concernant le mot de passe root, la configuration samba, etc. C'est ce qu'on appèle la "Contextualisation" de la VM.
-==== Contextualisation ====
-La contextualiation permet d'adapter la VM au contexte de l'utilisateur. Elle permet par exemple de demander à l'utilisateur de saisir un mot de passe root, un nom d'utilisateur, de cocher une case pour démarrer un service ou un autre, etc.
-La contextualisation se configurer dans l'onglet "contexte" lors de la création ou de la modification d'un modèle:
-{{ :wiki:documentation:screenshot-2018-3-6_opennebula_sunstone_cloud_operations_center_7_.png |}}
-=== Contextualisation SSH ===
-Il est possible d'injecter automatiquement dans le patron la clé SSH de l'utilisateur si celui-ci en a configuré une dans son compte sur la plateforme. Cela permet, pas exemple, de ne pas avoir à saisir de mot de passe root (mais cela empêche ainsi d'utiliser la console web). Pour cela il suffit de cliquer sur "Ajouter une contextualisation SSH". Cela permet d'avoir une contextualisation ssh adaptée à chaque utilisateur instanciant le modèle. Il est toutefois possible de forcer l'injection d'une clé tiers, en la précisant dans le champs "Clé SSH publique".
-Pour en savoir plus sur les clés SSH: https://delicious-insights.com/fr/articles/comprendre-et-maitriser-les-cles-ssh/
-=== Execution d'un script de démarrage ===
-Au démarrage de la VM il est possible de lancer un script. Ce script sera lancer à chaque démarrage. Par exemple, faire une image à jour automatique :
-<code bash>
-apt-get update && DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade --force-yes -o Dpkg::Options::="--force-confold"
-</code>
-<alert type="danger">
-**Attention!** Le script de démarrage est executé à __chaque__ démarrage. Ainsi si la contextualisation doit initialiser des services, il faut toujours vérifier que cette initialisation n'a pas déjà été faite! Afin de ne pas perdre de données après un redémarrage.
-</alert>
-Il est aussi possible de configurer des entrées utilisateurs
-=== Entrées utilisateurs ===
-Les entrées utilisateurs sont des champs à saisir au moment de l'instanciation de la VM. Par exemple, le mot de passe root. Ces champs sont ensuite réutilisables dans le script de démarrage, notamment pour effectuer le changement de mot de passe de l'utilisateur root ou de configurer un service, etc.
-Une entrée utilisateur peut être facultative ou obligatoire. Les types de champs possibles sont les suivants:
-  - **texte**, pour saisir du texte sur plusieurs lignes
-  - **texte (base 64)**, pour saisir un hash64
-  - **mot de passe**, pour saisir un mot de passe, champs sur une ligne qui n'affiche pas le contenu
-  - **nombre**, pour saisir un nombre entier
-  - **nombre (réel)**, pour saisir un nombre à virgule
-  - **plage**, pour saisir un une valeur comprise entre 2 bornes
-  - **interval**, comme ci-dessus mais avec des nombres à virgules
-  - **liste**, une liste déroulante
-  - **booléen**, une case à cocher (oui / non).
-Ces champs permettent de passer des variables au script de démarrage.
-Par exemple, reprenons le cas du champs de saisie du mot de passe root. Il faut créer un champs de type "mot de passe", obligatoire:
-{{ :wiki:documentation:screenshot-2018-3-6_opennebula_sunstone_cloud_operations_center_8_.png?600 |}}
-Lors de l'instanciation, cela sera traduit comme ceci:
-{{ :wiki:documentation:screenshot-2018-3-6_opennebula_sunstone_cloud_operations_center_9_.png?600 |}}
-Il faut toutefois utiliser la variable $ROOT_PASSWORD dans notre script de démarrage afin de modifier le compte root du serveur:
-<code bash>
-echo -e "$ROOT_PASSWD\n$ROOT_PASSWD\n" | passwd root
-</code>
-et donc dans l'interface du service:
-{{ :wiki:documentation:screenshot-2018-3-8_opennebula_sunstone_cloud_operations_center.png |}}
-Notre modèle est désormais contextualisé. Du moins pour la partie mot de passe root.
-===== Démarrer une VM vierge pour installation à partir d'un support =====
-Il est parfois nécessaire de faire une installation d'OS a partir d'un support d'installation (CDROM, DVD, etc.)
-Pour ce faire,il faut procéder en plusieurs étapes:
-  - uploader le support d'installation
-  - créer une VM vierge et y lier le CDROM/DVD
-  - procéder à l'installation
-==== uploader le support d'installation ====
-Avant de pouvoir booter sur le CD ou DVD d'installation, il faut que celui-ci soit disponible sur la plateforme IaaS. Pour ce faire, il faut préalablement télécharger  temporairement l'image ISO d'installation sur son poste de travail puis l'ajouter au service IaaS. Une fois l'ISO télécharger, il faut se rendre dans la partie ''Storage'' puis ''Images'' et cliquer sur le bouton "+" permettant d'ajouter une nouvelle image. Nous allons ici installer une Ubuntu 17.10.1 Server:
-{{ :wiki:documentation:screenshot-2018-3-9_opennebula_sunstone_cloud_operations_center_2_.png |}}
-  * **le nom** est le nom de l'image tel qu'il sera affiché dans la liste.
-  * **le type de l'image** doit etre "CDROM" même s'il s'agit d'un DVD.
-  * **L'espace de stockage** est l'endroit ou sera téléchargé l'image, il n'y en a qu'un de possible actuellement
-  * **Le chemin d'accès** permet d'indiquer ou se trouve actuellement l'image ISO d'installation. Elle se trouve sur votre poste de travail, il faut donc la téléverser (l'uploader).
-<alert type="danger">
-**Attention!** Il ne faut pas mettre de caractères spéciaux dans le nom de l'image sinon l'erreur ne sera signalée qu'au terme de l'upload.
-</alert>
-Une fois ces informations saisies, il faut cliquer sur le bouton "Créer" et attendre que l'image ISO soit bien uploadée sur le serveur. La barre de progression de l'upload se trouve en bas de la page:
-{{ :wiki:documentation:screenshot-2018-3-8_opennebula_sunstone_cloud_operations_center_2_.png |}}
-==== Créer une VM vierge pour y installer l'OS ====
-Maintenant que notre CD/DVD est disponible, nous devons créer une VM vierge et lui lier le support d'installation afin de boooter dessus et lancer l'installation au 1er démarrage.
-Nous fournissons un patron "**Machine avec disque vierge IDE pour installation via support**" qui contient la configuration nécessaire: un disque vierge de 1Mo (à retailler au moment de l'instanciation, le menu de boot activé, etc.). Il faut donc instancier une nouvelle VM à partir de ce modèle en respectant quelques étapes:
-=== Instanciation de notre VM vierge ===
-{{ :wiki:documentation:screenshot-2018-3-9_opennebula_sunstone_cloud_operations_center.png |}}
-<alert type="info">
-Ne pas oublier de préciser la taille du disque dur!
-</alert>
-Notre VM démarre mais ne peut booter puisque le disque est vierge:
-{{ :wiki:documentation:screenshot-2018-3-9_opennebula_sunstone_cloud_operations_center_1_.png |}}
-Il faut donc lui associer le support d'installation que nous avons préparé.
-=== attacher le support d'installation  ===
-Notre VM est instanciée mais elle n'a pas accès à notre support d'installation. Il faut donc l'y attacher.
-**Il faut commencer par arrêter notre VM. En l'absence d'OS il est nécessaire de forcer l’arrêt de la VM  en utilisant la fonction ''Éteindre (forcé)''**.
-Une fois notre VM arreter, il est possible de procéder à l'attachement. Pour ce faire, il faut aller dans l'onglet "Stockage" de notre VM puis y attacher notre support d'installation en cliquant sur le bouton ''Attacher un disque'' puis en sélectionnant notre image dans la liste:
-{{ :wiki:documentation:screenshot-2018-3-9_opennebula_sunstone_cloud_operations_center_3_.png |}}
-{{ :wiki:documentation:screenshot-2018-3-9_opennebula_sunstone_cloud_operations_center_4_.png |}}
-Notre VM possède désormais un disque dur vierge et un CDROM d'installation. On peut la démarrer. Elle tentera de booter sur le disque vierge, n'y trouvera pas d'OS et passera au CDROM qui lancera l'installation. A la fin de l'installation, le disque dur contiendra un OS bootable qui prendra ensuite la relève au démarrage:
-{{ :wiki:documentation:screenshot-2018-3-9_opennebula_sunstone_cloud_operations_center_7_.png |}}
-<alert>
-Notre installation se faisant à partir du support d'installation, il n'y aura pas de préconfiguration du réseau comme sur une image contextualisée. Il faudra donc, si nécessaire, faire la configuration réseau manuellement en fonction des données disponibles dans les onglets ''Réseau'' et ''Configuration'' de la VM.
-</alert>
-===  Post installation ===
-Contrairement aux VM instanciées à partir d'un modèle préinstallé, notre VM ne possède pas les outils de contextualisation. Il n'est donc pas possible de configurer le réseau automatiquement, ni de configurer les mots de passe. Pour que cela soit possible, il faut installer manuellement dans notre nouvelle OS le client de contextualisation Opennebula qui se téléchargera ici pour linux (pour windows, cf ci-dessous):
-https://github.com/OpenNebula/addon-context-linux/releases/
-==== Cas particulier de Windows ====
-L'installation d'un OS Microsoft nécessite quelques spécificités. En effet pour que le curseur de la souris soit correctement synchronisé sur la console web ("VNC") il faut changer le type de périphérique de pointage par défaut (cela se fait normalement dans l'onglet ''Entrée/Sortie'' du modèle:
-{{ :wiki:documentation:screenshot-2018-3-9_opennebula_sunstone_cloud_operations_center_8_.png |}}
-<alert type="info">
-Notre patron "Notre patron "VM Machine vierge" tient compte de ces spécificité." **tient compte de ces spécificité**.
-</alert>
-=== Installation ===
-Une autre spécificité est que Windows nécessite des pilotes particuliers pour détecter le disque dur au moment de l'installation.  Nous fournissons ces pilotes sous forme d'un CDROM disponible dans la liste des images: ''Drivers-VirtIO-Win-0.1.141''.
-Avant de pouvoir instancier une VM pour installer windows, il faudra donc y attacher, en plus du support d'installation ce CDROM de pilotes:
-{{ :wiki:documentation:screenshot-2018-3-9_opennebula_sunstone_cloud_operations_center_9_.png |}}
-<alert type="danger">
-**Attention!** l'ordre des disques est important. Le disque dur doit toujours se trouver en première place, suivi du support d'installation et enfin du CDROM de pilotes
-</alert>
-Le programme d'installation ne détectera aucun disque:
-{{ :wiki:documentation:screenshot-2018-3-9_opennebula_sunstone_cloud_operations_center_10_.png |}}
-Vous serez donc amené à charger un pilote à partir du CDROM de pilotes attaché à la VM. Il faudra donc pointer jusqu'au dossier ''F:\viostor'' correspondant à votre OS. Dans notre cas: ''F:\viostor\w2k12R2\amd64'':
-{{ :wiki:documentation:screenshot-2018-3-9_opennebula_sunstone_cloud_operations_center_11_.png |}}
-En cliquant sur ''suivant'' l'installeur détecte enfin le disque:
-{{ :wiki:documentation:screenshot-2018-3-9_opennebula_sunstone_cloud_operations_center_12_.png |}}
-Et l'installation peut continuer jusqu'à son terme.
-=== Configuration ===
-Une fois l'installation terminée, vous constaterez que Windows ne detecte aucune carte réseau. Il faut à nouveau avoir recours au CDROM de pilotes attaché à notre VM. Cette fois-ci les pilotes se trouverons dans ''F:\NetKVM\'' (dans notre cas ''F:\NetKVM\2k12R2\amd64'').
-<text type="danger">**Todo : tester l'agent KVM https://pve.proxmox.com/wiki/Qemu-guest-agent**</text>
-=== Contextualisation ===
-La contextualisation est aussi particulière avec Windows. Il faut télécharger l'extention de contextualisation ici https://github.com/OpenNebula/addon-context-windows/releases/.
-Il faudra aussi télécharger les scripts suivants:
-  * https://raw.githubusercontent.com/OpenNebula/addon-context-windows/v5.4.1/context.ps1
-  * https://raw.githubusercontent.com/OpenNebula/addon-context-windows/v5.4.1/startup.vbs
-Et les déposer à la racine du disque C:
-https://docs.opennebula.org/5.2/operation/vm_setup/kvm.html