Notes Martin ajoutées et qqs erreurs typos corrigées. Reste à trouver un DNS...

Notes Martin ajoutées et qqs erreurs typos corrigées. Reste à trouver un DNS ouvert différent de google...

first_steps.md

@@ -66,7 +66,7 @@ insert-ethers
 Créez une autre VM:
  - 512Mo de RAM
  - Disque d'au moins 25Go
- - Configurez le réseau pour que la "Carte 1" soit sous réseau interne avec mode proscuité
+ - Configurez le réseau pour que la "Carte 1" soit sous réseau interne (nommé intnet ou "_local-x_" si vous avez utilisé le script python de création de VM) avec mode proscuité autorisé pour les VMs.
  - Configurez le boot (menu système) pour que l'ordre d'amorçage prenne en charge le réseau et soit en premier dans la liste.
  - Démarrez cette nouvelle VM.
 

mpi.md

@@ -5,7 +5,7 @@ Le but ici n'est pas d'apprendre la programmation MPI, mais de se mettre dans la
 
 ### Hello World
 
-Application des plus classique quand on démarre un nouveau langage. On va utiliser une version en C. Copiez le contenu suivant dans le fichier ```helloMPI.c```
+L'application la plus classique quand on démarre un nouveau langage. On va utiliser une version en C. Copiez le contenu suivant dans le fichier ```helloMPI.c```
 
 ```c
 #include <stdio.h>
@@ -13,9 +13,9 @@ Application des plus classique quand on démarre un nouveau langage. On va utili
 
 #define MAX_LEN 25
 
-int main(int argc, char \*\*argv) {
+int main(int argc, char **argv) {
         int rank, size;
-        FILE \*fp;
+        FILE *fp;
         char hostnm[MAX_LEN + 1];
 
         MPI_Init(&argc, &argv);  //initialisation MPI
@@ -31,6 +31,7 @@ int main(int argc, char \*\*argv) {
         MPI_Finalize();  //fin de la communication MPI
         return 0;
 }
+
 ```
 
 
@@ -42,11 +43,11 @@ mpicc helloMPI.c -o helloMPI
 
 ### Lancement du job MPI directement sans SGE
 
-Ce qui suit est à proscrire pour vos utilisateurs. Nous allons tester le job MPI sans passer par SGE.
+Ce qui suit est donné à titre informatif/pédagogique mais c'est à proscrire pour vos utilisateurs. Nous allons tester le job MPI sans passer par SGE.
 
 > **Caution** De manière générale aucun job ne doit être lancé sur le noeud maître et tout doit être exécuté avec qsub. A la limite *qrsh* ou *qlogin* peuvent être utilisés pour faire des tests.
 
-Il nous faut d'abord créer un fichier ```machinefile``` qui contiendra la liste de nos noeuds. Si vous n'avez qu'un seul noeud, ce n'est pas terrible, surtoût pour un job paralléliser par MPI (...), mais on fera avec (dans ce cas, ne pas mettre la deuxième ligne). Contenu du fichier ```machinefile```:
+Il nous faut d'abord créer un fichier ```hostsfile``` qui contiendra la liste de nos noeuds. Si vous n'avez qu'un seul noeud, ce n'est pas terrible, surtoût pour un job paralléliser par MPI (...), mais on fera avec (dans ce cas, ne pas mettre la deuxième ligne). Contenu du fichier ```hostsfile```:
 ```
 compute-0-0
 compute-0-4
@@ -68,7 +69,7 @@ Nous demandons 25 coeurs donc le job échoue.
 
 ### lancement du job MPI avec SGE
 
-En principe, vous n'avez pas à vous préoccuper du fichier ```machines``` ou ```machinefile``` dans notre cas. SGE s'en occupe pour vous. C'est par exemple le cas avec l'environnement parallèle _mpi_ qui existe par défaut (la variable $pe_hostfile définit sur quels noeuds et sur combien de coeurs par noeud le job va tourner):
+En principe, vous n'avez pas à vous préoccuper du fichier ```machines``` ou ```hostsfile``` dans notre cas. SGE s'en occupe pour vous. C'est par exemple le cas avec l'environnement parallèle _mpi_ qui existe par défaut (la variable $pe_hostfile définit sur quels noeuds et sur combien de coeurs par noeud le job va tourner):
 
 ```bash
 qconf -sp mpi

quoi_faire.md

@@ -11,7 +11,7 @@ En effet, le principal problème de RocksCluster est son aspect vieillissant et
 
 En effet, bien qu'étant assez modulaire, il est difficile de sortir de RedHat/CentOS and co. (ScientificLinux). RocksCluster est peu souvent mis à jour:
 - il faut attendre longtemps après une mise à jour de CentOS, or CentOS est déjà en retard par rapport à RedHat.
-Cela peu poser des problèmes évidents de sécurité (exemples récents de failles OpenSSL ou bien bash) ou si vous souhaitez accéder à des fonctionnalités implémentées dans des versions récentes de CentOS (ex: _cgroups_ noyau / _docker_, version de _python_ (2.6, 2.7), de _yum_ et de la _glibc_ par défaut...). Tout ceci peut être changé, patché, maintenu manuellement (...) mais nécessite du temps et des compétences.
+Cela peut poser des problèmes évidents de sécurité (exemples récents de failles OpenSSL ou bien bash) ou si vous souhaitez accéder à des fonctionnalités implémentées dans des versions récentes de CentOS (ex: _cgroups_ noyau / _docker_, version de _python_ (2.6, 2.7), de _yum_ et de la _glibc_ par défaut...). Tout ceci peut être changé, patché, maintenu manuellement (...) mais nécessite du temps et des compétences.
 
 Par contre, la faible fréquence des mises à jour indique également une certaine stabilité et l'orientation CentOS/RedHat amène comme avantage tout l'écosystème existant sous RedHat, notamment la certification de certains drivers, etc...
 
@@ -55,12 +55,15 @@ Pour la mise en place d'un nouveau projet, je conseille de visionner [cette vid
 
 > **Comment** les systèmes de fichiers parallélisés existaient il y a longtemps dans Rocks au travers de PVFS. Cependant, ce dernier n'est plus utilisé/maintenu et proposé par Rocks. Un "roll" lustre existe pour la version 6.0 de RocksCluster.
 
+----
+
+
 Cependant, RocksCluster reste une distribution Linux classique basée sur CentOS. Vous pouvez le modifier comme bon vous semble et tout le code de surcouche _maison_ Rocks est libre et modifiable à souhait. Le fichier extend-compute permet de passer en phase de post-installation n'importe quel script shell.
 
 A l'UMR5554/ISE-M et sur la plate-forme LabEx MBB, nous utilisons un RocksCluster modifié pour nos besoins:
 - pas de service 411 pour synchroniser nos utilisateurs, mais une connexion à un LDAP,
 - un système de déploiement et d'hébergement de packages _maison_,
-- plusieurs NAS déclarés dans Rocks (mais pas gérés par Rocks) sous debian like avec NFS/ZFS, qui hébergent les homes des utilisateurs et des applcations ainsi que des librairies,
+- plusieurs NAS déclarés dans Rocks (mais pas gérés par Rocks) sous debian like avec NFS/ZFS, qui hébergent les homes des utilisateurs et des applications ainsi que des librairies,
 - et de nombreux autres scripts _maison_.
 
 Nous envisageons toutefois une migration vers une solution _maison_ à base d'un serveur d'image et de distribution debian/\*, avec SLURM comme gestionnaire de batch. Cependant, cela demande de rééduquer nos utilisateurs (comment soumettre et gérer ses jobs, etc...).