Introduction

Le service de calcul à haut-débit (HTC) de la plateforme SCIGNE repose sur un cluster de calcul optimisé pour le traitement de tâches parallélisées par la donnée. Ce cluster est connecté à une infrastructure plus large, la grille européenne de calcul EGI.

La gestion des calculs est réalisée avec DIRAC. Cet outil permet de gérer vos calculs sur le cluster de la plateforme SCIGNE, et également sur l'infrastructure de grille EGI.

Après une introduction sur le fonctionnement d'une grille de calcul, cette documentation décrit la soumission, le suivi et la récupération des résultats de vos calculs avec DIRAC.

La grille de calcul

Cette section présente les différents services utilisés lors de la soumission d'une tâche (job) sur la grille de calcul. L'interaction entre ces services lors du workflow d'un job est illustrée sur la figure suivante. Les acronymes sont détaillés dans le tableau Les principaux services de la grille de calcul.

Le déroulement d'un calcul sur l'infrastructure de grille

L'utilisateur gère les calculs avec DIRAC. Avant de soumettre le calcul, les données volumineuses (> 10 Mo) doivent être copiées sur le Storage Element (SE). Le fonctionnement du SE est détaillé dans la documentation dédiée au stockage. Ces données seront accessibles depuis les noeuds de calcul. Ensuite, le calcul est soumis au service DIRAC, qui sélectionne le (ou les) site(s) devant effectuer les calculs. Pour effectuer ce choix, DIRAC se base sur la disponibilité du site et le respect des pré-requis du calcul explicités par l'utilisateur. Une fois cette sélection réalisée, DIRAC soumet le calcul au Computing Element (CE). Cet élément distribue les jobs sur les Worker Nodes (WN). Une fois les calculs terminés et les résultats copiés sur un SE, le CE collecte les informations d'exécution qui sont ensuite transférées à DIRAC.

Durant le temps des calcul, l'utilisateur peut interroger DIRAC pour connaître l'état du déroulement de son calcul. A la fin du workflow, les résultats peuvent être récupérés par l'utilisateur sur le SE et les journaux d'exécution sur DIRAC.

Les principaux services de la grille de calcul
Élément Rôle
UI

L'UI (User Interface) est la station de travail équipée du client DIRAC. Elle permet de :

  • gérer un calcul (soumission, suivi de l'état, annulation) ;
  • récupérer les résultats d'un calcul ;
  • copier, répliquer ou supprimer des données sur la grille.
DIRAC DIRAC est le serveur avec lequel interagit l'utilisateur lors de la soumission, le suivi et la récupération des résultats d'un calcul. Ce serveur choisit les sites de grille correspondant au pré-requis du calcul. Il interagit principalement avec le CE pour la soumission des calculs, le transfert des sandbox et le suivi de l'état d'un calcul.
SE Le SE (Storage Element) est l'élément d'une grille gérant le stockage. Il permet de récupérer les résultats des calculs ou bien de fournir au calcul des fichiers de données volumineux. Il est accessible via différents protocoles.
CE Le CE (Computing Element) est le serveur interagissant directement avec le gestionnaire de queues. Il permet à DIRAC de soumettre des calculs sur un cluster local.
WN Le WN (Worker Node) est le serveur effectuant le calcul. Il se connecte au SE pour récupérer les données nécessaires au calcul. Il peut également copier les résultats du calcul sur le SE.

Gestion d'un calcul avec DIRAC

Le logiciel DIRAC peut être utilisé avec un client en ligne de commande ou à travers l'interface Web DIRAC. Cette section détaille l'utilisation de la ligne de commande.

Pré-requis à l'utilisation de DIRAC

Afin de pouvoir soumettre un calcul, les deux pré-requis suivants sont nécessaires :

  • disposer d'une station de travail équipée du client DIRAC ;
  • disposer d'un certificat valide enregistré dans une organisation virtuelle (VO). Le document Gestion d'un certificat détaille la demande de certificat et l'inscription à la VO régionale.

Client DIRAC

L'installation d'un client DIRAC est détaillée dans la documentation de DIRAC.

Pour les utilisateurs disposant d'un compte à l'IPHC, le client DIRAC est pré-installé sur les serveurs UI. Pour mettre en place l'environnement DIRAC, il suffit de réaliser :

$ source /libcern/dirac/v6r17p9/sl6.9/x86_64/setup.sh

Certificat

La partie privée et la partie publique du certificat doivent être placées dans le répertoire $HOME/.globus sur le serveur à partir duquel les calculs seront soumis. Ces fichiers ne doivent être lisibles que par leur propriétaire :

$ ls -l $HOME/.globus
-r-------- 1 user group 1935 Feb 16  2010 usercert.pem
-r-------- 1 user group 1920 Feb 16  2010 userkey.pem

Dans cette documentation, nous utilisons la VO vo.grand-est.fr, qui est la VO régionale. Vous devez remplacer le nom de cette VO par celle que vous utilisez (par ex. biomed ou vo.sbg.in2p3.fr).

Avant toute opération sur la grille régionale, il est nécessaire d'avoir un proxy valide. Il peut être généré avec la commande suivante :

$ dirac-proxy-init -U -g grandest_user -M

L'option -U permet d'indiquer que nous souhaitons un proxy longue durée, l'option -g indique le groupe auquel nous appartenons et l'option -M informe que l'extension VOMS doit être ajoutée au proxy.

La commande suivante permet de vérifier la durée de validité de son proxy :

$ dirac-proxy-info
subject      : /O=GRID-FR/C=FR/O=CNRS/OU=IPHC/CN=Prenom Nom/CN=proxy/CN=proxy
issuer       : /O=GRID-FR/C=FR/O=CNRS/OU=IPHC/CN=Prenom Nom/CN=proxy
identity     : /O=GRID-FR/C=FR/O=CNRS/OU=IPHC/CN=Prenom Nom
timeleft     : 23:53:43
DIRAC group  : grandest_user
rfc          : False
path         : /tmp/x509up_u1000
username     : pnom
properties   : NormalUser
VOMS         : True
VOMS fqan    : ['/vo.grand-est.fr']

Soumission d'un calcul

La soumission d'un calcul avec DIRAC nécessite un fichier texte contenant des instructions au format JDL (Job Description Language). Ce type de fichier détaille les caractéristiques du calcul ainsi que ses besoins. Le fichier JDL présenté dans l'exemple ci-dessous est fonctionnel et utilisable pour la réalisation d'un calcul simple.

JobName = "mysimplejob";
Executable = "/bin/bash";
Arguments = "myscript.sh";
StdOutput = "stdout.out";
StdError = "stderr.err";
InputSandbox = { "myscript.sh" };
OutputSandbox = { "stdout.out", "stderr.err" };
VirtualOrganisation = "vo.grand-est.fr";

Chaque attribut du fichier JDL exemple a un rôle bien précis :

  • JobName décrit le nom de la tâche réalisé.
  • Executable définit la commande à exécuter sur les noeuds de calcul.
  • Arguments spécifie les arguments à passer au programme définit par l'attribut Executable ; le contenu du script myscript.sh est ce que vous auriez tapé en interactif pour effectuer votre calcul.
  • StdOutput indique le nom du fichier vers lequel est redirigé la sortie standard.
  • StdError indique le nom du fichier vers lequel est redirigé les messages d'erreur.
  • InputSandbox indique les fichiers qui seront envoyés avec le fichier JDL au serveur DIRAC. Ces fichiers seront utilisables par le serveur (WN) exécutant le calcul. Il est important de noter que la taille totale de l'InputSandbox est limitée. Ainsi, si la taille de l'ensemble des fichiers à envoyer devait dépasser 10 Mo, il est nécessaire d'utiliser un SE, ou de pré-installer les logiciels nécessaires au calcul.
  • OutputSandbox indique les fichiers que nous souhaitons récupérer après l'exécution du calcul. Par défaut, il est conseillé de récupérer les fichiers stdout.out et stderr.err qui contiennent les sorties standard et erreur. Ces fichiers seront téléchargés depuis le WMS. De même que pour l'InputSandbox, le volume retourné ne doit pas dépasser 10 Mo. Si la taille totale des fichiers de l'OutputSanbox dépasse cette valeur, il est nécessaire de copier les fichiers de sortie (résultats, journaux du calcul) sur un SE puis de les récupérer par la suite, pour éviter leur troncation.
  • VirtualOrganization renseigne sur la VO dans laquelle va être effectué le calcul. Dans le cas de la grille régionale, il s'agit de vo.grand-est.fr.
#!/bin/sh

echo "=====  Begin  ====="
date
echo "The program is running on $HOSTNAME"
date
dd if=/dev/urandom of=fichier.txt bs=1G count=1
gfal-copy file://`pwd`/fichier.txt srm://sbgse1.in2p3.fr/dpm/in2p3.fr/home/vo.grand-est.fr/lab/name/fichier.txt
echo "=====  End  ====="

Les exécutables utilisés dans le fichier myscript.sh doivent être installés sur la grille. L'installation de ces logiciels est assurée par l'équipe support de la plateforme. N'hésitez pas à Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. si vous avez besoin de logiciels spécifiques.

La commande gfal-copy permet de copier le fichier créé sur l'élément de stockage esbgse1.in2p3.fr. Le fonctionnement du service de stockage est détaillé dans la documentation dédiée. Une fois que les fichiers my.jdl et myscript.sh sont créés, le calcul peut être soumis sur la grille avec la commande suivante :

$ dirac-wms-job-submit my.jdl
JobID = 79342906

Il est important de conserver l'identifiant de la tâche 79342906. En effet, cet identifiant est utilisé pour suivre les différentes étapes d'un calcul, ainsi que pour récupérer l'OutputSandbox.

Suivi de l'état d'un calcul

Pour connaître l'état d'un calcul, la commande suivante est utilisée avec l'identifiant du calcul :

$ dirac-wms-job-status 79342906
JobID=79342906 Status=Waiting; MinorStatus=Pilot Agent Submission; Site=ANY;

Une fois que le calcul est terminé, la commande précédente indique :

$ dirac-wms-job-status 79342906
JobID=79342906 Status=Done; MinorStatus=Execution Complete; Site=LCG.SBG.fr;

Les différents états que peuvent prendre le status d'un job sont détaillés sur la figure 3.1.

Récupération des résultats d'un calcul

Pour récupérer le contenu décrit par le paramètre OutputSandbox :

$ dirac-wms-job-get-output 79342906

Le rapatriement des fichiers de sortie peut être vérifié avec :

$ ls -rtl /home/user/79342906
total 12
-rw-r--r-- 1 user group 73 juil. 25 15:12 StdOut
Les différents états d'un job DIRAC

Utilisation avancée de DIRAC

Cette section détaille la soumission de tâches paramétriques.

Soumission d'un ensemble paramétrique de calculs

La soumission d'une tâche de type Parametric est la soumission d'un ensemble de calculs dont les fichiers JDL sont identiques, mais qui pourront accéder à une valeur paramétrable unique à chaque calcul. Ce type de tâche est très utile lorsque la soumission d'une série de calculs ne différent que par la valeur d'un paramètre (par exemple, un paramètre numérique utilisé dans le nom des fichiers d'entrée et de sortie).

JobName = "Test_param_%n";
JobGroup = "Param_Test_1";
Executable = "/bin/sh";
Arguments = "myparamscript.sh %s";
Parameters = 10;
ParameterStart = 0;
ParameterStep = 1;
StdOutput = "stdout.out";
StdError = "stderr.err";
InputSandbox = { "myscript.sh" };
OutputSandbox = { "stdout.out", "stderr.err" };
VirtualOrganisation = "vo.grand-est.fr";

Ce document JDL va générer 10 jobs. Les paramètres suivants peuvent être utilisés dans le fichier JDL :

  • %n : numéro de l'itération
  • %s : valeur du paramètre
  • %j : identifiant des jobs
$ dirac-wms-job-submit params.jdl
JobID = [79343433, 79343434, 79343435, 79343436, 79343437, 79343438, 79343439, 79343440, 79343441, 79343442]

Documentation complémentaire

Les liens ci-dessous permettent d'accéder à de la documentation complémentaire pour approfondir l'utilisation de DIRAC et de la grille de calcul :

Introduction

La plate-forme SCIGNE propose un service de conteneurs à la demande (container as a service) basé sur le projet OpenStack Magnum. Ce service permet de créer simplement un cluster de conteneurs Docker.

Les technologies Docker supportées sont Kubernetes et Swarm. D'autres technologies peuvent être ajoutées sur simple demande Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. de la plate-forme SCIGNE.

L'object de ce document est de fournir une information concise pour débuter dans l'utilisation du service de conteneurs (Magnum) d'OpenStack. Toutes les options ne sont pas traitées et peuvent être retrouvées dans la documentation officielle de ce module.

Environnement

L'accès à ce service nécessite que vous ayez un compte sur la plate-forme SCIGNE de l'IPHC et que votre client OpenStack soit correctement configuré. Une documentation dédiée détaille ces points.

Installation avec les paquets de la distribution

Nous recommendons d'utiliser les paquets de votre distribution Linux pour installer le client magnum.

Si vous avez un système d'exploitation Red Hat Linux ou dérivés (CentOS, Scientific Linux, ...), le client magnum peut être installé avec la commande suivante :

$ sudo yum install python2-openstackclient python-magnumclient

Si vous avez un système d'exploitation Debian ou dérivés (Ubuntu, Linux Mint, ...), le client magnum peut être installé avec la commande suivante :

$ sudo apt-get install python-openstackclient python-magnumclient

Installation avec PIP

Si votre système d'exploitation ne fournit pas de client OpenStack ou bien que la version est trop ancienne, vous pouvez utiliser PIP pour installer le client magnum :

$ sudo pip install python-openstackclient python-magnumclient

Vérification de l'installation

Pour vérifier que les commandes magnum et openstack sont bien installées, les commandes suivantes peuvent être utilisées :

$ magnum --version
2.7.0

$ openstack --version
3.12.0

La version qui est affichée peut être différente de celle qui est indiquée ci-dessus (ces valeurs correspondent à la version Pike d'OpenStack).

Gestion d'un cluster Kubernetes

Kubernetes (K8s)est un outil pour gérer le déploiement, la configuration et la montée en charge des applications conteneurisées. Le site Web de Kubernetes propose différents tutoriels sur l'utilisation de cette technologie.

Le service Cloud Computing de la plateforme SCIGNE est préconfiguré avec différents templates utilisables pour la création de clusters. Ces templates utilisent la technologie Docker pour fournir des conteneurs :

$ openstack coe cluster template list
+--------------------------------------+--------------------------------------+
| uuid                                 | name                                 |
+--------------------------------------+--------------------------------------+
| 1d6fcc5e-104e-475f-9254-f1e6f9a71896 | swarm-fedora-atomic26                |
| eb8c8d8f-7359-4177-bcb8-3abe7d0ec3b8 | k8s-fedora-atomic26-cluster-template |
+--------------------------------------+--------------------------------------+

Pour créer un cluster Kubernete, le template k8s-fedora-atomic26-cluster-template sera utilisé.

Création d'un cluster

La création d'un nouveau cluster est réalisée en une seule commande :

$ openstack coe  cluster create  --cluster-template k8s-fedora-atomic26 --node-count 2 \
  --name monclusterk8s
Request to create cluster 07e has been accepted.

$ openstack coe cluster list
+--------------------------------------+---------------+------------+--------------+--------------------+
| uuid                                 | name          | node_count | master_count | status             |
+--------------------------------------+---------------+------------+--------------+--------------------+
| 07e9f716-d1aa-4130-ad6f-7ac94d3e73c4 | monclusterk8s |          2 |            1 | CREATE_IN_PROGRESS |
+--------------------------------------+---------------+------------+--------------+--------------------+

Le paramètre node-count permet de faire varier le nombre de noeuds qui sont créés. D'autres paramètres, détailles sur la page du projet Magnum, peuvent également être spécifiés lors de la création de ce cluster.

Le suivi de création du cluster est réalisée à l'aide de la commande précédente. Une fois que l'état est CREATE_COMPLETE (il faut attendre quelques minutes), le cluster est opérationnel et prêt à être utilisé :

La création d'un nouveau cluster est réalisée en une seule commande :

$ openstack coe cluster show monclusterk8s
+---------------------+------------------------------------------------------------+
| Field               | Value                                                      |
+---------------------+------------------------------------------------------------+
| status              | CREATE_COMPLETE                                            |
| cluster_template_id | eb8c8d8f-7359-4177-bcb8-3abe7d0ec3b8                       |
| node_addresses      | [u'134.158.151.143', u'134.158.151.134']                   |
| uuid                | 77da102e-14a6-4b35-8e27-f9ce4237760d                       |
| stack_id            | 915373e8-83d7-47bb-a2ef-e9dd02aa5c63                       |
| status_reason       | Stack CREATE completed successfully                        |
| created_at          | 2018-05-28T08:02:29+00:00                                  |
| updated_at          | 2018-05-28T09:06:12+00:00                                  |
| coe_version         | v1.7.4                                                     |
| faults              |                                                            |
| keypair             | cloudkey                                                   |
| api_address         | https://134.158.151.109:6443                               |
| master_addresses    | [u'134.158.151.109']                                       |
| create_timeout      | 60                                                         |
| node_count          | 2                                                          |
| discovery_url       | https://discovery.etcd.io/393491e97871b13c2e3b8b78420858d9 |
| master_count        | 1                                                          |
| container_version   | 1.12.6                                                     |
| name                | monclusterk8s                                              |
+---------------------+------------------------------------------------------------+

L'adresse du master est celle qui nous intéresse (134.158.151.109). Elle nous permettra de nous connecter au cluster à l'aide de la clé SSH utilisée lors de la création du cluster et de vérifier que Kubernetes fonctionne correctement :

$ ssh -i cloudkey Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.
[fedora@monclusterk8s ~]$ kubectl cluster-info
Kubernetes master is running at http://localhost:8080
CoreDNS is running at http://localhost:8080/api/v1/namespaces/kube-system/services/kube-dns/proxy
[fedora@monclusterk8s ~]$ kubectl get nodes
k8-lbcpd7kagr-0-e62qarrc5asx-kube-minion-4or6eo443za4   Ready                      44m      v1.7.4
k8-lbcpd7kagr-1-635t36ajymyj-kube-minion-nhfuxaviylxc   Ready                      45m      v1.7.4
k8-qdg4chvdta-0-3tx4dcdhn2p6-kube-master-ju7tz7oued7j   Ready,SchedulingDisabled   49m      v1.7.4

Les paramètres de connexion au cluster peuvent aussi être récupérées en utilisant le client OpenStack :

$ openstack  coe cluster config monclusterk8s
export KUBECONFIG=/home/user/config

Le fichier /home/user/config contient les paramètres du cluster :

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /home/user/ca.pem
    server: https://134.158.151.109:6443
  name: monclusterk8s
contexts:
- context:
    cluster: monclusterk8s
    user: monclusterk8s
  name: monclusterk8s
current-context: monclusterk8s
kind: Config
preferences: {}
users:
- name: monclusterk8s
  user:
    client-certificate: /home/user/cert.pem
    client-key: /home/user/key.pem

Modification du cluster

Le cluster peut être facilement agrandi :

$ openstack coe cluster update monclusterk8s replace node_count=4
Request to update cluster k8s-cluster4 has been accepted.

$ openstack coe cluster list
+--------------------------------------+----------------+----------+------------+--------------+--------------------+
| uuid                                 | name           | keypair  | node_count | master_count | status             |
+--------------------------------------+----------------+----------+------------+--------------+--------------------+
| 07e9f716-d1aa-4130-ad6f-7ac94d3e73c4 | monclusterk8s  | cloudkey |          4 |            1 | UPDATE_IN_PROGRESS |
+--------------------------------------+----------------+----------+------------+--------------+--------------------+

Après quelques minutes, les nouveaux noeuds sont utilisables :

$ openstack coe cluster list
+--------------------------------------+----------------+----------+------------+--------------+-----------------+
| uuid                                 | name           | keypair  | node_count | master_count | status          |
+--------------------------------------+----------------+----------+------------+--------------+-----------------+
| 07e9f716-d1aa-4130-ad6f-7ac94d3e73c4 | monclusterk8s  | cloudkey |          4 |            1 | UPDATE_COMPLETE |
+--------------------------------------+----------------+----------+------------+--------------+-----------------+

Arrêt du cluster

Le cluster est arrêté avec la commande suivante :

$ openstack coe cluster delete monclusterk8s

Documentation complémentaire

Les sites suivants peuvent être consultés pour obtenir plus d'informations concernant l'utilisation de Magnum et de Kubernetes :

Introduction

La plateforme SCIGNE propose un service de calcul à haut débit (high-throughput computing) reposant sur les technologies de grille de calcul. Les échanges de données entre les différents centres de calcul composants la grille EGI sont réalisés à l'aide de protocols spécifiques (SRM, XROOTD).

Ce document détaille l'utilisation de ces protocoles pour gérer vos données depuis votre station de travail, la plateforme SCIGNE ou les sites partenaires. Il remplace la précédente documentation détaillant l'utilisation des outils lcg-util (ces outils ne sont plus maintenus).

Les systèmes de stockage

Cette section présente les différents systèmes de stockage disponibles sur la plateforme SCIGNE.

DPM

La part la plus importante du stockage de la plateforme est disponible à travers le service DPM et différents protocoles (HTTP, SRM, XRootD).

Le système de stockage DPM (Disk Pool Manager) est composé d'un serveur de tête et d'un ensemble de serveurs de fichiers. Le serveur de tête centralise les requêtes d'accès aux fichiers. Les serveurs de fichiers stockent physiquement les fichiers. L'accès aux fichiers s'effectue en interrogeant le serveur de tête à l'aide des commandes détaillées dans ce document.

L'accès aux données est contrôlé par certificat. Il est donc nécessaire de posséder un proxy valide lors de l'utilisation de ce type de stockage.

iRODS

Une autre part du stockage est accessible à travers le logiciel iRODS. iRODS est un système de stockage évolué, disposant de fonctionnalités avancées permettant d'implémenter des plans de gestion de données. Une documentation dédiée est disponible pour ce service.

Gestion des données sur un serveur DPM

Cette section détaille la gestion des données stockées sur un serveur DPM.

Généralités

L'URL suivante est utilisée pour l'ensemble de cette section. Elle sera abrégée en ${SRM} :

$ export SRM="srm://sbgse1.in2p3.fr:8446/dpm/in2p3.fr/home/vo.grand-est.fr"

Installation du client

Actuellement, les paquets ne sont disponibles que pour la distribution RedHat et ses dérivés. Les paquets sont disponibles dans le dépôt EPEL. Une fois ce dépôt disponible sur votre système, les outils gfal2 et dpm peuvent être rapidement installés avec :

$ yum install gfal2-util gfal2-all dpm

Lecture du contenu d'un répertoire

La commande gfal-ls permet de lister le contenu d'un répertoire. Le résultat de cette commande est similaire à celui de la commande ls. Dans l'exemple ci-dessous, remplacez :

$ gfal-ls ${SRM}
EOST
LIMH
LIVE
UMR7200
$ gfal-ls -l ${SRM}
drwxrwx---   1 48    50            0 Feb  6  2014 EOST
drwxrwx---   1 53    52            0 Feb  1  2013 LIMH
drwxrwx---   1 48    51            0 Apr  4  2015 LIVE
drwxrwx---   1 48    54            0 Mar 31  2011 UMR7200

Création d'un répertoire

La commande gfal-mkdir permet de créer un répertoire :

$ gfal-mkdir ${SRM}/lab/user/data

Copie d'un fichier

La commande gfal-copy permet de copier des données depuis ou vers un serveur DPM :

$ gfal-copy file://${PWD}/my_dataset.tar.gz ${SRM}/lab/user/data/my_dataset.tar.gz
Copying file://${PWD}/my_dataset.tar.gz   [DONE]  after 2s

Vérification des droits d'un fichier

La commande dpns-getacl permet d'obtenir les permissions d'accès à un fichier ou à un dossier. Le chemin du fichier utilisé par cette commande est raccourci par rapport à la variable ${SRM}, mais il faut au préalable exporter la variable d'environnement DPNS_HOST :

$ export DPNS_HOST=sbgse1.in2p3.fr
$ dpns-getacl /dpm/in2p3.fr/home/vo.grand-est.fr/lab/user/data/my_dataset.tar.gz
# file: /dpm/in2p3.fr/home/vo.grand-est.fr/lab/user/data/my_dataset.tar.gz
# owner: /O=GRID-FR/C=FR/O=CNRS/OU=LAB/CN=USER
# group: vo.grand-est.fr
user::rw-
group::rw-           #effective:rw-
other::r--

Modification des droits d'un fichier

La commande dpns-setactl permet de modifier les permissions d'accès à un fichier ou à un répertoire. Par défaut, les fichiers créés dans un répertoire héritent des permissions de ce répertoire. La commande suivante permet d'empêcher la consultation (lecture et écriture) à tout le monde, sauf au propriétaire et au groupe du fichier :

$ dpns-setacl -s u::6,g::4,o::0 /dpm/in2p3.fr/home/vo.grand-est.fr/lab/user/data/my_dataset.tar.gz
$ dpns-getactl /dpm/in2p3.fr/home/vo.grand-est.fr/lab/user/data/my_dataset.tar.gz
# file: /dpm/in2p3.fr/home/vo.grand-est.fr/lab/user/data/my_dataset.tar.gz
# owner: /O=GRID-FR/C=FR/O=CNRS/OU=LAB/CN=USER
# group: vo.france-grilles.fr
user::rw-
group::r--           #effective:r--
other::---

Suppression d'un fichier

La commande gfal-rm permet de supprimer un fichier sur le serveur DPM :

$ gfal-rm ${SRM}/lab/user/data/my_dataset.tar.gz

Suppression d'un répertoire

La commande gfal-rm -r permet de supprimer un répertoire (et son contenu) :

$ gfal-rm -r ${SRM}/lab/user/data

Documentation complémentaire

Ces liens proposent des références complémentaires pour approfondir la gestion des données sur la plateforme SCIGNE :

Introduction

Le service de Cloud Computing IaaS de la plateforme SCIGNE permet aux utilisateurs de démarrer des machines virtuelles (VM) de manière indépendante, et d'orchestrer ces déploiements pour créer des infrastructures de calcul à la demande. L'utilisateur peut choisir le système d'exploitation et le gabarit (nombre de coeurs, quantité de mémoire et de disque) de chacune de ces machines. Le fonctionnement de ce service repose sur le logiciel OpenStack.

Grâce aux différents modules disponibles (authentification, gestion des images, gestion du stockage, conteneurs à la demande, ordonnanceur, ...), OpenStack permet de piloter une infrastructure Cloud et de fournir un ensemble complet de services aux utilisateurs.

Cette documentation détaille l'utilisation du client en ligne de commande openstack interagissant avec les modules OpenStack pour utiliser efficacement le service de Cloud Computing IaaS. Une alternative à l'utilisation de la ligne de commande est d'utiliser l'interface Web Horizon.

L'équipe de la plateforme SCIGNE se tient disponible pour réaliser des formations sur l'utilisation de ce service. Pour cela, n'hésitez pas à Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. !

Installation

Cette section détaille la procédure d'installation du client en ligne de commande d'OpenStack.

Le client openstack est disponible pour différents systèmes d'exploitation, soit à travers une installation avec PIP ou par les gestionnaires de paquets APT ou YUM pour les distributions Linux Debian, Ubuntu, RedHat ou dérivées. Dans tous les cas, il est nécessaire que le logiciel Python (version 2.7 ou ultérieure) soit installé. Une seule installation est nécessaire, soit avec le gestionnaire de paquets de votre distribution, soit avec PIP. Nous recommandons d'utiliser l'installation à l'aide du gestionnaire de paquets quand c'est possible.

Les différents modes d'installation sont détaillées ci-après. Il faut éviter d'utiliser deux modes d'installation, en mélangeant par exemple PIP avec les paquets de la distribution, pour éviter des conflits entre les différentes versions qui peuvent rendre le client inutilisable.

Installation avec PIP

Pour suivre cette partie, il est nécessaire que PIP soit installé. Cette installation est détaillée sur le site de PIP. Le client openstack est installé avec les commandes suivantes :

$ pip install python-openstackclient

Installation sur les systèmes Debian et Ubuntu

La version du client openstack fournie par défaut dans Ubuntu 16.04 est trop ancienne et présente des bugs. Il faut donc utiliser une version plus récente disponible dans le dépôt cloud-archive. Pour installer un client openstack récent, il faut exécuter en tant que super-utilisateur (c'est-à-dire avec la commande sudo pour Ubuntu) :

$ sudo add-apt-repository cloud-archive:pike
$ sudo apt-get update
$ sudo apt-get install python-openstackclient

Note

Pour les versions antérieures d'Ubuntu, il est nécessaire d'utiliser la méthode d'installation avec PIP.

Installation sur les systèmes RedHat et dérivés

Les procédures d'installation pour les différentes distributions basées sur RedHat ne sont pas identiques.

Installation sur RedHat

L'installation en utilisant yum avec le système RedHat est réalisée en quelques étapes suivantes. Le logiciel n'est disponible que pour la version 7 de RedHat. Si vous souhaitez installer les clients sur une version antérieure, il est nécessaire de suivre la méthode d'installation PIP.

$ sudo yum install -y https://www.rdoproject.org/repos/openstack/openstack-pike/rdo-release-pike-1.noarch.rpm
$ sudo yum update -y
$ sudo yum install -y python-openstackclient

Installation sur CentOS

L'installation en utilisant yum avec le système CentOS est réalisée en quelques étapes suivantes. Le logiciel n'est disponible que pour la version 7 de CentOS. Si vous souhaitez installer les clients sur une version antérieure, il est nécessaire de suivre la méthode d'installation PIP.

$ sudo yum install -y centos-release-openstack-pike
$ sudo yum update -y
$ sudo yum install -y python-openstackclient

Note

Le paquet centos-release-openstack-pike est fournit par le dépôt extras, activé par défaut dans CentOS 7.

Vérification de l'installation

Exécutez la command openstack aver l'argument --version pour vérifier que le client est correctement installé :

$ openstack --version
openstack 3.12.0

Notez que la version retournée par la commande peut différer de la version ci-dessus.

Définition des variables d'environnement

Après avoir réalisé l'installation, vous êtes prêts à utiliser le service. La première étape est de configurer le client. Pour cela, créer le fichier ${HOME}/.novacreds/iphc.sh avec le contenu suivant (les valeurs username et password sont à remplacer par celles qui vous ont été transmises lors de la création de votre compte sur le service) :

export LANG=en_US.utf-8
export LC_ALL=en_US.utf-8
export OS_USERNAME=username
export OS_PASSWORD=password
export OS_PROJECT_NAME=FG_Cloud
export OS_USER_DOMAIN_NAME=default
export OS_PROJECT_DOMAIN_NAME=default
export OS_AUTH_URL=https://sbgcloud.in2p3.fr:5000/v3
export OS_IDENTITY_API_VERSION=3

Une fois que ce fichier est créé, il doit être sourcé pour charger les différentes variables d'environnement dans votre shell actuel :

$ source ${HOME}/.novacreds/iphc.sh

Il est nécessaire de réaliser cette étape à chaque fois que vous lancez un nouveau shell, à moins que vous n'ajoutiez la commande source précédente au fichier d'initialisation de votre shell (par exemple, le fichier ${HOME}/.bashrc pour le shell bash).

Vous pouvez maintenant tester que votre client fonctionne et qu'il arrive à se connecter correctement au Cloud :

$ openstack server list

Changement du mot de passe

Il est fortement conseillé de changer votre mot de passe avant votre première utilisation du service. Pour cela, utilisez la commande suivante :

$ openstack user password set
Current Password:
New Password:
Repeat New Password:
You should update the password you are using to authenticate to match your new password

Après avoir effectué cette opération, votre nouveau mot de passe est changé côté serveur, mais il n'est pas encore pris en compte coté client :

$ openstack server list
ERROR: Invalid OpenStack Nova credentials.

Il faut modifier aussi la variable d'environnement correspondante :

$ export OS_PASSWORD=MY_NEW_PASSWORD
$ openstack server list
+--------------------------------------+-------+--------+---------------------------+------------------------------+
| ID                                   | Name  | Status | Networks                  | Image Name                   |
+--------------------------------------+-------+--------+---------------------------+------------------------------+
| 36dd1e32-2a79-4e78-a4e1-999335de3cbd | MY_VM | ACTIVE | fg-cloud-net=172.16.3.222 | FG_Cloud-Ubuntu-16.04-x86_64 |
+--------------------------------------+-------+--------+---------------------------+------------------------------+

Si cette dernière commande s'effectue avec succès, vous pouvez maintenant mettre le fichier ${HOME}/.novacreds/iphc.sh à jour avec votre nouveau mot de passe.

Une fois que vous avez mis à jour le mot de passe dans le fichier ${HOME}/.novacreds/iphc.sh, il est nécessaire de sourcer à nouveau ce fichier pour que son nouveau contenu soit pris en compte.

L'aide en ligne est disponible :

$ openstack help user set

Change current user password

optional arguments:
  -h, --help            show this help message and exit
  --password <new-password>
                        New user password
  --original-password <original-password>
                        Original user password

Gestion de la clé SSH

Afin de pouvoir se connecter à la machine virtuelle, il est nécessaire d'utiliser une clé SSH et de l'enregistrer auprès du serveur OpenStack :

$ ssh-keygen -t rsa -f ${HOME}/.novacreds/cloudkey
[...]
$ openstack keypair create --public-key=${HOME}/.novacreds/cloudkey.pub cloudkey
$ openstack keypair list
+----------+-------------------------------------------------+
| Name     | Fingerprint                                     |
+----------+-------------------------------------------------+
| cloudkey | 33:91:4b:38:52:63:1d:18:7b:e0:e3:0d:3b:63:ce:4b |
+----------+-------------------------------------------------+

Gestion des machines virtuelles

Cette partie décrit la gestion des machines virtuelles.

Découverte de l'environnement OpenStack

Quelques commandes permettent de voir les éléments disponibles pour construire son image virtuelle. Tout d'abord, la liste des images de systèmes d'exploitation pour les machines virtuelles est obtenue avec :

$ openstack image list
+--------------------------------------+---------------------------------------------------------+--------+
| ID                                   | Name                                                    | Status |
+--------------------------------------+---------------------------------------------------------+--------+
| 926204b5-51d1-4d2e-81cf-a6d429b76121 | Image for CentOS 6 minimal [CentOS/6.x/KVM]_Appliance   | active |
| 92876744-962e-4831-851e-b57e68bc8cdc | Image for CentOS Server 6 [CentOS/6/KVM]                | active |
| 05e60b88-0fe7-42e7-a69d-0c3f7cd50955 | Image for CentOS Server 7 [CentOS/7/KVM]                | active |
| 114486ef-70f5-4c7f-ab91-0591448f0408 | Image for Fedora Atomic 27 [Fedora/27/KVM]              | active |
| 315dfa48-bbbd-4391-8dbd-f235149e8548 | Image for Ubuntu Server 14.04.05 LTS [Ubuntu/14.04/KVM] | active |
| e61497cd-8b23-4297-8742-557851c8d278 | Image for Ubuntu Server 16.04 LTS [Ubuntu/16.04/KVM]    | active |
+--------------------------------------+---------------------------------------------------------+--------+

Note

La liste des images disponibles n'étant pas figée (les images sont mises à jour réguliérement), il est fort probable que vous obteniez un résultat un peu différent.

Ensuite, la liste des gabarits de machines virtuelles (flavor) disponibles est affichée avec :

$ openstack flavor list
+----+----------------------+--------+------+-----------+-------+-----------+
| ID | Name                 |    RAM | Disk | Ephemeral | VCPUs | Is Public |
+----+----------------------+--------+------+-----------+-------+-----------+
| 1  | m1.tiny              |    512 |    1 |         0 |     1 | True      |
| 10 | m1.2xlarge-xbigmem   | 131072 |  320 |         0 |    16 | True      |
| 11 | m1.2xl-xbigmem-lowhd | 131072 |   50 |         0 |    16 | True      |
| 12 | m1.2xl-hugemem-lowhd | 262144 |   50 |         0 |    16 | True      |
| 2  | m1.small             |   2048 |   20 |         0 |     1 | True      |
| 3  | m1.medium            |   4096 |   40 |         0 |     2 | True      |
| 4  | m1.large             |   8192 |   80 |         0 |     4 | True      |
| 5  | m1.xlarge            |  16384 |  160 |         0 |     8 | True      |
| 6  | m1.2xlarge           |  32768 |  320 |         0 |    16 | True      |
| 7  | m1.cms-small         |   2048 |   50 |         0 |     1 | True      |
| 8  | m1.small-bigmem      |   4096 |   20 |         0 |     1 | True      |
| 9  | m1.2xlarge-hugemem   | 262144 |  320 |         0 |    16 | True      |
+----+----------------------+--------+------+-----------+-------+-----------+

Enfin, pour connaître les réseaux utilisables par la machine virtuelle, utilisez :

$ openstack network list
+--------------------------------------+--------------+--------------------------------------+
| ID                                   | Name         | Subnets                              |
+--------------------------------------+--------------+--------------------------------------+
| 16ddcf0e-05c7-4023-8fc6-9cb49fd93aa4 | fg-cloud-net | 3298961e-7787-4879-b147-ea4ecac2cdf3 |
| 8fa5eb12-ee72-4e77-a45b-8fde11efc75f | ext-net      | 6e8ffc7a-4536-4c21-a8e5-00227ee8619a |
+--------------------------------------+--------------+--------------------------------------+

Dans le tableau précédent, nous remarquons que deux réseaux sont disponibles, fg-cloud-net et ext-net. En fait, seul le réseau fg-cloud-net est utilisable directement au boot par la machine virtuelle. L'autre réseau est utilisé par la suite pour fournir des adresses IPs publiques.

Lancement de la machine virtuelle ( VM )

Dans la section précédente, nous avons récupéré la liste de tous les éléments utilisables pour composer la machine virtuelle. Une fois que vous avez choisi les différents éléments de votre machine virtuelle, elle peut être instanciée à l'aide de la commande openstack server create. Par exemple, si nous souhaitons lancer une image Ubuntu avec 1 cpu, 2 Go de RAM et 20 Go de disque dur sur le réseau fg-cloud-net et dont le nom sera MY_VM_NAME, nous utiliserons la commande suivante :

$ openstack server create --key-name cloudkey --image 92876744-962e-4831-851e-b57e68bc8cdc \
  --flavor m1.small --nic net-id=16ddcf0e-05c7-4023-8fc6-9cb49fd93aa4 MY_VM_NAME
+-----------------------------+---------------------------------------------------------------------------------+
| Field                       | Value                                                                           |
+-----------------------------+---------------------------------------------------------------------------------+
| OS-DCF:diskConfig           | MANUAL                                                                          |
| OS-EXT-AZ:availability_zone |                                                                                 |
| OS-EXT-STS:power_state      | NOSTATE                                                                         |
| OS-EXT-STS:task_state       | scheduling                                                                      |
| OS-EXT-STS:vm_state         | building                                                                        |
| OS-SRV-USG:launched_at      | None                                                                            |
| OS-SRV-USG:terminated_at    | None                                                                            |
| accessIPv4                  |                                                                                 |
| accessIPv6                  |                                                                                 |
| addresses                   |                                                                                 |
| adminPass                   | TUKseuxU23oW                                                                    |
| config_drive                |                                                                                 |
| created                     | 2018-07-11T08:29:41Z                                                            |
| flavor                      | m1.small (2)                                                                    |
| hostId                      |                                                                                 |
| id                          | 91243eef-9168-4250-b4d8-466f02797823                                            |
| image                       | Image for CentOS Server 6 [CentOS/6/KVM] (92876744-962e-4831-851e-b57e68bc8cdc) |
| key_name                    | cloudkey                                                                        |
| name                        | MY_VM_NAME                                                                      |
| progress                    | 0                                                                               |
| project_id                  | 59402a7327114c2cb97f0d9e6263cdda                                                |
| properties                  |                                                                                 |
| security_groups             | name='default'                                                                  |
| status                      | BUILD                                                                           |
| updated                     | 2018-07-11T08:29:41Z                                                            |
| user_id                     | c13c93bf1b79447c8cd1464128d7685f                                                |
| volumes_attached            |                                                                                 |
+-----------------------------+---------------------------------------------------------------------------------+

Note

Lors du lancement de machines virtuelles, vous pouvez vous retrouver confronté à des problèmes de dépassement de quota :

$ openstack server create [...] MY_VM_NAME
ERROR: Quota exceeded for cores: Requested 1, but already used 22 of 22 cores
(HTTP 413) (Request-ID: req-6aefedba-4666-4393-b6a1-24423f3bef78)

Dans cet exemple, l'erreur vous indique que tous les processeurs disponibles pour votre groupe (project) sont actuellement occupés. Vous pouvez soit attendre que d'autres utilisateurs en libèrent, ou alors demander aux administrateur du service de vous attribuer un quota supplémentaire.

Vous pouvez consulter les limites de quota grâce à la commande suivante :

$ openstack quota show
+----------------------+----------------------------------+
| Field                | Value                            |
+----------------------+----------------------------------+
| backup-gigabytes     | 1000                             |
| backups              | 10                               |
| cores                | 256                              |
| fixed-ips            | -1                               |
| floating-ips         | 50                               |
| gigabytes            | 1500                             |
| gigabytes_lvm        | -1                               |
| groups               | 10                               |
| health_monitors      | None                             |
| injected-file-size   | 10240                            |
| injected-files       | 5                                |
| injected-path-size   | 255                              |
| instances            | 64                               |
| key-pairs            | 100                              |
| l7_policies          | None                             |
| listeners            | None                             |
| load_balancers       | None                             |
| location             | None                             |
| name                 | None                             |
| networks             | 100                              |
| per-volume-gigabytes | -1                               |
| pools                | None                             |
| ports                | 500                              |
| project              | 59402a7327114c2cb97f0d9e6263cdda |
| project_name         | FG_Cloud                         |
| properties           | 128                              |
| ram                  | 1048576                          |
| rbac_policies        | 10                               |
| routers              | 10                               |
| secgroup-rules       | 100                              |
| secgroups            | 50                               |
| server-group-members | 10                               |
| server-groups        | 10                               |
| snapshots            | 10                               |
| snapshots_lvm        | -1                               |
| subnet_pools         | -1                               |
| subnets              | 100                              |
| volumes              | 50                               |
| volumes_lvm          | -1                               |
+----------------------+----------------------------------+

L'aide en ligne est disponible et décrit tous les paramètres utilisables :

$ openstack help server create
usage: openstack server create [-h] [-f {json,shell,table,value,yaml}]
                               [-c COLUMN] [--max-width <integer>]
                               [--fit-width] [--print-empty] [--noindent]
                               [--prefix PREFIX]
                               (--image <image> | --volume <volume>) --flavor
                               <flavor> [--security-group <security-group>]
                               [--key-name <key-name>]
                               [--property <key=value>]
                               [--file <dest-filename=source-filename>]
                               [--user-data <user-data>]
                               [--availability-zone <zone-name>]
                               [--block-device-mapping <dev-name=mapping>]
                               [--nic <net-id=net-uuid,v4-fixed-ip=ip-addr,v6-fixed-ip=ip-addr,port-id=port-uuid,auto,none>]
                               [--network <network>] [--port <port>]
                               [--hint <key=value>]
                               [--config-drive <config-drive-volume>|True]
                               [--min <count>] [--max <count>] [--wait]
                               <server-name>

 Create a new server
 [...]

Note

Lors de l'utilisation de la commande openstack, il est possible d'utiliser aussi bien les noms (par exemple MY_VM_NAME) que les identifiants (par exemple 36dd1e32-2a79-4e78-a4e1-999335de3cbd). Il est recommandé d'utiliser les identifiants, car ils sont uniques (il est possible de lancer deux machines virtuelles avec le même nom).

Avec la commande suivante, il est possible de suivre l'état de la VM :

$ openstack server show MY_VM_NAME
+-----------------------------+---------------------------------------------------------------------------------+
| Field                       | Value                                                                           |
+-----------------------------+---------------------------------------------------------------------------------+
| OS-DCF:diskConfig           | MANUAL                                                                          |
| OS-EXT-AZ:availability_zone | nova                                                                            |
| OS-EXT-STS:power_state      | Running                                                                         |
| OS-EXT-STS:task_state       | None                                                                            |
| OS-EXT-STS:vm_state         | active                                                                          |
| OS-SRV-USG:launched_at      | 2018-07-11T08:30:11.000000                                                      |
| OS-SRV-USG:terminated_at    | None                                                                            |
| accessIPv4                  |                                                                                 |
| accessIPv6                  |                                                                                 |
| addresses                   | fg-cloud-net=172.16.3.3                                                         |
| config_drive                |                                                                                 |
| created                     | 2018-07-11T08:29:41Z                                                            |
| flavor                      | m1.small (2)                                                                    |
| hostId                      | 7b9bc039b792fb0a6c58cfcc43c2209ec6c59e49fa13fad59abe140f                        |
| id                          | 91243eef-9168-4250-b4d8-466f02797823                                            |
| image                       | Image for CentOS Server 6 [CentOS/6/KVM] (92876744-962e-4831-851e-b57e68bc8cdc) |
| key_name                    | cloudkey                                                                        |
| name                        | MY_VM_NAME                                                                      |
| progress                    | 0                                                                               |
| project_id                  | 59402a7327114c2cb97f0d9e6263cdda                                                |
| properties                  |                                                                                 |
| security_groups             | name='default'                                                                  |
| status                      | ACTIVE                                                                          |
| updated                     | 2018-07-11T08:30:11Z                                                            |
| user_id                     | c13c93bf1b79447c8cd1464128d7685f                                                |
| volumes_attached            |                                                                                 |
+-----------------------------+---------------------------------------------------------------------------------+

Le status ACTIVE nous indique que la VM est prête à être utilisée. Toutefois, elle ne possède pas encore d'interface vers le réseau externe, puisque son adresse IP est dans le réseau interne. Avant de pouvoir s'y connecter par SSH, il est nécessaire de lui attacher une adresse IP publique (visible et accessible depuis internet). ce point est détaillé dans le chapitre Gestion du réseau.

Personnalisation des machines virtuelles

Vous pouvez personnaliser vos machines virtuelles lors de leur démarrage initial grâce au paramètre --user-data de openstack server create. Ce paramètre doit référencer un fichier contenant des instructions pour le logiciel cloud-init qui est présent dans la machine virtuelle.

L'exemple suivant met à jour le système et installe des paquets supplémentaires, utiles pour chiffrer un volume.

Créez un fichier cloud_init_cfg.txt contenant :

#cloud-config

# Upgrade the instance OS packages on first boot
package_upgrade: true

# Add packages for entropy gathering and encrypted volume management
packages:
    - haveged
    - cryptsetup

Note

le premier caractère '#' doit figurer tel-quel dans le fichier, il indique au logiciel cloud-init le format du contenu du fichier cloud_init_cfg.txt.

Et utilisez-le lors du démarrage de votre machine virtuelle :

$ openstack server create [...] --user-data cloud_init_cfg.txt MY_VM_NAME

Note

Attention: l'exécution du logiciel cloud-init n'est pas instantanée. Si vous demandez une mise à jour complète du système d'exploitation, cela peut prendre plusieurs minutes avant d'être effectué, alors que vous pouvez déjà vous connecter à la VM grâce à ssh. Pour vérifier que tout s'est bien passé, vous pouvez vérifier le contenu des fichiers : /var/log/cloud-init.log et /var/log/cloud-init-output.log sur la machine virtuelle.

Le logiciel cloud-init est très sensible au format du fichier cloud_init_cfg.txt, les espaces, tabulations et autres éléments de formattage sont importants. En plus de vous référer à la documentation citée ci-dessous, vous pouvez vous aider du logiciel yamllint pour vérifier le format. Toutefois celui-ci est plus pointilleux que cloud-init, donc n'utilisez ses remarques que de manière informative. Construisez votre script de contextualisation petit à petit en vérifiant à chaque étape que ce que vous avez ajouté fonctionne correctement.

Référez-vous à la documentation de cloud-init pour de plus amples informations sur les possibilités de configuration.

Gestion du réseau

Dans un premier temps, il faut vérifier si une adresse IP est disponible :

$ openstack floating ip list
+--------------------------------------+---------------------+------------------+--------------------------------------+
| ID                                   | Floating IP Address | Fixed IP Address | Port                                 |
+--------------------------------------+---------------------+------------------+--------------------------------------+
| 06ab2066-1158-4547-b909-94eaf1e29409 | 134.158.151.70      | 172.16.3.146     | ac2d31e4-f4dd-11e6-a174-ef95e2c5306b |
| 076aaea9-4dc5-46f7-8c77-8e783b6af9a1 | 134.158.151.26      | None             | None                                 |
| 0f4c02ef-e0d7-475a-a4f1-f5923fa4d5c4 | 134.158.151.72      | 172.16.3.131     | cbeaef62-f4dd-11e6-8601-a75ed3a3d535 |
+--------------------------------------+---------------------+------------------+--------------------------------------+

Dans cette liste, deux adresses IPs sont déjà associées à une adresse IP privée et une adresse est disponible (le champs Fixed IP Address a pour valeur None). Si toutes les adresses IPs sont utilisées, il faut en créer une nouvelle :

$ openstack floating ip create ext-net
+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| description         |                                      |
| fixed_ip_address    | None                                 |
| floating_ip_address | 134.158.151.224                      |
| floating_network_id | 314be651-fcaa-4dcc-ac0a-dfdcd7e58ba1 |
| headers             |                                      |
| id                  | f60c77d9-bae4-422d-83c3-16d155bac396 |
| port_id             | None                                 |
| project_id          | 59402a7327114c2cb97f0d9e6263cdda     |
| router_id           | None                                 |
| status              | DOWN                                 |
+---------------------+--------------------------------------+

Lorsqu'une adresse IP est disponible, elle peut être attachée à notre VM avec la commande suivante :

$ openstack server add floating ip MY_VM_NAME 134.158.151.224

Il est possible de vérifier que l'adresse IP a bien été atttachée :

$ openstack server list --name MY_VM_NAME -c ID -c Name -c Networks
+--------------------------------------+------------+--------------------------------------------+
| ID                                   | Name       | Networks                                   |
+--------------------------------------+------------+--------------------------------------------+
| 91243eef-9168-4250-b4d8-466f02797823 | MY_VM_NAME | fg-cloud-net=172.16.3.222, 134.158.151.224 |
+--------------------------------------+------------+--------------------------------------------+

Maintenant que la machine virtuelle a une adresse IP publique, vous pouvez tester la connectivité avec la commande ping :

$ ping -c 3 134.158.151.224

Et vous pouvez vous y connecter avec ssh :

$ ssh -i ${HOME}/.novacreds/cloudkey Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.

Si la connexion à la machine virtuelle par SSH échoue, consultez la section Erreur de connexion avec SSH.

Note

Les noms d'utilisateur par défaut sont pour les images Ubuntu et pour les images CentOS respectivement ubuntu et centos.

Gestion du stockage

Par défaut, lorsqu'une machine virtuelle est détruite, tous les changements que vous avez pu y apporter disparaissent. Pour pouvoir stocker des données réutilisables entre plusieurs sessions, il est nécessaire de créer des disques permanents. Pour afficher la liste de vos disques, utilisez :

$ openstack volume list
+--------------------------------------+---------------+-----------+------+--------------------------------------------+
| ID                                   | Display Name  | Status    | Size | Attached to                                |
+--------------------------------------+---------------+-----------+------+--------------------------------------------+
| d874ed50-f4dd-11e6-b99e-8f36e05a44c6 | MONGODB       | in-use    |  100 | Attached to DATA_ANALYSIS on /dev/vdd      |
| e3469d32-f4dd-11e6-b9be-3b36b57652e5 | DATA_1        | in-use    |  200 | Attached to DATA_ANALYSIS on /dev/vdc      |
| ec8de7c4-f4dd-11e6-a96b-7f9e7042f1e8 | chemistry-vol | available |  200 |                                            |
| 0243cb42-f4de-11e6-9d72-b73ff56f8215 | VM_IPHC_START | available |   10 |                                            |
| 09c16c44-f4de-11e6-8b45-433e4aa51e4c | SIMDAT_VOLUME | available |    8 |                                            |
| 0e48a656-f4de-11e6-878b-eb0c0efe4cca | vmdata_disk_2 | available |  250 |                                            |
| 13c86eae-f4de-11e6-b316-1f8b7ed3376e | DATA_DISK     | in-use    |   50 | Attached to DATA_ANALYSIS on /dev/vdb      |
| 179a0326-f4de-11e6-920c-c7f2b28ed02b | R_Data        | in-use    |    8 | Attached to vm_iphc_r_analysis on /dev/vdb |
+--------------------------------------+---------------+-----------+------+--------------------------------------------+

Pour créer un nouvel espace de stockage persistant (nommé MY_VOLUME_NAME et d'une taille de 8 Go), exécutez :

$ openstack volume create --size 8 MY_VOLUME_NAME
+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| attachments         | []                                   |
| availability_zone   | nova                                 |
| bootable            | false                                |
| consistencygroup_id | None                                 |
| created_at          | 2017-02-16T10:08:02.493311           |
| description         | None                                 |
| encrypted           | False                                |
| id                  | 58230433-086f-4ff2-99ac-8c3e0f5520c2 |
| multiattach         | False                                |
| name                | MY_VOLUME_NAME                       |
| properties          |                                      |
| replication_status  | disabled                             |
| size                | 8                                    |
| snapshot_id         | None                                 |
| source_volid        | None                                 |
| status              | creating                             |
| type                | None                                 |
| updated_at          | None                                 |
| user_id             | c13c93bf1b79447c8cd1464128d7685f     |
+---------------------+--------------------------------------+

Pour attacher ce nouveau volume à la machine virtuelle à l'aide de son identifiant, utilisez la commande :

$ openstack server add volume --device /dev/vdb MY_VM_NAME 58230433-086f-4ff2-99ac-8c3e0f5520c2

Le stockage sera mis à disposition par le système d'exploitation en tant que /dev/vdb. Pour vérifier que le disque est bien associé, vérifiez que la colonne Status à pour valeur in-use et que la colonne Attached to contient bien l'identifiant de la VM :

$ openstack volume list --name MY_VOLUME_NAME
+--------------------------------------+----------------+--------+------+------------------------------------+
| ID                                   | Display Name   | Status | Size | Attached to                        |
+--------------------------------------+----------------+--------+------+------------------------------------+
| 58230433-086f-4ff2-99ac-8c3e0f5520c2 | MY_VOLUME_NAME | in-use |    8 | Attached to MY_VM_NAME on /dev/vdb |
+--------------------------------------+-------------------------+------+------------------------------------+

Au départ, ce disque ne contient aucune donnée et n'est pas formaté. Si ce disque est destiné à contenir des données confidentielles, nous vous recommandons de le chiffrer. Cette opération est détaillée dans le chapitre Chiffrage des disques permanents. Dans le cas contraire, connectez-vous à votre VM pour formater ce disque et le monter :

[centos@my-vm-name ~]$ sudo su
[root@my-vm-name centos]# mkfs -t ext4 /dev/vdb
[root@my-vm-name centos]# mkdir /storage1
[root@my-vm-name centos]# mount /dev/vdb /storage1
[root@my-vm-name centos]# df -h /storage1
Filesystem      Size  Used Avail Use% Mounted on
/dev/vdb        8.0G  3.0M  7.8G   1% /storage1

La dernière commande permet de vérifier que nous avons bien l'espace disponible de la taille choisie (ici 8 Go) monté sur /storage1.

Note

Le disque virtuel peut également être partitionné avant le formatage. Pour ce faire, référez-vous à la documentation du système d'exploitation choisi.

Vous pouvez le déplacer d'une machine virtuelle à une autre en le démontant au sein de la VM (pour garantir l'intégrité des données stockées sur ce disque) :

[root@my-vm-name centos]# umount /storage1

Note

Si vous avez ajouté votre volume persistant dans le fichier /etc/fstab de votre machine virtuelle (c.f. plus bas), pensez à supprimer la ligne en question avant de démonter le disque virtuel sous peine de ne plus pouvoir démarrer votre VM.

Puis en détachant le disque à l'aide des commandes :

$ openstack server remove volume MY_VM_NAME 58230433-086f-4ff2-99ac-8c3e0f5520c2
$ openstack volume list --name MY_VOLUME_NAME
+--------------------------------------+----------------+-----------+------+-------------+
| ID                                   | Display Name   | Status    | Size | Attached to |
+--------------------------------------+----------------+-----------+------+-------------+
| 58230433-086f-4ff2-99ac-8c3e0f5520c2 | MY_VOLUME_NAME | available |    8 |             |
+--------------------------------------+----------------------------+------+-------------+

Note

Lorsque la machine virtuelle est redémarrée, le disque n'est pas monté automatiquement au système de fichier. Pour monter le disque automatiquement, il faut ajouter une entrée dans le fichier /etc/fstab.

Fin d'une machine virtuelle

Une fois les tâches sur la VM terminées, elle peut être arrêtée pour être redémarrée plus tard :

$ openstack server stop MY_VM_NAME
$ openstack server start MY_VM_NAME

Afin de libérer les ressources, la VM peut également être supprimée. Dans ce cas, toutes les modifications qui ont été apportées à l'image (installation de paquets, ...) seront perdues, hormis celles qui sont sur le disque persistant. Avant de supprimer la VM, il faut se connecter à la VM et démonter le disque persistant (pour éviter de corrompre les données) :

[root@my-vm-name centos]# umount /storage1

Si vous n'avez plus besoin des données sur le disque persistant, il faut le réinitialiser avec des données aléatoires pour des raisons de confidentialité (cette opération peut être assez longue) :

[root@my-vm-name centos]# dd if=/dev/urandom of=/dev/vdb bs=4k

Puis, une fois la suppression des données effectives, détacher et supprimer le volume avec :

$ openstack server remove volume  MY_VM_NAME 58230433-086f-4ff2-99ac-8c3e0f5520c2
$ openstack volume delete 58230433-086f-4ff2-99ac-8c3e0f5520c2

Enfin, vous pouvez supprimer la VM :

$ openstack server delete MY_VM_NAME

Utilisation avancée

Ce chapitre décrit des possibilités d'utilisation avancée du service de Cloud Computing IaaS.

Chiffrage des disques permanents

Cette section détaille l'utilisation de l'outil dm-crypt/LUKS pour le chiffrage des disques permanents. Cet outil est fourni en standard par les distributions Linux et peut facilement être installé avec le gestionnaire de paquets dans votre machine virtuelle. L'exemple se base sur l'utilisation d'une distribution Ubuntu, mais peut facilement être réalisé avec une distribution RedHat.

ubuntu@my-vm-name:~$ sudo su -
sudo: unable to resolve host my-vm-name
root@my-vm-name:~# apt -y update
root@my-vm-name:~# apt -y install cryptsetup

Pour chiffrer un disque permanent, il faut tout d'abord l'initialiser correctement. Dans l'exemple ci-dessous, le disque dénommé /dev/vdb est dans un premier temps rempli de données aléatoires, puis il est initialisé à l'aide de la commande cryptsetup luksFormat ci-dessous. Cette première étape peut être assez longue.

root@my-vm-name:~# dd if=/dev/urandom of=/dev/vdb bs=4k
root@my-vm-name:~# cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 \
--iter-time 5000 --use-random luksFormat /dev/vdb

Si cette dernière commande ralentit, voire bloque avec le message suivant :

System is out of entropy while generating volume key.
Please move mouse or type some text in another window to gather some random events.
Generating key (0% done).

Alors vous pouvez rendre la commande cryptsetup [...] luksFormat plus rapide en installant préalablement le programme haveged dans votre machine virtuelle (ce qui déjà fait si vous avez suivi la procédure décrite dans le chapitre Personnalisation des machines virtuelles).

La commande suivante permet de vérifier que le disque est maintenant du type LUKS :

root@my-vm-name:~# cryptsetup luksDump /dev/vdb
LUKS header information for /dev/vdb

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha512
Payload offset: 4096
MK bits:        512
MK digest:      c4 f7 4b 02 2a 3f 12 c1 2c ba e5 c9 d2 45 9a cd 89 20 6c 73
MK salt:        98 58 3e f3 f6 88 99 ea 2a f3 cf 71 a0 0d e5 8b
                d5 76 64 cb d2 5c 9b d1 8a d3 1d 18 0e 04 7a eb
MK iterations:  81250
UUID:           c216d954-199e-4eab-a167-a3587bd41cb3

Key Slot 0: ENABLED
    Iterations:             323227
    Salt:                   a0 45 3e 98 fa cf 60 74 c6 09 3d 54 97 89 be 65
                            5b 96 7c 1c 39 26 47 b4 8b 0e c1 3a c9 94 83 c2
    Key material offset:    8
    AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Le disque est maintenant prêt à être utilisé. La première fois que vous l'utilisez, il faut effectuer les étapes suivantes :

  1. Ouvrir le disque chiffré avec la commande cryptsetup luksOpen. Le nom storage1 n'est qu'indicatif, vous pouvez choisir ce que vous voulez :

    root@my-vm-name:~# cryptsetup luksOpen /dev/vdb storage1
    
  2. Créer un système de fichier sur le disque :

    root@my-vm-name:~# mkfs.ext4 /dev/mapper/storage1
    
  3. Créer le point de montage du disque :

    root@my-vm-name:~# mkdir /storage1
    
  4. Monter le disque :

    root@my-vm-name:~# mount -t ext4 /dev/mapper/storage1 /storage1
    
  5. Vérifier l'espace disponible (cela peut être légèrement différent de ce qui a été entré lors de la commande openstack volume create) :

    root@my-vm-name:~# df -h /storage1
    Filesystem            Size  Used Avail Use% Mounted on
    /dev/mapper/storage1  2.0G  6.0M  1.9G   1% /storage1
    

Une fois que le disque est opérationnel, les étapes 2 et 3 ne sont plus nécessaires.

Vous pouvez maintenant envoyer des fichiers (par exemple DONNEES.dat) depuis votre ordinateur personnel dans votre machine virtuelle de façon sécurisée, par exemple avec scp :

$ scp -i ${HOME}/.novacreds/cloudkey DONNEES.dat Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.:/le/chemin/destination
DONNEES.dat                               100%   82     0.1KB/s   00:00

Lorsque vous avez terminé votre travail sur le disque, vous pouvez le retirer proprement avec les commandes suivantes :

root@my-vm-name:~# umount /storage1
root@my-vm-name:~# cryptsetup close storage1

Pour les utilisations suivantes du disque virtuel persistant, il n'y aura pas besoin d'effectuer toutes ces opérations, seules les suivantes sont nécéssaires :

root@my-vm-name:~# cryptsetup luksOpen /dev/vdb storage1
root@my-vm-name:~# mkdir /storage1
root@my-vm-name:~# mount -t ext4 /dev/mapper/storage1 /storage1

Résolution des problèmes

Cette section vous permet de résoudre les problèmes les plus communs rencontrés lors de l'utilisation de OpenStack.

Erreur de connexion avec SSH

Immédiatement après le démarrage de la machine virtuelle, vous pouvez vous retrouver avec des problèmes de connection :

$ ssh -i ${HOME}/.novacreds/cloudkey Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.
ssh: connect to host 134.158.151.224 port 22: Connection refused

Ce problème est généralement dû au fait que le service SSH n'est pas encore démarré sur la machine virtuelle. Il faut attendre, cela pouvant prendre jusqu'à plusieurs minutes.

Un autre type d'erreur peut être rencontré :

$ ssh -i ${HOME}/.novacreds/cloudkey Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.
[...]
Permission denied (publickey).

Dans ce cas, il faut vérifier que la clé SSH que vous utilisez est la même que celle stockée dans la base de données OpenStack. Pour cela, vérifiez que leurs empreintes (fingerprint) sont équivalentes. Pour obtenir l'empreinte de la clé stocké par OpenStack, exécutez :

$ openstack keypair list
+----------+-------------------------------------------------+
| Name     | Fingerprint                                     |
+----------+-------------------------------------------------+
| cloudkey | 0d:97:13:66:49:03:44:da:69:82:3c:dd:b9:d7:25:64 |
+----------+-------------------------------------------------+

Et pour obtenir l'empreinte de la clé utilisé par la commande ssh, exécutez :

$ ssh-keygen -lf ${HOME}/.novacreds/cloudkey.pub
2048 33:91:4b:38:52:63:1d:18:7b:e0:e3:0d:3b:63:ce:4b  you@home (RSA)

Si elles sont différentes, il faut mettre à jour votre clé publique dans OpenStack :

$ openstack keypair delete cloudkey
$ openstack keypair add --pub-key=${HOME}/.novacreds/cloudkey.pub cloudkey
$ openstack keypair list
+----------+-------------------------------------------------+
| Name     | Fingerprint                                     |
+----------+-------------------------------------------------+
| cloudkey | 33:91:4b:38:52:63:1d:18:7b:e0:e3:0d:3b:63:ce:4b |
+----------+-------------------------------------------------+

Si elles sont bien identiques, il se peut que OpenStack n'ait pas réussi à les installer correctement lors du démarrage de la nouvelle VM. La brique logicielle cloud-init est responsable de l'installation de la clé SSH dans votre machine virtuelle. Vous pouvez voir les lignes de log de cloud-init dans la console de la machine virtuelle. Pour obtenir l'url de connexion à la console, utilisez la commande suivante :

$ openstack console url show --novnc MY_VM_NAME
+-------+----------------------------------------------------------------------------------------+
| Type  | Url                                                                                    |
+-------+----------------------------------------------------------------------------------------+
| novnc | http://sbgcloud.in2p3.fr:6080/vnc_auto.html?token=d609176d-c397-4841-b4dc-566300209209 |
+-------+----------------------------------------------------------------------------------------+

Puis, après vous être connecté à la console avec un navigateur Internet, recherchez les lignes qui contiennent les éléments ci-info et Authorized keys from et comparez les empreintes de votre clé. Si vous voyez des messages d'erreur, le plus simple est de Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. de SCIGNE en leur fournissant une copie de ces messages d'erreur.

Lorsque la clé est transférée avec succès sur la machine virtuelle, vous avez un message du type :

Cloud-init v. 0.7.5 running 'module:final' at Mon, 27 Jun 2015 08:15:34 +0000. Up 65.40 seconds.
ci-info: ++++++++++++++Authorized keys from /root/.ssh/authorized_keys for user root++++++++++++++
ci-info: +---------+-------------------------------------------------+---------+-----------------+
ci-info: | Keytype |                Fingerprint (md5)                | Options |     Comment     |
ci-info: +---------+-------------------------------------------------+---------+-----------------+
ci-info: | ssh-rsa | 33:91:4b:38:52:63:1d:18:7b:e0:e3:0d:3b:63:ce:4b |    -    |   Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.   |
ci-info: +---------+-------------------------------------------------+---------+-----------------+

Si vous souhaitez uniquement consulter la sortie console de la machine virtuelle, il sera plus confortable d'utiliser :

$ opentack console log show MY_VM_NAME

Documentation complémentaire

Les sites suivants peuvent être consultés pour obtenir plus d'informations concernant l'utilisation d'OpenStack :

Introduction

L'intergiciel (middleware) utilisé par le service de calcul à haut débit (grille de calcul) de la plateforme SCIGNE repose sur un ensemble d'outils utilisant un certficat X509 pour s'authentifier auprès des différents services (calcul, stockage). Ce certificat permet de simplifier et de sécuriser l'authentification aux différentes ressources constituant la grille de calcul internationale.

Ce document détaille l'obtention et la gestion de ce certificat dans le cadre de l'utilisation des ressources de grille, que ce soit celle de la plateforme SCIGNE ou des infrastructures EGI et WLCG.

Les certificats électroniques

Le certificat électronique est une carte d'identité numérique qui permet :

  • d'indiquer la qualité du possesseur du certificat (utilisateur, service ou machine) et la limite de validité des informations contenues ;
  • de s'authentifier et d'obtenir un certain nombre de privilèges sur un ensemble de services de la grille ;
  • d'assurer la confidentialité des échanges grâce au chiffrement des données ;
  • d'assurer la non-répudiation et l'intégrité des données grâce à la signature numérique.

Le certificat est délivré par une autorité de certification qui fait foi de tiers de confiance. Pour les personnels issus des établissements français (CEA, CNRS, INRA, INRIA, INSERM, Universités, ...) les certificats sont délivrés par l'Infrastructure de Gestion de Clés (IGC) hébergée Ministère de l'Education nationale, de l'Enseignement supérieur et de la Recherche, à travers un service administré par RENATER.

Obtention d'un certificat

Pour obtenir un certificat utilisable avec le service de calcul à haut débit, deux étapes sont nécessaires. Tout d'abord, il faut en faire la demande auprès de l'autorité de certification, puis il faut s'enregistrer avec le certificat délivré auprès de l'organisation virtuelle (VO) vo.grand-est.fr (et également vo.sbg.in2p3.fr pour les utilisateurs de l'IPHC).

Demande de certificat

La demande du certificat se fait en six étapes.

  1. Vérifier les consignes d'obtention de certificat GRID-FR
  2. Récupérer le certificat de l'autorité de certification (AC) pour qu'elles soient reconnues par votre navigateur en se connectant sur la page des ACs GRID2-FR (si vous ne l'avez pas encore fait). En effet, les navigateurs comme Firefox, Internet Explorer ou Safari n'intégrent pas par défaut les certificats de l'AC du ministère. Il faut donc les charger manuellement et indiquer à son navigateur qu'ils sont de confiance.
  3. Demander un certificat utilisateur par l'onglet Request a Certificate en remplissant le formulaire en ligne. Les personnes des laboratoires CNRS (UMR, ...) doivent effectuer leur demande en renseignant leur adresse e-mail. Si c'est votre première demande, contactez l'Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. pour vous accompagner.
  4. Une fois la demande effectuée, vous allez recevoir une demande de confirmation par messagerie. Il es nécessaire de confirmer votre demande en répondant à ce courrier électronique.
  5. Une fois votre demande confirmée, elle sera validée par l'autorité d'enregistrement. Un message électronique vous préviendra de cette validation, de la création de votre certificat et de la marche à suivre pour le récupérer.
  6. Récupérer et sauvegarder votre certificat en suivant la procédure décrite dans la section.

Enregistrement auprès de la VO régionale

Afin de pouvoir effectuer des calculs sur la grille régionale, il est nécessaire d'enregistrer votre certificat auprès de la VO vo.grand-est.fr en vous rendant sur la page d'enregistrement. L'enregistrement au sein de la VO permet de vous attribuer un ensemble de droits sur la grille régionale de calcul. Une fois le formulaire rempli, vous recevrez un message électronique vous demandant de confirmer votre demande. Il est important de répondre à ce message pour pouvoir rejoindre la VO régionale.

Pour les utilisateurs de l'IPHC, la VO vo.sbg.in2p3.fr est également disponible. Pour vous inscrire à cette VO, rendez-vous sur la page d'enregistrement de cette VO.

Une fois que votre demande est validée, vous pouvez utiliser votre certificat pour accéder aux ressources de la grille régionale et effectuer des calculs.

Enregistrement auprès d'autres VOs

D'autres VOs sont disponibles et permettent d'accéder à des ressources de calcul et de stockage plus importantes. N'hésitez pas à contacter l'équipe support de la plateforme SCIGNE pour obtenir plus d'informations pour y accéder.

Vous trouverez ci-dessous la liste des VOs supportées et le lien pour s'incrire :

La liste globale des VOs existantes est disponible sur le portail des VOs. Si vous souhaitez que la plateforme supporte d'autres VOs, n'hésitez pas à contacter Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. !

Renouvellement du certificat

Chaque année, vous allez recevoir un message électronique vous invitant à renouveler votre certificat, deux mois avant son expiration. Cette étape est réalisée en se connectant sur le site indiqué dans le message. Le certificat renouvelé n'a pas besoin d'être ré-enregistré auprès de la VO régionale.

Gestion du certificat électronique avec le navigateur

Le certificat est utilisé avec votre navigateur pour accéder aux sites sécurisés. Cette section décrit les méthodes pour importer et exporter les certificats depuis les navigateurs Firefox, Internet Explorer et Safari. La sauvegarde du certificat est importante afin de pouvoir le récupérer en cas de réinstallation de votre navigateur, ainsi que pour pouvoir l'utiliser avec d'autres logiciels (outils pour accéder à la grille, logiciel de messagerie, ...).

Gestion du certificat avec Firefox

Cette section décrit l'importation et l'exportation d'un certificat avec le navigateur Firefox.

Importer un certificat

Pour importer votre certificat électronique vers Firefox, suivez les étapes suivantes.

  1. Allez dans le menu Édition > Préférences puis sélectionner Vie privée et sécurité > Afficher les certificats.
  2. Dans l'onglet Vos certificats, sélectionnez le certificat à sauvegarder, puis cliquez sur Importer....
  3. Une fenêtre s'ouvre vous permettant de sélectionner le fichier à importer. Une fois que vous avez sélectionné le fichier contenant le certificat, une boîte de dialogue apparaît pour vous demander le mot de passe principal de Sécurité personnelle.
  4. Une nouvelle fenêtre apparaît vous demandant le mot de passe protégeant le certificat. Entrez le mot de passe et validez en appuyant sur le bouton OK. Une fenêtre vous informe alors que la récupération des certificats et clés privées est réussie.

Exporter un certificat

Pour exporter votre certificat électronique depuis Firefox, suivez les étapes ci-dessous.

  1. Allez dans le menu Édition > Préférences puis sélectionner Vie privée et sécurité > Afficher les certificats.
  2. Dans l'onglet Vos certificats, sélectionnez le certificat à sauvegarder, puis cliquez sur Sauvegarder....
  3. Le logiciel demandera sous quel nom sera sauvegardé le certificat. Le certificat sera sauvegardé au format PKCS12 (extension .p12).
  4. Une boîte de dialogue apparaît ensuite pour vous demander votre mot de passe principal de Sécurité personnelle, puis par deux fois le mot de passe pour protéger votre certificat. Il est important d'avoir un mot de passe robuste et de ne pas le perdre.
  5. Une fois que vous avez validé les mots de passe, Firefox sauvegarde votre certificat à l'endroit indiqué.

Gestion du certificat avec Internet Explorer

Cette section décrit l'importation et l'exportation d'un certificat avec le navigateur Internet Explorer

Importer un certificat

Pour importer votre certificat électronique vers Internet Explorer, suivez les étapes suivantes.

  1. Allez dans Outils > Options Internet > Contenu > Certificats. Dans l'onglet Personnel, cliquez sur le bouton Importer... et passez la première page de l'assistant.
  2. Choisissez le certificat à importer en cliquant sur Parcourir puis en sélectionnant Échange d'informations personnelles dans le menu déroulant permettant de sélectionner le type de fichier.
  3. Entrez le mot de passe de protection du certificat et cliquez sur les cases Activer la protection renforcée et Marquer cette clé comme exportable.
  4. Sélectionnez le magasin de certificats et terminer en passant à l'écran suivant.
  5. Une nouvelle fenêtre s'ouvre. Elle vous permet de choisir le niveau de sécurité. Cliquez sur Définir le niveau de sécurité... et choisissez Haut. Le prochain écran vous demande un mot de passe. Utilisez un mot de passe robuste pour protéger votre certificat et terminez l'importation en cliquant sur Terminer.

Exporter un certificat

Pour exporter votre certificat électronique depuis Internet Explorer, suivez les étapes ci-dessous.

  1. Allez dans Outils > Options Internet > Contenu > Certificats.
  2. Dans l'onglet Personnel, sélectionnez votre certificat.
  3. Cliquez sur Exporter et passez la première page de l'assistant.
  4. Choisissez l'option Oui, exporter la clé privée, puis cliquez sur Suivant.
  5. Choisissez l'exportation au format PKCS #12 et cochez les deux premières cases.
  6. Vous devez alors saisir deux fois le mot de passe de chiffrement du certificat. Il est recommandé de choisir un mot de passe robuste.
  7. Choisissez enfin l'emplacement et le nom du fichier et confirmez au niveau du récapitulatif. Votre certificat est sauvegardé avec l'extension .pfx (un fichier au format PKCS12 peut avoir les extensions .p12 ou .pfx).

Gestion du certificat avec Safari

Cette section décrit l'importation et l'exportation d'un certificat avec le navigateur Safari

Importer un certificat

Pour importer votre certificat électronique vers Safari, suivez les étapes suivantes.

  1. Double-cliquez sur le fichier de certificat que vous souhaitez importer. Le Trousseau d'accès s'ouvre et vous demande si vous souhaitez ajouter le certificat au trousseau. Sélectionnez le trousseau session et cliquez sur le bouton Ajouter.
  2. Une fenêtre s'ouvre vous demandant le mot de passe protégeant le certificat. Entrez le mot de passe et cliquez sur le bouton OK. Le certificat est alors importé.
  3. Vous pouvez vérifier que le certificat est bien installé en cliquant dans la catégorie Mes Certificats du Trousseau d'accès.

Exporter un certificat

Pour exporter votre certificat électronique depuis Safari, suivez les étapes ci-dessous.

  1. Sélectionnez Applications > Utilitaires > Trousseau d'accès.
  2. Cliquez dans la catégorie Mes Certificats, puis sélectionnez le certificat à exporter.
  3. Sélectionnez fichier > Exporter, puis saisissez le nom du fichier à créer, son emplacement (Bureaupar défaut) et le format PKCS12.
  4. Saisissez le mot de passe de chiffrement et validez pour sauvegarder votre certificat.

Gestion du certificat en ligne de commande

L'utilisation des logiciels pour accéder à la grille de calcul (gestion des calculs et du stockage) nécessite un certificat électronique de type X509. Ce certificat se compose des fichiers userkey.pem (clé privée) et usercert.pem (clé publique) qui doivent être placés dans le répertoire $HOME/.globus. Ils sont générés à partir du fichier PKCS12 sauvegardé depuis le navigateur en utilisant l'outil en ligne de commande openssl. Dans l'exemple ci-dessous, nous supposons que le certificat a été enregistré sous le nom cert.p12. La génération de la clé privée et de la clé publique est réalisée avec les commandes suivantes :

$ openssl pkcs12 -nocerts -in cert.p12 -out ~/.globus/userkey.pem
$ openssl pkcs12 -clcerts -nokeys -in cert.p12 -out ~/.globus/usercert.pem
$ chmod 400 ~/.globus/userkey.pem
$ chmod 400 ~/.globus/usercert.pem
$ ls ~/.globus
-r-------- 1 user group 1935 Feb 16  2010 usercert.pem
-r-------- 1 user group 1920 Feb 16  2010 userkey.pem

La commande chmod est utilisée pour restreindre l'accès aux certificats au seul utilisateur.