https://wiki-ima.plil.fr/mediawiki//api.php?action=feedcontributions&feedformat=atom&user=AdurotWiki d'activités IMA - Contributions de l’utilisateur [fr]2026-05-14T02:51:10ZContributions de l’utilisateurMediaWiki 1.29.2https://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48900TP sysres IMA5sc 2018/2019 G32018-12-17T17:15:31Z<p>Adurot : /* Authentification LDAP sur point d'accès */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP commune=<br />
<br />
==Création des machines virtuelles==<br />
Pour réaliser cette partie du TP nous avons besoin d'une machine virtuelle, nous allons la créer sur cordouan à l'aide de l'hyperviseur xen.<br />
<br />
Nous créons donc une image qui sera la base de notre machine :<br />
<br />
xen-create-image --hostname=pegase --ip=193.48.57.179 --netmask=255.255.255.240 --gateway=193.48.57.160 -size=10Gb --swap=128Mb --lvm=virtual<br />
<br />
Une fois que cette image est créée, on édite le fichier de configuration /etc/xen/pegase.cfg afin de lui attribuer une interface réseau virtuelle qui sera dans le bridge IMA5sc.<br />
<br />
vif = [ 'mac=00:16:3E:6F:37:08, bridge=IMA5sc' ]<br />
<br />
Une fois le fichier de configuration créé, nous pouvons lancer la machine virtuelle à l'aide de la commande suivante et de son option -c permettant d'afficher la console. <br />
<br />
xl create -c /etc/xen/pegase.cfg<br />
<br />
Le mot de passe root était affiché à l'écran à la fin de la création de la machine virtuelle, mais il est toujours possible d'aller le récupérer dans les logs dans le fichier /var/log/xen-tools/pegase.log<br />
<br />
==Ajout de partitions logiques==<br />
<br />
Notre machine virtuelle fonctionne et est connectée au réseau. Pour le moment un seul volume de 10Go accueil notre système. Pour les besoins du TP, nous allons sur l'hôte (cordouan) créer deux volumes virtuels, un pour le /home et un autre pour le /var. Nous allons créer ces volumes virtuels dans le groupe de volume "virtual". Nous ajoutons également trois volumes de 1Gb afin de faire un RAID 5 logiciel dans la machine virtuelle.<br />
<br />
lvcreate -L10G -n pegase-home virtual<br />
lvcreate -L10G -n pegase-var virtual<br />
lvcreate -L1G -n pegase-part1 virtual<br />
lvcreate -L1G -n pegase-part2 virtual<br />
lvcreate -L1G -n pegase-part3 virtual<br />
<br />
Nous ajoutons ensuite ces volumes à notre machine virtuelle en tant que disque physique xvdb1, xvdc1, etc...<br />
<br />
root = '/dev/xvda2 ro'<br />
disk = [<br />
'phy:/dev/virtual/pegase-disk,xvda2,w',<br />
'phy:/dev/virtual/pegase-swap,xvda1,w',<br />
'phy:/dev/virtual/Pegase-home,xvdb1,w',<br />
'phy:/dev/virtual/Pegase-var,xvdc1,w',<br />
'phy:/dev/virtual/pegase-part1,xvdd1,w',<br />
'phy:/dev/virtual/pegase-part2,xvde1,w',<br />
'phy:/dev/virtual/pegase-part3,xvdf1,w'<br />
]<br />
<br />
<br />
Nous pouvons maintenant redémarrer la machine et monter un système de fichier sur nos disques. On peut vérifier qu'ils existent d'ailleurs à l'aide de la commande fdisk -l.<br />
<br />
mkfs -t ext4 xvdb1<br />
mkfs -t ext4 xvdc1<br />
mkfs -t ext4 xvdd1<br />
mkfs -t ext4 xvde1<br />
mkfs -t ext4 xvdf1<br />
<br />
Nous ajoutons le montage du disque xvdb1 en tant que /home dans /etc/fstab<br />
<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
<br />
Pour le /var, il faut faire attention de ne pas perdre les données déjà existante, au risque d'avoir une machine inutilisable. Ainsi, on va venir monter temporairement le disque xvdc1 dans /mnt avant d'y déplacer l'intégralité du /var.<br />
<br />
mount /dev/xvdc1 /mnt<br />
mv /var/* /mnt<br />
<br />
Une fois ceci fait, nous pouvons le rajouter dans /etc/fstab<br />
<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
<br />
Maintenant, intéressons nous au RAID, nous avons utilisé l'utilitaire mdadm afin de réaliser le RAID5 en logiciel. Puis nous avons formaté la partition formée par le raid avant de la monter. Puis nous créons un fichier sur cette partition.<br />
<br />
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1<br />
mkfs -t ext4 /dev/md0<br />
mount /dev/md0 /mnt<br />
touch coucou.txt<br />
<br />
On ajoute le /dev/md0 au /etc/fstab afin qu'il soit monté au lancement de la machine :<br />
<br />
proc /proc proc defaults 0 0<br />
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0<br />
/dev/xvda1 none swap sw 0 0<br />
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
/dev/md0 /mnt/raid ext4 defaults 0 2<br />
<br />
<br />
On vérifie que tous nos disques ont été correctement montés :<br />
<br />
lsblk<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
xvda1 202:1 0 128M 0 disk [SWAP]<br />
xvda2 202:2 0 10G 0 disk /<br />
xvdb1 202:17 0 10G 0 disk /home<br />
xvdc1 202:33 0 10G 0 disk /var<br />
xvdd1 202:49 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
xvde1 202:65 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
xvdf1 202:81 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
<br />
Par défaut, notre raid n'a pas de fichier de configuration, nous devons en créer un. Sans fichier de configuration, le device RAID ne sera pas forcément créé dans /dev/md0 mais dans un md aléatoire, ainsi, notre fstab plantera (car nous n'aurons pas forcément le RAID sur /dev/md0). Donc nous devons avoir un fichier de configuration qui sera persistant et chargé par le noyau durant le boot. <br />
<br />
mdadm -Es >> /etc/mdadm.conf<br />
<br />
Cette configuration ressemble à <br />
<br />
cat /etc/mdadm.conf<br />
ARRAY /dev/md/0 metadata=1.2 UUID=b28705d4:15d1703c:4cf988d8:f0d77f12 name=pegase-ansible2:0<br />
<br />
<br />
A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre redondance, simulons une panne sur un des disques de notre RAID, ce qui pourrait arriver dans un cas réel.<br />
<br />
mdadm --set-faulty /dev/md0 /dev/xvdf1<br />
mdadm --remove /dev/xvdf1<br />
<br />
Nous constatons que notre fichier coucou.txt est toujours présent, malgré la "perte" de l'un des disques. Cependant, il faut tout de même se dire que nous avons fait un raid logiciel sur des partitions logiques, en pratique, si on perd vraiment le disque, nous perdrons quoi qu'il arrive tous les volumes logiques. Ainsi nous faisons ça pour l'aspect éducatif.<br />
<br />
==Chiffrement des disques RAID==<br />
<br />
Il peut être utile pour diverses raison de chiffrer les disques afin qu'un accès non autorisé par le propriétaire soit proscrit. Pour cela nous allons utiliser l'utilitaire cryptsetup avec le format LUKS afin de chiffrer notre disque en AES-256 avec un mot de passe.<br />
<br />
==Installation de bind et apache2==<br />
<br />
L'objectif va être d'héberger notre propre serveur DNS grâce au logiciel bind et de vérifier son fonctionnement en hébergeant un site web avec apache2. On commence donc par installer ces deux paquets :<br />
<br />
apt-get install apache2 bind9<br />
<br />
==Configuration de Bind==<br />
<br />
Pour continuer ce TP, nous avons acheté un nom de domaine (pegase.space) sur le registraire Gandi. La configuration de bind se trouve dans le répertoire <code>/etc/bind</code> dans lequel nous avons créé un fichier nommé <code>db.pegase.space</code> représentant notre zone et avec le contenu suivant :<br />
<br />
$TTL 604800 <br />
@ IN SOA ns.pegase.space. root.pegase.space ( <br />
42 ; Serial <br />
604800 ; Refresh <br />
86400 ; Retry <br />
2419200 ; Expire <br />
604800 ) ; Negative Cache TTL <br />
; <br />
IN NS ns.pegase.space. <br />
ns IN A 193.48.57.179 <br />
www IN A 193.48.57.179 <br />
@ IN A 193.48.57.179<br />
<br />
Nous avons également modifié le fichier de configuration <code>named.conf.local</code> en ajoutant la ligne allow-transfer à "none".<br />
<br />
zone "pegase.space" {<br />
type master; <br />
file "/etc/bind/db.pegase.space"; <br />
allow-transfer {"none";}; <br />
}; <br />
<br />
On peut maintenant redémarrer le service bind qui est maintenant opérationnel<br />
<br />
service bind9 restart<br />
<br />
Nous nous sommes ensuite rendu sur le site de Gandi sur lequel avons ajouté un Glue Record <code>ns.pegase.space</code> pointant vers l'IP de notre VM. Cet enregistrement permet la résolution du nom de notre serveur DNS qui ne peut se résoudre lui même.<br />
<br />
On peut ensuite ajouter le serveur maître utilisé pour résoudre les adresses de notre zone pegase.space à savoir <code>ns.pegase.space</code>.<br />
<br />
Après un certain temps, le temps que ces informations se propagent, nous étions en mesure d'obtenir l'IP de notre VM en effectuant par exemple un <br />
<br />
host pegase.space<br />
<br />
==Sécuriser les échanges DNS : DNSSEC==<br />
<br />
Dans cette partie, nous allons faire en sorte de certifier à un utilisateur que l'IP qu'il reçoit dans la réponse DNS est bien celle du domaine voulu. Pour ce faire, nous allons configurer bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.<br />
<br />
On commence naturellement par activer DNSSEC en ajoutant l'option <code>dnssec-enable yes;</code> dans le fichier <code>/etc/bind/named.conf.local</code>.<br />
<br />
On génère deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. <br />
<br />
dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE pegase.space<br />
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE pegase.space<br />
<br />
Nous avons ensuite renommé ces clefs pour plus de lisibilité en <code>pegase-zsk.key</code>, <code>pegase-zsk.private</code>, <code>pegase-ksk.key</code>, <code>pegase-ksk.private</code><br />
<br />
On ajoute ensuite via la directive <code>include</code> nos clefs au fichier de zone <code>db.pegase.space</code><br />
<br />
$include /etc/bind/pegase-ksk.key<br />
$include /etc/bind/pegase-zsk.key<br />
<br />
Nous pouvons maintenant signer la zone :<br />
<br />
dnssec-signzone -o pegase.space -k pegase-ksk db.pegase.space pegase-zsk<br />
<br />
Enfin, il ne faut pas oublier d'incrémenter la valeur du sérial dans <code>db.pegase.conf</code> et de changer le fichier de zone dans <code>named.conf.local</code>.<br />
<br />
zone "pegase.space" {<br />
type master; <br />
file "/etc/bind/db.pegase.space.signed"; <br />
allow-transfer {"none";}; <br />
}; <br />
<br />
Du coté de chez Gandi, il faut fournir les deux clefs publiques générés dans la rubrique DNSSEC en veillant à sélectionner le bon algorithme de chiffrement.<br />
<br />
Pour attester du bon fonctionnement de DNSSEC, on pourra utiliser le site http://dnsviz.net/.<br />
<br />
[[Fichier:pegase-dnssec.png]]<br />
<br />
==Cassage d'une clef WPA==<br />
<br />
L'exercice de cette sous-partie consiste à se procurer le mot de passe de la borne WiFi cracotte03. Il existe pour ce faire une suite logicielle nommée aircrack-ng spécialisée dans l'analyse des réseaux WiFi. Une fois doté d'un ordinateur équipé d'une carte WiFi, il faut commencer par noter le nom de l'interface sans-fil, ici wlp3s0.<br />
<br />
On peut maintenant lancer la commande suivante :<br />
<br />
airmon-ng start wlp3s0<br />
<br />
Celle-ci a pour effet de créer une nouvelle interface (wlp3s0mon) sans-fil mais en mode moniteur, mode permettant de capturer tous les paquets d'un réseau sans-fil.<br />
<br />
On repère ensuite le BSSID de cracotte03 ainsi que son channel.<br />
<br />
airodump-ng wlp3s0mon<br />
<br />
Nous sommes maintenant en mesure de récupérer les trames brutes correspondant au handshake.<br />
<br />
airodump-ng --bssid 04:DA:D2:9C:50:52 wlp3s0mon--channel 9 --write result<br />
<br />
Finalement, nous pouvons lancer le cassage de la clef :<br />
<br />
aircrack-ng result-01.cap -w dico<br />
<br />
Le fichier <code>dico</code> contient l'ensemble des possibilités des mots de passe à 8 chiffres (de 00000000 à 99999999) que va devoir essayer aircrack-ng.<br />
<br />
'''Résultat :''' 42429904<br />
<br />
[[Fichier:wpa-cracotte03.png]]<br />
<br />
=Sécuriser apache2 : SSL/TLS=<br />
<br />
==Création du certificat==<br />
<br />
Nous commençons par un générer deux fichiers grâce à la commande <br />
<br />
openssl req -nodes -newkey rsa:2048 -sha1 -keyout pegase.space.key -out pegase.csr<br />
<br />
* <code>pegase.csr</code> : il s'agit d'un fichier servant à faire une demande de certificat auprès d'une autorité de certification. Il contient quelques informations personnelles ainsi que la clef publique.<br />
* <code>pegase.space.key</code> : c'est la clef privée (à ne jamais distribuer) qui est complémentaire à celle présente dans le csr.<br />
<br />
On peut ensuite se rendre sur Gandi afin d'acheter le certificat. Le csr sera demandé pendant la procédure puis il faudra choisir une des trois méthodes proposées pour la vérification. Nous avons choisi celle par email car il s'agit à priori de la pus rapide.<br />
<br />
Il nous faut maintenant récupérer notre certificat depuis Gandi ainsi que le certificat intermédiaire. On déplace ensuite l'ensemble de ces clefs dans les répertoires appropriés.<br />
<br />
/etc/ssl/certs/pegase.space.crt <br />
/etc/ssl/private/pegase.space.key <br />
/etc/ssl/certs/GandiStandardSSLCA2.pem<br />
<br />
==Configuration d'apache2==<br />
<br />
Avant toute chose, on s'assure que le module ssl est actif pour apache2.<br />
<br />
a2enmod ssl<br />
<br />
On se rend dans le répertoire <code>/etc/apache2/sites-enabled</code> et on modifie par exemple le fichier <code>000-default.conf</code>.<br />
<br />
<VirtualHost *:80> <br />
ServerName www.pegase.space <br />
Redirect / https://www.pegase.space <br />
</VirtualHost> <br />
<br />
<VirtualHost _default_:443> <br />
ServerName www.pegase.space <br />
DocumentRoot /var/www/html <br />
SSLEngine On <br />
SSLCertificateFile /etc/ssl/certs/pegase.space.crt <br />
SSLCertificateKeyFile /etc/ssl/private/pegase.space.key <br />
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem <br />
SSLVerifyClient None <br />
</VirtualHost> <br />
<br />
Le premier VirtualHost s'assure que l'utilisateur se connecte toujours en https (grâce au Redirect) et le second est justement utilisé pour l'accès en https au site.<br />
<br />
Enfin, on redémarre le service apache2 pour que les modifications soient prises en compte.<br />
<br />
service apache2 restart<br />
<br />
=Partie TP personnelle=<br />
<br />
==Authentification LDAP sur point d'accès==<br />
<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
Le serveur LDAP de l'école est situé sur la VLAN48, il a tout d'abord fallu vérifier que les machines de la VLAN50 (du bridge "StudentsInfo" des machines de TP) arrivent à accéder à celles du VLAN48. C'est bien le cas, nous arrivons bien à ping le nom de domaine ldap.polytech-lille.fr. Ainsi, nous pouvons maintenant mettre en place le serveur d'authentification sur le VLAN50. <br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48893TP sysres IMA5sc 2018/2019 G32018-12-17T16:52:13Z<p>Adurot : /* Partie TP personnelle */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP commune=<br />
<br />
==Création des machines virtuelles==<br />
Pour réaliser cette partie du TP nous avons besoin d'une machine virtuelle, nous allons la créer sur cordouan à l'aide de l'hyperviseur xen.<br />
<br />
Nous créons donc une image qui sera la base de notre machine :<br />
<br />
xen-create-image --hostname=pegase --ip=193.48.57.179 --netmask=255.255.255.240 --gateway=193.48.57.160 -size=10Gb --swap=128Mb --lvm=virtual<br />
<br />
Une fois que cette image est créée, on édite le fichier de configuration /etc/xen/pegase.cfg afin de lui attribuer une interface réseau virtuelle qui sera dans le bridge IMA5sc.<br />
<br />
vif = [ 'mac=00:16:3E:6F:37:08, bridge=IMA5sc' ]<br />
<br />
Une fois le fichier de configuration créé, nous pouvons lancer la machine virtuelle à l'aide de la commande suivante et de son option -c permettant d'afficher la console. <br />
<br />
xl create -c /etc/xen/pegase.cfg<br />
<br />
Le mot de passe root était affiché à l'écran à la fin de la création de la machine virtuelle, mais il est toujours possible d'aller le récupérer dans les logs dans le fichier /var/log/xen-tools/pegase.log<br />
<br />
==Ajout de partitions logiques==<br />
<br />
Notre machine virtuelle fonctionne et est connectée au réseau. Pour le moment un seul volume de 10Go accueil notre système. Pour les besoins du TP, nous allons sur l'hôte (cordouan) créer deux volumes virtuels, un pour le /home et un autre pour le /var. Nous allons créer ces volumes virtuels dans le groupe de volume "virtual". Nous ajoutons également trois volumes de 1Gb afin de faire un RAID 5 logiciel dans la machine virtuelle.<br />
<br />
lvcreate -L10G -n pegase-home virtual<br />
lvcreate -L10G -n pegase-var virtual<br />
lvcreate -L1G -n pegase-part1 virtual<br />
lvcreate -L1G -n pegase-part2 virtual<br />
lvcreate -L1G -n pegase-part3 virtual<br />
<br />
Nous ajoutons ensuite ces volumes à notre machine virtuelle en tant que disque physique xvdb1, xvdc1, etc...<br />
<br />
root = '/dev/xvda2 ro'<br />
disk = [<br />
'phy:/dev/virtual/pegase-disk,xvda2,w',<br />
'phy:/dev/virtual/pegase-swap,xvda1,w',<br />
'phy:/dev/virtual/Pegase-home,xvdb1,w',<br />
'phy:/dev/virtual/Pegase-var,xvdc1,w',<br />
'phy:/dev/virtual/pegase-part1,xvdd1,w',<br />
'phy:/dev/virtual/pegase-part2,xvde1,w',<br />
'phy:/dev/virtual/pegase-part3,xvdf1,w'<br />
]<br />
<br />
<br />
Nous pouvons maintenant redémarrer la machine et monter un système de fichier sur nos disques. On peut vérifier qu'ils existent d'ailleurs à l'aide de la commande fdisk -l.<br />
<br />
mkfs -t ext4 xvdb1<br />
mkfs -t ext4 xvdc1<br />
mkfs -t ext4 xvdd1<br />
mkfs -t ext4 xvde1<br />
mkfs -t ext4 xvdf1<br />
<br />
Nous ajoutons le montage du disque xvdb1 en tant que /home dans /etc/fstab<br />
<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
<br />
Pour le /var, il faut faire attention de ne pas perdre les données déjà existante, au risque d'avoir une machine inutilisable. Ainsi, on va venir monter temporairement le disque xvdc1 dans /mnt avant d'y déplacer l'intégralité du /var.<br />
<br />
mount /dev/xvdc1 /mnt<br />
mv /var/* /mnt<br />
<br />
Une fois ceci fait, nous pouvons le rajouter dans /etc/fstab<br />
<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
<br />
Maintenant, intéressons nous au RAID, nous avons utilisé l'utilitaire mdadm afin de réaliser le RAID5 en logiciel. Puis nous avons formaté la partition formée par le raid avant de la monter. Puis nous créons un fichier sur cette partition.<br />
<br />
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1<br />
mkfs -t ext4 /dev/md0<br />
mount /dev/md0 /mnt<br />
touch coucou.txt<br />
<br />
On ajoute le /dev/md0 au /etc/fstab afin qu'il soit monté au lancement de la machine :<br />
<br />
proc /proc proc defaults 0 0<br />
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0<br />
/dev/xvda1 none swap sw 0 0<br />
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
/dev/md0 /mnt/raid ext4 defaults 0 2<br />
<br />
<br />
On vérifie que tous nos disques ont été correctement montés :<br />
<br />
lsblk<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
xvda1 202:1 0 128M 0 disk [SWAP]<br />
xvda2 202:2 0 10G 0 disk /<br />
xvdb1 202:17 0 10G 0 disk /home<br />
xvdc1 202:33 0 10G 0 disk /var<br />
xvdd1 202:49 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
xvde1 202:65 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
xvdf1 202:81 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
<br />
Par défaut, notre raid n'a pas de fichier de configuration, nous devons en créer un. Sans fichier de configuration, le device RAID ne sera pas forcément créé dans /dev/md0 mais dans un md aléatoire, ainsi, notre fstab plantera (car nous n'aurons pas forcément le RAID sur /dev/md0). Donc nous devons avoir un fichier de configuration qui sera persistant et chargé par le noyau durant le boot. <br />
<br />
mdadm -Es >> /etc/mdadm.conf<br />
<br />
Cette configuration ressemble à <br />
<br />
cat /etc/mdadm.conf<br />
ARRAY /dev/md/0 metadata=1.2 UUID=b28705d4:15d1703c:4cf988d8:f0d77f12 name=pegase-ansible2:0<br />
<br />
<br />
A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre redondance, simulons une panne sur un des disques de notre RAID, ce qui pourrait arriver dans un cas réel.<br />
<br />
mdadm --set-faulty /dev/md0 /dev/xvdf1<br />
mdadm --remove /dev/xvdf1<br />
<br />
Nous constatons que notre fichier coucou.txt est toujours présent, malgré la "perte" de l'un des disques. Cependant, il faut tout de même se dire que nous avons fait un raid logiciel sur des partitions logiques, en pratique, si on perd vraiment le disque, nous perdrons quoi qu'il arrive tous les volumes logiques. Ainsi nous faisons ça pour l'aspect éducatif.<br />
<br />
==Chiffrement des disques RAID==<br />
<br />
Il peut être utile pour diverses raison de chiffrer les disques afin qu'un accès non autorisé par le propriétaire soit proscrit. Pour cela nous allons utiliser l'utilitaire cryptsetup avec le format LUKS afin de chiffrer notre disque en AES-256 avec un mot de passe.<br />
<br />
==Installation de bind et apache2==<br />
<br />
L'objectif va être d'héberger notre propre serveur DNS grâce au logiciel bind et de vérifier son fonctionnement en hébergeant un site web avec apache2. On commence donc par installer ces deux paquets :<br />
<br />
apt-get install apache2 bind9<br />
<br />
==Configuration de Bind==<br />
<br />
Pour continuer ce TP, nous avons acheté un nom de domaine (pegase.space) sur le registraire Gandi. La configuration de bind se trouve dans le répertoire <code>/etc/bind</code> dans lequel nous avons créé un fichier nommé <code>db.pegase.space</code> représentant notre zone et avec le contenu suivant :<br />
<br />
$TTL 604800 <br />
@ IN SOA ns.pegase.space. root.pegase.space ( <br />
42 ; Serial <br />
604800 ; Refresh <br />
86400 ; Retry <br />
2419200 ; Expire <br />
604800 ) ; Negative Cache TTL <br />
; <br />
IN NS ns.pegase.space. <br />
ns IN A 193.48.57.179 <br />
www IN A 193.48.57.179 <br />
@ IN A 193.48.57.179<br />
<br />
Nous avons également modifié le fichier de configuration <code>named.conf.local</code> en ajoutant la ligne allow-transfer à "none".<br />
<br />
zone "pegase.space" {<br />
type master; <br />
file "/etc/bind/db.pegase.space"; <br />
allow-transfer {"none";}; <br />
}; <br />
<br />
On peut maintenant redémarrer le service bind qui est maintenant opérationnel<br />
<br />
service bind9 restart<br />
<br />
Nous nous sommes ensuite rendu sur le site de Gandi sur lequel avons ajouté un Glue Record <code>ns.pegase.space</code> pointant vers l'IP de notre VM. Cet enregistrement permet la résolution du nom de notre serveur DNS qui ne peut se résoudre lui même.<br />
<br />
On peut ensuite ajouter le serveur maître utilisé pour résoudre les adresses de notre zone pegase.space à savoir <code>ns.pegase.space</code>.<br />
<br />
Après un certain temps, le temps que ces informations se propagent, nous étions en mesure d'obtenir l'IP de notre VM en effectuant par exemple un <br />
<br />
host pegase.space<br />
<br />
==Sécuriser les échanges DNS : DNSSEC==<br />
<br />
Dans cette partie, nous allons faire en sorte de certifier à un utilisateur que l'IP qu'il reçoit dans la réponse DNS est bien celle du domaine voulu. Pour ce faire, nous allons configurer bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.<br />
<br />
On commence naturellement par activer DNSSEC en ajoutant l'option <code>dnssec-enable yes;</code> dans le fichier <code>/etc/bind/named.conf.local</code>.<br />
<br />
On génère deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. <br />
<br />
dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE pegase.space<br />
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE pegase.space<br />
<br />
Nous avons ensuite renommé ces clefs pour plus de lisibilité en <code>pegase-zsk.key</code>, <code>pegase-zsk.private</code>, <code>pegase-ksk.key</code>, <code>pegase-ksk.private</code><br />
<br />
On ajoute ensuite via la directive <code>include</code> nos clefs au fichier de zone <code>db.pegase.space</code><br />
<br />
$include /etc/bind/pegase-ksk.key<br />
$include /etc/bind/pegase-zsk.key<br />
<br />
Nous pouvons maintenant signer la zone :<br />
<br />
dnssec-signzone -o pegase.space -k pegase-ksk db.pegase.space pegase-zsk<br />
<br />
Enfin, il ne faut pas oublier d'incrémenter la valeur du sérial dans <code>db.pegase.conf</code> et de changer le fichier de zone dans <code>named.conf.local</code>.<br />
<br />
zone "pegase.space" {<br />
type master; <br />
file "/etc/bind/db.pegase.space.signed"; <br />
allow-transfer {"none";}; <br />
}; <br />
<br />
Du coté de chez Gandi, il faut fournir les deux clefs publiques générés dans la rubrique DNSSEC en veillant à sélectionner le bon algorithme de chiffrement.<br />
<br />
Pour attester du bon fonctionnement de DNSSEC, on pourra utiliser le site http://dnsviz.net/.<br />
<br />
[[Fichier:pegase-dnssec.png]]<br />
<br />
==Cassage d'une clef WPA==<br />
<br />
L'exercice de cette sous-partie consiste à se procurer le mot de passe de la borne WiFi cracotte03. Il existe pour ce faire une suite logicielle nommée aircrack-ng spécialisée dans l'analyse des réseaux WiFi. Une fois doté d'un ordinateur équipé d'une carte WiFi, il faut commencer par noter le nom de l'interface sans-fil, ici wlp3s0.<br />
<br />
On peut maintenant lancer la commande suivante :<br />
<br />
airmon-ng start wlp3s0<br />
<br />
Celle-ci a pour effet de créer une nouvelle interface (wlp3s0mon) sans-fil mais en mode moniteur, mode permettant de capturer tous les paquets d'un réseau sans-fil.<br />
<br />
On repère ensuite le BSSID de cracotte03 ainsi que son channel.<br />
<br />
airodump-ng wlp3s0mon<br />
<br />
Nous sommes maintenant en mesure de récupérer les trames brutes correspondant au handshake.<br />
<br />
airodump-ng --bssid 04:DA:D2:9C:50:52 wlp3s0mon--channel 9 --write result<br />
<br />
Finalement, nous pouvons lancer le cassage de la clef :<br />
<br />
aircrack-ng result-01.cap -w dico<br />
<br />
Le fichier <code>dico</code> contient l'ensemble des possibilités des mots de passe à 8 chiffres (de 00000000 à 99999999) que va devoir essayer aircrack-ng.<br />
<br />
'''Résultat :''' 42429904<br />
<br />
[[Fichier:wpa-cracotte03.png]]<br />
<br />
=Sécuriser apache2 : SSL/TLS=<br />
<br />
==Création du certificat==<br />
<br />
Nous commençons par un générer deux fichiers grâce à la commande <br />
<br />
openssl req -nodes -newkey rsa:2048 -sha1 -keyout pegase.space.key -out pegase.csr<br />
<br />
* <code>pegase.csr</code> : il s'agit d'un fichier servant à faire une demande de certificat auprès d'une autorité de certification. Il contient quelques informations personnelles ainsi que la clef publique.<br />
* <code>pegase.space.key</code> : c'est la clef privée (à ne jamais distribuer) qui est complémentaire à celle présente dans le csr.<br />
<br />
On peut ensuite se rendre sur Gandi afin d'acheter le certificat. Le csr sera demandé pendant la procédure puis il faudra choisir une des trois méthodes proposées pour la vérification. Nous avons choisi celle par email car il s'agit à priori de la pus rapide.<br />
<br />
Il nous faut maintenant récupérer notre certificat depuis Gandi ainsi que le certificat intermédiaire. On déplace ensuite l'ensemble de ces clefs dans les répertoires appropriés.<br />
<br />
/etc/ssl/certs/pegase.space.crt <br />
/etc/ssl/private/pegase.space.key <br />
/etc/ssl/certs/GandiStandardSSLCA2.pem<br />
<br />
==Configuration d'apache2==<br />
<br />
Avant toute chose, on s'assure que le module ssl est actif pour apache2.<br />
<br />
a2enmod ssl<br />
<br />
On se rend dans le répertoire <code>/etc/apache2/sites-enabled</code> et on modifie par exemple le fichier <code>000-default.conf</code>.<br />
<br />
<VirtualHost *:80> <br />
ServerName www.pegase.space <br />
Redirect / https://www.pegase.space <br />
</VirtualHost> <br />
<br />
<VirtualHost _default_:443> <br />
ServerName www.pegase.space <br />
DocumentRoot /var/www/html <br />
SSLEngine On <br />
SSLCertificateFile /etc/ssl/certs/pegase.space.crt <br />
SSLCertificateKeyFile /etc/ssl/private/pegase.space.key <br />
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem <br />
SSLVerifyClient None <br />
</VirtualHost> <br />
<br />
Le premier VirtualHost s'assure que l'utilisateur se connecte toujours en https (grâce au Redirect) et le second est justement utilisé pour l'accès en https au site.<br />
<br />
Enfin, on redémarre le service apache2 pour que les modifications soient prises en compte.<br />
<br />
service apache2 restart<br />
<br />
=Partie TP personnelle=<br />
<br />
==Authentification LDAP sur point d'accès==<br />
<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
Le serveur LDAP de l'école est situé sur la VLAN48, il a tout d'abord fallu vérifier que les machines de la VLAN50 (du bridge "StudentsInfo" des machines de TP) arrivent à accéder à celles du VLAN48. C'est bien le cas, nous arrivons bien à ping le nom de domaine ldap.polytech-lille.fr.<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48826TP sysres IMA5sc 2018/2019 G32018-12-17T15:22:13Z<p>Adurot : /* Ajout de partitions logiques */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP commune=<br />
<br />
==Création des machines virtuelles==<br />
Pour réaliser cette partie du TP nous avons besoin d'une machine virtuelle, nous allons la créer sur cordouan à l'aide de l'hyperviseur xen.<br />
<br />
Nous créons donc une image qui sera la base de notre machine :<br />
<br />
xen-create-image --hostname=pegase --ip=193.48.57.179 --netmask=255.255.255.240 --gateway=193.48.57.160 -size=10Gb --swap=128Mb --lvm=virtual<br />
<br />
Une fois que cette image est créée, on édite le fichier de configuration /etc/xen/pegase.cfg afin de lui attribuer une interface réseau virtuelle qui sera dans le bridge IMA5sc.<br />
<br />
vif = [ 'mac=00:16:3E:6F:37:08, bridge=IMA5sc' ]<br />
<br />
Une fois le fichier de configuration créé, nous pouvons lancer la machine virtuelle à l'aide de la commande suivante et de son option -c permettant d'afficher la console. <br />
<br />
xl create -c /etc/xen/pegase.cfg<br />
<br />
Le mot de passe root était affiché à l'écran à la fin de la création de la machine virtuelle, mais il est toujours possible d'aller le récupérer dans les logs dans le fichier /var/log/xen-tools/pegase.log<br />
<br />
==Ajout de partitions logiques==<br />
<br />
Notre machine virtuelle fonctionne et est connectée au réseau. Pour le moment un seul volume de 10Go accueil notre système. Pour les besoins du TP, nous allons sur l'hôte (cordouan) créer deux volumes virtuels, un pour le /home et un autre pour le /var. Nous allons créer ces volumes virtuels dans le groupe de volume "virtual". Nous ajoutons également trois volumes de 1Gb afin de faire un RAID 5 logiciel dans la machine virtuelle.<br />
<br />
lvcreate -L10G -n pegase-home virtual<br />
lvcreate -L10G -n pegase-var virtual<br />
lvcreate -L1G -n pegase-part1 virtual<br />
lvcreate -L1G -n pegase-part2 virtual<br />
lvcreate -L1G -n pegase-part3 virtual<br />
<br />
Nous ajoutons ensuite ces volumes à notre machine virtuelle en tant que disque physique xvdb1, xvdc1, etc...<br />
<br />
root = '/dev/xvda2 ro'<br />
disk = [<br />
'phy:/dev/virtual/pegase-disk,xvda2,w',<br />
'phy:/dev/virtual/pegase-swap,xvda1,w',<br />
'phy:/dev/virtual/Pegase-home,xvdb1,w',<br />
'phy:/dev/virtual/Pegase-var,xvdc1,w',<br />
'phy:/dev/virtual/pegase-part1,xvdd1,w',<br />
'phy:/dev/virtual/pegase-part2,xvde1,w',<br />
'phy:/dev/virtual/pegase-part3,xvdf1,w'<br />
]<br />
<br />
<br />
Nous pouvons maintenant redémarrer la machine et monter un système de fichier sur nos disques. On peut vérifier qu'ils existent d'ailleurs à l'aide de la commande fdisk -l.<br />
<br />
mkfs -t ext4 xvdb1<br />
mkfs -t ext4 xvdc1<br />
mkfs -t ext4 xvdd1<br />
mkfs -t ext4 xvde1<br />
mkfs -t ext4 xvdf1<br />
<br />
Nous ajoutons le montage du disque xvdb1 en tant que /home dans /etc/fstab<br />
<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
<br />
Pour le /var, il faut faire attention de ne pas perdre les données déjà existante, au risque d'avoir une machine inutilisable. Ainsi, on va venir monter temporairement le disque xvdc1 dans /mnt avant d'y déplacer l'intégralité du /var.<br />
<br />
mount /dev/xvdc1 /mnt<br />
mv /var/* /mnt<br />
<br />
Une fois ceci fait, nous pouvons le rajouter dans /etc/fstab<br />
<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
<br />
Maintenant, intéressons nous au RAID, nous avons utilisé l'utilitaire mdadm afin de réaliser le RAID5 en logiciel. Puis nous avons formaté la partition formée par le raid avant de la monter. Puis nous créons un fichier sur cette partition.<br />
<br />
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1<br />
mkfs -t ext4 /dev/md0<br />
mount /dev/md0 /mnt<br />
touch coucou.txt<br />
<br />
On ajoute le /dev/md0 au /etc/fstab afin qu'il soit monté au lancement de la machine :<br />
<br />
proc /proc proc defaults 0 0<br />
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0<br />
/dev/xvda1 none swap sw 0 0<br />
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
/dev/md0 /mnt/raid ext4 defaults 0 2<br />
<br />
<br />
On vérifie que tous nos disques ont été correctement montés :<br />
<br />
lsblk<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
xvda1 202:1 0 128M 0 disk [SWAP]<br />
xvda2 202:2 0 10G 0 disk /<br />
xvdb1 202:17 0 10G 0 disk /home<br />
xvdc1 202:33 0 10G 0 disk /var<br />
xvdd1 202:49 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
xvde1 202:65 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
xvdf1 202:81 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
<br />
Par défaut, notre raid n'a pas de fichier de configuration, nous devons en créer un. Sans fichier de configuration, le device RAID ne sera pas forcément créé dans /dev/md0 mais dans un md aléatoire, ainsi, notre fstab plantera (car nous n'aurons pas forcément le RAID sur /dev/md0). Donc nous devons avoir un fichier de configuration qui sera persistant et chargé par le noyau durant le boot. <br />
<br />
mdadm -Es >> /etc/mdadm.conf<br />
<br />
Cette configuration ressemble à <br />
<br />
cat /etc/mdadm.conf<br />
ARRAY /dev/md/0 metadata=1.2 UUID=b28705d4:15d1703c:4cf988d8:f0d77f12 name=pegase-ansible2:0<br />
<br />
<br />
A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre redondance, simulons une panne sur un des disques de notre RAID, ce qui pourrait arriver dans un cas réel.<br />
<br />
mdadm --set-faulty /dev/md0 /dev/xvdf1<br />
mdadm --remove /dev/xvdf1<br />
<br />
Nous constatons que notre fichier coucou.txt est toujours présent, malgré la "perte" de l'un des disques. Cependant, il faut tout de même se dire que nous avons fait un raid logiciel sur des partitions logiques, en pratique, si on perd vraiment le disque, nous perdrons quoi qu'il arrive tous les volumes logiques. Ainsi nous faisons ça pour l'aspect éducatif.<br />
<br />
==Chiffrement des disques RAID==<br />
<br />
Il peut être utile pour diverses raison de chiffrer les disques afin qu'un accès non autorisé par le propriétaire soit proscrit. Pour cela nous allons utiliser l'utilitaire cryptsetup avec le format LUKS afin de chiffrer notre disque en AES-256 avec un mot de passe.<br />
<br />
==Installation de bind et apache2==<br />
<br />
L'objectif va être d'héberger notre propre serveur DNS grâce au logiciel bind et de vérifier son fonctionnement en hébergeant un site web avec apache2. On commence donc par installer ces deux paquets :<br />
<br />
apt-get install apache2 bind9<br />
<br />
==Configuration de Bind==<br />
<br />
Pour continuer ce TP, nous avons acheté un nom de domaine (pegase.space) sur le registraire Gandi. La configuration de bind se trouve dans le répertoire <code>/etc/bind</code> dans lequel nous avons créé un fichier nommé <code>db.pegase.space</code> représentant notre zone et avec le contenu suivant :<br />
<br />
$TTL 604800 <br />
@ IN SOA ns.pegase.space. root.pegase.space ( <br />
42 ; Serial <br />
604800 ; Refresh <br />
86400 ; Retry <br />
2419200 ; Expire <br />
604800 ) ; Negative Cache TTL <br />
; <br />
IN NS ns.pegase.space. <br />
ns IN A 193.48.57.179 <br />
www IN A 193.48.57.179 <br />
@ IN A 193.48.57.179<br />
<br />
Nous avons également modifié le fichier de configuration <code>named.conf.local</code> en ajoutant la ligne allow-transfer à "none".<br />
<br />
zone "pegase.space" {<br />
type master; <br />
file "/etc/bind/db.pegase.space"; <br />
allow-transfer {"none";}; <br />
}; <br />
<br />
On peut maintenant redémarrer le service bind qui est maintenant opérationnel<br />
<br />
service bind9 restart<br />
<br />
Nous nous sommes ensuite rendu sur le site de Gandi sur lequel avons ajouté un Glue Record <code>ns.pegase.space</code> pointant vers l'IP de notre VM. Cet enregistrement permet la résolution du nom de notre serveur DNS qui ne peut se résoudre lui même.<br />
<br />
On peut ensuite ajouter le serveur maître utilisé pour résoudre les adresses de notre zone pegase.space à savoir <code>ns.pegase.space</code>.<br />
<br />
Après un certain temps, le temps que ces informations se propagent, nous étions en mesure d'obtenir l'IP de notre VM en effectuant par exemple un <br />
<br />
host pegase.space<br />
<br />
==Sécuriser les échanges DNS : DNSSEC==<br />
<br />
Dans cette partie, nous allons faire en sorte de certifier à un utilisateur que l'IP qu'il reçoit dans la réponse DNS est bien celle du domaine voulu. Pour ce faire, nous allons configurer bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.<br />
<br />
On commence naturellement par activer DNSSEC en ajoutant l'option <code>dnssec-enable yes;</code> dans le fichier <code>/etc/bind/named.conf.local</code>.<br />
<br />
On génère deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. <br />
<br />
dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE pegase.space<br />
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE pegase.space<br />
<br />
Nous avons ensuite renommé ces clefs pour plus de lisibilité en <code>pegase-zsk.key</code>, <code>pegase-zsk.private</code>, <code>pegase-ksk.key</code>, <code>pegase-ksk.private</code><br />
<br />
On ajoute ensuite via la directive <code>include</code> nos clefs au fichier de zone <code>db.pegase.space</code><br />
<br />
$include /etc/bind/pegase-ksk.key<br />
$include /etc/bind/pegase-zsk.key<br />
<br />
Nous pouvons maintenant signer la zone :<br />
<br />
dnssec-signzone -o pegase.space -k pegase-ksk db.pegase.space pegase-zsk<br />
<br />
Enfin, il ne faut pas oublier d'incrémenter la valeur du sérial dans <code>db.pegase.conf</code> et de changer le fichier de zone dans <code>named.conf.local</code>.<br />
<br />
zone "pegase.space" {<br />
type master; <br />
file "/etc/bind/db.pegase.space.signed"; <br />
allow-transfer {"none";}; <br />
}; <br />
<br />
Du coté de chez Gandi, il faut fournir les deux clefs publiques générés dans la rubrique DNSSEC en veillant à sélectionner le bon algorithme de chiffrement.<br />
<br />
Pour attester du bon fonctionnement de DNSSEC, on pourra utiliser le site http://dnsviz.net/.<br />
<br />
[[Fichier:pegase-dnssec.png]]<br />
<br />
==Cassage d'une clef WPA==<br />
<br />
L'exercice de cette sous-partie consiste à se procurer le mot de passe de la borne WiFi cracotte03. Il existe pour ce faire une suite logicielle nommée aircrack-ng spécialisée dans l'analyse des réseaux WiFi. Une fois doté d'un ordinateur équipé d'une carte WiFi, il faut commencer par noter le nom de l'interface sans-fil, ici wlp3s0.<br />
<br />
On peut maintenant lancer la commande suivante :<br />
<br />
airmon-ng start wlp3s0<br />
<br />
Celle-ci a pour effet de créer une nouvelle interface (wlp3s0mon) sans-fil mais en mode moniteur, mode permettant de capturer tous les paquets d'un réseau sans-fil.<br />
<br />
On repère ensuite le BSSID de cracotte03 ainsi que son channel.<br />
<br />
airodump-ng wlp3s0mon<br />
<br />
Nous sommes maintenant en mesure de récupérer les trames brutes correspondant au handshake.<br />
<br />
airodump-ng --bssid 04:DA:D2:9C:50:52 wlp3s0mon--channel 9 --write result<br />
<br />
Finalement, nous pouvons lancer le cassage de la clef :<br />
<br />
aircrack-ng result-01.cap -w dico<br />
<br />
Le fichier <code>dico</code> contient l'ensemble des possibilités des mots de passe à 8 chiffres (de 00000000 à 99999999) que va devoir essayer aircrack-ng.<br />
<br />
'''Résultat :''' 42429904<br />
<br />
[[Fichier:wpa-cracotte03.png]]<br />
<br />
=Sécuriser apache2 : SSL/TLS=<br />
<br />
==Création du certificat==<br />
<br />
Nous commençons par un générer deux fichiers grâce à la commande <br />
<br />
openssl req -nodes -newkey rsa:2048 -sha1 -keyout pegase.space.key -out pegase.csr<br />
<br />
* <code>pegase.csr</code> : il s'agit d'un fichier servant à faire une demande de certificat auprès d'une autorité de certification. Il contient quelques informations personnelles ainsi que la clef publique.<br />
* <code>pegase.space.key</code> : c'est la clef privée (à ne jamais distribuer) qui est complémentaire à celle présente dans le csr.<br />
<br />
On peut ensuite se rendre sur Gandi afin d'acheter le certificat. Le csr sera demandé pendant la procédure puis il faudra choisir une des trois méthodes proposées pour la vérification. Nous avons choisi celle par email car il s'agit à priori de la pus rapide.<br />
<br />
Il nous faut maintenant récupérer notre certificat depuis Gandi ainsi que le certificat intermédiaire. On déplace ensuite l'ensemble de ces clefs dans les répertoires appropriés.<br />
<br />
/etc/ssl/certs/pegase.space.crt <br />
/etc/ssl/private/pegase.space.key <br />
/etc/ssl/certs/GandiStandardSSLCA2.pem<br />
<br />
==Configuration d'apache2==<br />
<br />
Avant toute chose, on s'assure que le module ssl est actif pour apache2.<br />
<br />
a2enmod ssl<br />
<br />
On se rend dans le répertoire <code>/etc/apache2/sites-enabled</code> et on modifie par exemple le fichier <code>000-default.conf</code>.<br />
<br />
<VirtualHost *:80> <br />
ServerName www.pegase.space <br />
Redirect / https://www.pegase.space <br />
</VirtualHost> <br />
<br />
<VirtualHost _default_:443> <br />
ServerName www.pegase.space <br />
DocumentRoot /var/www/html <br />
SSLEngine On <br />
SSLCertificateFile /etc/ssl/certs/pegase.space.crt <br />
SSLCertificateKeyFile /etc/ssl/private/pegase.space.key <br />
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem <br />
SSLVerifyClient None <br />
</VirtualHost> <br />
<br />
Le premier VirtualHost s'assure que l'utilisateur se connecte toujours en https (grâce au Redirect) et le second est justement utilisé pour l'accès en https au site.<br />
<br />
Enfin, on redémarre le service apache2 pour que les modifications soient prises en compte.<br />
<br />
service apache2 restart<br />
<br />
=Partie TP personnelle=<br />
<br />
==Authentification LDAP sur point d'accès==<br />
<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48597TP sysres IMA5sc 2018/2019 G32018-12-11T14:50:21Z<p>Adurot : /* Ajout de partitions logiques */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
<br />
==Création des machines virtuelles==<br />
Pour réaliser cette partie du TP nous avons besoin d'une machine virtuelle, nous allons la créer sur cordouan à l'aide de l'hyperviseur xen.<br />
<br />
Nous créons donc une image qui sera la base de notre machine :<br />
<br />
xen-create-image --hostname=pegase --ip=193.48.57.179 --netmask=255.255.255.240 --gateway=193.48.57.160 -size=10Gb --swap=128Mb --lvm=virtual<br />
<br />
Une fois que cette image est crée, on édite le fichier de configuration /etc/xen/pegase.cfg afin de lui attribuer une interface réseau virtuelle qui sera dans le bridge IMA5sc.<br />
<br />
vif = [ 'mac=00:16:3E:6F:37:08, bridge=IMA5sc' ]<br />
<br />
Une fois le fichier de configuration crée nous pouvons lancer la machine virtuelle à l'aide de la commande <br />
<br />
xl create -c /etc/xen/pegase.cfg<br />
<br />
Le mot de passe root était affiché à l'écran à la fin de la création de la machine virtuelle, mais il est toujours possible d'aller le récupérer dans les logs dans /var/log/xen-tools/pegase.log<br />
<br />
==Ajout de partitions logiques==<br />
<br />
Notre machine virtuelle fonctionne et est connectée au réseau, il faut dorénavant lui apporter du stockage, nous allons sur l'hôte (cordouan) créer deux volumes virtuels, un pour le /home et un autre pour le /var. Nous allons créer ces volumes virtuels dans le groupe de volume "virtual". Nous ajoutons également trois volumes de 1Gb afin de faire un RAID 5 logiciel dans la machine virtuelle.<br />
<br />
lvcreate -L10G -n pegase-home virtual<br />
lvcreate -L10G -n pegase-var virtual<br />
lvcreate -L1G -n pegase-part1 virtual<br />
lvcreate -L1G -n pegase-part2 virtual<br />
lvcreate -L1G -n pegase-part3 virtual<br />
<br />
Nous ajoutons ensuite ces volumes à notre machine virtuelle en tant que disque physique xvdb1, xvdc1, etc...<br />
<br />
root = '/dev/xvda2 ro'<br />
disk = [<br />
'phy:/dev/virtual/pegase-disk,xvda2,w',<br />
'phy:/dev/virtual/pegase-swap,xvda1,w',<br />
'phy:/dev/virtual/Pegase-home,xvdb1,w',<br />
'phy:/dev/virtual/Pegase-var,xvdc1,w',<br />
'phy:/dev/virtual/pegase-part1,xvdd1,w',<br />
'phy:/dev/virtual/pegase-part2,xvde1,w',<br />
'phy:/dev/virtual/pegase-part3,xvdf1,w'<br />
]<br />
<br />
<br />
Nous pouvons maintenant redémarrer la machine et monter un système de fichier de nos disques. On peut vérifier qu'ils existent d'ailleurs à l'aide de la commande fdisk -l<br />
<br />
mkfs -t ext4 xvdb1<br />
mkfs -t ext4 xvdc1<br />
mkfs -t ext4 xvdd1<br />
mkfs -t ext4 xvde1<br />
mkfs -t ext4 xvdf1<br />
<br />
Nous ajoutons le montage du disque xvdb1 en tant que /home dans /etc/fstab<br />
<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
<br />
Pour le /var, il faut faire attention de ne pas perdre les données déja existante, au risque d'avoir une machine inutilisable. Ainsi, on va venir monter temporairement le disque xvdc1 dans /mnt avant d'y déplacer l'intégralité du /var.<br />
<br />
mount /dev/xvdc1 /mnt<br />
mv /var/* /mnt<br />
<br />
Une fois ceci fait, nous pouvons le rajouter dans /etc/fstab<br />
<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
<br />
Maintenant, intéressons nous au RAID, nous allons utiliser l'utilitaire mdadm afin de réaliser le RAID5 en logiciel. Puis nous allons formater la partition formée par le raid et la monter. Puis nous créons un fichier sur cette partition.<br />
<br />
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1<br />
mkfs -t ext4 /dev/md0<br />
mount /dev/md0 /mnt<br />
touch coucou.txt<br />
<br />
On ajoute le /dev/md0 au /etc/fstab afin qu'il soit monté au lancement de la machine :<br />
<br />
proc /proc proc defaults 0 0<br />
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0<br />
/dev/xvda1 none swap sw 0 0<br />
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
/dev/md0 /mnt/raid ext4 defaults 0 2<br />
<br />
<br />
On vérifie que tous nos disques ont été correctement montés :<br />
<br />
lsblk<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
xvda1 202:1 0 128M 0 disk [SWAP]<br />
xvda2 202:2 0 10G 0 disk /<br />
xvdb1 202:17 0 10G 0 disk /home<br />
xvdc1 202:33 0 10G 0 disk /var<br />
xvdd1 202:49 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
xvde1 202:65 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
xvdf1 202:81 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
<br />
Par défaut, notre raid n'a pas de fichier de configuration, nous devons en créer un. Sans fichier de configuration, le device RAID ne sera pas forcément créé dans /dev/md0 mais dans un md aléatoire, ainsi, notre fstab plantera (car nous n'aurons pas forcément le RAID sur /dev/md0). Donc nous devons avoir un fichier de configuration qui sera persistant et chargé par le noyau durant le boot. <br />
<br />
mdadm --detail --scan --verbose >> /etc/mdadm.conf<br />
<br />
Cette configuration ressemble à <br />
<br />
cat /etc/mdadm.conf<br />
ARRAY /dev/md0 level=raid5 num-devices=3 metadata=1.2 name=pegase-ansible2:0 UUID=82f804f4:49086028:d00d6af6:97fffa09<br />
devices=/dev/xvdd1,/dev/xvde1,/dev/xvdf1<br />
<br />
<br />
A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre redondance, simulons une panne sur un des disques de notre RAID, ce qui pourrait arriver dans un cas réel.<br />
<br />
mdadm --set-faulty /dev/md0 /dev/xvdf1<br />
mdadm --remove /dev/xvdf1<br />
<br />
Nous constatons que notre fichier coucou.txt est toujours présent, malgré la "perte" de l'un des disques. Cependant, il faut tout de même se dire que nous avons fait un raid logiciel sur des partitions logiques, en pratique, si on perd vraiment le disque, nous perdrons quoi qu'il arrive tous les volumes logiques. Ainsi nous faisons ça pour l'aspect éducatif.<br />
<br />
==Chiffrement des disques RAID==<br />
<br />
Il peut être utile pour diverses raison de chiffrer les disques afin qu'un accès non autorisé par le propriétaire soit proscrit. Pour cela nous allons utiliser l'utilitaire cryptsetup avec le format LUKS afin de chiffrer notre disque en AES-256 avec un mot de passe.<br />
<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48594TP sysres IMA5sc 2018/2019 G32018-12-11T14:41:56Z<p>Adurot : /* Ajout de partitions logiques */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
<br />
==Création des machines virtuelles==<br />
Pour réaliser cette partie du TP nous avons besoin d'une machine virtuelle, nous allons la créer sur cordouan à l'aide de l'hyperviseur xen.<br />
<br />
Nous créons donc une image qui sera la base de notre machine :<br />
<br />
xen-create-image --hostname=pegase --ip=193.48.57.179 --netmask=255.255.255.240 --gateway=193.48.57.160 -size=10Gb --swap=128Mb --lvm=virtual<br />
<br />
Une fois que cette image est crée, on édite le fichier de configuration /etc/xen/pegase.cfg afin de lui attribuer une interface réseau virtuelle qui sera dans le bridge IMA5sc.<br />
<br />
vif = [ 'mac=00:16:3E:6F:37:08, bridge=IMA5sc' ]<br />
<br />
Une fois le fichier de configuration crée nous pouvons lancer la machine virtuelle à l'aide de la commande <br />
<br />
xl create -c /etc/xen/pegase.cfg<br />
<br />
Le mot de passe root était affiché à l'écran à la fin de la création de la machine virtuelle, mais il est toujours possible d'aller le récupérer dans les logs dans /var/log/xen-tools/pegase.log<br />
<br />
==Ajout de partitions logiques==<br />
<br />
Notre machine virtuelle fonctionne et est connectée au réseau, il faut dorénavant lui apporter du stockage, nous allons sur l'hôte (cordouan) créer deux volumes virtuels, un pour le /home et un autre pour le /var. Nous allons créer ces volumes virtuels dans le groupe de volume "virtual". Nous ajoutons également trois volumes de 1Gb afin de faire un RAID 5 logiciel dans la machine virtuelle.<br />
<br />
lvcreate -L10G -n pegase-home virtual<br />
lvcreate -L10G -n pegase-var virtual<br />
lvcreate -L1G -n pegase-part1 virtual<br />
lvcreate -L1G -n pegase-part2 virtual<br />
lvcreate -L1G -n pegase-part3 virtual<br />
<br />
Nous ajoutons ensuite ces volumes à notre machine virtuelle en tant que disque physique xvdb1, xvdc1, etc...<br />
<br />
root = '/dev/xvda2 ro'<br />
disk = [<br />
'phy:/dev/virtual/pegase-disk,xvda2,w',<br />
'phy:/dev/virtual/pegase-swap,xvda1,w',<br />
'phy:/dev/virtual/Pegase-home,xvdb1,w',<br />
'phy:/dev/virtual/Pegase-var,xvdc1,w',<br />
'phy:/dev/virtual/pegase-part1,xvdd1,w',<br />
'phy:/dev/virtual/pegase-part2,xvde1,w',<br />
'phy:/dev/virtual/pegase-part3,xvdf1,w'<br />
]<br />
<br />
<br />
Nous pouvons maintenant redémarrer la machine et monter un système de fichier de nos disques. On peut vérifier qu'ils existent d'ailleurs à l'aide de la commande fdisk -l<br />
<br />
mkfs -t ext4 xvdb1<br />
mkfs -t ext4 xvdc1<br />
mkfs -t ext4 xvdd1<br />
mkfs -t ext4 xvde1<br />
mkfs -t ext4 xvdf1<br />
<br />
Nous ajoutons le montage du disque xvdb1 en tant que /home dans /etc/fstab<br />
<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
<br />
Pour le /var, il faut faire attention de ne pas perdre les données déja existante, au risque d'avoir une machine inutilisable. Ainsi, on va venir monter temporairement le disque xvdc1 dans /mnt avant d'y déplacer l'intégralité du /var.<br />
<br />
mount /dev/xvdc1 /mnt<br />
mv /var/* /mnt<br />
<br />
Une fois ceci fait, nous pouvons le rajouter dans /etc/fstab<br />
<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
<br />
Maintenant, intéressons nous au RAID, nous allons utiliser l'utilitaire mdadm afin de réaliser le RAID5 en logiciel. Puis nous allons formater la partition formée par le raid et la monter. Puis nous créons un fichier sur cette partition.<br />
<br />
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1<br />
mkfs -t ext4 /dev/md0<br />
mount /dev/md0 /mnt<br />
touch coucou.txt<br />
<br />
On ajoute le /dev/md0 au /etc/fstab afin qu'il soit monté au lancement de la machine :<br />
<br />
# <file system> <mount point> <type> <options> <dump> <pass><br />
proc /proc proc defaults 0 0<br />
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0<br />
/dev/xvda1 none swap sw 0 0<br />
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
/dev/md0 /mnt/raid ext4 defaults 0 2<br />
<br />
<br />
On vérifie que tous nos disques ont été correctement montés :<br />
<br />
lsblk<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
xvda1 202:1 0 128M 0 disk [SWAP]<br />
xvda2 202:2 0 10G 0 disk /<br />
xvdb1 202:17 0 10G 0 disk /home<br />
xvdc1 202:33 0 10G 0 disk /var<br />
xvdd1 202:49 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
xvde1 202:65 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
xvdf1 202:81 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
<br />
A partir de là, nous pouvons simuler une panne sur un des disques de notre RAID, ce qui pourrait arriver dans un cas réel<br />
<br />
mdadm --set-faulty /dev/md0 /dev/xvdf1<br />
mdadm --remove /dev/xvdf1<br />
<br />
Nous constatons que notre fichier coucou.txt est toujours présent, malgré la "perte" de l'un des disques. Cependant, il faut tout de même se dire que nous avons fait un raid logiciel sur des partitions logiques, en pratique, si on perd vraiment le disque, nous perdrons quoi qu'il arrive tous les volumes logiques. Ainsi nous faisons ça pour l'aspect éducatif.<br />
<br />
==Chiffrement des disques RAID==<br />
<br />
Il peut être utile pour diverses raison de chiffrer les disques afin qu'un accès non autorisé par le propriétaire soit proscrit. Pour cela nous allons utiliser l'utilitaire cryptsetup avec le format LUKS afin de chiffrer notre disque en AES-256 avec un mot de passe.<br />
<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48592TP sysres IMA5sc 2018/2019 G32018-12-11T14:38:23Z<p>Adurot : /* Ajout de partitions logiques */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
<br />
==Création des machines virtuelles==<br />
Pour réaliser cette partie du TP nous avons besoin d'une machine virtuelle, nous allons la créer sur cordouan à l'aide de l'hyperviseur xen.<br />
<br />
Nous créons donc une image qui sera la base de notre machine :<br />
<br />
xen-create-image --hostname=pegase --ip=193.48.57.179 --netmask=255.255.255.240 --gateway=193.48.57.160 -size=10Gb --swap=128Mb --lvm=virtual<br />
<br />
Une fois que cette image est crée, on édite le fichier de configuration /etc/xen/pegase.cfg afin de lui attribuer une interface réseau virtuelle qui sera dans le bridge IMA5sc.<br />
<br />
vif = [ 'mac=00:16:3E:6F:37:08, bridge=IMA5sc' ]<br />
<br />
Une fois le fichier de configuration crée nous pouvons lancer la machine virtuelle à l'aide de la commande <br />
<br />
xl create -c /etc/xen/pegase.cfg<br />
<br />
Le mot de passe root était affiché à l'écran à la fin de la création de la machine virtuelle, mais il est toujours possible d'aller le récupérer dans les logs dans /var/log/xen-tools/pegase.log<br />
<br />
==Ajout de partitions logiques==<br />
<br />
Notre machine virtuelle fonctionne et est connectée au réseau, il faut dorénavant lui apporter du stockage, nous allons sur l'hôte (cordouan) créer deux volumes virtuels, un pour le /home et un autre pour le /var. Nous allons créer ces volumes virtuels dans le groupe de volume "virtual". Nous ajoutons également trois volumes de 1Gb afin de faire un RAID 5 logiciel dans la machine virtuelle.<br />
<br />
lvcreate -L10G -n pegase-home virtual<br />
lvcreate -L10G -n pegase-var virtual<br />
lvcreate -L1G -n pegase-part1 virtual<br />
lvcreate -L1G -n pegase-part2 virtual<br />
lvcreate -L1G -n pegase-part3 virtual<br />
<br />
Nous ajoutons ensuite ces volumes à notre machine virtuelle en tant que disque physique xvdb1, xvdc1, etc...<br />
<br />
root = '/dev/xvda2 ro'<br />
disk = [<br />
'phy:/dev/virtual/pegase-disk,xvda2,w',<br />
'phy:/dev/virtual/pegase-swap,xvda1,w',<br />
'phy:/dev/virtual/Pegase-home,xvdb1,w',<br />
'phy:/dev/virtual/Pegase-var,xvdc1,w',<br />
'phy:/dev/virtual/pegase-part1,xvdd1,w',<br />
'phy:/dev/virtual/pegase-part2,xvde1,w',<br />
'phy:/dev/virtual/pegase-part3,xvdf1,w'<br />
]<br />
<br />
<br />
Nous pouvons maintenant redémarrer la machine et monter un système de fichier de nos disques. On peut vérifier qu'ils existent d'ailleurs à l'aide de la commande fdisk -l<br />
<br />
mkfs -t ext4 xvdb1<br />
mkfs -t ext4 xvdc1<br />
mkfs -t ext4 xvdd1<br />
mkfs -t ext4 xvde1<br />
mkfs -t ext4 xvdf1<br />
<br />
Nous ajoutons le montage du disque xvdb1 en tant que /home dans /etc/fstab<br />
<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
<br />
Pour le /var, il faut faire attention de ne pas perdre les données déja existante, au risque d'avoir une machine inutilisable. Ainsi, on va venir monter temporairement le disque xvdc1 dans /mnt avant d'y déplacer l'intégralité du /var.<br />
<br />
mount /dev/xvdc1 /mnt<br />
mv /var/* /mnt<br />
<br />
Une fois ceci fait, nous pouvons le rajouter dans /etc/fstab<br />
<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
<br />
Maintenant, intéressons nous au RAID, nous allons utiliser l'utilitaire mdadm afin de réaliser le RAID5 en logiciel. Puis nous allons formater la partition formée par le raid et la monter. Puis nous créons un fichier sur cette partition.<br />
<br />
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1<br />
mkfs -t ext4 /dev/md0<br />
mount /dev/md0 /mnt<br />
touch coucou.txt<br />
<br />
On vérifie que tous nos disques ont été correctement montés :<br />
<br />
lsblk<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
xvda1 202:1 0 128M 0 disk [SWAP]<br />
xvda2 202:2 0 10G 0 disk /<br />
xvdb1 202:17 0 10G 0 disk /home<br />
xvdc1 202:33 0 10G 0 disk /var<br />
xvdd1 202:49 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
xvde1 202:65 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
xvdf1 202:81 0 1G 0 disk <br />
`-md0 9:127 0 2G 0 raid5 /mnt<br />
<br />
A partir de là, nous pouvons simuler une panne sur un des disques de notre RAID, ce qui pourrait arriver dans un cas réel<br />
<br />
mdadm --set-faulty /dev/md0 /dev/xvdf1<br />
mdadm --remove /dev/xvdf1<br />
<br />
Nous constatons que notre fichier coucou.txt est toujours présent, malgré la "perte" de l'un des disques. Cependant, il faut tout de même se dire que nous avons fait un raid logiciel sur des partitions logiques, en pratique, si on perd vraiment le disque, nous perdrons quoi qu'il arrive tous les volumes logiques. Ainsi nous faisons ça pour l'aspect éducatif.<br />
<br />
==Chiffrement des disques RAID==<br />
<br />
Il peut être utile pour diverses raison de chiffrer les disques afin qu'un accès non autorisé par le propriétaire soit proscrit. Pour cela nous allons utiliser l'utilitaire cryptsetup avec le format LUKS afin de chiffrer notre disque en AES-256 avec un mot de passe.<br />
<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48589TP sysres IMA5sc 2018/2019 G32018-12-11T14:29:34Z<p>Adurot : /* Ajout de partitions logiques */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
<br />
==Création des machines virtuelles==<br />
Pour réaliser cette partie du TP nous avons besoin d'une machine virtuelle, nous allons la créer sur cordouan à l'aide de l'hyperviseur xen.<br />
<br />
Nous créons donc une image qui sera la base de notre machine :<br />
<br />
xen-create-image --hostname=pegase --ip=193.48.57.179 --netmask=255.255.255.240 --gateway=193.48.57.160 -size=10Gb --swap=128Mb --lvm=virtual<br />
<br />
Une fois que cette image est crée, on édite le fichier de configuration /etc/xen/pegase.cfg afin de lui attribuer une interface réseau virtuelle qui sera dans le bridge IMA5sc.<br />
<br />
vif = [ 'mac=00:16:3E:6F:37:08, bridge=IMA5sc' ]<br />
<br />
Une fois le fichier de configuration crée nous pouvons lancer la machine virtuelle à l'aide de la commande <br />
<br />
xl create -c /etc/xen/pegase.cfg<br />
<br />
Le mot de passe root était affiché à l'écran à la fin de la création de la machine virtuelle, mais il est toujours possible d'aller le récupérer dans les logs dans /var/log/xen-tools/pegase.log<br />
<br />
==Ajout de partitions logiques==<br />
<br />
Notre machine virtuelle fonctionne et est connectée au réseau, il faut dorénavant lui apporter du stockage, nous allons sur l'hôte (cordouan) créer deux volumes virtuels, un pour le /home et un autre pour le /var. Nous allons créer ces volumes virtuels dans le groupe de volume "virtual". Nous ajoutons également trois volumes de 1Gb afin de faire un RAID 5 logiciel dans la machine virtuelle.<br />
<br />
lvcreate -L10G -n pegase-home virtual<br />
lvcreate -L10G -n pegase-var virtual<br />
lvcreate -L1G -n pegase-part1 virtual<br />
lvcreate -L1G -n pegase-part2 virtual<br />
lvcreate -L1G -n pegase-part3 virtual<br />
<br />
Nous ajoutons ensuite ces volumes à notre machine virtuelle en tant que disque physique xvdb1, xvdc1, etc...<br />
<br />
root = '/dev/xvda2 ro'<br />
disk = [<br />
'phy:/dev/virtual/pegase-disk,xvda2,w',<br />
'phy:/dev/virtual/pegase-swap,xvda1,w',<br />
'phy:/dev/virtual/Pegase-home,xvdb1,w',<br />
'phy:/dev/virtual/Pegase-var,xvdc1,w',<br />
'phy:/dev/virtual/pegase-part1,xvdd1,w',<br />
'phy:/dev/virtual/pegase-part2,xvde1,w',<br />
'phy:/dev/virtual/pegase-part3,xvdf1,w'<br />
]<br />
<br />
<br />
Nous pouvons maintenant redémarrer la machine et monter un système de fichier de nos disques. On peut vérifier qu'ils existent d'ailleurs à l'aide de la commande fdisk -l<br />
<br />
mkfs -t ext4 xvdb1<br />
mkfs -t ext4 xvdc1<br />
mkfs -t ext4 xvdd1<br />
mkfs -t ext4 xvde1<br />
mkfs -t ext4 xvdf1<br />
<br />
Nous ajoutons le montage du disque xvdb1 en tant que /home dans /etc/fstab<br />
<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
<br />
Pour le /var, il faut faire attention de ne pas perdre les données déja existante, au risque d'avoir une machine inutilisable. Ainsi, on va venir monter temporairement le disque xvdc1 dans /mnt avant d'y déplacer l'intégralité du /var.<br />
<br />
mount /dev/xvdc1 /mnt<br />
mv /var/* /mnt<br />
<br />
Une fois ceci fait, nous pouvons le rajouter dans /etc/fstab<br />
<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
<br />
Maintenant, intéressons nous au RAID, nous allons utiliser l'utilitaire mdadm afin de réaliser le RAID5 en logiciel. Puis nous allons formater la partition formée par le raid et la monter. Puis nous créons un fichier sur cette partition.<br />
<br />
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1<br />
mkfs -t ext4 /dev/md0<br />
mount /dev/md0 /mnt<br />
touch coucou.txt<br />
<br />
On vérifie que tous nos disques ont été correctement montés :<br />
<br />
lsblk<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
xvda1 202:1 0 128M 0 disk [SWAP]<br />
xvda2 202:2 0 10G 0 disk /<br />
xvdb1 202:17 0 10G 0 disk /home<br />
xvdc1 202:33 0 10G 0 disk /var<br />
xvdd1 202:49 0 1G 0 disk <br />
`-md127 9:127 0 2G 0 raid5 /mnt<br />
xvde1 202:65 0 1G 0 disk <br />
`-md127 9:127 0 2G 0 raid5 /mnt<br />
xvdf1 202:81 0 1G 0 disk <br />
`-md127 9:127 0 2G 0 raid5 /mnt<br />
<br />
A partir de là, nous pouvons simuler une panne sur un des disques de notre RAID, ce qui pourrait arriver dans un cas réel<br />
<br />
mdadm --set-faulty /dev/md0 /dev/xvdf1<br />
mdadm --remove /dev/xvdf1<br />
<br />
Nous constatons que notre fichier coucou.txt est toujours présent, malgré la "perte" de l'un des disques. Cependant, il faut tout de même se dire que nous avons fait un raid logiciel sur des partitions logiques, en pratique, si on perd vraiment le disque, nous perdrons quoi qu'il arrive tous les volumes logiques. Ainsi nous faisons ça pour l'aspect éducatif.<br />
<br />
==Chiffrement des disques RAID==<br />
<br />
Il peut être utile pour diverses raison de chiffrer les disques afin qu'un accès non autorisé par le propriétaire soit proscrit. Pour cela nous allons utiliser l'utilitaire cryptsetup avec le format LUKS afin de chiffrer notre disque en AES-256 avec un mot de passe.<br />
<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48586TP sysres IMA5sc 2018/2019 G32018-12-11T11:11:21Z<p>Adurot : /* Ajout de partitions sur la machine virtuelle */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
<br />
==Création des machines virtuelles==<br />
Pour réaliser cette partie du TP nous avons besoin d'une machine virtuelle, nous allons la créer sur cordouan à l'aide de l'hyperviseur xen.<br />
<br />
Nous créons donc une image qui sera la base de notre machine :<br />
<br />
xen-create-image --hostname=pegase --ip=193.48.57.179 --netmask=255.255.255.240 --gateway=193.48.57.160 -size=10Gb --swap=128Mb --lvm=virtual<br />
<br />
Une fois que cette image est crée, on édite le fichier de configuration /etc/xen/pegase.cfg afin de lui attribuer une interface réseau virtuelle qui sera dans le bridge IMA5sc.<br />
<br />
vif = [ 'mac=00:16:3E:6F:37:08, bridge=IMA5sc' ]<br />
<br />
Une fois le fichier de configuration crée nous pouvons lancer la machine virtuelle à l'aide de la commande <br />
<br />
xl create -c /etc/xen/pegase.cfg<br />
<br />
Le mot de passe root était affiché à l'écran à la fin de la création de la machine virtuelle, mais il est toujours possible d'aller le récupérer dans les logs dans /var/log/xen-tools/pegase.log<br />
<br />
==Ajout de partitions logiques==<br />
<br />
Notre machine virtuelle fonctionne et est connectée au réseau, il faut dorénavant lui apporter du stockage, nous allons sur l'hôte (cordouan) créer deux volumes virtuels, un pour le /home et un autre pour le /var. Nous allons créer ces volumes virtuels dans le groupe de volume "virtual". Nous ajoutons également trois volumes de 1Gb afin de faire un RAID 5 logiciel dans la machine virtuelle.<br />
<br />
lvcreate -L10G -n pegase-home virtual<br />
lvcreate -L10G -n pegase-var virtual<br />
lvcreate -L1G -n pegase-part1 virtual<br />
lvcreate -L1G -n pegase-part2 virtual<br />
lvcreate -L1G -n pegase-part3 virtual<br />
<br />
Nous ajoutons ensuite ces volumes à notre machine virtuelle en tant que disque physique xvdb1, xvdc1, etc...<br />
<br />
root = '/dev/xvda2 ro'<br />
disk = [<br />
'phy:/dev/virtual/pegase-disk,xvda2,w',<br />
'phy:/dev/virtual/pegase-swap,xvda1,w',<br />
'phy:/dev/virtual/Pegase-home,xvdb1,w',<br />
'phy:/dev/virtual/Pegase-var,xvdc1,w',<br />
'phy:/dev/virtual/pegase-part1,xvdd1,w',<br />
'phy:/dev/virtual/pegase-part2,xvde1,w',<br />
'phy:/dev/virtual/pegase-part3,xvdf1,w'<br />
]<br />
<br />
<br />
Nous pouvons maintenant redémarrer la machine et monter un système de fichier de nos disques. On peut vérifier qu'ils existent d'ailleurs à l'aide de la commande fdisk -l<br />
<br />
mkfs -t ext4 xvdb1<br />
mkfs -t ext4 xvdc1<br />
mkfs -t ext4 xvdd1<br />
mkfs -t ext4 xvde1<br />
mkfs -t ext4 xvdf1<br />
<br />
Nous ajoutons le montage du disque xvdb1 en tant que /home dans /etc/fstab<br />
<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
<br />
Pour le /var, il faut faire attention de ne pas perdre les données déja existante, au risque d'avoir une machine inutilisable. Ainsi, on va venir monter temporairement le disque xvdc1 dans /mnt avant d'y déplacer l'intégralité du /var.<br />
<br />
mount /dev/xvdc1 /mnt<br />
mv /var/* /mnt<br />
<br />
Une fois ceci fait, nous pouvons le rajouter dans /etc/fstab<br />
<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
<br />
Maintenant, intéressons nous au RAID, nous allons utiliser l'utilitaire mdadm afin de réaliser le RAID5 en logiciel. Puis nous allons formater la partition formée par le raid et la monter. Puis nous créons un fichier sur cette partition.<br />
<br />
mdadm --create /dev/md/raid --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1<br />
mkfs -t ext4 /dev/md/raid<br />
mount /dev/md/raid /mnt<br />
touch coucou.txt<br />
<br />
On vérifie que tous nos disques ont été correctement montés :<br />
<br />
lsblk<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
xvda1 202:1 0 128M 0 disk [SWAP]<br />
xvda2 202:2 0 10G 0 disk /<br />
xvdb1 202:17 0 10G 0 disk /home<br />
xvdc1 202:33 0 10G 0 disk /var<br />
xvdd1 202:49 0 1G 0 disk <br />
`-md127 9:127 0 2G 0 raid5 /mnt<br />
xvde1 202:65 0 1G 0 disk <br />
`-md127 9:127 0 2G 0 raid5 /mnt<br />
xvdf1 202:81 0 1G 0 disk <br />
`-md127 9:127 0 2G 0 raid5 /mnt<br />
<br />
A partir de là, nous pouvons simuler une panne sur un des disques de notre RAID, ce qui pourrait arriver dans un cas réel<br />
<br />
mdadm --set-faulty /dev/md/raid /dev/xvdf1<br />
mdadm --remove /dev/xvdf1<br />
<br />
Nous constatons que notre fichier coucou.txt est toujours présent, malgré la "perte" de l'un des disques. Cependant, il faut tout de même se dire que nous avons fait un raid logiciel sur des partitions logiques, en pratique, si on perd vraiment le disque, nous perdrons quoi qu'il arrive tous les volumes logiques. Ainsi nous faisons ça pour l'aspect éducatif.<br />
<br />
==Chiffrement des disques RAID==<br />
<br />
Il peut être utile pour diverses raison de chiffrer les disques afin qu'un accès non autorisé par le propriétaire soit proscrit. Pour cela nous allons utiliser l'utilitaire cryptsetup avec le format LUKS afin de chiffrer notre disque en AES-256 avec un mot de passe.<br />
<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48585TP sysres IMA5sc 2018/2019 G32018-12-11T11:10:41Z<p>Adurot : /* Partie TP */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
<br />
==Création des machines virtuelles==<br />
Pour réaliser cette partie du TP nous avons besoin d'une machine virtuelle, nous allons la créer sur cordouan à l'aide de l'hyperviseur xen.<br />
<br />
Nous créons donc une image qui sera la base de notre machine :<br />
<br />
xen-create-image --hostname=pegase --ip=193.48.57.179 --netmask=255.255.255.240 --gateway=193.48.57.160 -size=10Gb --swap=128Mb --lvm=virtual<br />
<br />
Une fois que cette image est crée, on édite le fichier de configuration /etc/xen/pegase.cfg afin de lui attribuer une interface réseau virtuelle qui sera dans le bridge IMA5sc.<br />
<br />
vif = [ 'mac=00:16:3E:6F:37:08, bridge=IMA5sc' ]<br />
<br />
Une fois le fichier de configuration crée nous pouvons lancer la machine virtuelle à l'aide de la commande <br />
<br />
xl create -c /etc/xen/pegase.cfg<br />
<br />
Le mot de passe root était affiché à l'écran à la fin de la création de la machine virtuelle, mais il est toujours possible d'aller le récupérer dans les logs dans /var/log/xen-tools/pegase.log<br />
<br />
==Ajout de partitions logiques==<br />
<br />
Notre machine virtuelle fonctionne et est connectée au réseau, il faut dorénavant lui apporter du stockage, nous allons sur l'hôte (cordouan) créer deux volumes virtuels, un pour le /home et un autre pour le /var. Nous allons créer ces volumes virtuels dans le groupe de volume "virtual". Nous ajoutons également trois volumes de 1Gb afin de faire un RAID 5 logiciel dans la machine virtuelle.<br />
<br />
lvcreate -L10G -n pegase-home virtual<br />
lvcreate -L10G -n pegase-var virtual<br />
lvcreate -L1G -n pegase-part1 virtual<br />
lvcreate -L1G -n pegase-part2 virtual<br />
lvcreate -L1G -n pegase-part3 virtual<br />
<br />
Nous ajoutons ensuite ces volumes à notre machine virtuelle en tant que disque physique xvdb1, xvdc1, etc...<br />
<br />
root = '/dev/xvda2 ro'<br />
disk = [<br />
'phy:/dev/virtual/pegase-disk,xvda2,w',<br />
'phy:/dev/virtual/pegase-swap,xvda1,w',<br />
'phy:/dev/virtual/Pegase-home,xvdb1,w',<br />
'phy:/dev/virtual/Pegase-var,xvdc1,w',<br />
'phy:/dev/virtual/pegase-part1,xvdd1,w',<br />
'phy:/dev/virtual/pegase-part2,xvde1,w',<br />
'phy:/dev/virtual/pegase-part3,xvdf1,w'<br />
]<br />
<br />
<br />
Nous pouvons maintenant redémarrer la machine et monter un système de fichier de nos disques. On peut vérifier qu'ils existent d'ailleurs à l'aide de la commande fdisk -l<br />
<br />
mkfs -t ext4 xvdb1<br />
mkfs -t ext4 xvdc1<br />
mkfs -t ext4 xvdd1<br />
mkfs -t ext4 xvde1<br />
mkfs -t ext4 xvdf1<br />
<br />
Nous ajoutons le montage du disque xvdb1 en tant que /home dans /etc/fstab<br />
<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
<br />
Pour le /var, il faut faire attention de ne pas perdre les données déja existante, au risque d'avoir une machine inutilisable. Ainsi, on va venir monter temporairement le disque xvdc1 dans /mnt avant d'y déplacer l'intégralité du /var.<br />
<br />
mount /dev/xvdc1 /mnt<br />
mv /var/* /mnt<br />
<br />
Une fois ceci fait, nous pouvons le rajouter dans /etc/fstab<br />
<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
<br />
Maintenant, intéressons nous au RAID, nous allons utiliser l'utilitaire mdadm afin de réaliser le RAID5 en logiciel. Puis nous allons formater la partition formée par le raid et la monter. Puis nous créons un fichier sur cette partition.<br />
<br />
mdadm --create /dev/md/raid --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1<br />
mkfs -t ext4 /dev/md/raid<br />
mount /dev/md/raid /mnt<br />
touch coucou.txt<br />
<br />
On vérifie que tous nos disques ont été correctement montés :<br />
<br />
lsblk<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
xvda1 202:1 0 128M 0 disk [SWAP]<br />
xvda2 202:2 0 10G 0 disk /<br />
xvdb1 202:17 0 10G 0 disk /home<br />
xvdc1 202:33 0 10G 0 disk /var<br />
xvdd1 202:49 0 1G 0 disk <br />
`-md127 9:127 0 2G 0 raid5 /mnt<br />
xvde1 202:65 0 1G 0 disk <br />
`-md127 9:127 0 2G 0 raid5 /mnt<br />
xvdf1 202:81 0 1G 0 disk <br />
`-md127 9:127 0 2G 0 raid5 /mnt<br />
<br />
A partir de là, nous pouvons simuler une panne sur un des disques de notre RAID, ce qui pourrait arriver dans un cas réel<br />
<br />
mdadm --set-faulty /dev/md/raid /dev/xvdf1<br />
mdadm --remove /dev/xvdf1<br />
<br />
Nous constatons que notre fichier coucou.txt est toujours présent, malgré la "perte" de l'un des disques. Cependant, il faut tout de même se dire que nous avons fait un raid logiciel sur des partitions logiques, en pratique, si on perd vraiment le disque, nous perdrons quoi qu'il arrive tous les volumes logiques. Ainsi nous faisons ça pour l'aspect éducatif.<br />
<br />
==Chiffrement des disques RAID==<br />
<br />
Il peut être utile pour diverses raison de chiffrer les disques afin qu'un accès non autorisé par le propriétaire soit proscrit. Pour cela nous allons utiliser l'utilitaire cryptsetup avec le format LUKS afin de chiffrer notre disque en AES-256 avec un mot de passe.<br />
<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory<br />
<br />
<br />
==Ajout de partitions sur la machine virtuelle==</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48581TP sysres IMA5sc 2018/2019 G32018-12-11T10:48:17Z<p>Adurot : /* Création des machines virtuelles */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
<br />
==Création des machines virtuelles==<br />
Pour réaliser cette partie du TP nous avons besoin d'une machine virtuelle, nous allons la créer sur cordouan à l'aide de l'hyperviseur xen.<br />
<br />
Nous créons donc une image qui sera la base de notre machine :<br />
<br />
xen-create-image --hostname=pegase --ip=193.48.57.179 --netmask=255.255.255.240 --gateway=193.48.57.160 -size=10Gb --swap=128Mb --lvm=virtual<br />
<br />
Une fois que cette image est crée, on édite le fichier de configuration /etc/xen/pegase.cfg afin de lui attribuer une interface réseau virtuelle qui sera dans le bridge IMA5sc.<br />
<br />
vif = [ 'mac=00:16:3E:6F:37:08, bridge=IMA5sc' ]<br />
<br />
Une fois le fichier de configuration crée nous pouvons lancer la machine virtuelle à l'aide de la commande <br />
<br />
xl create -c /etc/xen/pegase.cfg<br />
<br />
Le mot de passe root était affiché à l'écran à la fin de la création de la machine virtuelle, mais il est toujours possible d'aller le récupérer dans les logs dans /var/log/xen-tools/pegase.log<br />
<br />
==Ajout de partitions logiques==<br />
<br />
Notre machine virtuelle fonctionne et est connectée au réseau, il faut dorénavant lui apporter du stockage, nous allons sur l'hôte (cordouan) créer deux volumes virtuels, un pour le /home et un autre pour le /var. Nous allons créer ces volumes virtuels dans le groupe de volume "virtual". Nous ajoutons également trois volumes de 1Gb afin de faire un RAID 5 logiciel dans la machine virtuelle.<br />
<br />
lvcreate -L10G -n pegase-home virtual<br />
lvcreate -L10G -n pegase-var virtual<br />
lvcreate -L1G -n pegase-part1 virtual<br />
lvcreate -L1G -n pegase-part2 virtual<br />
lvcreate -L1G -n pegase-part3 virtual<br />
<br />
Nous ajoutons ensuite ces volumes à notre machine virtuelle en tant que disque physique xvdb1, xvdc1, etc...<br />
<br />
root = '/dev/xvda2 ro'<br />
disk = [<br />
'phy:/dev/virtual/pegase-disk,xvda2,w',<br />
'phy:/dev/virtual/pegase-swap,xvda1,w',<br />
'phy:/dev/virtual/Pegase-home,xvdb1,w',<br />
'phy:/dev/virtual/Pegase-var,xvdc1,w',<br />
'phy:/dev/virtual/pegase-part1,xvdd1,w',<br />
'phy:/dev/virtual/pegase-part2,xvde1,w',<br />
'phy:/dev/virtual/pegase-part3,xvdf1,w'<br />
]<br />
<br />
<br />
Nous pouvons maintenant redémarrer la machine et monter un système de fichier de nos disques. On peut vérifier qu'ils existent d'ailleurs à l'aide de la commande fdisk -l<br />
<br />
mkfs -t ext4 xvdb1<br />
mkfs -t ext4 xvdc1<br />
mkfs -t ext4 xvdd1<br />
mkfs -t ext4 xvde1<br />
mkfs -t ext4 xvdf1<br />
<br />
Nous ajoutons le montage du disque xvdb1 en tant que /home dans /etc/fstab<br />
<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
<br />
Pour le /var, il faut faire attention de ne pas perdre les données déja existante, au risque d'avoir une machine inutilisable. Ainsi, on va venir monter temporairement le disque xvdc1 dans /mnt avant d'y déplacer l'intégralité du /var.<br />
<br />
mount /dev/xvdc1 /mnt<br />
mv /var/* /mnt<br />
<br />
Une fois ceci fait, nous pouvons le rajouter dans /etc/fstab<br />
<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
<br />
Maintenant, intéressons nous au RAID, nous allons utiliser l'utilitaire mdadm afin de réaliser le RAID5 en logiciel. Puis nous allons formater la partition formée par le raid et la monter. Puis nous créons un fichier sur cette partition.<br />
<br />
mdadm --create /dev/md/raid --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1<br />
mkfs -t ext4 /dev/md/raid<br />
mount /dev/md/raid /mnt<br />
touch coucou.txt<br />
<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory<br />
<br />
<br />
==Ajout de partitions sur la machine virtuelle==</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48579TP sysres IMA5sc 2018/2019 G32018-12-11T10:47:38Z<p>Adurot : /* Ajout de partitions logiques */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
<br />
==Création des machines virtuelles==<br />
Pour réaliser cette partie du TP nous avons besoin d'une machine virtuelle, nous allons la créer sur cordouan à l'aide de l'hyperviseur xen.<br />
<br />
Nous créons donc une image qui sera la base de notre machine :<br />
xen-create-image --hostname=pegase --ip=193.48.57.179 --netmask=255.255.255.240 --gateway=193.48.57.160<br />
<br />
Une fois que cette image est crée, on édite le fichier de configuration /etc/xen/pegase.cfg afin de lui attribuer une interface réseau virtuelle qui sera dans le bridge IMA5sc.<br />
<br />
vif = [ 'mac=00:16:3E:6F:37:08, bridge=IMA5sc' ]<br />
<br />
Une fois le fichier de configuration crée nous pouvons lancer la machine virtuelle à l'aide de la commande <br />
<br />
xl create -c /etc/xen/pegase.cfg<br />
<br />
Le mot de passe root était affiché à l'écran à la fin de la création de la machine virtuelle, mais il est toujours possible d'aller le récupérer dans les logs dans /var/log/xen-tools/pegase.log<br />
<br />
==Ajout de partitions logiques==<br />
<br />
Notre machine virtuelle fonctionne et est connectée au réseau, il faut dorénavant lui apporter du stockage, nous allons sur l'hôte (cordouan) créer deux volumes virtuels, un pour le /home et un autre pour le /var. Nous allons créer ces volumes virtuels dans le groupe de volume "virtual". Nous ajoutons également trois volumes de 1Gb afin de faire un RAID 5 logiciel dans la machine virtuelle.<br />
<br />
lvcreate -L10G -n pegase-home virtual<br />
lvcreate -L10G -n pegase-var virtual<br />
lvcreate -L1G -n pegase-part1 virtual<br />
lvcreate -L1G -n pegase-part2 virtual<br />
lvcreate -L1G -n pegase-part3 virtual<br />
<br />
Nous ajoutons ensuite ces volumes à notre machine virtuelle en tant que disque physique xvdb1, xvdc1, etc...<br />
<br />
root = '/dev/xvda2 ro'<br />
disk = [<br />
'phy:/dev/virtual/pegase-disk,xvda2,w',<br />
'phy:/dev/virtual/pegase-swap,xvda1,w',<br />
'phy:/dev/virtual/Pegase-home,xvdb1,w',<br />
'phy:/dev/virtual/Pegase-var,xvdc1,w',<br />
'phy:/dev/virtual/pegase-part1,xvdd1,w',<br />
'phy:/dev/virtual/pegase-part2,xvde1,w',<br />
'phy:/dev/virtual/pegase-part3,xvdf1,w'<br />
]<br />
<br />
<br />
Nous pouvons maintenant redémarrer la machine et monter un système de fichier de nos disques. On peut vérifier qu'ils existent d'ailleurs à l'aide de la commande fdisk -l<br />
<br />
mkfs -t ext4 xvdb1<br />
mkfs -t ext4 xvdc1<br />
mkfs -t ext4 xvdd1<br />
mkfs -t ext4 xvde1<br />
mkfs -t ext4 xvdf1<br />
<br />
Nous ajoutons le montage du disque xvdb1 en tant que /home dans /etc/fstab<br />
<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
<br />
Pour le /var, il faut faire attention de ne pas perdre les données déja existante, au risque d'avoir une machine inutilisable. Ainsi, on va venir monter temporairement le disque xvdc1 dans /mnt avant d'y déplacer l'intégralité du /var.<br />
<br />
mount /dev/xvdc1 /mnt<br />
mv /var/* /mnt<br />
<br />
Une fois ceci fait, nous pouvons le rajouter dans /etc/fstab<br />
<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
<br />
Maintenant, intéressons nous au RAID, nous allons utiliser l'utilitaire mdadm afin de réaliser le RAID5 en logiciel. Puis nous allons formater la partition formée par le raid et la monter. Puis nous créons un fichier sur cette partition.<br />
<br />
mdadm --create /dev/md/raid --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1<br />
mkfs -t ext4 /dev/md/raid<br />
mount /dev/md/raid /mnt<br />
touch coucou.txt<br />
<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory<br />
<br />
<br />
==Ajout de partitions sur la machine virtuelle==</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48569TP sysres IMA5sc 2018/2019 G32018-12-11T09:58:29Z<p>Adurot : /* Partie TP */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
<br />
==Création des machines virtuelles==<br />
Pour réaliser cette partie du TP nous avons besoin d'une machine virtuelle, nous allons la créer sur cordouan à l'aide de l'hyperviseur xen.<br />
<br />
Nous créons donc une image qui sera la base de notre machine :<br />
xen-create-image --hostname=pegase --ip=193.48.57.179 --netmask=255.255.255.240 --gateway=193.48.57.160<br />
<br />
Une fois que cette image est crée, on édite le fichier de configuration /etc/xen/pegase.cfg afin de lui attribuer une interface réseau virtuelle qui sera dans le bridge IMA5sc.<br />
<br />
vif = [ 'mac=00:16:3E:6F:37:08, bridge=IMA5sc' ]<br />
<br />
Une fois le fichier de configuration crée nous pouvons lancer la machine virtuelle à l'aide de la commande <br />
<br />
xl create -c /etc/xen/pegase.cfg<br />
<br />
Le mot de passe root était affiché à l'écran à la fin de la création de la machine virtuelle, mais il est toujours possible d'aller le récupérer dans les logs dans /var/log/xen-tools/pegase.log<br />
<br />
==Ajout de partitions logiques==<br />
<br />
Notre machine virtuelle fonctionne et est connectée au réseau, il faut dorénavant lui apporter du stockage, nous allons sur l'hôte (cordouan) créer deux volumes virtuels, un pour le /home et un autre pour le /var. Nous allons créer ces volumes virtuels dans le groupe de volume "virtual". Nous ajoutons également trois volumes de 1Gb afin de faire un RAID 5 logiciel dans la machine virtuelle.<br />
<br />
lvcreate -L10G -n pegase-home virtual<br />
lvcreate -L10G -n pegase-var virtual<br />
lvcreate -L1G -n pegase-part1 virtual<br />
lvcreate -L1G -n pegase-part2 virtual<br />
lvcreate -L1G -n pegase-part3 virtual<br />
<br />
Nous ajoutons ensuite ces volumes à notre machine virtuelle en tant que disque physique xvdb1, xvdc1, etc...<br />
<br />
root = '/dev/xvda2 ro'<br />
disk = [<br />
'phy:/dev/virtual/pegase-disk,xvda2,w',<br />
'phy:/dev/virtual/pegase-swap,xvda1,w',<br />
'phy:/dev/virtual/Pegase-home,xvdb1,w',<br />
'phy:/dev/virtual/Pegase-var,xvdc1,w',<br />
'phy:/dev/virtual/pegase-part1,xvdd1,w',<br />
'phy:/dev/virtual/pegase-part2,xvde1,w',<br />
'phy:/dev/virtual/pegase-part3,xvdf1,w'<br />
]<br />
<br />
<br />
Nous pouvons maintenant redémarrer la machine et monter un système de fichier de nos disques. On peut vérifier qu'ils existent d'ailleurs à l'aide de la commande fdisk -l<br />
<br />
mkfs -t ext4 xvdb1<br />
mkfs -t ext4 xvdc1<br />
mkfs -t ext4 xvdd1<br />
mkfs -t ext4 xvde1<br />
mkfs -t ext4 xvdf1<br />
<br />
Nous ajoutons le montage du disque xvdb1 en tant que /home dans /etc/fstab<br />
<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
<br />
Pour le /var, il faut faire attention de ne pas perdre les données déja existante, au risque d'avoir une machine inutilisable. Ainsi, on va venir monter temporairement le disque xvdc1 dans /mnt avant d'y déplacer l'intégralité du /var.<br />
<br />
mount /dev/xvdc1 /mnt<br />
mv /var/* /mnt<br />
<br />
Une fois ceci fait, nous pouvons le rajouter dans /etc/fstab<br />
<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
<br />
Maintenant, intéressons nous au RAID, nous allons utiliser l'utilitaire mdadm afin de réaliser le RAID5 en logiciel. Puis nous allons formater la partition formée par le raid et la monter. Puis nous créons un fichier sur cette partition.<br />
<br />
mdadm --create /dev/md/raid --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1<br />
mkfs -t ext4 /dev/md/raid<br />
mount /dev/md/raid /mnt<br />
touch coucou.txt<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory<br />
<br />
<br />
==Ajout de partitions sur la machine virtuelle==</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48554TP sysres IMA5sc 2018/2019 G32018-12-10T23:06:22Z<p>Adurot : /* Partie TP */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
<br />
==Création des machines virtuelles==<br />
Pour réaliser cette partie du TP nous avons besoin d'une machine virtuelle, nous allons la créer sur cordouan à l'aide de l'hyperviseur xen.<br />
<br />
Nous créons donc une image qui sera la base de notre machine :<br />
xen-create-image --hostname=pegase --ip=193.48.57.179 --netmask=255.255.255.240 --gateway=193.48.57.160<br />
<br />
Une fois que cette image est crée, on édite le fichier de configuration /etc/xen/pegase.cfg afin de lui attribuer une interface réseau virtuelle qui sera dans le bridge IMA5sc.<br />
<br />
vif = [ 'mac=00:16:3E:6F:37:08, bridge=IMA5sc' ]<br />
<br />
Une fois le fichier de configuration crée nous pouvons lancer la machine virtuelle à l'aide de la commande <br />
<br />
xl create -c /etc/xen/pegase.cfg<br />
<br />
Le mot de passe root était affiché à l'écran à la fin de la création de la machine virtuelle, mais il est toujours possible d'aller le récupérer dans les logs dans /var/log/xen-tools/pegase.log<br />
<br />
==Ajout de partitions logiques==<br />
<br />
Notre machine virtuelle fonctionne et est connectée au réseau, il faut dorénavant lui apporter du stockage, nous allons sur l'hôte (cordouan) créer deux volumes virtuels, un pour le /home et un autre pour le /var. Nous allons créer ces volumes virtuels dans le groupe de volume "virtual". Nous ajoutons également trois volumes de 1Gb afin de faire un RAID 5 logiciel dans la machine virtuelle.<br />
<br />
lvcreate -L10G -n pegase-home virtual<br />
lvcreate -L10G -n pegase-var virtual<br />
lvcreate -L1G -n pegase-part1 virtual<br />
lvcreate -L1G -n pegase-part2 virtual<br />
lvcreate -L1G -n pegase-part3 virtual<br />
<br />
Nous ajoutons ensuite ces volumes à notre machine virtuelle en tant que disque physique xvdb1, xvdc1, etc...<br />
<br />
root = '/dev/xvda2 ro'<br />
disk = [<br />
'phy:/dev/virtual/pegase-disk,xvda2,w',<br />
'phy:/dev/virtual/pegase-swap,xvda1,w',<br />
'phy:/dev/virtual/Pegase-home,xvdb1,w',<br />
'phy:/dev/virtual/Pegase-var,xvdc1,w',<br />
'phy:/dev/virtual/pegase-part1,xvdd1,w',<br />
'phy:/dev/virtual/pegase-part2,xvde1,w',<br />
'phy:/dev/virtual/pegase-part3,xvdf1,w'<br />
]<br />
<br />
<br />
Nous pouvons maintenant redémarrer la machine et monter un système de fichier de nos disques. On peut vérifier qu'ils existent d'ailleurs à l'aide de la commande fdisk -l<br />
<br />
mkfs -t ext4 xvdb1<br />
mkfs -t ext4 xvdc1<br />
mkfs -t ext4 xvdd1<br />
mkfs -t ext4 xvde1<br />
mkfs -t ext4 xvdf1<br />
<br />
Nous ajoutons le montage du disque xvdb1 en tant que /home dans /etc/fstab<br />
<br />
/dev/xvdb1 /home ext4 defaults 0 2<br />
<br />
Pour le /var, il faut faire attention de ne pas perdre les données déja existante, au risque d'avoir une machine inutilisable. Ainsi, on va venir monter temporairement le disque xvdc1 dans /mnt avant d'y déplacer l'intégralité du /var.<br />
<br />
mount /dev/xvdc1 /mnt<br />
mv /var/* /mnt<br />
<br />
Une fois ceci fait, nous pouvons le rajouter dans /etc/fstab<br />
<br />
/dev/xvdc1 /var ext4 defaults 0 2<br />
<br />
Maintenant, intéressons nous au RAID, nous allons utiliser l'utilitaire mdadm afin de réaliser le RAID5 en logiciel. <br />
<br />
mdadm --create /dev/md/raid --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1<br />
<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory<br />
<br />
<br />
==Ajout de partitions sur la machine virtuelle==</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48550TP sysres IMA5sc 2018/2019 G32018-12-10T22:56:55Z<p>Adurot : /* Partie TP */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
<br />
==Création des machines virtuelles==<br />
Pour réaliser cette partie du TP nous avons besoin d'une machine virtuelle, nous allons la créer sur cordouan à l'aide de l'hyperviseur xen.<br />
<br />
Nous créons donc une image qui sera la base de notre machine :<br />
xen-create-image --hostname=pegase --ip=193.48.57.179 --netmask=255.255.255.240 --gateway=193.48.57.160<br />
<br />
Une fois que cette image est crée, on édite le fichier de configuration /etc/xen/pegase.cfg afin de lui attribuer une interface réseau virtuelle qui sera dans le bridge IMA5sc.<br />
<br />
vif = [ 'mac=00:16:3E:6F:37:08, bridge=IMA5sc' ]<br />
<br />
Une fois le fichier de configuration crée nous pouvons lancer la machine virtuelle à l'aide de la commande <br />
<br />
xl create -c /etc/xen/pegase.cfg<br />
<br />
Le mot de passe root était affiché à l'écran à la fin de la création de la machine virtuelle, mais il est toujours possible d'aller le récupérer dans les logs dans /var/log/xen-tools/pegase.log<br />
<br />
==Ajout de partitions logiques==<br />
<br />
Notre machine virtuelle fonctionne et est connectée au réseau, il faut dorénavant lui apporter du stockage, nous allons sur l'hôte (cordouan) créer deux volumes virtuels, un pour le /home et un autre pour le /var. Nous allons créer ces volumes virtuels dans le groupe de volume "virtual". Nous ajoutons également trois volumes de 1Gb afin de faire un RAID 5 logiciel dans la machine virtuelle.<br />
<br />
lvcreate -L10G -n pegase-home virtual<br />
lvcreate -L10G -n pegase-var virtual<br />
lvcreate -L1G -n pegase-part1 virtual<br />
lvcreate -L1G -n pegase-part2 virtual<br />
lvcreate -L1G -n pegase-part3 virtual<br />
<br />
Nous ajoutons ensuite ces volumes à notre machine virtuelle en tant que disque physique xvdb1, xvdc1, etc...<br />
<br />
root = '/dev/xvda2 ro'<br />
disk = [<br />
'phy:/dev/virtual/pegase-disk,xvda2,w',<br />
'phy:/dev/virtual/pegase-swap,xvda1,w',<br />
'phy:/dev/virtual/Pegase-home,xvdb1,w',<br />
'phy:/dev/virtual/Pegase-var,xvdc1,w',<br />
'phy:/dev/virtual/pegase-part1,xvdd1,w',<br />
'phy:/dev/virtual/pegase-part2,xvde1,w',<br />
'phy:/dev/virtual/pegase-part3,xvdf1,w'<br />
]<br />
<br />
<br />
Nous pouvons maintenant redémarrer la machine et monter un système de fichier de nos disques. On peut vérifier qu'ils existent d'ailleurs à l'aide de lsblk<br />
<br />
lsblk<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
xvda1 202:1 0 128M 0 disk [SWAP]<br />
xvda2 202:2 0 10G 0 disk /<br />
xvdb1 202:17 0 10G 0 disk /home<br />
xvdc1 202:33 0 10G 0 disk /var<br />
<br />
<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory<br />
<br />
<br />
==Ajout de partitions sur la machine virtuelle==</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48547TP sysres IMA5sc 2018/2019 G32018-12-10T20:46:31Z<p>Adurot : /* Partie TP */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory<br />
<br />
<br />
==Ajout de partitions sur la machine virtuelle==</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48139TP sysres IMA5sc 2018/2019 G32018-11-27T10:21:45Z<p>Adurot : /* Authentification LDAP sur point d'accès */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|400px|thumb|right|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48137TP sysres IMA5sc 2018/2019 G32018-11-27T10:21:20Z<p>Adurot : /* Partie TP */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48135TP sysres IMA5sc 2018/2019 G32018-11-27T10:20:39Z<p>Adurot : /* Partie TP */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à interroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|200px|thumb|left|Topologie de notre réseau]]<br />
<br />
<br />
Tout d'abord, nous allons créer une machine virtuelle sur Cordouan afin d'y mettre le serveur RADIUS. Pour se faire nous allons installer les paquets suivants : <br />
<br />
apt-get install freeradius freeradius-ldap<br />
<br />
On précise freeradius-ldap pour ajouter le module ldap, en effet freeradius est un serveur d'authentification qui ne gère pas que LDAP.<br />
<br />
===Configuration du serveur RADIUS===<br />
<br />
Pour configurer notre serveur RADIUS, on édite le fichier /etc/freeradius/3.0/client<br />
<br />
<br />
===Configuration du point d'accès===<br />
<br />
ap>en<br />
ap(config)#interface dot11radio0<br />
ap(config)#encryption mode ciphers tkip<br />
ap(config)#ssid PLILL<br />
ap(config-ssid)#authentication open eap eap_methods<br />
ap(config-ssid)#authentication network-eap eap_methods<br />
ap(config-ssid)#end<br />
ap(config-ssid)#ip address 172.26.145.113 255.255.255.0<br />
ap(config)#wirte memory</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48120TP sysres IMA5sc 2018/2019 G32018-11-27T09:56:13Z<p>Adurot : /* Partie TP */</p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à intérroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-schema.png|200px|thumb|left|Topologie de notre réseau]]</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=48119TP sysres IMA5sc 2018/2019 G32018-11-27T09:55:25Z<p>Adurot : </p>
<hr />
<div>=Première séance=<br />
<br />
Nous allons au cours de cette première séance mettre en place un réseau de 3 conteneurs ''from scratch'' en exploitant le principe des espaces de noms pour assurer l'isolation. Un des conteneurs agira comme serveur mandataire inverse plus communément appelé ''reverse proxy'' et aura pour rôle de dispatcher les requêtes vers les deux autres conteneurs serveur web suivant le nom de domaine ciblé par l'utilisateur. Ces deux conteneurs ne seront pas accessibles directement depuis le réseau, c'est le reverse proxy qui assura la liaison entre ces deux différents réseaux. <br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
mkfs.ext4 /home/pifou/containers/container1<br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
umount /mnt/container1<br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
ip link add monpetitpont type bridge<br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
<br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
ps aux | grep unshare<br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
ip addr add 192.168.1.2/24 dev eth0<br />
ip addr add 192.168.1.3/24 dev eth0<br />
ip addr add 192.168.1.4/24 dev eth0<br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
ip link set eth0 up<br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
ip addr add 172.26.145.150/24 dev eth1<br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
==Suite de la première séance==<br />
<br />
Nous allons créer des sous-domaines du domaine plil.space mis à notre disposition chez Gandi. <br />
<br />
Tout d'abord nous créons une entrée de type "A" avec comme nom "durotduq.plil.space" et qui pointe vers 172.26.145.150. Ensuite, nous ajoutons deux entrées CNAME "durotduq1" et "durotduq2" avec comme valeur "durotduq". Bien qu'au final tous ces sous-domaines dirigent vers 172.26.145.150, le ''reverse proxy'' sera quand même en mesure de distinguer les requêtes entrantes et de les dispatcher vers les services concernés selon le sous-domaine.<br />
<br />
'''''10h15 => Serveurs Web unshare OK'''''<br />
<br />
Sur le conteneur mandataire inverse, on applique la configuration suivante dans le fichier /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br /><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br /><br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br /><br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br /><br />
</VirtualHost><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs 1 et 2 dans monpetitpont. S'agissant d'adresses privées, elles sont donc non accessibles depuis l'extérieur et par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs ''from scratch'' fonctionne mais elle a l'inconvénient d'être relativement longue à installer et peu pratique. De plus, sans un minimum de scripting, les configurations ne peuvent être pérennisées. Ainsi, nous devions tout refaire à la main à chaque fois. <br />
<br />
Dans la pratique, on préférera utiliser Docker comme système de gestion de conteneurs, car il permet d’une manière simple de manipuler et gérer les conteneurs. Il permet également que les configurations soient durables et offre la possibilité de gérer différentes version pour une même image et même de les distribuer. <br />
<br />
Nous allons donc réaliser exactement la même architecture mais cette fois-ci à l'aide de Docker. Nous partirons sur la base d'une image Debian. <br />
<br />
Lancement d'un conteneur Docker à partir de l'image debian<br />
<br />
docker run -i -t debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy=http://proxy.polytech-lille.fr:3218<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, nous pouvons faire un commit des fichiers de ce conteneur, de cette manière, nous aurons une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir réaliser ce commit, il faut connaitre l'identifiant du conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
A cet instant, nous avons une image myapache2 basée sur Debian avec les paquetages listés précédemment. La présence de cette image se vérifier avec la commande suivante.<br />
<br />
docker images<br />
<br />
Maintenant que nous sommes en mesure de lancer 3 conteneurs identiques contenant un serveur web Apache 2, nous créons un réseau Docker pour interconnecter les conteneurs. Sans précision de l'option --driver, il s'agit par défaut d'un bridge, ce que nous voulons.<br />
<br />
docker network create pontpont<br />
<br />
Nous pouvons à présent lancer les 3 conteneurs en spécifiant leur réseau d'attache et sans oublier d'exposer le port 80 du conteneur ''reverse proxy'' en le rendant accessible depuis le port 80 de la machine. Il faudra donc veiller à changer l'entrée DNS de type A avec l'IP de la zabeth (172.26.145.37).<br />
<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -i -t myapache2 /bin/bash<br />
docker run --net pontpont -p 80:80 -i -t myapache2 /bin/bash<br />
<br />
La suite est très similaire à ce qui a été fait en première partie.<br />
<br />
On repère les IPs des conteneurs 1 et 2 pour pouvoir adapter la configuration d'Apache 2 et on change la valeur de l'entrée DNS de type A durotduq.plil.space avec l'IP de la zabeth.<br />
<br />
Le résultat final est bien évidemment identique, la solution moins formatricice certes mais plus pratique et utilisée en production. <br />
<br />
'''''12h10 => Serveurs Web docker OK'''''<br />
<br />
<br />
=Partie TP=<br />
==Authentification LDAP sur point d'accès==<br />
L'objectif est de pouvoir s'authentifier auprès d'une borne point d'accès wifi Cisco à l'aide de ses identifiants Polytech. Pour se faire nous allons mettre en place un serveur RADIUS à l'aide de l'implémentation Open Source FreeRADIUS (https://github.com/FreeRADIUS). Le serveur RADIUS sert à intérroger le serveur LDAP afin d'authentifier l'utilisateur et lui autoriser la connexion.<br />
<br />
[[Fichier:radius-server.png|200px|thumb|left|texte descriptif]]</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=Fichier:Radius-schema.png&diff=48118Fichier:Radius-schema.png2018-11-27T09:54:33Z<p>Adurot : </p>
<hr />
<div></div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47857TP sysres IMA5sc 2018/2019 G32018-11-19T14:53:13Z<p>Adurot : </p>
<hr />
<div>=Première séance=<br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
</div><br />
<br/><br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkfs.ext4 /home/pifou/containers/container1<br />
</div><br />
<br/><br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkdir /mnt/container1<br />
<br />
mkdir /mnt/container2<br />
<br />
mkdir /mnt/container3<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
</div><br />
<br/><br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
</div><br />
<br/><br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
</div><br />
<br/><br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
</div><br />
<br/><br />
<br />
Enfin, on peut démonter la partition <br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
umount /mnt/container1<br />
</div><br />
<br/><br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
</div><br />
<br/><br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
</div><br />
<br/><br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add monpetitpont type bridge<br />
</div><br />
<br/><br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add vif1 type veth peer name eth0@vif1<br />
<br />
ip link add vif2 type veth peer name eth0@vif2<br />
<br />
ip link add vif3 type veth peer name eth0@vif3<br />
<br />
ip link add vif4 type veth peer name eth1@vif4<br />
</div><br />
<br/><br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 master monpetitpont<br />
<br />
ip link set vif2 master monpetitpont<br />
<br />
ip link set vif3 master monpetitpont<br />
<br />
ip link set vif4 master bridge<br />
</div><br />
<br/><br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 up<br />
<br />
ip link set vif2 up<br />
<br />
ip link set vif3 up<br />
<br />
ip link set vif4 up<br />
</div><br />
<br/><br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip a add dev monpetitpont 192.168.1.1/24<br />
<br />
ip link set monpetitpont down<br />
<br />
ip link set monpetitpont up<br />
</div><br />
<br/><br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
</div><br />
<br/><br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
</div><br />
<br/><br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ps aux | grep unshare<br />
</div><br />
<br/><br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 192.168.1.2/24 dev eth0<br />
<br />
ip addr add 192.168.1.3/24 dev eth0<br />
<br />
ip addr add 192.168.1.4/24 dev eth0<br />
</div><br />
<br/><br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0 up<br />
</div><br />
<br/><br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 172.26.145.150/24 dev eth1<br />
</div><br />
<br/><br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
=Seconde séance=<br />
<br />
Nous allons créer des noms de domaines sur GANDI. <br />
<br />
Tout d'abord nous créons une entrée de type "A" qui aura pour nom "durotduq.plil.space" et qui redirigera vers 172.26.145.150. Puis CNAME : "durotduq1" et "durotduq2".<br />
<br />
10h15 => Serveurs Web unshare OK<br />
<br />
Sur le conteneur mandataire inverse on met cette configuration dans /etc/apache2/sites-enabled/000-default.conf.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
<VirtualHost *:80><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br />
<br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br />
<br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br />
<br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br />
<br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br />
</VirtualHost><br />
</div><br />
<br/><br />
<br />
192.168.1.102 et 192.168.1.101 étant les adresses IP des conteneurs dans monpetitpont. Il convient que ces adresses ne sont pas accessibles depuis l'extérieur et que par conséquent toute connexion se fera par le biais du serveur mandataire inverse.<br />
<br />
==Réalisation avec Docker==<br />
<br />
Notre architecture de conteneurs fonctionne mais elle a l'inconvénient d'être lourde et longue à installer, de plus les configurations ne sont pas perennes. Ainsi, on doit tout refaire à la main à chaque fois. <br />
<br />
En cas pratique, on préféreras utiliser Docker comme système de gestion de conteneurs, car il permet simplement de manipuler et gérer les conteneurs, mais aussi faire en sorte que nos configurations soient durable. <br />
<br />
On va donc réaliser exactement la même architecture, mais à l'aide de Docker. On va donc partir sur la base d'une image Debian. <br />
<br />
Lancement d'un contenneur Docker à partir de l'image debian<br />
<br />
docker run -it debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy<br />
<br />
Mise à jour de la liste des paquetages en local puis installation des paquetages vim, nano et apache2<br />
<br />
apt-get update && apt-get install vim nano apache2<br />
<br />
Maintenant, on peut faire un commit de ce conteneur, de cette manière, on aura une nouvelle image sur laquelle on pourra instancier des conteneurs. <br />
<br />
Pour pouvoir faire un commit de conteneur, il faut connaitre l'identifiant de conteneur :<br />
<br />
docker ps<br />
docker commit 7e456 myapache2<br />
<br />
Maintenant, on a crée une image myapache2 depuis notre conteneur, on peut acceder à la liste des conteneurs à l'aide de <br />
<br />
docker images<br />
<br />
On crée un réseau Docker pour interconnecter les conteneurs.<br />
<br />
docker network create pontpont<br />
<br />
Maintenant on va créer 3 conteneurs sur la base de notre image crée précédemment. Pour le troisième conteneur qui correspond au serveur mandataire inverse.<br />
<br />
docker run -it myapache2 /bin/bash<br />
docker run -it myapache2 /bin/bash<br />
docker run -p 80:80 -it myapache2 /bin/bash<br />
<br />
<br />
<br />
<br />
12h10 => Serveurs Web docker OK</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47808TP sysres IMA5sc 2018/2019 G32018-11-19T12:04:02Z<p>Adurot : /* Lancement et configuration réseau des 3 conteneurs */</p>
<hr />
<div>=Première séance=<br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
</div><br />
<br/><br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkfs.ext4 /home/pifou/containers/container1<br />
</div><br />
<br/><br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkdir /mnt/container1<br />
<br />
mkdir /mnt/container2<br />
<br />
mkdir /mnt/container3<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
</div><br />
<br/><br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
</div><br />
<br/><br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
</div><br />
<br/><br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
</div><br />
<br/><br />
<br />
Enfin, on peut démonter la partition <br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
umount /mnt/container1<br />
</div><br />
<br/><br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
</div><br />
<br/><br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
</div><br />
<br/><br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add monpetitpont type bridge<br />
</div><br />
<br/><br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add vif1 type veth peer name eth0@vif1<br />
<br />
ip link add vif2 type veth peer name eth0@vif2<br />
<br />
ip link add vif3 type veth peer name eth0@vif3<br />
<br />
ip link add vif4 type veth peer name eth1@vif4<br />
</div><br />
<br/><br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 master monpetitpont<br />
<br />
ip link set vif2 master monpetitpont<br />
<br />
ip link set vif3 master monpetitpont<br />
<br />
ip link set vif4 master bridge<br />
</div><br />
<br/><br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 up<br />
<br />
ip link set vif2 up<br />
<br />
ip link set vif3 up<br />
<br />
ip link set vif4 up<br />
</div><br />
<br/><br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip a add dev monpetitpont 192.168.1.1/24<br />
<br />
ip link set monpetitpont down<br />
<br />
ip link set monpetitpont up<br />
</div><br />
<br/><br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
</div><br />
<br/><br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
</div><br />
<br/><br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ps aux | grep unshare<br />
</div><br />
<br/><br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 192.168.1.2/24 dev eth0<br />
<br />
ip addr add 192.168.1.3/24 dev eth0<br />
<br />
ip addr add 192.168.1.4/24 dev eth0<br />
</div><br />
<br/><br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0 up<br />
</div><br />
<br/><br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 172.26.145.150/24 dev eth1<br />
</div><br />
<br/><br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
<br />
Nous allons creer des noms de domaines sur GANDI. <br />
<br />
Tout d'abord nous créons une entrée de type "A" qui aura pour nom "durotduq.plil.space" et qui redirigera vers 172.26.145.150. Puis CNAME : "durotduq1" et "durotduq2".<br />
<br />
10h15 => Serveurs Web unshare OK<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
<VirtualHost *:80><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br />
<br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br />
<br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br />
<br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br />
<br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br />
</VirtualHost><br />
</div><br />
<br/><br />
<br />
Lancement d'un contenneur Docker à partir de l'image debian<br />
<br />
docker run -it debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy<br />
<br />
12h10 => Serveurs Web docker OK</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47807TP sysres IMA5sc 2018/2019 G32018-11-19T12:03:44Z<p>Adurot : /* Lancement et configuration réseau des 3 conteneurs */</p>
<hr />
<div>=Première séance=<br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
</div><br />
<br/><br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkfs.ext4 /home/pifou/containers/container1<br />
</div><br />
<br/><br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkdir /mnt/container1<br />
<br />
mkdir /mnt/container2<br />
<br />
mkdir /mnt/container3<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
</div><br />
<br/><br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
</div><br />
<br/><br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
</div><br />
<br/><br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
</div><br />
<br/><br />
<br />
Enfin, on peut démonter la partition <br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
umount /mnt/container1<br />
</div><br />
<br/><br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
</div><br />
<br/><br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
</div><br />
<br/><br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add monpetitpont type bridge<br />
</div><br />
<br/><br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add vif1 type veth peer name eth0@vif1<br />
<br />
ip link add vif2 type veth peer name eth0@vif2<br />
<br />
ip link add vif3 type veth peer name eth0@vif3<br />
<br />
ip link add vif4 type veth peer name eth1@vif4<br />
</div><br />
<br/><br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 master monpetitpont<br />
<br />
ip link set vif2 master monpetitpont<br />
<br />
ip link set vif3 master monpetitpont<br />
<br />
ip link set vif4 master bridge<br />
</div><br />
<br/><br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 up<br />
<br />
ip link set vif2 up<br />
<br />
ip link set vif3 up<br />
<br />
ip link set vif4 up<br />
</div><br />
<br/><br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip a add dev monpetitpont 192.168.1.1/24<br />
<br />
ip link set monpetitpont down<br />
<br />
ip link set monpetitpont up<br />
</div><br />
<br/><br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
</div><br />
<br/><br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
</div><br />
<br/><br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ps aux | grep unshare<br />
</div><br />
<br/><br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 192.168.1.2/24 dev eth0<br />
<br />
ip addr add 192.168.1.3/24 dev eth0<br />
<br />
ip addr add 192.168.1.4/24 dev eth0<br />
</div><br />
<br/><br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0 up<br />
</div><br />
<br/><br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 172.26.145.150/24 dev eth1<br />
</div><br />
<br/><br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
<br />
Nous allons creer des noms de domaines sur GANDI. <br />
<br />
Tout d'abord nous créons une entrée de type "A" qui aura pour nom "durotduq.plil.space" et qui redirigera vers 172.26.145.150. Puis CNAME : "durotduq1" et "durotduq2".<br />
<br />
10h15 => Serveurs Web unshare OK<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
<VirtualHost *:80><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br />
<br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br />
<br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br />
<br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br />
<br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br />
</VirtualHost><br />
</div><br />
<br/><br />
<br />
Lancement d'un contenneur Docker à partir de l'image debian<br />
<br />
docker run -it debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy<br />
<br />
12h10 => Serveurs Web docker OK</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47803TP sysres IMA5sc 2018/2019 G32018-11-19T12:00:57Z<p>Adurot : </p>
<hr />
<div>=Première séance=<br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
</div><br />
<br/><br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkfs.ext4 /home/pifou/containers/container1<br />
</div><br />
<br/><br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkdir /mnt/container1<br />
<br />
mkdir /mnt/container2<br />
<br />
mkdir /mnt/container3<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
</div><br />
<br/><br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
</div><br />
<br/><br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
</div><br />
<br/><br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
</div><br />
<br/><br />
<br />
Enfin, on peut démonter la partition <br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
umount /mnt/container1<br />
</div><br />
<br/><br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
</div><br />
<br/><br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
</div><br />
<br/><br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add monpetitpont type bridge<br />
</div><br />
<br/><br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add vif1 type veth peer name eth0@vif1<br />
<br />
ip link add vif2 type veth peer name eth0@vif2<br />
<br />
ip link add vif3 type veth peer name eth0@vif3<br />
<br />
ip link add vif4 type veth peer name eth1@vif4<br />
</div><br />
<br/><br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 master monpetitpont<br />
<br />
ip link set vif2 master monpetitpont<br />
<br />
ip link set vif3 master monpetitpont<br />
<br />
ip link set vif4 master bridge<br />
</div><br />
<br/><br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 up<br />
<br />
ip link set vif2 up<br />
<br />
ip link set vif3 up<br />
<br />
ip link set vif4 up<br />
</div><br />
<br/><br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip a add dev monpetitpont 192.168.1.1/24<br />
<br />
ip link set monpetitpont down<br />
<br />
ip link set monpetitpont up<br />
</div><br />
<br/><br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
</div><br />
<br/><br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
</div><br />
<br/><br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ps aux | grep unshare<br />
</div><br />
<br/><br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 192.168.1.2/24 dev eth0<br />
<br />
ip addr add 192.168.1.3/24 dev eth0<br />
<br />
ip addr add 192.168.1.4/24 dev eth0<br />
</div><br />
<br/><br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0 up<br />
</div><br />
<br/><br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 172.26.145.150/24 dev eth1<br />
</div><br />
<br/><br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
<br />
Nous allons creer des noms de domaines sur GANDI. <br />
<br />
Tout d'abord nous créons une entrée de type "A" qui aura pour nom "durotduq.plil.space" et qui redirigera vers 172.26.145.150. Puis CNAME : "durotduq1" et "durotduq2".<br />
<br />
10h15 => Serveurs Web unshare OK<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
<VirtualHost *:80><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br />
<br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br />
<br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br />
<br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br />
<br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br />
</VirtualHost><br />
</div><br />
<br/><br />
<br />
Lancement d'un contenneur Docker à partir de l'image debian<br />
<br />
docker run -it debian /bin/bash<br />
<br />
Export du proxy<br />
<br />
export http_proxy</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47754TP sysres IMA5sc 2018/2019 G32018-11-19T10:53:47Z<p>Adurot : </p>
<hr />
<div>=Première séance=<br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
</div><br />
<br/><br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkfs.ext4 /home/pifou/containers/container1<br />
</div><br />
<br/><br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkdir /mnt/container1<br />
<br />
mkdir /mnt/container2<br />
<br />
mkdir /mnt/container3<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
</div><br />
<br/><br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
</div><br />
<br/><br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
</div><br />
<br/><br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
</div><br />
<br/><br />
<br />
Enfin, on peut démonter la partition <br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
umount /mnt/container1<br />
</div><br />
<br/><br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
</div><br />
<br/><br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
</div><br />
<br/><br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add monpetitpont type bridge<br />
</div><br />
<br/><br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add vif1 type veth peer name eth0@vif1<br />
<br />
ip link add vif2 type veth peer name eth0@vif2<br />
<br />
ip link add vif3 type veth peer name eth0@vif3<br />
<br />
ip link add vif4 type veth peer name eth1@vif4<br />
</div><br />
<br/><br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 master monpetitpont<br />
<br />
ip link set vif2 master monpetitpont<br />
<br />
ip link set vif3 master monpetitpont<br />
<br />
ip link set vif4 master bridge<br />
</div><br />
<br/><br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 up<br />
<br />
ip link set vif2 up<br />
<br />
ip link set vif3 up<br />
<br />
ip link set vif4 up<br />
</div><br />
<br/><br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip a add dev monpetitpont 192.168.1.1/24<br />
<br />
ip link set monpetitpont down<br />
<br />
ip link set monpetitpont up<br />
</div><br />
<br/><br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
</div><br />
<br/><br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
</div><br />
<br/><br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ps aux | grep unshare<br />
</div><br />
<br/><br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 192.168.1.2/24 dev eth0<br />
<br />
ip addr add 192.168.1.3/24 dev eth0<br />
<br />
ip addr add 192.168.1.4/24 dev eth0<br />
</div><br />
<br/><br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0 up<br />
</div><br />
<br/><br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 172.26.145.150/24 dev eth1<br />
</div><br />
<br/><br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
<br />
Nous allons creer des noms de domaines sur GANDI. <br />
<br />
Tout d'abord nous créons une entrée de type "A" qui aura pour nom "durotduq.plil.space" et qui redirigera vers 172.26.145.150. Puis CNAME : "durotduq1" et "durotduq2".<br />
<br />
10h15 => Serveurs Web unshare OK<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
<VirtualHost *:80><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br />
<br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br />
<br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br />
<br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br />
<br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br />
</VirtualHost><br />
</div><br />
<br/></div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47753TP sysres IMA5sc 2018/2019 G32018-11-19T10:53:06Z<p>Adurot : </p>
<hr />
<div>=Première séance=<br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
</div><br />
<br/><br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkfs.ext4 /home/pifou/containers/container1<br />
</div><br />
<br/><br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkdir /mnt/container1<br />
<br />
mkdir /mnt/container2<br />
<br />
mkdir /mnt/container3<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
</div><br />
<br/><br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
</div><br />
<br/><br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
</div><br />
<br/><br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
</div><br />
<br/><br />
<br />
Enfin, on peut démonter la partition <br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
umount /mnt/container1<br />
</div><br />
<br/><br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
</div><br />
<br/><br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
</div><br />
<br/><br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add monpetitpont type bridge<br />
</div><br />
<br/><br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add vif1 type veth peer name eth0@vif1<br />
<br />
ip link add vif2 type veth peer name eth0@vif2<br />
<br />
ip link add vif3 type veth peer name eth0@vif3<br />
<br />
ip link add vif4 type veth peer name eth1@vif4<br />
</div><br />
<br/><br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 master monpetitpont<br />
<br />
ip link set vif2 master monpetitpont<br />
<br />
ip link set vif3 master monpetitpont<br />
<br />
ip link set vif4 master bridge<br />
</div><br />
<br/><br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 up<br />
<br />
ip link set vif2 up<br />
<br />
ip link set vif3 up<br />
<br />
ip link set vif4 up<br />
</div><br />
<br/><br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip a add dev monpetitpont 192.168.1.1/24<br />
<br />
ip link set monpetitpont down<br />
<br />
ip link set monpetitpont up<br />
</div><br />
<br/><br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
</div><br />
<br/><br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
</div><br />
<br/><br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ps aux | grep unshare<br />
</div><br />
<br/><br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 192.168.1.2/24 dev eth0<br />
<br />
ip addr add 192.168.1.3/24 dev eth0<br />
<br />
ip addr add 192.168.1.4/24 dev eth0<br />
</div><br />
<br/><br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0 up<br />
</div><br />
<br/><br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 172.26.145.150/24 dev eth1<br />
</div><br />
<br/><br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
<br />
Nous allons creer des noms de domaines sur GANDI. <br />
<br />
Tout d'abord nous créons une entrée de type "A" qui aura pour nom "durotduq.plil.space" et qui redirigera vers 172.26.145.150. Puis CNAME : "durotduq1" et "durotduq2".<br />
<br />
10h15 => Serveurs Web unshare OK<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
<VirtualHost *:80><br />
ServerName durotduq1.plil.space<br />
ServerAdmin webmaster@localhost<br />
<br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br />
<br />
ProxyPass / http://192.168.1.101/<br />
ProxyPassReverse / http://192.168.1.101/<br />
ProxyRequests Off<br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br />
ServerName durotduq2.plil.space<br />
ServerAdmin webmaster@localhost<br />
<br />
ErrorLog ${APACHE_LOG_DIR}/error.log<br />
CustomLog ${APACHE_LOG_DIR}/access.log combined<br />
<br />
ProxyPass / http://192.168.1.102/<br />
ProxyPassReverse / http://192.168.1.102/<br />
ProxyRequests Off<br />
</VirtualHost><br />
<br />
</div><br />
<br/></div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47699TP sysres IMA5sc 2018/2019 G32018-11-19T10:16:10Z<p>Adurot : M</p>
<hr />
<div>=Première séance=<br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
</div><br />
<br/><br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkfs.ext4 /home/pifou/containers/container1<br />
</div><br />
<br/><br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkdir /mnt/container1<br />
<br />
mkdir /mnt/container2<br />
<br />
mkdir /mnt/container3<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
</div><br />
<br/><br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
</div><br />
<br/><br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
</div><br />
<br/><br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
</div><br />
<br/><br />
<br />
Enfin, on peut démonter la partition <br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
umount /mnt/container1<br />
</div><br />
<br/><br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
</div><br />
<br/><br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
</div><br />
<br/><br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add monpetitpont type bridge<br />
</div><br />
<br/><br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add vif1 type veth peer name eth0@vif1<br />
<br />
ip link add vif2 type veth peer name eth0@vif2<br />
<br />
ip link add vif3 type veth peer name eth0@vif3<br />
<br />
ip link add vif4 type veth peer name eth1@vif4<br />
</div><br />
<br/><br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 master monpetitpont<br />
<br />
ip link set vif2 master monpetitpont<br />
<br />
ip link set vif3 master monpetitpont<br />
<br />
ip link set vif4 master bridge<br />
</div><br />
<br/><br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 up<br />
<br />
ip link set vif2 up<br />
<br />
ip link set vif3 up<br />
<br />
ip link set vif4 up<br />
</div><br />
<br/><br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip a add dev monpetitpont 192.168.1.1/24<br />
<br />
ip link set monpetitpont down<br />
<br />
ip link set monpetitpont up<br />
</div><br />
<br/><br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
</div><br />
<br/><br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
</div><br />
<br/><br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ps aux | grep unshare<br />
</div><br />
<br/><br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 192.168.1.2/24 dev eth0<br />
<br />
ip addr add 192.168.1.3/24 dev eth0<br />
<br />
ip addr add 192.168.1.4/24 dev eth0<br />
</div><br />
<br/><br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0 up<br />
</div><br />
<br/><br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 172.26.145.150/24 dev eth1<br />
</div><br />
<br/><br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.<br />
<br />
<br />
Nous allons creer des noms de domaines sur GANDI. <br />
<br />
Tout d'abord nous créons une entrée de type "A" qui aura pour nom "durotduq.plil.space" et qui redirigera vers 172.26.145.150. Puis CNAME : "durotduq1" et "durotduq2".</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47653TP sysres IMA5sc 2018/2019 G32018-11-19T08:51:21Z<p>Adurot : /* Lancement et configuration réseau des 3 conteneurs */</p>
<hr />
<div>=Première séance=<br />
<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio dont tous les octets sont égales à 0.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
</div><br />
<br/><br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkfs.ext4 /home/pifou/containers/container1<br />
</div><br />
<br/><br />
<br />
==Montage du système de fichiers==<br />
<br />
On commence par créer les répertoires qui contiendront les ''rootfs'' montés. Dans un premier temps, on monte le système de fichiers précédemment créé dans /mnt/container1.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mkdir /mnt/container1<br />
<br />
mkdir /mnt/container2<br />
<br />
mkdir /mnt/container3<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
</div><br />
<br/><br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le miroir devuan extérieur à l'école.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
</div><br />
<br/><br />
<br />
Ensuite on utilise l'outil deboostrap dans /mnt/container1 pour créer un système Debian de base.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
</div><br />
<br/><br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montés.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
echo "proc /proc proc defaults 0 0" >> /mnt/container1/etc/fstab<br />
</div><br />
<br/><br />
<br />
Enfin, on peut démonter la partition <br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
umount /mnt/container1<br />
</div><br />
<br/><br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
</div><br />
<br/><br />
<br />
Ensuite on peut monter les trois systèmes de fichiers.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
mount -t ext4 -o loop /home/pifou/containers/container1 /mnt/container1<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container2 /mnt/container2<br />
<br />
mount -t ext4 -o loop /home/pifou/containers/container3 /mnt/container3<br />
</div><br />
<br/><br />
<br />
==Configuration des interfaces réseau==<br />
<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement ils seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. C'est pourquoi on va créer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s’agira de notre conteneur qui agira comme serveur mandataire inverse). On va donc créer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles vif1, vif2 et vif3 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add monpetitpont type bridge<br />
</div><br />
<br/><br />
<br />
===Création des 4 interfaces virtuelles===<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link add vif1 type veth peer name eth0@vif1<br />
<br />
ip link add vif2 type veth peer name eth0@vif2<br />
<br />
ip link add vif3 type veth peer name eth0@vif3<br />
<br />
ip link add vif4 type veth peer name eth1@vif4<br />
</div><br />
<br/><br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
<br />
vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 master monpetitpont<br />
<br />
ip link set vif2 master monpetitpont<br />
<br />
ip link set vif3 master monpetitpont<br />
<br />
ip link set vif4 master bridge<br />
</div><br />
<br/><br />
<br />
Il ne faut pas omettre d'activer les interfaces, sans quoi la communication serait impossible.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set vif1 up<br />
<br />
ip link set vif2 up<br />
<br />
ip link set vif3 up<br />
<br />
ip link set vif4 up<br />
</div><br />
<br/><br />
<br />
On pense à ajouter une adresse IP au commutateur virtuel, même si ce n'est pas obligatoire.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip a add dev monpetitpont 192.168.1.1/24<br />
<br />
ip link set monpetitpont down<br />
<br />
ip link set monpetitpont up<br />
</div><br />
<br/><br />
<br />
== Lancement et configuration réseau des 3 conteneurs ==<br />
<br />
=== Lancement des conteneurs ===<br />
<br />
Pour ce faire, on va utiliser l’utilitaire unshare permettant de lancer des programmes avec des espaces de noms différents de ceux du parent.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
unshare -n -u -p -f -m chroot /mnt/container1 /bin/sh -c "mount /proc ; /bin/bash"<br />
</div><br />
<br/><br />
<br />
On avait créé dans la partie précédente des paires d'interfaces virtuelles connectées entre elles. Les vif ont été reliés à monpetitpont, il faut maintenant connecter les autres parties aux conteneurs pour qu'ils puissent communiquer entre eux bien qu'ils aient des des espaces de noms différents. Tout ceci aura pour effet de faire apparaître une interface nommée eth0 pour chaque conteneur et une interface eth1 pour le dernier conteneur.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0@vif1 netns /proc/<PID_unshare_c1>/ns/net name eth0<br />
<br />
ip link set eth0@vif2 netns /proc/<PID_unshare_c2>/ns/net name eth0<br />
<br />
ip link set eth0@vif3 netns /proc/<PID_unshare_c3>/ns/net name eth0<br />
<br />
ip link set eth1@vif4 netns /proc/<PID_unshare_c3>/ns/net name eth1<br />
</div><br />
<br/><br />
<br />
Les différents PID sont récupérés simplement grâce à la commande suivante.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ps aux | grep unshare<br />
</div><br />
<br/><br />
<br />
On est maintenant en mesure d'attribuer des IPs pour nos conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 192.168.1.2/24 dev eth0<br />
<br />
ip addr add 192.168.1.3/24 dev eth0<br />
<br />
ip addr add 192.168.1.4/24 dev eth0<br />
</div><br />
<br/><br />
<br />
A nouveau, il est nécessaire d'activer les interfaces eth0 de nos 3 conteneurs.<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip link set eth0 up<br />
</div><br />
<br/><br />
<br />
Nous devons mettre une adresse ip à l'interface eth1 du container3 qui se trouve dans le bridge. Pour se faire, il faut trouver une adresse ip dans le réseau 172.26.145.0/24 (on ping pour voir si une adresse est libre)<br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
ip addr add 172.26.145.150/24 dev eth1<br />
</div><br />
<br/><br />
<br />
Nous sommes maintenant en mesure de ''pinger'' les conteneurs entre-eux mais également les machines de la salle avec le conteneur 3 et son interface eth1 dont l'autre morceau est connecté au bridge de la machine.</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47529TP sysres IMA5sc 2018/2019 G32018-11-13T10:06:36Z<p>Adurot : </p>
<hr />
<div>=Première séance=<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio.<br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
</div><br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
mkfs.ext4 /home/pifou/containers/container1<br />
</div><br />
<br />
==Montage du système de fichiers==<br />
<br />
On monte le système de fichier précédemment crée dans /mnt/container1<br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
mkdir /mnt/container1<br />
mkdir /mnt/container2<br />
mkdir /mnt/container3<br />
mount -t ext4 -o loop /mnt/container1<br />
</div><br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le mirroir devuan extérieur à l'école<br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
</div><br />
<br />
Puis on utilise deboostrap dans /mnt/container1<br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
debootstrap --include=vim,nano,apache2 stable /mnt/container1<br />
</div><br />
<br />
Puis on renseigne le fichier fstab de notre container1, il s'agit du fichier qui indique comment les systèmes de fichiers doivent être montées<br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab<br />
</div><br />
<br />
<br />
Enfin, on peut démonter la partition <br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
umount /tmp/fs1<br />
</div><br />
<br />
Une fois que nous avons déployé tout ce dont nous avons besoin au sein du container1 il ne reste plus qu'à dupliquer ce fichier deux fois, et on aura trois partitions utilisables pour nos conteneurs<br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
cp /home/pifou/containers/container1 /home/pifou/containers/container2<br />
cp /home/pifou/containers/container1 /home/pifou/containers/container3<br />
</div><br />
<br />
Ensuite on peut monter les trois systèmes de fichiers :<br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
mount -t ext4 -o loop /mnt/container1<br />
mount -t ext4 -o loop /mnt/container2<br />
mount -t ext4 -o loop /mnt/container3<br />
</div><br />
<br />
==Configuration des interfaces réseau==<br />
Pour l'instant, on a tout ce qu'il faut pour lancer les conteneurs, seulement il seraient bien inutiles s'ils ne pouvaient aucunement communiquer entre eux ou avec le système hôte. Ainsi on va creer dans le système hôte 4 interfaces virtuelles pour les 3 conteneurs (un conteneur aura deux interfaces virtuelles dont l'une sera dans le bridge donnant accès à internet, il s'agirat de notre conteneur mandataire inverse). On va donc creer un commutateur virtuel dans lequel on mettra les trois interfaces virtuelles eth0 de nos trois conteneurs.<br />
<br />
===Création du bridge===<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
ip link add monpetitpont type bridge<br />
</div><br />
<br />
===Création des 4 interfaces virtuelles===<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
ip link add vif1 type veth peer name eth0@vif1<br />
ip link add vif2 type veth peer name eth0@vif2<br />
ip link add vif3 type veth peer name eth0@vif3<br />
ip link add vif4 type veth peer name eth1@vif4<br />
</div><br />
<br />
===Connexion des interfaces virtuelles aux commutateurs virtuels===<br />
Vif1 vif2 et vif3 sont mises dans monpetitpont, tandis que vif4 est mise dans bridge<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
ip link set vif1 master monpetitpont<br />
ip link set vif2 master monpetitpont<br />
ip link set vif3 master monpetitpont<br />
ip link set vif4 master bridge<br />
</div><br />
<br />
Il ne faut pas ommettre d'activer les interfaces, sans quoi la communication sera impossible<br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
ip link set vif1 up<br />
ip link set vif2 up<br />
ip link set vif3 up<br />
ip link set vif4 up<br />
</div><br />
<br />
On pense à ajouter une adresse ip au commutateur virtuel, même si ce n'est pas obligatoire :<br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
ip a add dev monpetitpont 192.168.1.1/24<br />
ip link set monpetitpont down<br />
ip link set monpetitpont up<br />
</div></div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47528TP sysres IMA5sc 2018/2019 G32018-11-12T14:54:59Z<p>Adurot : /* Première séance */</p>
<hr />
<div>=Première séance=<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio.<br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
dd if=/dev/zero of=/home/pifou/containers/container1 bs=1024k count=10240<br />
</div><br />
<br />
==Création du système de fichiers==<br />
<br />
On associe un système de fichiers de type ext4 à notre fichier.<br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
mkfs.ext4 /home/pifou/containers/container1<br />
</div><br />
<br />
==Montage du système de fichiers==<br />
<br />
On monte le système de fichier précédemment crée dans /mnt/container1<br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
mkdir /mnt/container1<br />
mount -t ext4 -o loop /mnt/container1<br />
</div><br />
<br />
==Déploiement de l'arborescence Debian==<br />
<br />
Avant tout, on renseigne le proxy de l'école dans la variable d’environnement correspondante afin qu'on puisse télécharger les paquetages sur le mirroir devuan extérieur à l'école<br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
</div><br />
<br />
Puis on utilise deboostrap dans /mnt/container1<br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
export http_proxy=https://proxy.polytech-lille.fr:3128<br />
</div></div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47526TP sysres IMA5sc 2018/2019 G32018-11-12T14:40:48Z<p>Adurot : /* Création des fichiers disque des conteneurs */</p>
<hr />
<div>=Première séance=<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio, <br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Inconsolata"><br />
dd if=/dev/zero of=~/containers/container1 bs=1024k count=10240<br />
</div></div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47525TP sysres IMA5sc 2018/2019 G32018-11-12T14:40:19Z<p>Adurot : /* Création des fichiers disque des conteneurs */</p>
<hr />
<div>=Première séance=<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio, <br />
<br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Roboto"><br />
dd if=/dev/zero of=~/containers/container1 bs=1024k count=10240<br />
</div></div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47524TP sysres IMA5sc 2018/2019 G32018-11-12T14:39:27Z<p>Adurot : /* Création des fichiers disque des conteneurs */</p>
<hr />
<div>=Première séance=<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio, <br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Roboto"><br />
<br />
dd if=/dev/zero of=~/containers/container1 bs=1024k count=10240<br />
</div><br />
<br/></div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47523TP sysres IMA5sc 2018/2019 G32018-11-12T14:39:10Z<p>Adurot : /* Création des fichiers disque des conteneurs */</p>
<hr />
<div>=Première séance=<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio, <br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Arial"><br />
<br />
dd if=/dev/zero of=~/containers/container1 bs=1024k count=10240<br />
</div><br />
<br/></div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47522TP sysres IMA5sc 2018/2019 G32018-11-12T14:38:42Z<p>Adurot : /* Création des fichiers disque des conteneurs */</p>
<hr />
<div>=Première séance=<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio, <br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Roboto"><br />
<br />
dd if=/dev/zero of=~/containers/container1 bs=1024k count=10240<br />
</div><br />
<br/></div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G3&diff=47521TP sysres IMA5sc 2018/2019 G32018-11-12T14:37:46Z<p>Adurot : Page créée avec « =Première séance= ==Création des fichiers disque des conteneurs== On crée un fichier de 10 Gio = 10 240 * 1 Mio, <br/> <div style="padding:15px;color:#ffffff;backgr... »</p>
<hr />
<div>=Première séance=<br />
==Création des fichiers disque des conteneurs==<br />
<br />
On crée un fichier de 10 Gio = 10 240 * 1 Mio, <br />
<br />
<br/><br />
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas"><br />
dd if=/dev/zero of=~/containers/container1 bs=1024k count=10240<br />
</div><br />
<br/></div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019&diff=47520TP sysres IMA5sc 2018/20192018-11-12T14:11:03Z<p>Adurot : </p>
<hr />
<div>== Répartition des binômes ==<br />
<br />
{| class="wikitable"<br />
! Cahier !! Elèves <br />
|-<br />
| [[ TP sysres IMA5sc 2018/2019 G1 | Cahier groupe n°1]]<br />
| Taky Djeraba & Baptiste Cartier<br />
|-<br />
| [[ TP sysres IMA5sc 2018/2019 G2 | Cahier groupe n°2]]<br />
| Jade Dupont & Quentin Boëns<br />
|-<br />
| [[ TP sysres IMA5sc 2018/2019 G3 | Cahier groupe n°3]]<br />
| Antoine Duquenoy & Anthony Durot<br />
|-<br />
| [[ TP sysres IMA5sc 2018/2019 G4 | Cahier groupe n°4]]<br />
| Paul Ribeiro & Antoine Untereiner<br />
|-<br />
| [[ TP sysres IMA5sc 2018/2019 G5 | Cahier groupe n°5]]<br />
| Delobelle Matthieu & Yang Ji<br />
|-<br />
| [[ TP sysres IMA5sc 2018/2019 G6 | Cahier groupe n°6]]<br />
| Simon Feutrier & Antoine Gosse<br />
|-<br />
| [[ TP sysres IMA5sc 2018/2019 G7 | Cahier groupe n°7]]<br />
| Naif Mehanna & Maxime Créteur<br />
|-<br />
| [[ TP sysres IMA5sc 2018/2019 G8 | Cahier groupe n°8]]<br />
| Justine Senellart & Rodolphe Toin<br />
|-<br />
| [[ TP sysres IMA5sc 2018/2019 G9 | Cahier groupe n°9]]<br />
| Prénom Nom & Prénom Nom<br />
|-<br />
| [[ TP sysres IMA5sc 2018/2019 G10 | Cahier groupe n°10]]<br />
| Prénom Nom & Prénom Nom<br />
|-<br />
| [[ TP sysres IMA5sc 2018/2019 G11 | Cahier groupe n°11]]<br />
| Prénom Nom & Prénom Nom<br />
|-<br />
| [[ TP sysres IMA5sc 2018/2019 G12 | Cahier groupe n°12]]<br />
| Benjamin Canu & Amaury Carval<br />
|-<br />
| [[ TP sysres IMA5sc 2018/2019 G13 | Cahier groupe n°13]]<br />
| Prénom Nom & Prénom Nom<br />
|-<br />
|}</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=Projet_IMA3_P3,_2016/2017,_TD1&diff=44312Projet IMA3 P3, 2016/2017, TD12017-06-18T20:34:48Z<p>Adurot : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 25px; padding: 20px; font-weight: bold; text-align: center; font-size: 98%; background: #6060FF; vertical-align: top; width: 99%;"> Projet IMA3-SC 2016/2017 : Le Jeu de Simon et le Guitar Hero </div>=<br />
<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Cahier des Charges </div>==<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Description du système </div>===<br />
<br />
* L'objectif principal de notre projet est de réaliser un jeu qui utilise à la fois les lumières et le son. Pour cela, nous avons pensé à deux versions : le Simon et un jeu du type Guitar Hero.<br />
<br />
* Le Simon est constitué de quatre boutons de couleurs différentes : un bleu, un rouge, un vert et un jaune. Le jeu va afficher une séquence de couleurs qui sont chacune associées à un son. Le joueur doit ensuite se souvenir de la suite (en s'aidant du son et des couleurs comme moyen mnémotechnique) pour la reproduire dans le bon ordre en appuyant sur les boutons.<br />
<br />
* Le jeu Guitar Hero, quant à lui, est un jeu où il faut actionner des boutons de couleur précise, au moment où elles apparaissent sur une barre de défilement, à l'écran. Ces différentes activations, aux bons moments, permettent de réaliser une mélodie plus ou moins complexe selon la difficulté de la chanson à reproduire. Le tout est effectué grâce à une guitare connectée, afin de pousser l'expérience de simulation un peu plus loin. Si nous réalisons, ce jeu, il faut prendre en compte un affichage plus complexe. De plus, le Guitar Hero ajoute une notion de temps de réponse, plus difficile à gérer. Ce temps de réponse permet de laisser une courte marge d'erreur dans la réactivité de l'utilisateur, pour simuler pleinement l'utilisation d'une guitare électrique.<br />
<br />
<br />
Nous avons choisis de d'abord nous concentrer sur le Simon et de faire le jeu Guitar Hero seulement si nous avons le temps.<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Le matériel </div>===<br />
<br />
Pour ce projet nous utiliserons :<br />
<br />
* Une page internet sur l'ordinateur pour pouvoir modifier les différents aspects du jeu : les règles du jeu, la musique jouée par le Simon ou bien la difficulté<br />
<br />
* Le Raspberry Pi, utilisée en tant que serveur, va envoyer les données en série ( qui seront traitées par le FPGA ), de les recupérer, et de faire l'algorithme.<br />
<br />
* Une carte Arduino pour relier la Raspberry Pi aux composants dans un premier temps : elle nous permet de coder en C (au lieu d'un langage assembleur) pour créer des programmes et gérer les différents modules tel que les boutons et les LEDs. Elle permettra une simulation momentanée du FPGA, afin que nous puissions avancer sur la partie informatique, sans attendre d'en avoir fini avec la partie FPGA.<br />
<br />
* Une fois le programme et les interactions fonctionnels, nous remplacerons l'Arduino par une FPGA qui est circuit logique programmable : on peut modifier les circuits logiques à l'intérieur mais on ne peut pas créer un programme avec un langage de plus haut niveau. Nous devrons donc utiliser des logiciels tiers qui nous permettront de placer des portes logiques (ET, OU,...) pour créer notre programme en assembleur.<br />
<br />
* Pour ce qui est de la partie mécanique, nous réaliserons une guitare en bois pour le "Guitar Hero" ainsi qu'un "jeu de Simon" réalisé via l'impression 3D.<br />
<br />
* Si le temps nous le permet, nous utiliserons un Xbee pour créer une connexion sans fil, afin d'expérimenter un module nouveau et acquérir de nouvelles compétences.<br />
<br />
*Nous utiliserons également des composants électroniques tels que des boutons poussoirs, des LEDs ou une matrice de LEDs pour l'affichage dans le cas du jeu de Simon, ainsi que de "l'essentiel" pour un système communiquant (à savoir résistances, fils électriques, etc...)<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Description des séances </div>==<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 21/03/17 Séance 1 : Répartition des tâches et premiers pas </div>===<br />
<br />
La première séance fut consacrée à la répartition des rôles et à la prise de conscience de la difficulté des différentes tâches. L'idée de faire un " jeu de Simon " que nous améliorerons ensuite en " guitar hero " a cependant été conservée.<br />
<br />
==== Partie électronique ====<br />
<br />
Nous avons décidé de concentrer deux personnes sur le FPGA car c'est un élément très complexe et complètement nouveau.<br />
Nous allons en effet devoir réfléchir à très bas niveau avec simplement des registres et des portes logiques.<br />
<br />
L'objectif du composant sera de récupérer un message contenant les boutons sur lesquelles appuyer. <br />
Une fois ce message reçu, le FPGA va comparer le bouton saisi par l'utilisateur avec le bouton demander. <br />
S'il est correct, le FPGA va passer à la couleur suivante, sinon il va renvoyer un message pour dire à la Raspberry (ou l'ordinateur) que l'utilisateur s'est trompé.<br />
<br />
Pour commencer, nous réalisons le tutoriel pour allumer une LED qui va nous permettre de comprendre le fonctionnement de Altium Designer.<br />
Cela nous a pris du temps mais nous avons pu réaliser d'autres essaies avec des registres à décalages et des boutons.<br />
<br />
Nous avons ensuite directement commencer le Simon :<br />
Le choix a été fait d'utiliser des registres à décalages pour récupérer la séquence de couleur envoyé par l'ordinateur/la raspberry. <br />
Nous allons en effet stocker toute la séquence de la "partie" car sinon il faudrait gérer beaucoup d'échange entre l'ordinateur et le FPGA ce qui est lourd en Altium et fait perdre du temps réaction du programme.<br />
<br />
D'un point de vue technique, utiliser un registre à décalage semble être la meilleur méthode pour récupérer un à un les bits qui arrivent sur la liaison série puis nous utilisons 4 registres à décalage : 1 pour chaque couleur.<br />
Pour chacun des registres nous aurons donc une séquence comme suit : 0100010010111. Les 1 correspondent aux moments ou il faut appuyer sur la couleur et les 0 aux moments ou il ne faut pas appuyer sur cette couleur. <br />
Nous devons donc également gérer les clocks des registres "couleurs". Ces registres doivent arrêter leur clock lorsque les bits de chaque couleur est à 0.<br />
<br />
Le registre pour la liaison série sera la clock du système puisqu'elle doit lire toute la séquence mais elle doit également s'arrêter lorsque le FPGA arrive à la fin de la séquence. Pour lui indiquer la fin de la séquence nous avons choisit le mot 0000 car il y aura toujours un bouton à appuyer pour le jeu Simon.<br />
<br />
==== Partie informatique ====<br />
<br />
L'objectif ici était la découverte des technologies à utiliser pour le système. Notamment une Arduino en liaison série à un PC et un serveur Websockets codé en C.<br />
La partie programmation arduino ne fut pas un problème. En effet, ce n'était pas la première fois que nous utilisions cet outil, et donc la mise en place de la liaison série fut très rapide.<br />
Ce n'est cependant pas le cas de la communication websockets. Bien que l'exemple de code fourni par M. Redon soit fonctionnel, le code n'en reste pas moins complexe à comprendre. Il fallait donc réussir à modifier le code du serveur websockets, afin de relier les deux systèmes entre eux.<br />
<br />
==== Partie mécanique : un modèle de guitare à découper====<br />
<br />
<br />
Dans cette première séance, nous avons décidé de focaliser nos premiers efforts sur la partie mécanique du "guitar hero". En effet, le " jeu de simon " pouvait être avancé plus tard car plus facile à modéliser et à réaliser.[[Fichier:1.jpg||right|vignette|upright=2|]]<br />
Nous sommes alors partis sur l'idée de créer une maquette de guitare, sur laquelle nous allions disposer différents boutons de couleur, actionnables grâce à une pression sur le manche de l'instrument. Nous avions une ligne directrice mais pas encore d'idée précise de comment allait être réalisé la guitare, ni même ce à quoi elle allait ressembler.<br />
<br />
<br />
Nous avons décidé de découper la guitare en bois qui nous servirait de support pour notre " guitar hero " grâce à la découpeuse laser. Pour se faire, un fichier conforme à la découpe devait être réalisé. <br />
Ainsi nous avons donc pris une image de guitare depuis internet. Dans le logiciel " GIMP ", nous avons ensuite repassé les contours de l'instrument en rouge. Une fois ceci fait, nous avons effacé l'image de la guitare originale pour ne garder que les contours rouges. Enfin après quelques réglages, l'export en fichier SVG permettait une découpe précise. Les contours de la guitare sont disponibles ci contre (cliquez sur l'image pour bien voir).<br />
<br />
A la fin de la séance, la guitare était prête à être réalisée et nous avons décidé de faire l'intégralité du " jeu de simon " via l'impression 3D. Cependant, aucune grande avancée n'a eu lieu sur la partie mécanique du jeu de Simon lors de cette séance.<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 28/03/17 Séance 2 : Poursuite du Projet et rencontre des premiers problèmes </div>===<br />
<br />
La deuxième séance fut davantage productive, car chacun de nous savait les différentes tâches qu'il lui restait à accomplir.<br />
<br />
==== Partie électronique ====<br />
Nous nous sommes rendu compte qu'utiliser le registre à décalage pour la liaison série comme nous le faisions n'était pas possible.<br />
En effet, la liaison série est en asynchrone et nous ne connaissance donc pas la clock. <br />
Nous ne pouvons donc pas utiliser cette clock pour le registre à décalage car sinon nous risquons de ne pas lire assez vite (ou trop vite) et donc récupérer trop de valeurs ou en rater.<br />
<br />
Le professeur nous a donc indiqué qu'il nous mettrait à disposition un module qui va s'occuper justement de lire la liaison série et de garder la séquence et de ressortir le message en parallèle.<br />
Ce composant envoie également sur un autre pin un 1 à chaque fois qu'un bit est envoyé par la liaison série (et reçu par le composant).<br />
Nous utilisons, selon ses conseils, un module analogique-digital qui va nous permettre de simuler l'envoi de la séquence.<br />
Après plusieurs tentatives nous avons un programme qui fonctionne correctement pour recevoir les valeurs. Il nous reste à comparer l'appui d'un bouton et la couleur à presser.<br />
<br />
==== Partie informatique ====<br />
<br />
L'écriture du programme de communication fut terminé assez rapidement. Mais il ne fonctionnait pas...<br />
En effet, un problème s'opérait lors de l'appel de la liaison série par le serveur websocket à réception d'un message.<br />
<br />
L'incompréhension régnait un peu, car à nos yeux tout était sensé fonctionner. Le principe était assez simple : à réception d'un message par le serveur websockets, ce dernier devait ouvrir une communication série sur le port TTY_USB0 (ou TTY_ACM0 en fonction de l'arduino) à 9600 bauds, y transférer le message reçu, puis refermer la communication.<br />
<br />
Après un long moment de doute, le problème fut résolu. Ce dernier était assez idiot. En effet, notre fonction d'envoi de message via le port série s'appelait : " send(..) ". Il s'avère qu'une fonction d'une des librairies utilisées se nomme de la même manière. Il y avait donc conflit et empêchait le programme de fonctionner correctement.<br />
<br />
Nous avons donc pu relier l'ordinateur à un montage de prototypage Arduino/LEDs afin de tester le bon fonctionnement du programme. Une combinaison de 4 LED devait s'allumer à réception d'un caractère. Il fallait donc envoyé un message compris entre 0(aucune LED allumée) et 15(toutes les LED allumées). Cependant, le début de la table ASCII ne représente pas des caractères. Le serveur envoie donc un message alphabétique compris entre 65 ('A') et 80 ('P') et l'arduino interprète ceci comme une valeur de 0 a 15<br />
<br />
==== Partie mécanique : découpe de la guitare, modélisation et impression d'un prototype de touches pour cette dernière ====<br />
<br />
[[Fichier:pp.jpg||left|vignette|upright=0.8|]]Cette séance fut entamée par la découpe de la guitare grâce à la découpeuse laser du Fabricarium de Polytech. Dans un premier temps il a d'abord était nécessaire " d'apprivoiser " la découpeuse et d'apprendre à bien la configurer pour obtenir le résultat souhaité, sans risques. Un premier essai a d'abord était réalisé dans du carton pour pouvoir juger des différentes dimensions de la guitare.<br />
Enfin, une seconde version, en bois, fut réalisée durant cette séance. Finalement nous décidons de partir sur l'idée d'une guitare réalisée en 4 couches d'épaisseur : 2 extérieures en bois ( une de face, décorée avec les boutons à actionner et la carte arduino et une seconde, arrière, de protection), et deux intérieures en carton(creusées pour laisser passer les fils de connectiques).<br />
<br />
Note : Malheureusement, une des couche en bois a était cassée par la suite lors de la confection de la guitare. La panne prolongée de la découpeuse laser nous a contraint à renoncer à l'idée d'une quatrième couche en bois de protection.[[Fichier:po.jpg||right|vignette|upright=1.2|]]<br />
<br />
<br />
De plus, via le logiciel de modélisation FreeCAD, nous avons commencé à concevoir deux prototypes de " touches " (boutons) pour la guitare. <br />
<br />
L'idée était de créer des surfaces larges (pouvant recueillir une phalange de doigts au minimum) faisant office de touches, en dessous desquelles nous insérerions un bouton poussoir 4 pins (fournis par les professeurs). La création de touches plus larges était indispensable. En effet, les boutons poussoirs étaient bien trop petits pour avoir un actionnement facile et agréable.<br />
Nous avons pu lancer l'impression des touches à la fin de la séance. Cependant, les différents tests et les défauts d'impression nous ont fait comprendre qu'il serait difficile de " glisser " un bouton poussoir dans une touche avec un espace assez étroit pour le maintenir, sans pour autant bloquer son actionnement lorsqu'une pression était appliquée. De plus, la fixation risquait d'être assez complexe. <br />
Nous avons alors décidé de faire un tout autre type de touche mais avec le même fonctionnement. Pour cela nous allions avoir besoin de modéliser et d'imprimer de nouveaux un prototype de touche.<br />
Il allait ensuite falloir percer la première couche en bois de la guitare. Puis il serait également nécessaire de creuser les sous couches en carton pour y placer les boutons poussoirs et les différents câbles.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 05/04/2017 Séance 3 : Encore beaucoup de choses à faire !</div>===<br />
<br />
Bien que ce soit notre dernière séance officielle, nous savions que nous allions avoir besoin de beaucoup de temps pour terminer ce projet ! <br />
<br />
==== Partie électronique ====<br />
[[Fichier:fpga.png|||vignette|upright=2|]]<br />
Le but de cette séance était de finaliser le FPGA et d'ajouter les blocs reception.vhdl et emission.vhdl fournis par M. Boé, ils nous permettent de gerer facilement la conversion serie / parallèle en asynchrone. Ainsi nous pouvons tester notre FPGA et nous rendre compte que ça ne marche pas, il y a un problème que nous n'arrivons pas à résoudre.<br />
Compte tenu du temps imparti, et du fait que la nanoboard n'était pas "embarquable", nous avons décidé de nous concentrer sur l'arduino afin d'avoir quelque chose qui fonctionne.<br />
<br />
==== Partie informatique ====<br />
<br />
<br />
L'objectif de la séance était la mise en place de l'interface WEB, notamment pour le jeu Guitar Hero. <br />
<br />
Nous avons utilisé un canvas Javascript afin de dessiner un interface similaire a celle du jeu original.<br />
<br />
==== Partie mécanique ====<br />
<br />
La troisième séance était destinée à l’élaboration du jeu de Simon. Une première idée était de créer quatre pièces plates, composées de multiples leds, qu'il faudrait actionner via une simple pression. Cependant, nous nous sommes dit qu'une seule LED pour une couleur, suffisait à indiquer la combinaison à reproduire. <br />
<br />
Le tout devait être assez grand pour contenir la carte arduino ainsi que toute la connectique, sans pour autant être trop encombrant, tout en étant assez ergonomique et agréable au regard.<br />
<br />
Nous avons donc décidé de créer un support creux qui contiendrait la partie électronique , au dessus duquel nous placerions les 4 pièces de couleur avec une LED pour chaque couleur.<br />
<br />
Nous savions dès lors, qu'un travail long minutieux nous attendait.<br />
<br />
Ainsi nous avons fait de nombreux croquis avec les différentes pièces et leurs dimensions éventuelles. Des pièces que nous allions réaliser uniquement en impression 3D. Un travail similaire a été réalisé pour la guitare, afin de ne pas percer la guitare à de mauvais endroits, et pour agencé les différents parties à ajouter sur la guitare de la meilleure façon possible. Pour résumer cette séance, nous avons réalisé tous les croquis nécessaires à la réalisation de la guitare et du Simon.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Séance supplémentaire : Terminons ce Projet !</div>===<br />
<br />
Il n'y a pas eu un nombre précis de "séances supplémentaires". Chacun des membres du groupe travaillait soit chez lui, soit à l'école de manière régulière, afin d'avancer sa partie le plus rapidement possible.<br />
<br />
==== Partie électronique ====<br />
[[Fichier:pcb1.jpg|left|vignette|upright=0.8|]]<br />
[[Fichier:pcb2.jpg|right|vignette|upright=0.8|]]<br />
Pour le Simon, il a fallut souder les câbles aux boutons et aux leds ( avec leur résistance ). Pour se faire, on a utilisé un circuit à pastilles qui se place entre l'arduino et les boutons/led. Cela permet de prendre moins de place et de faire plus propre qu'une breadboard.<br />
<br />
=== Partie informatique ===<br />
<br />
La partie FPGA n'étant pas fonctionelle, il a fallut le remplacer par un Arduino. <br />
<br />
Le code de l'Arduino consiste en une succession d'étapes pour jouer. Tout d'abord il faut recevoir via le port série la séquence totale du Simon, sous la forme de chaîne de caractères. Par exemple si le message reçu est "RVBR", alors la séquence totale du Simon sera Rouge Vert Bleu Rouge. Ainsi une fonction reception_message a été codée, qui attend la réception série de la séquence. <br />
<br />
Dans l'algorithme du jeu en lui même on a une variable globale qui stocke l'état de la partie, et une qui stocke l'étape de la séquence. Ainsi en fonction de l'état de la partie on va soit jouer la séquence sur les leds, lire l'état des boutons, ou provoquer un game over.<br />
<br />
La fonction playSequence va parcourir la séquence totale jusqu'à l'étape actuelle et va allumer les différentes leds en conséquence.<br />
<br />
La fonction readSequence va elle lire l'état successif des boutons et le comparer à la séquence actuelle. Si il y a une erreur, on sort de la fonction, et l'état de la partie devient un game over. Sinon, on continue et on appelle playSequence en incrémentant l'étape. En cas de réussite de la séquence, les 4 leds s'allument pour indiquer lé réussite et le passage au niveau supérieur.<br />
<br />
Coté websockets, c'est facile, dès qu'on reçoit un message par le client, on l'envoie à l'arduino ( bien qu'on aurait du vérifier la conformité du message ), l'arduino ne lira le message que si on est en étape de lecture de la séquence, donc après un game over par exemple. <br />
<br />
==== Partie mécanique : Suite et fin de la confection de la guitare et du jeu de Simon====<br />
<br />
Comme nous l'avons prédit, la plus grosse partie du travail réalisé a dû être faite lors de séances supplémentaires ou par travail personnel chez soi.<br />
<br />
Après avoir réalisé les croquis, il était essentiel de créer rapidement les différents supports. En effet, cela nous permettait d'avoir du temps pour éventuellement recommencer et revoir les axes de travail en cas d'impossibilité de réalisation pour quelconque raison. De plus, une fois la partie mécanique terminée, nous pouvions l'utiliser comme support pour les tests électroniques. Enfin, cela nous laissait du temps en fin de projet pour décorer notre projet, que nous voulions personnalisé afin d'en être le plus satisfaits possible. <br />
<br />
Un gros travail de modélisation à dû être fait sur FREECAD. Le support du jeu de Simon fut la pièce la plus simple à réaliser (un cylindre semi fermé, de 7 cm de rayon).<br />
<br />
Puis une simple découpe grâce à une scie permettrait de faire réceptacle pour une "croix porteuse" sur laquelle serait disposés les touches du Simon.<br />
<br />
De la même façon que pour la guitare, les touches seraient placées au dessus de boutons poussoirs. Ces derniers seront collés sur la croix. <br />
[[Fichier:tg.jpg||right|vignette|upright=1.5|]]<br />
Une fois ceci fait, il fallait réaliser le plus important du jeu : les touches à actionner ! <br />
<br />
Pour cela, il était préférable de conserver la forme cylindrique du support en modélisant 4 pièces, d'un quart de disque chacune. Par soucis de fixation sur la croix et par envie d’esthétisme, les touches seraient un peu incurvées pour donner une forme moins géométrique au rendu final. <br />
<br />
De plus, elles seront perforées pour laisser passer une LED de la même couleur que la touche sur laquelle elle se trouve. Ainsi l'utilisateur pourra mémoriser les touches à activer via le système lumineux des LEDs. <br />
<br />
Enfin, un cylindre permettant l'accroche sur la croix à été prévu sur la partie inférieure de les touches du Simon. (suite à une impression peu précise, ce cylindre sera " fondu " pour épouser la forme de la croix sans jeu dans la fixation.)<br />
<br />
[[Fichier:touc2.jpg||left|vignette|upright=1.7|]]<br />
Vint ensuite le moment de la création ! L'impression de ces pièces étant la plus complexe, nous pensions qu'il serait nécessaire de les recommencer plusieurs fois. La WitBox du Fabricarium (la plus précise des imprimantes mise à notre disposition) a réalisé une impression assez laborieuse. Un gros travail de ponçage à donc dû être réalisé, car le support nécessaire pour imprimer cette pièce " incurvée " avait donné de nombreuses bavures sur la surface des touches. Afin que le toucher reste agréable, nous avons donc retravaillé les pièces.<br />
<br />
<br />
Une fois ceci fait, nous avons essayé de les positionner sur la croix prévue à cet effet. Une fois encore, nous étions confronté aux limites de l'impression 3D. Les dimensions du " cylindre pillier " étant non précise, et cette partie étant trop fine pour être sciée sans rupture de la pièce, nous avons décidé de faire " fondre " cette partie et de la placer, encore chaude sur la partie en forme de croix. Cela permettait une fixation sûre et une dimension épousant parfaitement les formes du support. L'inconvénient fut que cette méthode, peu précise, n'a fait qu'accentuer les erreurs d'impressions au niveaux du visuel. Effectivement, les 4 pièces ne semblent pas régulières et le disque qu'elles sont censées former (ensemble de 4 quarts de disque) ne semble pas parfait.[[Fichier:bttt.jpg||right|vignette|upright=1.5|]][[Fichier:socle.jpg||right|vignette|upright=1.5|]]<br />
<br />
<br />
Nous décidons cependant de conserver ce léger défaut, car si nous recommencions nous risquerions d'être de nouveau confronté au même souci, l'erreur n'étant pas uniquement dû à notre manipulation mais également à l'imprimante 3D. <br />
<br />
<br />
L'impression du socle était la plus longue à imprimer (près de 6 heures) .Après l'avoir un peu scié comme prévu, cette pièce était également prête à être peinte. Nous avons fait de même avec la croix à placer sur le socle et servant de support aux quatre touches du Simon. Cette impression étant rapide et facile, un seul essai suffit pour obtenir notre version définitive. L'impression fut dans ce cas, parfaitement aux mesures souhaitées dans le fichier .stl (bien que réalisé avec une imprimante de moins bonne qualité que la WitBox). Ainsi les boutons poussoirs que nous avions à positionner dessus tenaient sans souci par un simple encastrement. Par la suite, par mesure de sécurité, <br />
nous avons tout de même rajouté un point de colle en dessous des boutons pour éviter tout désencastrement non souhaité. <br />
[[Fichier:tr.jpg||left|vignette|upright=1.4|]]<br />
<br />
<br />
<br />
En parallèle, nous avons travaillé sur les différentes couches d'épaisseur de la guitare. Dans un premier temps il était nécessaire de retirer une partie dans le manche pour y placer les boutons poussoirs. Cette étape aurait pu être réalisé rapidement avec la découpeuse laser, mais celle ci étant en panne, nous l'avons fait via une perceuse et un foret au Fabricarium. Le résultat était un peu moins net mais convenable cependant. De plus le "trou" sera caché par la pièce contenant les touches. Une fois la couche de bois travaillée, nous avons creusé la partie cartonnée afin de pouvoir y laisser passer les différents câbles liant les boutons poussoirs (situés sous les touches du manche de la guitare) à une breadboard (sur la partie basse de l'instrument).<br />
<br />
Afin que les câbles sortent de la guitare de façon propre, nous avons percé 4 trous à la base du manche. Ainsi de chaque trou ressortira deux fils de connectique ( un pour l'entrée du bouton poussoir et un pour la sortie).<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:tt.jpg||left|vignette|upright=2|]]<br />
Ceci étant terminé, il fallait passer à la conception des touches de la guitare.[[Fichier:touc.jpg||right|vignette|upright=2.2|]]<br />
C'est en observant une imprimante 3D du Fabricarium qu'une idée de modèle touche vue le jour. Nous allions faire une seule et unique pièces pour les 4 touches.<br />
Fine, elle pourrait être facilement pliée sous une pression du doigts pour actionner un bouton poussoir situé en dessous de chacune des 4 touches.suffirait juste de peindre les 4 touches de couleurs différentes pour les différencier.<br />
Cette pièce serait fixée sur le manche de la guitare, couvrant une couche de bois perforée et une cartonnée " creusée " pour laisser passer la connectique jusqu'à la partie inférieure de la guitare.<br />
<br />
Finalement, il aura fallut quelques heures supplémentaires des séances pour avoir toutes nos partie modéliser sur FREECAD et prête à être imprimées, qu'elles soient destinées au Simon ou au Guitar Hero.<br />
<br />
L'heure est donc à la réalisation ! Les impressions 3D se sont faites sur l'imprimante d'un des membre du groupe ainsi que sur celles du Fabricarium. <br />
<br />
Les touches qui actionneraient les boutons poussoirs étaient les plus à même d'être à recommencer. En effet, un problème de fixation, ou encore une rigidité trop grande empêcherait l'actionnement du bouton et serait donc inutilisable. Ainsi nous avons commencé par imprimer les touches (pour la guitare et pour le simon). Dans un premier temps, nous nous sommes occupés de la pièce pour la guitare. La première impression fut décevante, car trop épaisse (8mm) , la pièce ne pliait pas sous la pression des doigts et n’actionnait donc pas les boutons placés dessous.<br />
<br />
Ce pourquoi nous avons lancé immédiatement une nouvelle impression avec 3mm d'épaisseur. Les tests étant concluants, nous n'avions plus qu'à la peindre de 4 couleurs différentes pour symboliser les 4 touches du guitar hero. <br />
<br />
<br />
Ceci commença par la réalisation de soudures des boutons poussoirs avec les fils. Ces fils seraient ensuite placés sous la couche de bois, dans la couche de carton. Cette étape fut rapidement terminée.<br />
<br />
Les 8 boutons poussoirs étaient prêts ! Quatre pour la guitare, quatre pour le jeu de Simon.<br />
<br />
Finalement, toutes les pièces étant réalisées, il fallait réaliser un travail d'assemblage, et de finitions (au niveaux des couches de peinture notamment). <br />
<br />
Nous nous sommes préalablement assuré que tous les boutons poussoirs étaient fonctionnels et que les soudures étaient correctement réalisées grâce à des tests rapides avec la carte arduino.<br />
<br />
<br />
[[Fichier:led.jpg||left|vignette|upright=1.2|]][[Fichier:end.jpg||RIGHT|vignette|upright=1.3|]]<br />
Enfin, il ne restait plus qu'à peindre nos différentes pièces.<br />
<br />
Premièrement nous avons appliqué deux couches de blanc sur chacune des pièces. Puis sur celles qui nécessitaient une couleur précise ( en autre : les touches de la guitare et du Simon), nous avons repassé deux couches de couleur dessus.<br />
Puis, nous avons assemblé toutes les pièces entre elles pour obtenir le résultat final ! <br />
<br />
L'assemblage des différentes couches de la guitare à d'abord était provisoirement fait avec de la colle forte. Si le collage venait à céder, nous utiliserons sans doute des vis ou des accroches en plastique pour maintenir le tout en place.<br />
<br />
Nous en avons profité pour utiliser la peinture restantes pour décorer un peu notre guitare et ainsi la personnaliser comme bon nous semblait.<br />
<br />
<br />
<br />
<br />
<br />
Finalement, le résultat est plus que satisfaisant ! Les quatre couleurs primaires étant vives, elles donnent un aspect coloré et joyeux à notre projet ! Les quatre touches du Simon, surmontées d'une LED de la même couleur que la touche, permettent une utilisation claire et facile du " jeu de Simon ".<br />
<br />
<br />
Dans la globalité, nous sommes assez fiers du résultat de la partie mécanique ! Que ce soit du "jeu de Simon" ou de la Guitare du "Guitar Héro", les boutons poussoirs sont activables facilement (voir la vidéo de démonstration en cliquant sur le lien suivant :[https://youtu.be/3-p--BhHGr4] ). De plus le résultat est assez agréable à regarder ou encore facile a prendre en main. <br />
<br />
<br />
<br />
La partie mécanique étant bien avancée avant la fin du projet, nous avons décidé de procéder à certaines améliorations. En effet, les tests des parties électronique et informatique pouvaient donc s’effectuer sur le Simon et la guitare ainsi réalisée. Ainsi dans tous les cas nous avions deux prototypes à présenter à la fin du projet.<br />
<br />
En parallèle, une version plus élaborée de la guitare pouvait ainsi être en construction.<br />
Pour se faire, nous avons repris le fichier SVG explicité lors de la première séance et nous lui avons rajouté un rectangle rouge au niveau du manche, pour une découpe plus propre à la découpeuse laser, et moins fragilisante pour le bois.<br />
<br />
[[Fichier:entretoise.jpg||right|vignette|upright=1.5|]]<br />
[[Fichier:cote.jpg||left|vignette|upright=1.5|]]<br />
<br />
<br />
De plus pour gagner en propreté, nous avons placé un PCB pour éviter l’encombrement.<br />
Enfin, nous avons pris la décision de laisser la guitare creuse, afin de pouvoir mieux voir le contenu électronique à l’intérieur et de garder un aspect plus propre et épuré de la guitare.<br />
<br />
Pour ce faire, nous allons utiliser des entretoises qui permettront une largeur de guitare homogène. Afin d’éviter une pliure du bois au niveau des touches (et ainsi éviter que les touches ne soient pas actionnées car pas d’opposition de force), nous avons insisté sur les entretoises au-dessous des touches (que nous avons pris soin de fixer avec de la colle pour éviter de fragiliser le bois au niveau du manche en le perçant).<br />
<br />
Finalement, les touches sont activables facilement, une fois la guitare prise en main. Un signal logique bas est bien transmis une fois les touches appuyées. Et il est bien détecté par l’arduino. <br />
<br />
[[Fichier:guitaredroite.jpg||center|vignette|upright=2|]]<br />
<br />
<br />
<br />
Désormais, la partie mécanique étant terminée et fonctionnelle, il faut la lier à la partie informatique et électronique. Nous allons perfectionner la partie FPGA et Arduino pour exploiter pleinement les deux supports (guitare et jeu de Simon) ainsi réalisés.<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Conclusion </div>==<br />
<br />
<br />
En conclusion, Le jeu de Simon est terminé et est fonctionnel''. En effet le serveur websocket envoie une combinaison de couleur, composée par un utilisateur, à l’arduino, qu’un second utilisateur devra tenter de reproduire (couleur par couleur, en reprenant du début à chaque fois, avec une couleur en plus à chaque tour). Le Jeu de Simon est terminé : L’objectif principal de notre projet est donc réalisé.<br />
<br />
Cependant, le Guitar Héro n’a pas pu être abouti. Nous avions précisé dès le début du projet que nous tâcherions de finir le Simon en priorité et de faire le Guitare Héro ensuite. La guitare est finalisée et fonctionnelle. Nous n’étions donc pas si loin de terminer les deux projets. <br />
Nous sommes globalement satisfaits du travail réalisé et de la prestation proposée. En effet en sachant que nous avions deux projets en simultané (bien que très ressemblant entre eux) nous avons su terminer le premier et bien avancer sur le second. Le but principal était de nous amuser, de prendre du plaisir dans la réalisation d'un projet et de faire quelque chose qui nous plaisait avant tout, l’objectif est atteint.<br />
<br />
Le FPGA n'a pas pu être aboutit non plus, et c'est dommage, car c'est une technologie intéressante, et c'est plus optimisé et rapide qu'une Arduino. <br />
<br />
Ce projet fut très intéressant car il nous a permis de mettre en application certains de nos cours étudiés cette année en IMA3, mais également d’en apprendre énormément par nous même à force de pratique et de recherches personnelles. Pour l’ensemble des membres du groupe, ce projet a été la confirmation de l’intérêt porté aux systèmes communicants, et nous a donc convaincu de choisir la filière SC à partir du semestre 8 en IMA4.<br />
<br />
<br />
La démonstration du fonctionnement du Jeu de Simon, est disponible à l'adresse suivante : https://youtu.be/RbgPtALDmFw .</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=Projet_IMA3_P3,_2016/2017,_TD1&diff=44309Projet IMA3 P3, 2016/2017, TD12017-06-18T20:31:03Z<p>Adurot : /* 21/03/17 Séance 1 : Répartition des tâches et premiers pas */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 25px; padding: 20px; font-weight: bold; text-align: center; font-size: 98%; background: #6060FF; vertical-align: top; width: 99%;"> Projet IMA3-SC 2016/2017 : Le Jeu de Simon et le Guitar Hero </div>=<br />
<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Cahier des Charges </div>==<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Description du système </div>===<br />
<br />
* L'objectif principal de notre projet est de réaliser un jeu qui utilise à la fois les lumières et le son. Pour cela, nous avons pensé à deux versions : le Simon et un jeu du type Guitar Hero.<br />
<br />
* Le Simon est constitué de quatre boutons de couleurs différentes : un bleu, un rouge, un vert et un jaune. Le jeu va afficher une séquence de couleurs qui sont chacune associées à un son. Le joueur doit ensuite se souvenir de la suite (en s'aidant du son et des couleurs comme moyen mnémotechnique) pour la reproduire dans le bon ordre en appuyant sur les boutons.<br />
<br />
* Le jeu Guitar Hero, quant à lui, est un jeu où il faut actionner des boutons de couleur précise, au moment où elles apparaissent sur une barre de défilement, à l'écran. Ces différentes activations, aux bons moments, permettent de réaliser une mélodie plus ou moins complexe selon la difficulté de la chanson à reproduire. Le tout est effectué grâce à une guitare connectée, afin de pousser l'expérience de simulation un peu plus loin. Si nous réalisons, ce jeu, il faut prendre en compte un affichage plus complexe. De plus, le Guitar Hero ajoute une notion de temps de réponse, plus difficile à gérer. Ce temps de réponse permet de laisser une courte marge d'erreur dans la réactivité de l'utilisateur, pour simuler pleinement l'utilisation d'une guitare électrique.<br />
<br />
<br />
Nous avons choisis de d'abord nous concentrer sur le Simon et de faire le jeu Guitar Hero seulement si nous avons le temps.<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Le matériel </div>===<br />
<br />
Pour ce projet nous utiliserons :<br />
<br />
* Une page internet sur l'ordinateur pour pouvoir modifier les différents aspects du jeu : les règles du jeu, la musique jouée par le Simon ou bien la difficulté<br />
<br />
* Le Raspberry Pi, utilisée en tant que serveur, va envoyer les données en série ( qui seront traitées par le FPGA ), de les recupérer, et de faire l'algorithme.<br />
<br />
* Une carte Arduino pour relier la Raspberry Pi aux composants dans un premier temps : elle nous permet de coder en C (au lieu d'un langage assembleur) pour créer des programmes et gérer les différents modules tel que les boutons et les LEDs. Elle permettra une simulation momentanée du FPGA, afin que nous puissions avancer sur la partie informatique, sans attendre d'en avoir fini avec la partie FPGA.<br />
<br />
* Une fois le programme et les interactions fonctionnels, nous remplacerons l'Arduino par une FPGA qui est circuit logique programmable : on peut modifier les circuits logiques à l'intérieur mais on ne peut pas créer un programme avec un langage de plus haut niveau. Nous devrons donc utiliser des logiciels tiers qui nous permettront de placer des portes logiques (ET, OU,...) pour créer notre programme en assembleur.<br />
<br />
* Pour ce qui est de la partie mécanique, nous réaliserons une guitare en bois pour le "Guitar Hero" ainsi qu'un "jeu de Simon" réalisé via l'impression 3D.<br />
<br />
* Si le temps nous le permet, nous utiliserons un Xbee pour créer une connexion sans fil, afin d'expérimenter un module nouveau et acquérir de nouvelles compétences.<br />
<br />
*Nous utiliserons également des composants électroniques tels que des boutons poussoirs, des LEDs ou une matrice de LEDs pour l'affichage dans le cas du jeu de Simon, ainsi que de "l'essentiel" pour un système communiquant (à savoir résistances, fils électriques, etc...)<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Description des séances </div>==<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 21/03/17 Séance 1 : Répartition des tâches et premiers pas </div>===<br />
<br />
La première séance fut consacrée à la répartition des rôles et à la prise de conscience de la difficulté des différentes tâches. L'idée de faire un « jeu de Simon » que nous améliorerons ensuite en « guitar hero » a cependant été conservée.<br />
<br />
==== Partie électronique ====<br />
<br />
Nous avons décidé de concentrer deux personnes sur le FPGA car c'est un élément très complexe et complètement nouveau.<br />
Nous allons en effet devoir réfléchir à très bas niveau avec simplement des registres et des portes logiques.<br />
<br />
L'objectif du composant sera de récupérer un message contenant les boutons sur lesquelles appuyer. <br />
Une fois ce message reçu, le FPGA va comparer le bouton saisi par l'utilisateur avec le bouton demander. <br />
S'il est correct, le FPGA va passer à la couleur suivante, sinon il va renvoyer un message pour dire à la Raspberry (ou l'ordinateur) que l'utilisateur s'est trompé.<br />
<br />
Pour commencer, nous réalisons le tutoriel pour allumer une LED qui va nous permettre de comprendre le fonctionnement de Altium Designer.<br />
Cela nous a pris du temps mais nous avons pu réaliser d'autres essaies avec des registres à décalages et des boutons.<br />
<br />
Nous avons ensuite directement commencer le Simon :<br />
Le choix a été fait d'utiliser des registres à décalages pour récupérer la séquence de couleur envoyé par l'ordinateur/la raspberry. <br />
Nous allons en effet stocker toute la séquence de la "partie" car sinon il faudrait gérer beaucoup d'échange entre l'ordinateur et le FPGA ce qui est lourd en Altium et fait perdre du temps réaction du programme.<br />
<br />
D'un point de vue technique, utiliser un registre à décalage semble être la meilleur méthode pour récupérer un à un les bits qui arrivent sur la liaison série puis nous utilisons 4 registres à décalage : 1 pour chaque couleur.<br />
Pour chacun des registres nous aurons donc une séquence comme suit : 0100010010111. Les 1 correspondent aux moments ou il faut appuyer sur la couleur et les 0 aux moments ou il ne faut pas appuyer sur cette couleur. <br />
Nous devons donc également gérer les clocks des registres "couleurs". Ces registres doivent arrêter leur clock lorsque les bits de chaque couleur est à 0.<br />
<br />
Le registre pour la liaison série sera la clock du système puisqu'elle doit lire toute la séquence mais elle doit également s'arrêter lorsque le FPGA arrive à la fin de la séquence. Pour lui indiquer la fin de la séquence nous avons choisit le mot 0000 car il y aura toujours un bouton à appuyer pour le jeu Simon.<br />
<br />
==== Partie informatique ====<br />
<br />
L'objectif ici était la découverte des technologies à utiliser pour le système. Notamment une Arduino en liaison série à un PC et un serveur Websockets codé en C.<br />
La partie programmation arduino ne fut pas un problème. En effet, ce n'était pas la première fois que nous utilisions cet outil, et donc la mise en place de la liaison série fut très rapide.<br />
Ce n'est cependant pas le cas de la communication websockets. Bien que l'exemple de code fourni par M. Redon soit fonctionnel, le code n'en reste pas moins complexe à comprendre. Il fallait donc réussir à modifier le code du serveur websockets, afin de relier les deux systèmes entre eux.<br />
<br />
==== Partie mécanique : un modèle de guitare à découper====<br />
<br />
<br />
Dans cette première séance, nous avons décidé de focaliser nos premiers efforts sur la partie mécanique du "guitar hero". En effet, le « jeu de simon » pouvait être avancé plus tard car plus facile à modéliser et à réaliser.[[Fichier:1.jpg||right|vignette|upright=2|]]<br />
Nous sommes alors partis sur l'idée de créer une maquette de guitare, sur laquelle nous allions disposer différents boutons de couleur, actionnables grâce à une pression sur le manche de l'instrument. Nous avions une ligne directrice mais pas encore d'idée précise de comment allait être réalisé la guitare, ni même ce à quoi elle allait ressembler.<br />
<br />
<br />
Nous avons décidé de découper la guitare en bois qui nous servirait de support pour notre « guitar hero » grâce à la découpeuse laser. Pour se faire, un fichier conforme à la découpe devait être réalisé. <br />
Ainsi nous avons donc pris une image de guitare depuis internet. Dans le logiciel « GIMP », nous avons ensuite repassé les contours de l'instrument en rouge. Une fois ceci fait, nous avons effacé l'image de la guitare originale pour ne garder que les contours rouges. Enfin après quelques réglages, l'export en fichier SVG permettait une découpe précise. Les contours de la guitare sont disponibles ci contre (cliquez sur l'image pour bien voir).<br />
<br />
A la fin de la séance, la guitare était prête à être réalisée et nous avons décidé de faire l'intégralité du « jeu de simon » via l'impression 3D. Cependant, aucune grande avancée n'a eu lieu sur la partie mécanique du jeu de Simon lors de cette séance.<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 28/03/17 Séance 2 : Poursuite du Projet et rencontre des premiers problèmes </div>===<br />
<br />
La deuxième séance fut davantage productive, car chacun de nous savait les différentes tâches qu'il lui restait à accomplir.<br />
<br />
==== Partie électronique ====<br />
Nous nous sommes rendu compte qu'utiliser le registre à décalage pour la liaison série comme nous le faisions n'était pas possible.<br />
En effet, la liaison série est en asynchrone et nous ne connaissance donc pas la clock. <br />
Nous ne pouvons donc pas utiliser cette clock pour le registre à décalage car sinon nous risquons de ne pas lire assez vite (ou trop vite) et donc récupérer trop de valeurs ou en rater.<br />
<br />
Le professeur nous a donc indiqué qu'il nous mettrait à disposition un module qui va s'occuper justement de lire la liaison série et de garder la séquence et de ressortir le message en parallèle.<br />
Ce composant envoie également sur un autre pin un 1 à chaque fois qu'un bit est envoyé par la liaison série (et reçu par le composant).<br />
Nous utilisons, selon ses conseils, un module analogique-digital qui va nous permettre de simuler l'envoi de la séquence.<br />
Après plusieurs tentatives nous avons un programme qui fonctionne correctement pour recevoir les valeurs. Il nous reste à comparer l'appui d'un bouton et la couleur à presser.<br />
<br />
==== Partie informatique ====<br />
<br />
L'écriture du programme de communication fut terminé assez rapidement. Mais il ne fonctionnait pas...<br />
En effet, un problème s'opérait lors de l'appel de la liaison série par le serveur websocket à réception d'un message.<br />
<br />
L'incompréhension régnait un peu, car à nos yeux tout était sensé fonctionner. Le principe était assez simple : à réception d'un message par le serveur websockets, ce dernier devait ouvrir une communication série sur le port TTY_USB0 (ou TTY_ACM0 en fonction de l'arduino) à 9600 bauds, y transférer le message reçu, puis refermer la communication.<br />
<br />
Après un long moment de doute, le problème fut résolu. Ce dernier était assez idiot. En effet, notre fonction d'envoi de message via le port série s'appelait : " send(..) ". Il s'avère qu'une fonction d'une des librairies utilisées se nomme de la même manière. Il y avait donc conflit et empêchait le programme de fonctionner correctement.<br />
<br />
Nous avons donc pu relier l'ordinateur à un montage de prototypage Arduino/LEDs afin de tester le bon fonctionnement du programme. Une combinaison de 4 LED devait s'allumer à réception d'un caractère. Il fallait donc envoyé un message compris entre 0(aucune LED allumée) et 15(toutes les LED allumées). Cependant, le début de la table ASCII ne représente pas des caractères. Le serveur envoie donc un message alphabétique compris entre 65 ('A') et 80 ('P') et l'arduino interprète ceci comme une valeur de 0 a 15<br />
<br />
==== Partie mécanique : découpe de la guitare, modélisation et impression d'un prototype de touches pour cette dernière ====<br />
<br />
[[Fichier:pp.jpg||left|vignette|upright=0.8|]]Cette séance fut entamée par la découpe de la guitare grâce à la découpeuse laser du Fabricarium de Polytech. Dans un premier temps il a d'abord était nécessaire « d'apprivoiser » la découpeuse et d'apprendre à bien la configurer pour obtenir le résultat souhaité, sans risques. Un premier essai a d'abord était réalisé dans du carton pour pouvoir juger des différentes dimensions de la guitare.<br />
Enfin, une seconde version, en bois, fut réalisée durant cette séance. Finalement nous décidons de partir sur l'idée d'une guitare réalisée en 4 couches d'épaisseur : 2 extérieures en bois ( une de face, décorée avec les boutons à actionner et la carte arduino et une seconde, arrière, de protection), et deux intérieures en carton(creusées pour laisser passer les fils de connectiques).<br />
<br />
Note : Malheureusement, une des couche en bois a était cassée par la suite lors de la confection de la guitare. La panne prolongée de la découpeuse laser nous a contraint à renoncer à l'idée d'une quatrième couche en bois de protection.[[Fichier:po.jpg||right|vignette|upright=1.2|]]<br />
<br />
<br />
De plus, via le logiciel de modélisation FreeCAD, nous avons commencé à concevoir deux prototypes de « touches » (boutons) pour la guitare. <br />
<br />
L'idée était de créer des surfaces larges (pouvant recueillir une phalange de doigts au minimum) faisant office de touches, en dessous desquelles nous insérerions un bouton poussoir 4 pins (fournis par les professeurs). La création de touches plus larges était indispensable. En effet, les boutons poussoirs étaient bien trop petits pour avoir un actionnement facile et agréable.<br />
Nous avons pu lancer l'impression des touches à la fin de la séance. Cependant, les différents tests et les défauts d'impression nous ont fait comprendre qu'il serait difficile de « glisser » un bouton poussoir dans une touche avec un espace assez étroit pour le maintenir, sans pour autant bloquer son actionnement lorsqu'une pression était appliquée. De plus, la fixation risquait d'être assez complexe. <br />
Nous avons alors décidé de faire un tout autre type de touche mais avec le même fonctionnement. Pour cela nous allions avoir besoin de modéliser et d'imprimer de nouveaux un prototype de touche.<br />
Il allait ensuite falloir percer la première couche en bois de la guitare. Puis il serait également nécessaire de creuser les sous couches en carton pour y placer les boutons poussoirs et les différents câbles.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 05/04/2017 Séance 3 : Encore beaucoup de choses à faire !</div>===<br />
<br />
Bien que ce soit notre dernière séance officielle, nous savions que nous allions avoir besoin de beaucoup de temps pour terminer ce projet ! <br />
<br />
==== Partie électronique ====<br />
[[Fichier:fpga.png|||vignette|upright=2|]]<br />
Le but de cette séance était de finaliser le FPGA et d'ajouter les blocs reception.vhdl et emission.vhdl fournis par M. Boé, ils nous permettent de gerer facilement la conversion serie / parallèle en asynchrone. Ainsi nous pouvons tester notre FPGA et nous rendre compte que ça ne marche pas, il y a un problème que nous n'arrivons pas à résoudre.<br />
Compte tenu du temps imparti, et du fait que la nanoboard n'était pas "embarquable", nous avons décidé de nous concentrer sur l'arduino afin d'avoir quelque chose qui fonctionne.<br />
<br />
==== Partie informatique ====<br />
<br />
<br />
L'objectif de la séance était la mise en place de l'interface WEB, notamment pour le jeu Guitar Hero. <br />
<br />
Nous avons utilisé un canvas Javascript afin de dessiner un interface similaire a celle du jeu original.<br />
<br />
==== Partie mécanique ====<br />
<br />
La troisième séance était destinée à l’élaboration du jeu de Simon. Une première idée était de créer quatre pièces plates, composées de multiples leds, qu'il faudrait actionner via une simple pression. Cependant, nous nous sommes dit qu'une seule LED pour une couleur, suffisait à indiquer la combinaison à reproduire. <br />
<br />
Le tout devait être assez grand pour contenir la carte arduino ainsi que toute la connectique, sans pour autant être trop encombrant, tout en étant assez ergonomique et agréable au regard.<br />
<br />
Nous avons donc décidé de créer un support creux qui contiendrait la partie électronique , au dessus duquel nous placerions les 4 pièces de couleur avec une LED pour chaque couleur.<br />
<br />
Nous savions dès lors, qu'un travail long minutieux nous attendait.<br />
<br />
Ainsi nous avons fait de nombreux croquis avec les différentes pièces et leurs dimensions éventuelles. Des pièces que nous allions réaliser uniquement en impression 3D. Un travail similaire a été réalisé pour la guitare, afin de ne pas percer la guitare à de mauvais endroits, et pour agencé les différents parties à ajouter sur la guitare de la meilleure façon possible. Pour résumer cette séance, nous avons réalisé tous les croquis nécessaires à la réalisation de la guitare et du Simon.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Séance supplémentaire : Terminons ce Projet !</div>===<br />
<br />
Il n'y a pas eu un nombre précis de "séances supplémentaires". Chacun des membres du groupe travaillait soit chez lui, soit à l'école de manière régulière, afin d'avancer sa partie le plus rapidement possible.<br />
<br />
==== Partie électronique ====<br />
[[Fichier:pcb1.jpg|left|vignette|upright=0.8|]]<br />
[[Fichier:pcb2.jpg|right|vignette|upright=0.8|]]<br />
Pour le Simon, il a fallut souder les câbles aux boutons et aux leds ( avec leur résistance ). Pour se faire, on a utilisé un circuit à pastilles qui se place entre l'arduino et les boutons/led. Cela permet de prendre moins de place et de faire plus propre qu'une breadboard.<br />
<br />
=== Partie informatique ===<br />
<br />
La partie FPGA n'étant pas fonctionelle, il a fallut le remplacer par un Arduino. <br />
<br />
Le code de l'Arduino consiste en une succession d'étapes pour jouer. Tout d'abord il faut recevoir via le port série la séquence totale du Simon, sous la forme de chaîne de caractères. Par exemple si le message reçu est "RVBR", alors la séquence totale du Simon sera Rouge Vert Bleu Rouge. Ainsi une fonction reception_message a été codée, qui attend la réception série de la séquence. <br />
<br />
Dans l'algorithme du jeu en lui même on a une variable globale qui stocke l'état de la partie, et une qui stocke l'étape de la séquence. Ainsi en fonction de l'état de la partie on va soit jouer la séquence sur les leds, lire l'état des boutons, ou provoquer un game over.<br />
<br />
La fonction playSequence va parcourir la séquence totale jusqu'à l'étape actuelle et va allumer les différentes leds en conséquence.<br />
<br />
La fonction readSequence va elle lire l'état successif des boutons et le comparer à la séquence actuelle. Si il y a une erreur, on sort de la fonction, et l'état de la partie devient un game over. Sinon, on continue et on appelle playSequence en incrémentant l'étape. En cas de réussite de la séquence, les 4 leds s'allument pour indiquer lé réussite et le passage au niveau supérieur.<br />
<br />
Coté websockets, c'est facile, dès qu'on reçoit un message par le client, on l'envoie à l'arduino ( bien qu'on aurait du vérifier la conformité du message ), l'arduino ne lira le message que si on est en étape de lecture de la séquence, donc après un game over par exemple. <br />
<br />
==== Partie mécanique : Suite et fin de la confection de la guitare et du jeu de Simon====<br />
<br />
Comme nous l'avons prédit, la plus grosse partie du travail réalisé a dû être faite lors de séances supplémentaires ou par travail personnel chez soi.<br />
<br />
Après avoir réalisé les croquis, il était essentiel de créer rapidement les différents supports. En effet, cela nous permettait d'avoir du temps pour éventuellement recommencer et revoir les axes de travail en cas d'impossibilité de réalisation pour quelconque raison. De plus, une fois la partie mécanique terminée, nous pouvions l'utiliser comme support pour les tests électroniques. Enfin, cela nous laissait du temps en fin de projet pour décorer notre projet, que nous voulions personnalisé afin d'en être le plus satisfaits possible. <br />
<br />
Un gros travail de modélisation à dû être fait sur FREECAD. Le support du jeu de Simon fut la pièce la plus simple à réaliser (un cylindre semi fermé, de 7 cm de rayon).<br />
<br />
Puis une simple découpe grâce à une scie permettrait de faire réceptacle pour une "croix porteuse" sur laquelle serait disposés les touches du Simon.<br />
<br />
De la même façon que pour la guitare, les touches seraient placées au dessus de boutons poussoirs. Ces derniers seront collés sur la croix. <br />
[[Fichier:tg.jpg||right|vignette|upright=1.5|]]<br />
Une fois ceci fait, il fallait réaliser le plus important du jeu : les touches à actionner ! <br />
<br />
Pour cela, il était préférable de conserver la forme cylindrique du support en modélisant 4 pièces, d'un quart de disque chacune. Par soucis de fixation sur la croix et par envie d’esthétisme, les touches seraient un peu incurvées pour donner une forme moins géométrique au rendu final. <br />
<br />
De plus, elles seront perforées pour laisser passer une LED de la même couleur que la touche sur laquelle elle se trouve. Ainsi l'utilisateur pourra mémoriser les touches à activer via le système lumineux des LEDs. <br />
<br />
Enfin, un cylindre permettant l'accroche sur la croix à été prévu sur la partie inférieure de les touches du Simon. (suite à une impression peu précise, ce cylindre sera « fondu » pour épouser la forme de la croix sans jeu dans la fixation.)<br />
<br />
[[Fichier:touc2.jpg||left|vignette|upright=1.7|]]<br />
Vint ensuite le moment de la création ! L'impression de ces pièces étant la plus complexe, nous pensions qu'il serait nécessaire de les recommencer plusieurs fois. La WitBox du Fabricarium (la plus précise des imprimantes mise à notre disposition) a réalisé une impression assez laborieuse. Un gros travail de ponçage à donc dû être réalisé, car le support nécessaire pour imprimer cette pièce « incurvée » avait donné de nombreuses bavures sur la surface des touches. Afin que le toucher reste agréable, nous avons donc retravaillé les pièces.<br />
<br />
<br />
Une fois ceci fait, nous avons essayé de les positionner sur la croix prévue à cet effet. Une fois encore, nous étions confronté aux limites de l'impression 3D. Les dimensions du « cylindre pillier » étant non précise, et cette partie étant trop fine pour être sciée sans rupture de la pièce, nous avons décidé de faire « fondre » cette partie et de la placer, encore chaude sur la partie en forme de croix. Cela permettait une fixation sûre et une dimension épousant parfaitement les formes du support. L'inconvénient fut que cette méthode, peu précise, n'a fait qu'accentuer les erreurs d'impressions au niveaux du visuel. Effectivement, les 4 pièces ne semblent pas régulières et le disque qu'elles sont censées former (ensemble de 4 quarts de disque) ne semble pas parfait.[[Fichier:bttt.jpg||right|vignette|upright=1.5|]][[Fichier:socle.jpg||right|vignette|upright=1.5|]]<br />
<br />
<br />
Nous décidons cependant de conserver ce léger défaut, car si nous recommencions nous risquerions d'être de nouveau confronté au même souci, l'erreur n'étant pas uniquement dû à notre manipulation mais également à l'imprimante 3D. <br />
<br />
<br />
L'impression du socle était la plus longue à imprimer (près de 6 heures) .Après l'avoir un peu scié comme prévu, cette pièce était également prête à être peinte. Nous avons fait de même avec la croix à placer sur le socle et servant de support aux quatre touches du Simon. Cette impression étant rapide et facile, un seul essai suffit pour obtenir notre version définitive. L'impression fut dans ce cas, parfaitement aux mesures souhaitées dans le fichier .stl (bien que réalisé avec une imprimante de moins bonne qualité que la WitBox). Ainsi les boutons poussoirs que nous avions à positionner dessus tenaient sans souci par un simple encastrement. Par la suite, par mesure de sécurité, <br />
nous avons tout de même rajouté un point de colle en dessous des boutons pour éviter tout désencastrement non souhaité. <br />
[[Fichier:tr.jpg||left|vignette|upright=1.4|]]<br />
<br />
<br />
<br />
En parallèle, nous avons travaillé sur les différentes couches d'épaisseur de la guitare. Dans un premier temps il était nécessaire de retirer une partie dans le manche pour y placer les boutons poussoirs. Cette étape aurait pu être réalisé rapidement avec la découpeuse laser, mais celle ci étant en panne, nous l'avons fait via une perceuse et un foret au Fabricarium. Le résultat était un peu moins net mais convenable cependant. De plus le "trou" sera caché par la pièce contenant les touches. Une fois la couche de bois travaillée, nous avons creusé la partie cartonnée afin de pouvoir y laisser passer les différents câbles liant les boutons poussoirs (situés sous les touches du manche de la guitare) à une breadboard (sur la partie basse de l'instrument).<br />
<br />
Afin que les câbles sortent de la guitare de façon propre, nous avons percé 4 trous à la base du manche. Ainsi de chaque trou ressortira deux fils de connectique ( un pour l'entrée du bouton poussoir et un pour la sortie).<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:tt.jpg||left|vignette|upright=2|]]<br />
Ceci étant terminé, il fallait passer à la conception des touches de la guitare.[[Fichier:touc.jpg||right|vignette|upright=2.2|]]<br />
C'est en observant une imprimante 3D du Fabricarium qu'une idée de modèle touche vue le jour. Nous allions faire une seule et unique pièces pour les 4 touches.<br />
Fine, elle pourrait être facilement pliée sous une pression du doigts pour actionner un bouton poussoir situé en dessous de chacune des 4 touches.suffirait juste de peindre les 4 touches de couleurs différentes pour les différencier.<br />
Cette pièce serait fixée sur le manche de la guitare, couvrant une couche de bois perforée et une cartonnée « creusée » pour laisser passer la connectique jusqu'à la partie inférieure de la guitare.<br />
<br />
Finalement, il aura fallut quelques heures supplémentaires des séances pour avoir toutes nos partie modéliser sur FREECAD et prête à être imprimées, qu'elles soient destinées au Simon ou au Guitar Hero.<br />
<br />
L'heure est donc à la réalisation ! Les impressions 3D se sont faites sur l'imprimante d'un des membre du groupe ainsi que sur celles du Fabricarium. <br />
<br />
Les touches qui actionneraient les boutons poussoirs étaient les plus à même d'être à recommencer. En effet, un problème de fixation, ou encore une rigidité trop grande empêcherait l'actionnement du bouton et serait donc inutilisable. Ainsi nous avons commencé par imprimer les touches (pour la guitare et pour le simon). Dans un premier temps, nous nous sommes occupés de la pièce pour la guitare. La première impression fut décevante, car trop épaisse (8mm) , la pièce ne pliait pas sous la pression des doigts et n’actionnait donc pas les boutons placés dessous.<br />
<br />
Ce pourquoi nous avons lancé immédiatement une nouvelle impression avec 3mm d'épaisseur. Les tests étant concluants, nous n'avions plus qu'à la peindre de 4 couleurs différentes pour symboliser les 4 touches du guitar hero. <br />
<br />
<br />
Ceci commença par la réalisation de soudures des boutons poussoirs avec les fils. Ces fils seraient ensuite placés sous la couche de bois, dans la couche de carton. Cette étape fut rapidement terminée.<br />
<br />
Les 8 boutons poussoirs étaient prêts ! Quatre pour la guitare, quatre pour le jeu de Simon.<br />
<br />
Finalement, toutes les pièces étant réalisées, il fallait réaliser un travail d'assemblage, et de finitions (au niveaux des couches de peinture notamment). <br />
<br />
Nous nous sommes préalablement assuré que tous les boutons poussoirs étaient fonctionnels et que les soudures étaient correctement réalisées grâce à des tests rapides avec la carte arduino.<br />
<br />
<br />
[[Fichier:led.jpg||left|vignette|upright=1.2|]][[Fichier:end.jpg||RIGHT|vignette|upright=1.3|]]<br />
Enfin, il ne restait plus qu'à peindre nos différentes pièces.<br />
<br />
Premièrement nous avons appliqué deux couches de blanc sur chacune des pièces. Puis sur celles qui nécessitaient une couleur précise ( en autre : les touches de la guitare et du Simon), nous avons repassé deux couches de couleur dessus.<br />
Puis, nous avons assemblé toutes les pièces entre elles pour obtenir le résultat final ! <br />
<br />
L'assemblage des différentes couches de la guitare à d'abord était provisoirement fait avec de la colle forte. Si le collage venait à céder, nous utiliserons sans doute des vis ou des accroches en plastique pour maintenir le tout en place.<br />
<br />
Nous en avons profité pour utiliser la peinture restantes pour décorer un peu notre guitare et ainsi la personnaliser comme bon nous semblait.<br />
<br />
<br />
<br />
<br />
<br />
Finalement, le résultat est plus que satisfaisant ! Les quatre couleurs primaires étant vives, elles donnent un aspect coloré et joyeux à notre projet ! Les quatre touches du Simon, surmontées d'une LED de la même couleur que la touche, permettent une utilisation claire et facile du « jeu de Simon ».<br />
<br />
<br />
Dans la globalité, nous sommes assez fiers du résultat de la partie mécanique ! Que ce soit du "jeu de Simon" ou de la Guitare du "Guitar Héro", les boutons poussoirs sont activables facilement (voir la vidéo de démonstration en cliquant sur le lien suivant :[https://youtu.be/3-p--BhHGr4] ). De plus le résultat est assez agréable à regarder ou encore facile a prendre en main. <br />
<br />
<br />
<br />
La partie mécanique étant bien avancée avant la fin du projet, nous avons décidé de procéder à certaines améliorations. En effet, les tests des parties électronique et informatique pouvaient donc s’effectuer sur le Simon et la guitare ainsi réalisée. Ainsi dans tous les cas nous avions deux prototypes à présenter à la fin du projet.<br />
<br />
En parallèle, une version plus élaborée de la guitare pouvait ainsi être en construction.<br />
Pour se faire, nous avons repris le fichier SVG explicité lors de la première séance et nous lui avons rajouté un rectangle rouge au niveau du manche, pour une découpe plus propre à la découpeuse laser, et moins fragilisante pour le bois.<br />
<br />
[[Fichier:entretoise.jpg||right|vignette|upright=1.5|]]<br />
[[Fichier:cote.jpg||left|vignette|upright=1.5|]]<br />
<br />
<br />
De plus pour gagner en propreté, nous avons placé un PCB pour éviter l’encombrement.<br />
Enfin, nous avons pris la décision de laisser la guitare creuse, afin de pouvoir mieux voir le contenu électronique à l’intérieur et de garder un aspect plus propre et épuré de la guitare.<br />
<br />
Pour ce faire, nous allons utiliser des entretoises qui permettront une largeur de guitare homogène. Afin d’éviter une pliure du bois au niveau des touches (et ainsi éviter que les touches ne soient pas actionnées car pas d’opposition de force), nous avons insisté sur les entretoises au-dessous des touches (que nous avons pris soin de fixer avec de la colle pour éviter de fragiliser le bois au niveau du manche en le perçant).<br />
<br />
Finalement, les touches sont activables facilement, une fois la guitare prise en main. Un signal logique bas est bien transmis une fois les touches appuyées. Et il est bien détecté par l’arduino. <br />
<br />
[[Fichier:guitaredroite.jpg||center|vignette|upright=2|]]<br />
<br />
<br />
<br />
Désormais, la partie mécanique étant terminée et fonctionnelle, il faut la lier à la partie informatique et électronique. Nous allons perfectionner la partie FPGA et Arduino pour exploiter pleinement les deux supports (guitare et jeu de Simon) ainsi réalisés.<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Conclusion </div>==<br />
<br />
<br />
En conclusion, Le jeu de Simon est terminé et est fonctionnel''. En effet le serveur websocket envoie une combinaison de couleur, composée par un utilisateur, à l’arduino, qu’un second utilisateur devra tenter de reproduire (couleur par couleur, en reprenant du début à chaque fois, avec une couleur en plus à chaque tour). Le Jeu de Simon est terminé : L’objectif principal de notre projet est donc réalisé.<br />
<br />
Cependant, le Guitar Héro n’a pas pu être abouti. Nous avions précisé dès le début du projet que nous tâcherions de finir le Simon en priorité et de faire le Guitare Héro ensuite. La guitare est finalisée et fonctionnelle. Nous n’étions donc pas si loin de terminer les deux projets. <br />
Nous sommes globalement satisfaits du travail réalisé et de la prestation proposée. En effet en sachant que nous avions deux projets en simultané (bien que très ressemblant entre eux) nous avons su terminer le premier et bien avancer sur le second. Le but principal était de nous amuser, de prendre du plaisir dans la réalisation d'un projet et de faire quelque chose qui nous plaisait avant tout, l’objectif est atteint.<br />
<br />
Le FPGA n'a pas pu être aboutit non plus, et c'est dommage, car c'est une technologie intéressante, et c'est plus optimisé et rapide qu'une Arduino. <br />
<br />
Ce projet fut très intéressant car il nous a permis de mettre en application certains de nos cours étudiés cette année en IMA3, mais également d’en apprendre énormément par nous même à force de pratique et de recherches personnelles. Pour l’ensemble des membres du groupe, ce projet a été la confirmation de l’intérêt porté aux systèmes communicants, et nous a donc convaincu de choisir la filière SC à partir du semestre 8 en IMA4.<br />
<br />
<br />
La démonstration du fonctionnement du Jeu de Simon, est disponible à l'adresse suivante : https://youtu.be/RbgPtALDmFw .</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=Projet_IMA3_P3,_2016/2017,_TD1&diff=44308Projet IMA3 P3, 2016/2017, TD12017-06-18T20:29:36Z<p>Adurot : /* Conclusion */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 25px; padding: 20px; font-weight: bold; text-align: center; font-size: 98%; background: #6060FF; vertical-align: top; width: 99%;"> Projet IMA3-SC 2016/2017 : Le Jeu de Simon et le Guitar Hero </div>=<br />
<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Cahier des Charges </div>==<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Description du système </div>===<br />
<br />
* L'objectif principal de notre projet est de réaliser un jeu qui utilise à la fois les lumières et le son. Pour cela, nous avons pensé à deux versions : le Simon et un jeu du type Guitar Hero.<br />
<br />
* Le Simon est constitué de quatre boutons de couleurs différentes : un bleu, un rouge, un vert et un jaune. Le jeu va afficher une séquence de couleurs qui sont chacune associées à un son. Le joueur doit ensuite se souvenir de la suite (en s'aidant du son et des couleurs comme moyen mnémotechnique) pour la reproduire dans le bon ordre en appuyant sur les boutons.<br />
<br />
* Le jeu Guitar Hero, quant à lui, est un jeu où il faut actionner des boutons de couleur précise, au moment où elles apparaissent sur une barre de défilement, à l'écran. Ces différentes activations, aux bons moments, permettent de réaliser une mélodie plus ou moins complexe selon la difficulté de la chanson à reproduire. Le tout est effectué grâce à une guitare connectée, afin de pousser l'expérience de simulation un peu plus loin. Si nous réalisons, ce jeu, il faut prendre en compte un affichage plus complexe. De plus, le Guitar Hero ajoute une notion de temps de réponse, plus difficile à gérer. Ce temps de réponse permet de laisser une courte marge d'erreur dans la réactivité de l'utilisateur, pour simuler pleinement l'utilisation d'une guitare électrique.<br />
<br />
<br />
Nous avons choisis de d'abord nous concentrer sur le Simon et de faire le jeu Guitar Hero seulement si nous avons le temps.<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Le matériel </div>===<br />
<br />
Pour ce projet nous utiliserons :<br />
<br />
* Une page internet sur l'ordinateur pour pouvoir modifier les différents aspects du jeu : les règles du jeu, la musique jouée par le Simon ou bien la difficulté<br />
<br />
* Le Raspberry Pi, utilisée en tant que serveur, va envoyer les données en série ( qui seront traitées par le FPGA ), de les recupérer, et de faire l'algorithme.<br />
<br />
* Une carte Arduino pour relier la Raspberry Pi aux composants dans un premier temps : elle nous permet de coder en C (au lieu d'un langage assembleur) pour créer des programmes et gérer les différents modules tel que les boutons et les LEDs. Elle permettra une simulation momentanée du FPGA, afin que nous puissions avancer sur la partie informatique, sans attendre d'en avoir fini avec la partie FPGA.<br />
<br />
* Une fois le programme et les interactions fonctionnels, nous remplacerons l'Arduino par une FPGA qui est circuit logique programmable : on peut modifier les circuits logiques à l'intérieur mais on ne peut pas créer un programme avec un langage de plus haut niveau. Nous devrons donc utiliser des logiciels tiers qui nous permettront de placer des portes logiques (ET, OU,...) pour créer notre programme en assembleur.<br />
<br />
* Pour ce qui est de la partie mécanique, nous réaliserons une guitare en bois pour le "Guitar Hero" ainsi qu'un "jeu de Simon" réalisé via l'impression 3D.<br />
<br />
* Si le temps nous le permet, nous utiliserons un Xbee pour créer une connexion sans fil, afin d'expérimenter un module nouveau et acquérir de nouvelles compétences.<br />
<br />
*Nous utiliserons également des composants électroniques tels que des boutons poussoirs, des LEDs ou une matrice de LEDs pour l'affichage dans le cas du jeu de Simon, ainsi que de "l'essentiel" pour un système communiquant (à savoir résistances, fils électriques, etc...)<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Description des séances </div>==<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 21/03/17 Séance 1 : Répartition des tâches et premiers pas </div>===<br />
<br />
La première séance fut consacrée à la répartition des rôles et à la prise de conscience de la difficulté des différentes tâches. L'idée de faire un « jeu de Simon » que nous amélioreront ensuite en « guitar hero » a cependant été conservée.<br />
<br />
==== Partie électronique ====<br />
<br />
Nous avons décidé de concentrer deux personnes sur le FPGA car c'est un élément très complexe et complètement nouveau.<br />
Nous allons en effet devoir reflechir à très bas niveau avec simplement des registres et des portes logiques.<br />
<br />
L'objectif du composant sera de récupérer un message contenant les boutons sur lesquelles appuyer. <br />
Une fois ce message reçu, le FPGA va comparer le bouton saisi par l'utilisateur avec le bouton demander. <br />
S'il est correct, le FPGA va passer à la couleur suivante, sinon il va renvoyer un message pour dire à la Raspberry (ou l'ordinateur) que l'utilisateur s'est trompé.<br />
<br />
Pour commencer, nous réalisons le tutoriel pour allumer une LED qui va nous permettre de comprendre le fonctionnement de Altium Designer.<br />
Cela nous a pris du temps mais nous avons pu réaliser d'autres essaies avec des registres à décalages et des boutons.<br />
<br />
Nous avons ensuite directement commencer le Simon :<br />
Le choix a été fait d'utiliser des registres à décalages pour récupérer la séquence de couleur envoyé par l'ordinateur/la raspberry. <br />
Nous allons en effet stocker toute la séquence de la "partie" car sinon il faudrait gérer beaucoup d'échange entre l'ordinateur et le FPGA ce qui est lourd en Altium et fait perdre du temps réaction du programme.<br />
<br />
D'un point de vue technique, utiliser un registre à décalage semble être la meilleur méthode pour récupérer un à un les bits qui arrivent sur la liaison série puis nous utilisons 4 registres à décalage : 1 pour chaque couleur.<br />
Pour chacun des registres nous aurons donc une séquence comme suit : 0100010010111. Les 1 correspondent aux moments ou il faut appuyer sur la couleur et les 0 aux moments ou il ne faut pas appuyer sur cette couleur. <br />
Nous devons donc également gérer les clocks des registres "couleurs". Ces registres doivent arrêter leur clock lorsque les bits de chaque couleur est à 0.<br />
<br />
Le registre pour la liaison série sera la clock du système puisqu'elle doit lire toute la séquence mais elle doit également s'arrêter lorsque le FPGA arrive à la fin de la séquence. Pour lui indiquer la fin de la séquence nous avons choisit le mot 0000 car il y aura toujours un bouton à appuyer pour le jeu Simon.<br />
<br />
==== Partie informatique ====<br />
<br />
L'objectif ici était la découverte des technologies à utiliser pour le système. Notamment une Arduino en liaison série à un PC et un serveur Websockets codé en C.<br />
La partie programmation arduino ne fut pas un problème. En effet, ce n'était pas la première fois que nous utilisions cet outil, et donc la mise en place de la liaison série fut très rapide.<br />
Ce n'est cependant pas le cas de la communication websockets. Bien que l'exemple de code fourni par M. Redon soit fonctionnel, le code n'en reste pas moins complexe à comprendre. Il fallait donc réussir à modifier le code du serveur websockets, afin de relier les deux systèmes entre eux.<br />
<br />
==== Partie mécanique : un modèle de guitare à découper====<br />
<br />
<br />
Dans cette première séance, nous avons décidé de focaliser nos premiers efforts sur la partie mécanique du "guitar hero". En effet, le « jeu de simon » pouvait être avancé plus tard car plus facile à modéliser et à réaliser.[[Fichier:1.jpg||right|vignette|upright=2|]]<br />
Nous sommes alors partis sur l'idée de créer une maquette de guitare, sur laquelle nous allions disposer différents boutons de couleur, actionnables grâce à une pression sur le manche de l'instrument. Nous avions une ligne directrice mais pas encore d'idée précise de comment allait être réalisé la guitare, ni même ce à quoi elle allait ressembler.<br />
<br />
<br />
Nous avons décidé de découper la guitare en bois qui nous servirait de support pour notre « guitar hero » grâce à la découpeuse laser. Pour se faire, un fichier conforme à la découpe devait être réalisé. <br />
Ainsi nous avons donc pris une image de guitare depuis internet. Dans le logiciel « GIMP », nous avons ensuite repassé les contours de l'instrument en rouge. Une fois ceci fait, nous avons effacé l'image de la guitare originale pour ne garder que les contours rouges. Enfin après quelques réglages, l'export en fichier SVG permettait une découpe précise. Les contours de la guitare sont disponibles ci contre (cliquez sur l'image pour bien voir).<br />
<br />
A la fin de la séance, la guitare était prête à être réalisée et nous avons décidé de faire l'intégralité du « jeu de simon » via l'impression 3D. Cependant, aucune grande avancée n'a eu lieu sur la partie mécanique du jeu de Simon lors de cette séance.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 28/03/17 Séance 2 : Poursuite du Projet et rencontre des premiers problèmes </div>===<br />
<br />
La deuxième séance fut davantage productive, car chacun de nous savait les différentes tâches qu'il lui restait à accomplir.<br />
<br />
==== Partie électronique ====<br />
Nous nous sommes rendu compte qu'utiliser le registre à décalage pour la liaison série comme nous le faisions n'était pas possible.<br />
En effet, la liaison série est en asynchrone et nous ne connaissance donc pas la clock. <br />
Nous ne pouvons donc pas utiliser cette clock pour le registre à décalage car sinon nous risquons de ne pas lire assez vite (ou trop vite) et donc récupérer trop de valeurs ou en rater.<br />
<br />
Le professeur nous a donc indiqué qu'il nous mettrait à disposition un module qui va s'occuper justement de lire la liaison série et de garder la séquence et de ressortir le message en parallèle.<br />
Ce composant envoie également sur un autre pin un 1 à chaque fois qu'un bit est envoyé par la liaison série (et reçu par le composant).<br />
Nous utilisons, selon ses conseils, un module analogique-digital qui va nous permettre de simuler l'envoi de la séquence.<br />
Après plusieurs tentatives nous avons un programme qui fonctionne correctement pour recevoir les valeurs. Il nous reste à comparer l'appui d'un bouton et la couleur à presser.<br />
<br />
==== Partie informatique ====<br />
<br />
L'écriture du programme de communication fut terminé assez rapidement. Mais il ne fonctionnait pas...<br />
En effet, un problème s'opérait lors de l'appel de la liaison série par le serveur websocket à réception d'un message.<br />
<br />
L'incompréhension régnait un peu, car à nos yeux tout était sensé fonctionner. Le principe était assez simple : à réception d'un message par le serveur websockets, ce dernier devait ouvrir une communication série sur le port TTY_USB0 (ou TTY_ACM0 en fonction de l'arduino) à 9600 bauds, y transférer le message reçu, puis refermer la communication.<br />
<br />
Après un long moment de doute, le problème fut résolu. Ce dernier était assez idiot. En effet, notre fonction d'envoi de message via le port série s'appelait : " send(..) ". Il s'avère qu'une fonction d'une des librairies utilisées se nomme de la même manière. Il y avait donc conflit et empêchait le programme de fonctionner correctement.<br />
<br />
Nous avons donc pu relier l'ordinateur à un montage de prototypage Arduino/LEDs afin de tester le bon fonctionnement du programme. Une combinaison de 4 LED devait s'allumer à réception d'un caractère. Il fallait donc envoyé un message compris entre 0(aucune LED allumée) et 15(toutes les LED allumées). Cependant, le début de la table ASCII ne représente pas des caractères. Le serveur envoie donc un message alphabétique compris entre 65 ('A') et 80 ('P') et l'arduino interprète ceci comme une valeur de 0 a 15<br />
<br />
==== Partie mécanique : découpe de la guitare, modélisation et impression d'un prototype de touches pour cette dernière ====<br />
<br />
[[Fichier:pp.jpg||left|vignette|upright=0.8|]]Cette séance fut entamée par la découpe de la guitare grâce à la découpeuse laser du Fabricarium de Polytech. Dans un premier temps il a d'abord était nécessaire « d'apprivoiser » la découpeuse et d'apprendre à bien la configurer pour obtenir le résultat souhaité, sans risques. Un premier essai a d'abord était réalisé dans du carton pour pouvoir juger des différentes dimensions de la guitare.<br />
Enfin, une seconde version, en bois, fut réalisée durant cette séance. Finalement nous décidons de partir sur l'idée d'une guitare réalisée en 4 couches d'épaisseur : 2 extérieures en bois ( une de face, décorée avec les boutons à actionner et la carte arduino et une seconde, arrière, de protection), et deux intérieures en carton(creusées pour laisser passer les fils de connectiques).<br />
<br />
Note : Malheureusement, une des couche en bois a était cassée par la suite lors de la confection de la guitare. La panne prolongée de la découpeuse laser nous a contraint à renoncer à l'idée d'une quatrième couche en bois de protection.[[Fichier:po.jpg||right|vignette|upright=1.2|]]<br />
<br />
<br />
De plus, via le logiciel de modélisation FreeCAD, nous avons commencé à concevoir deux prototypes de « touches » (boutons) pour la guitare. <br />
<br />
L'idée était de créer des surfaces larges (pouvant recueillir une phalange de doigts au minimum) faisant office de touches, en dessous desquelles nous insérerions un bouton poussoir 4 pins (fournis par les professeurs). La création de touches plus larges était indispensable. En effet, les boutons poussoirs étaient bien trop petits pour avoir un actionnement facile et agréable.<br />
Nous avons pu lancer l'impression des touches à la fin de la séance. Cependant, les différents tests et les défauts d'impression nous ont fait comprendre qu'il serait difficile de « glisser » un bouton poussoir dans une touche avec un espace assez étroit pour le maintenir, sans pour autant bloquer son actionnement lorsqu'une pression était appliquée. De plus, la fixation risquait d'être assez complexe. <br />
Nous avons alors décidé de faire un tout autre type de touche mais avec le même fonctionnement. Pour cela nous allions avoir besoin de modéliser et d'imprimer de nouveaux un prototype de touche.<br />
Il allait ensuite falloir percer la première couche en bois de la guitare. Puis il serait également nécessaire de creuser les sous couches en carton pour y placer les boutons poussoirs et les différents câbles.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 05/04/2017 Séance 3 : Encore beaucoup de choses à faire !</div>===<br />
<br />
Bien que ce soit notre dernière séance officielle, nous savions que nous allions avoir besoin de beaucoup de temps pour terminer ce projet ! <br />
<br />
==== Partie électronique ====<br />
[[Fichier:fpga.png|||vignette|upright=2|]]<br />
Le but de cette séance était de finaliser le FPGA et d'ajouter les blocs reception.vhdl et emission.vhdl fournis par M. Boé, ils nous permettent de gerer facilement la conversion serie / parallèle en asynchrone. Ainsi nous pouvons tester notre FPGA et nous rendre compte que ça ne marche pas, il y a un problème que nous n'arrivons pas à résoudre.<br />
Compte tenu du temps imparti, et du fait que la nanoboard n'était pas "embarquable", nous avons décidé de nous concentrer sur l'arduino afin d'avoir quelque chose qui fonctionne.<br />
<br />
==== Partie informatique ====<br />
<br />
<br />
L'objectif de la séance était la mise en place de l'interface WEB, notamment pour le jeu Guitar Hero. <br />
<br />
Nous avons utilisé un canvas Javascript afin de dessiner un interface similaire a celle du jeu original.<br />
<br />
==== Partie mécanique ====<br />
<br />
La troisième séance était destinée à l’élaboration du jeu de Simon. Une première idée était de créer quatre pièces plates, composées de multiples leds, qu'il faudrait actionner via une simple pression. Cependant, nous nous sommes dit qu'une seule LED pour une couleur, suffisait à indiquer la combinaison à reproduire. <br />
<br />
Le tout devait être assez grand pour contenir la carte arduino ainsi que toute la connectique, sans pour autant être trop encombrant, tout en étant assez ergonomique et agréable au regard.<br />
<br />
Nous avons donc décidé de créer un support creux qui contiendrait la partie électronique , au dessus duquel nous placerions les 4 pièces de couleur avec une LED pour chaque couleur.<br />
<br />
Nous savions dès lors, qu'un travail long minutieux nous attendait.<br />
<br />
Ainsi nous avons fait de nombreux croquis avec les différentes pièces et leurs dimensions éventuelles. Des pièces que nous allions réaliser uniquement en impression 3D. Un travail similaire a été réalisé pour la guitare, afin de ne pas percer la guitare à de mauvais endroits, et pour agencé les différents parties à ajouter sur la guitare de la meilleure façon possible. Pour résumer cette séance, nous avons réalisé tous les croquis nécessaires à la réalisation de la guitare et du Simon.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Séance supplémentaire : Terminons ce Projet !</div>===<br />
<br />
Il n'y a pas eu un nombre précis de "séances supplémentaires". Chacun des membres du groupe travaillait soit chez lui, soit à l'école de manière régulière, afin d'avancer sa partie le plus rapidement possible.<br />
<br />
==== Partie électronique ====<br />
[[Fichier:pcb1.jpg|left|vignette|upright=0.8|]]<br />
[[Fichier:pcb2.jpg|right|vignette|upright=0.8|]]<br />
Pour le Simon, il a fallut souder les câbles aux boutons et aux leds ( avec leur résistance ). Pour se faire, on a utilisé un circuit à pastilles qui se place entre l'arduino et les boutons/led. Cela permet de prendre moins de place et de faire plus propre qu'une breadboard.<br />
<br />
=== Partie informatique ===<br />
<br />
La partie FPGA n'étant pas fonctionelle, il a fallut le remplacer par un Arduino. <br />
<br />
Le code de l'Arduino consiste en une succession d'étapes pour jouer. Tout d'abord il faut recevoir via le port série la séquence totale du Simon, sous la forme de chaîne de caractères. Par exemple si le message reçu est "RVBR", alors la séquence totale du Simon sera Rouge Vert Bleu Rouge. Ainsi une fonction reception_message a été codée, qui attend la réception série de la séquence. <br />
<br />
Dans l'algorithme du jeu en lui même on a une variable globale qui stocke l'état de la partie, et une qui stocke l'étape de la séquence. Ainsi en fonction de l'état de la partie on va soit jouer la séquence sur les leds, lire l'état des boutons, ou provoquer un game over.<br />
<br />
La fonction playSequence va parcourir la séquence totale jusqu'à l'étape actuelle et va allumer les différentes leds en conséquence.<br />
<br />
La fonction readSequence va elle lire l'état successif des boutons et le comparer à la séquence actuelle. Si il y a une erreur, on sort de la fonction, et l'état de la partie devient un game over. Sinon, on continue et on appelle playSequence en incrémentant l'étape. En cas de réussite de la séquence, les 4 leds s'allument pour indiquer lé réussite et le passage au niveau supérieur.<br />
<br />
Coté websockets, c'est facile, dès qu'on reçoit un message par le client, on l'envoie à l'arduino ( bien qu'on aurait du vérifier la conformité du message ), l'arduino ne lira le message que si on est en étape de lecture de la séquence, donc après un game over par exemple. <br />
<br />
==== Partie mécanique : Suite et fin de la confection de la guitare et du jeu de Simon====<br />
<br />
Comme nous l'avons prédit, la plus grosse partie du travail réalisé a dû être faite lors de séances supplémentaires ou par travail personnel chez soi.<br />
<br />
Après avoir réalisé les croquis, il était essentiel de créer rapidement les différents supports. En effet, cela nous permettait d'avoir du temps pour éventuellement recommencer et revoir les axes de travail en cas d'impossibilité de réalisation pour quelconque raison. De plus, une fois la partie mécanique terminée, nous pouvions l'utiliser comme support pour les tests électroniques. Enfin, cela nous laissait du temps en fin de projet pour décorer notre projet, que nous voulions personnalisé afin d'en être le plus satisfaits possible. <br />
<br />
Un gros travail de modélisation à dû être fait sur FREECAD. Le support du jeu de Simon fut la pièce la plus simple à réaliser (un cylindre semi fermé, de 7 cm de rayon).<br />
<br />
Puis une simple découpe grâce à une scie permettrait de faire réceptacle pour une "croix porteuse" sur laquelle serait disposés les touches du Simon.<br />
<br />
De la même façon que pour la guitare, les touches seraient placées au dessus de boutons poussoirs. Ces derniers seront collés sur la croix. <br />
[[Fichier:tg.jpg||right|vignette|upright=1.5|]]<br />
Une fois ceci fait, il fallait réaliser le plus important du jeu : les touches à actionner ! <br />
<br />
Pour cela, il était préférable de conserver la forme cylindrique du support en modélisant 4 pièces, d'un quart de disque chacune. Par soucis de fixation sur la croix et par envie d’esthétisme, les touches seraient un peu incurvées pour donner une forme moins géométrique au rendu final. <br />
<br />
De plus, elles seront perforées pour laisser passer une LED de la même couleur que la touche sur laquelle elle se trouve. Ainsi l'utilisateur pourra mémoriser les touches à activer via le système lumineux des LEDs. <br />
<br />
Enfin, un cylindre permettant l'accroche sur la croix à été prévu sur la partie inférieure de les touches du Simon. (suite à une impression peu précise, ce cylindre sera « fondu » pour épouser la forme de la croix sans jeu dans la fixation.)<br />
<br />
[[Fichier:touc2.jpg||left|vignette|upright=1.7|]]<br />
Vint ensuite le moment de la création ! L'impression de ces pièces étant la plus complexe, nous pensions qu'il serait nécessaire de les recommencer plusieurs fois. La WitBox du Fabricarium (la plus précise des imprimantes mise à notre disposition) a réalisé une impression assez laborieuse. Un gros travail de ponçage à donc dû être réalisé, car le support nécessaire pour imprimer cette pièce « incurvée » avait donné de nombreuses bavures sur la surface des touches. Afin que le toucher reste agréable, nous avons donc retravaillé les pièces.<br />
<br />
<br />
Une fois ceci fait, nous avons essayé de les positionner sur la croix prévue à cet effet. Une fois encore, nous étions confronté aux limites de l'impression 3D. Les dimensions du « cylindre pillier » étant non précise, et cette partie étant trop fine pour être sciée sans rupture de la pièce, nous avons décidé de faire « fondre » cette partie et de la placer, encore chaude sur la partie en forme de croix. Cela permettait une fixation sûre et une dimension épousant parfaitement les formes du support. L'inconvénient fut que cette méthode, peu précise, n'a fait qu'accentuer les erreurs d'impressions au niveaux du visuel. Effectivement, les 4 pièces ne semblent pas régulières et le disque qu'elles sont censées former (ensemble de 4 quarts de disque) ne semble pas parfait.[[Fichier:bttt.jpg||right|vignette|upright=1.5|]][[Fichier:socle.jpg||right|vignette|upright=1.5|]]<br />
<br />
<br />
Nous décidons cependant de conserver ce léger défaut, car si nous recommencions nous risquerions d'être de nouveau confronté au même souci, l'erreur n'étant pas uniquement dû à notre manipulation mais également à l'imprimante 3D. <br />
<br />
<br />
L'impression du socle était la plus longue à imprimer (près de 6 heures) .Après l'avoir un peu scié comme prévu, cette pièce était également prête à être peinte. Nous avons fait de même avec la croix à placer sur le socle et servant de support aux quatre touches du Simon. Cette impression étant rapide et facile, un seul essai suffit pour obtenir notre version définitive. L'impression fut dans ce cas, parfaitement aux mesures souhaitées dans le fichier .stl (bien que réalisé avec une imprimante de moins bonne qualité que la WitBox). Ainsi les boutons poussoirs que nous avions à positionner dessus tenaient sans souci par un simple encastrement. Par la suite, par mesure de sécurité, <br />
nous avons tout de même rajouté un point de colle en dessous des boutons pour éviter tout désencastrement non souhaité. <br />
[[Fichier:tr.jpg||left|vignette|upright=1.4|]]<br />
<br />
<br />
<br />
En parallèle, nous avons travaillé sur les différentes couches d'épaisseur de la guitare. Dans un premier temps il était nécessaire de retirer une partie dans le manche pour y placer les boutons poussoirs. Cette étape aurait pu être réalisé rapidement avec la découpeuse laser, mais celle ci étant en panne, nous l'avons fait via une perceuse et un foret au Fabricarium. Le résultat était un peu moins net mais convenable cependant. De plus le "trou" sera caché par la pièce contenant les touches. Une fois la couche de bois travaillée, nous avons creusé la partie cartonnée afin de pouvoir y laisser passer les différents câbles liant les boutons poussoirs (situés sous les touches du manche de la guitare) à une breadboard (sur la partie basse de l'instrument).<br />
<br />
Afin que les câbles sortent de la guitare de façon propre, nous avons percé 4 trous à la base du manche. Ainsi de chaque trou ressortira deux fils de connectique ( un pour l'entrée du bouton poussoir et un pour la sortie).<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:tt.jpg||left|vignette|upright=2|]]<br />
Ceci étant terminé, il fallait passer à la conception des touches de la guitare.[[Fichier:touc.jpg||right|vignette|upright=2.2|]]<br />
C'est en observant une imprimante 3D du Fabricarium qu'une idée de modèle touche vue le jour. Nous allions faire une seule et unique pièces pour les 4 touches.<br />
Fine, elle pourrait être facilement pliée sous une pression du doigts pour actionner un bouton poussoir situé en dessous de chacune des 4 touches.suffirait juste de peindre les 4 touches de couleurs différentes pour les différencier.<br />
Cette pièce serait fixée sur le manche de la guitare, couvrant une couche de bois perforée et une cartonnée « creusée » pour laisser passer la connectique jusqu'à la partie inférieure de la guitare.<br />
<br />
Finalement, il aura fallut quelques heures supplémentaires des séances pour avoir toutes nos partie modéliser sur FREECAD et prête à être imprimées, qu'elles soient destinées au Simon ou au Guitar Hero.<br />
<br />
L'heure est donc à la réalisation ! Les impressions 3D se sont faites sur l'imprimante d'un des membre du groupe ainsi que sur celles du Fabricarium. <br />
<br />
Les touches qui actionneraient les boutons poussoirs étaient les plus à même d'être à recommencer. En effet, un problème de fixation, ou encore une rigidité trop grande empêcherait l'actionnement du bouton et serait donc inutilisable. Ainsi nous avons commencé par imprimer les touches (pour la guitare et pour le simon). Dans un premier temps, nous nous sommes occupés de la pièce pour la guitare. La première impression fut décevante, car trop épaisse (8mm) , la pièce ne pliait pas sous la pression des doigts et n’actionnait donc pas les boutons placés dessous.<br />
<br />
Ce pourquoi nous avons lancé immédiatement une nouvelle impression avec 3mm d'épaisseur. Les tests étant concluants, nous n'avions plus qu'à la peindre de 4 couleurs différentes pour symboliser les 4 touches du guitar hero. <br />
<br />
<br />
Ceci commença par la réalisation de soudures des boutons poussoirs avec les fils. Ces fils seraient ensuite placés sous la couche de bois, dans la couche de carton. Cette étape fut rapidement terminée.<br />
<br />
Les 8 boutons poussoirs étaient prêts ! Quatre pour la guitare, quatre pour le jeu de Simon.<br />
<br />
Finalement, toutes les pièces étant réalisées, il fallait réaliser un travail d'assemblage, et de finitions (au niveaux des couches de peinture notamment). <br />
<br />
Nous nous sommes préalablement assuré que tous les boutons poussoirs étaient fonctionnels et que les soudures étaient correctement réalisées grâce à des tests rapides avec la carte arduino.<br />
<br />
<br />
[[Fichier:led.jpg||left|vignette|upright=1.2|]][[Fichier:end.jpg||RIGHT|vignette|upright=1.3|]]<br />
Enfin, il ne restait plus qu'à peindre nos différentes pièces.<br />
<br />
Premièrement nous avons appliqué deux couches de blanc sur chacune des pièces. Puis sur celles qui nécessitaient une couleur précise ( en autre : les touches de la guitare et du Simon), nous avons repassé deux couches de couleur dessus.<br />
Puis, nous avons assemblé toutes les pièces entre elles pour obtenir le résultat final ! <br />
<br />
L'assemblage des différentes couches de la guitare à d'abord était provisoirement fait avec de la colle forte. Si le collage venait à céder, nous utiliserons sans doute des vis ou des accroches en plastique pour maintenir le tout en place.<br />
<br />
Nous en avons profité pour utiliser la peinture restantes pour décorer un peu notre guitare et ainsi la personnaliser comme bon nous semblait.<br />
<br />
<br />
<br />
<br />
<br />
Finalement, le résultat est plus que satisfaisant ! Les quatre couleurs primaires étant vives, elles donnent un aspect coloré et joyeux à notre projet ! Les quatre touches du Simon, surmontées d'une LED de la même couleur que la touche, permettent une utilisation claire et facile du « jeu de Simon ».<br />
<br />
<br />
Dans la globalité, nous sommes assez fiers du résultat de la partie mécanique ! Que ce soit du "jeu de Simon" ou de la Guitare du "Guitar Héro", les boutons poussoirs sont activables facilement (voir la vidéo de démonstration en cliquant sur le lien suivant :[https://youtu.be/3-p--BhHGr4] ). De plus le résultat est assez agréable à regarder ou encore facile a prendre en main. <br />
<br />
<br />
<br />
La partie mécanique étant bien avancée avant la fin du projet, nous avons décidé de procéder à certaines améliorations. En effet, les tests des parties électronique et informatique pouvaient donc s’effectuer sur le Simon et la guitare ainsi réalisée. Ainsi dans tous les cas nous avions deux prototypes à présenter à la fin du projet.<br />
<br />
En parallèle, une version plus élaborée de la guitare pouvait ainsi être en construction.<br />
Pour se faire, nous avons repris le fichier SVG explicité lors de la première séance et nous lui avons rajouté un rectangle rouge au niveau du manche, pour une découpe plus propre à la découpeuse laser, et moins fragilisante pour le bois.<br />
<br />
[[Fichier:entretoise.jpg||right|vignette|upright=1.5|]]<br />
[[Fichier:cote.jpg||left|vignette|upright=1.5|]]<br />
<br />
<br />
De plus pour gagner en propreté, nous avons placé un PCB pour éviter l’encombrement.<br />
Enfin, nous avons pris la décision de laisser la guitare creuse, afin de pouvoir mieux voir le contenu électronique à l’intérieur et de garder un aspect plus propre et épuré de la guitare.<br />
<br />
Pour ce faire, nous allons utiliser des entretoises qui permettront une largeur de guitare homogène. Afin d’éviter une pliure du bois au niveau des touches (et ainsi éviter que les touches ne soient pas actionnées car pas d’opposition de force), nous avons insisté sur les entretoises au-dessous des touches (que nous avons pris soin de fixer avec de la colle pour éviter de fragiliser le bois au niveau du manche en le perçant).<br />
<br />
Finalement, les touches sont activables facilement, une fois la guitare prise en main. Un signal logique bas est bien transmis une fois les touches appuyées. Et il est bien détecté par l’arduino. <br />
<br />
[[Fichier:guitaredroite.jpg||center|vignette|upright=2|]]<br />
<br />
<br />
<br />
Désormais, la partie mécanique étant terminée et fonctionnelle, il faut la lier à la partie informatique et électronique. Nous allons perfectionner la partie FPGA et Arduino pour exploiter pleinement les deux supports (guitare et jeu de Simon) ainsi réalisés.<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Conclusion </div>==<br />
<br />
<br />
En conclusion, Le jeu de Simon est terminé et est fonctionnel''. En effet le serveur websocket envoie une combinaison de couleur, composée par un utilisateur, à l’arduino, qu’un second utilisateur devra tenter de reproduire (couleur par couleur, en reprenant du début à chaque fois, avec une couleur en plus à chaque tour). Le Jeu de Simon est terminé : L’objectif principal de notre projet est donc réalisé.<br />
<br />
Cependant, le Guitar Héro n’a pas pu être abouti. Nous avions précisé dès le début du projet que nous tâcherions de finir le Simon en priorité et de faire le Guitare Héro ensuite. La guitare est finalisée et fonctionnelle. Nous n’étions donc pas si loin de terminer les deux projets. <br />
Nous sommes globalement satisfaits du travail réalisé et de la prestation proposée. En effet en sachant que nous avions deux projets en simultané (bien que très ressemblant entre eux) nous avons su terminer le premier et bien avancer sur le second. Le but principal était de nous amuser, de prendre du plaisir dans la réalisation d'un projet et de faire quelque chose qui nous plaisait avant tout, l’objectif est atteint.<br />
<br />
Le FPGA n'a pas pu être aboutit non plus, et c'est dommage, car c'est une technologie intéressante, et c'est plus optimisé et rapide qu'une Arduino. <br />
<br />
Ce projet fut très intéressant car il nous a permis de mettre en application certains de nos cours étudiés cette année en IMA3, mais également d’en apprendre énormément par nous même à force de pratique et de recherches personnelles. Pour l’ensemble des membres du groupe, ce projet a été la confirmation de l’intérêt porté aux systèmes communicants, et nous a donc convaincu de choisir la filière SC à partir du semestre 8 en IMA4.<br />
<br />
<br />
La démonstration du fonctionnement du Jeu de Simon, est disponible à l'adresse suivante : https://youtu.be/RbgPtALDmFw .</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=Projet_IMA3_P3,_2016/2017,_TD1&diff=44307Projet IMA3 P3, 2016/2017, TD12017-06-18T20:27:39Z<p>Adurot : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 25px; padding: 20px; font-weight: bold; text-align: center; font-size: 98%; background: #6060FF; vertical-align: top; width: 99%;"> Projet IMA3-SC 2016/2017 : Le Jeu de Simon et le Guitar Hero </div>=<br />
<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Cahier des Charges </div>==<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Description du système </div>===<br />
<br />
* L'objectif principal de notre projet est de réaliser un jeu qui utilise à la fois les lumières et le son. Pour cela, nous avons pensé à deux versions : le Simon et un jeu du type Guitar Hero.<br />
<br />
* Le Simon est constitué de quatre boutons de couleurs différentes : un bleu, un rouge, un vert et un jaune. Le jeu va afficher une séquence de couleurs qui sont chacune associées à un son. Le joueur doit ensuite se souvenir de la suite (en s'aidant du son et des couleurs comme moyen mnémotechnique) pour la reproduire dans le bon ordre en appuyant sur les boutons.<br />
<br />
* Le jeu Guitar Hero, quant à lui, est un jeu où il faut actionner des boutons de couleur précise, au moment où elles apparaissent sur une barre de défilement, à l'écran. Ces différentes activations, aux bons moments, permettent de réaliser une mélodie plus ou moins complexe selon la difficulté de la chanson à reproduire. Le tout est effectué grâce à une guitare connectée, afin de pousser l'expérience de simulation un peu plus loin. Si nous réalisons, ce jeu, il faut prendre en compte un affichage plus complexe. De plus, le Guitar Hero ajoute une notion de temps de réponse, plus difficile à gérer. Ce temps de réponse permet de laisser une courte marge d'erreur dans la réactivité de l'utilisateur, pour simuler pleinement l'utilisation d'une guitare électrique.<br />
<br />
<br />
Nous avons choisis de d'abord nous concentrer sur le Simon et de faire le jeu Guitar Hero seulement si nous avons le temps.<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Le matériel </div>===<br />
<br />
Pour ce projet nous utiliserons :<br />
<br />
* Une page internet sur l'ordinateur pour pouvoir modifier les différents aspects du jeu : les règles du jeu, la musique jouée par le Simon ou bien la difficulté<br />
<br />
* Le Raspberry Pi, utilisée en tant que serveur, va envoyer les données en série ( qui seront traitées par le FPGA ), de les recupérer, et de faire l'algorithme.<br />
<br />
* Une carte Arduino pour relier la Raspberry Pi aux composants dans un premier temps : elle nous permet de coder en C (au lieu d'un langage assembleur) pour créer des programmes et gérer les différents modules tel que les boutons et les LEDs. Elle permettra une simulation momentanée du FPGA, afin que nous puissions avancer sur la partie informatique, sans attendre d'en avoir fini avec la partie FPGA.<br />
<br />
* Une fois le programme et les interactions fonctionnels, nous remplacerons l'Arduino par une FPGA qui est circuit logique programmable : on peut modifier les circuits logiques à l'intérieur mais on ne peut pas créer un programme avec un langage de plus haut niveau. Nous devrons donc utiliser des logiciels tiers qui nous permettront de placer des portes logiques (ET, OU,...) pour créer notre programme en assembleur.<br />
<br />
* Pour ce qui est de la partie mécanique, nous réaliserons une guitare en bois pour le "Guitar Hero" ainsi qu'un "jeu de Simon" réalisé via l'impression 3D.<br />
<br />
* Si le temps nous le permet, nous utiliserons un Xbee pour créer une connexion sans fil, afin d'expérimenter un module nouveau et acquérir de nouvelles compétences.<br />
<br />
*Nous utiliserons également des composants électroniques tels que des boutons poussoirs, des LEDs ou une matrice de LEDs pour l'affichage dans le cas du jeu de Simon, ainsi que de "l'essentiel" pour un système communiquant (à savoir résistances, fils électriques, etc...)<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Description des séances </div>==<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 21/03/17 Séance 1 : Répartition des tâches et premiers pas </div>===<br />
<br />
La première séance fut consacrée à la répartition des rôles et à la prise de conscience de la difficulté des différentes tâches. L'idée de faire un « jeu de Simon » que nous amélioreront ensuite en « guitar hero » a cependant été conservée.<br />
<br />
==== Partie électronique ====<br />
<br />
Nous avons décidé de concentrer deux personnes sur le FPGA car c'est un élément très complexe et complètement nouveau.<br />
Nous allons en effet devoir reflechir à très bas niveau avec simplement des registres et des portes logiques.<br />
<br />
L'objectif du composant sera de récupérer un message contenant les boutons sur lesquelles appuyer. <br />
Une fois ce message reçu, le FPGA va comparer le bouton saisi par l'utilisateur avec le bouton demander. <br />
S'il est correct, le FPGA va passer à la couleur suivante, sinon il va renvoyer un message pour dire à la Raspberry (ou l'ordinateur) que l'utilisateur s'est trompé.<br />
<br />
Pour commencer, nous réalisons le tutoriel pour allumer une LED qui va nous permettre de comprendre le fonctionnement de Altium Designer.<br />
Cela nous a pris du temps mais nous avons pu réaliser d'autres essaies avec des registres à décalages et des boutons.<br />
<br />
Nous avons ensuite directement commencer le Simon :<br />
Le choix a été fait d'utiliser des registres à décalages pour récupérer la séquence de couleur envoyé par l'ordinateur/la raspberry. <br />
Nous allons en effet stocker toute la séquence de la "partie" car sinon il faudrait gérer beaucoup d'échange entre l'ordinateur et le FPGA ce qui est lourd en Altium et fait perdre du temps réaction du programme.<br />
<br />
D'un point de vue technique, utiliser un registre à décalage semble être la meilleur méthode pour récupérer un à un les bits qui arrivent sur la liaison série puis nous utilisons 4 registres à décalage : 1 pour chaque couleur.<br />
Pour chacun des registres nous aurons donc une séquence comme suit : 0100010010111. Les 1 correspondent aux moments ou il faut appuyer sur la couleur et les 0 aux moments ou il ne faut pas appuyer sur cette couleur. <br />
Nous devons donc également gérer les clocks des registres "couleurs". Ces registres doivent arrêter leur clock lorsque les bits de chaque couleur est à 0.<br />
<br />
Le registre pour la liaison série sera la clock du système puisqu'elle doit lire toute la séquence mais elle doit également s'arrêter lorsque le FPGA arrive à la fin de la séquence. Pour lui indiquer la fin de la séquence nous avons choisit le mot 0000 car il y aura toujours un bouton à appuyer pour le jeu Simon.<br />
<br />
==== Partie informatique ====<br />
<br />
L'objectif ici était la découverte des technologies à utiliser pour le système. Notamment une Arduino en liaison série à un PC et un serveur Websockets codé en C.<br />
La partie programmation arduino ne fut pas un problème. En effet, ce n'était pas la première fois que nous utilisions cet outil, et donc la mise en place de la liaison série fut très rapide.<br />
Ce n'est cependant pas le cas de la communication websockets. Bien que l'exemple de code fourni par M. Redon soit fonctionnel, le code n'en reste pas moins complexe à comprendre. Il fallait donc réussir à modifier le code du serveur websockets, afin de relier les deux systèmes entre eux.<br />
<br />
==== Partie mécanique : un modèle de guitare à découper====<br />
<br />
<br />
Dans cette première séance, nous avons décidé de focaliser nos premiers efforts sur la partie mécanique du "guitar hero". En effet, le « jeu de simon » pouvait être avancé plus tard car plus facile à modéliser et à réaliser.[[Fichier:1.jpg||right|vignette|upright=2|]]<br />
Nous sommes alors partis sur l'idée de créer une maquette de guitare, sur laquelle nous allions disposer différents boutons de couleur, actionnables grâce à une pression sur le manche de l'instrument. Nous avions une ligne directrice mais pas encore d'idée précise de comment allait être réalisé la guitare, ni même ce à quoi elle allait ressembler.<br />
<br />
<br />
Nous avons décidé de découper la guitare en bois qui nous servirait de support pour notre « guitar hero » grâce à la découpeuse laser. Pour se faire, un fichier conforme à la découpe devait être réalisé. <br />
Ainsi nous avons donc pris une image de guitare depuis internet. Dans le logiciel « GIMP », nous avons ensuite repassé les contours de l'instrument en rouge. Une fois ceci fait, nous avons effacé l'image de la guitare originale pour ne garder que les contours rouges. Enfin après quelques réglages, l'export en fichier SVG permettait une découpe précise. Les contours de la guitare sont disponibles ci contre (cliquez sur l'image pour bien voir).<br />
<br />
A la fin de la séance, la guitare était prête à être réalisée et nous avons décidé de faire l'intégralité du « jeu de simon » via l'impression 3D. Cependant, aucune grande avancée n'a eu lieu sur la partie mécanique du jeu de Simon lors de cette séance.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 28/03/17 Séance 2 : Poursuite du Projet et rencontre des premiers problèmes </div>===<br />
<br />
La deuxième séance fut davantage productive, car chacun de nous savait les différentes tâches qu'il lui restait à accomplir.<br />
<br />
==== Partie électronique ====<br />
Nous nous sommes rendu compte qu'utiliser le registre à décalage pour la liaison série comme nous le faisions n'était pas possible.<br />
En effet, la liaison série est en asynchrone et nous ne connaissance donc pas la clock. <br />
Nous ne pouvons donc pas utiliser cette clock pour le registre à décalage car sinon nous risquons de ne pas lire assez vite (ou trop vite) et donc récupérer trop de valeurs ou en rater.<br />
<br />
Le professeur nous a donc indiqué qu'il nous mettrait à disposition un module qui va s'occuper justement de lire la liaison série et de garder la séquence et de ressortir le message en parallèle.<br />
Ce composant envoie également sur un autre pin un 1 à chaque fois qu'un bit est envoyé par la liaison série (et reçu par le composant).<br />
Nous utilisons, selon ses conseils, un module analogique-digital qui va nous permettre de simuler l'envoi de la séquence.<br />
Après plusieurs tentatives nous avons un programme qui fonctionne correctement pour recevoir les valeurs. Il nous reste à comparer l'appui d'un bouton et la couleur à presser.<br />
<br />
==== Partie informatique ====<br />
<br />
L'écriture du programme de communication fut terminé assez rapidement. Mais il ne fonctionnait pas...<br />
En effet, un problème s'opérait lors de l'appel de la liaison série par le serveur websocket à réception d'un message.<br />
<br />
L'incompréhension régnait un peu, car à nos yeux tout était sensé fonctionner. Le principe était assez simple : à réception d'un message par le serveur websockets, ce dernier devait ouvrir une communication série sur le port TTY_USB0 (ou TTY_ACM0 en fonction de l'arduino) à 9600 bauds, y transférer le message reçu, puis refermer la communication.<br />
<br />
Après un long moment de doute, le problème fut résolu. Ce dernier était assez idiot. En effet, notre fonction d'envoi de message via le port série s'appelait : " send(..) ". Il s'avère qu'une fonction d'une des librairies utilisées se nomme de la même manière. Il y avait donc conflit et empêchait le programme de fonctionner correctement.<br />
<br />
Nous avons donc pu relier l'ordinateur à un montage de prototypage Arduino/LEDs afin de tester le bon fonctionnement du programme. Une combinaison de 4 LED devait s'allumer à réception d'un caractère. Il fallait donc envoyé un message compris entre 0(aucune LED allumée) et 15(toutes les LED allumées). Cependant, le début de la table ASCII ne représente pas des caractères. Le serveur envoie donc un message alphabétique compris entre 65 ('A') et 80 ('P') et l'arduino interprète ceci comme une valeur de 0 a 15<br />
<br />
==== Partie mécanique : découpe de la guitare, modélisation et impression d'un prototype de touches pour cette dernière ====<br />
<br />
[[Fichier:pp.jpg||left|vignette|upright=0.8|]]Cette séance fut entamée par la découpe de la guitare grâce à la découpeuse laser du Fabricarium de Polytech. Dans un premier temps il a d'abord était nécessaire « d'apprivoiser » la découpeuse et d'apprendre à bien la configurer pour obtenir le résultat souhaité, sans risques. Un premier essai a d'abord était réalisé dans du carton pour pouvoir juger des différentes dimensions de la guitare.<br />
Enfin, une seconde version, en bois, fut réalisée durant cette séance. Finalement nous décidons de partir sur l'idée d'une guitare réalisée en 4 couches d'épaisseur : 2 extérieures en bois ( une de face, décorée avec les boutons à actionner et la carte arduino et une seconde, arrière, de protection), et deux intérieures en carton(creusées pour laisser passer les fils de connectiques).<br />
<br />
Note : Malheureusement, une des couche en bois a était cassée par la suite lors de la confection de la guitare. La panne prolongée de la découpeuse laser nous a contraint à renoncer à l'idée d'une quatrième couche en bois de protection.[[Fichier:po.jpg||right|vignette|upright=1.2|]]<br />
<br />
<br />
De plus, via le logiciel de modélisation FreeCAD, nous avons commencé à concevoir deux prototypes de « touches » (boutons) pour la guitare. <br />
<br />
L'idée était de créer des surfaces larges (pouvant recueillir une phalange de doigts au minimum) faisant office de touches, en dessous desquelles nous insérerions un bouton poussoir 4 pins (fournis par les professeurs). La création de touches plus larges était indispensable. En effet, les boutons poussoirs étaient bien trop petits pour avoir un actionnement facile et agréable.<br />
Nous avons pu lancer l'impression des touches à la fin de la séance. Cependant, les différents tests et les défauts d'impression nous ont fait comprendre qu'il serait difficile de « glisser » un bouton poussoir dans une touche avec un espace assez étroit pour le maintenir, sans pour autant bloquer son actionnement lorsqu'une pression était appliquée. De plus, la fixation risquait d'être assez complexe. <br />
Nous avons alors décidé de faire un tout autre type de touche mais avec le même fonctionnement. Pour cela nous allions avoir besoin de modéliser et d'imprimer de nouveaux un prototype de touche.<br />
Il allait ensuite falloir percer la première couche en bois de la guitare. Puis il serait également nécessaire de creuser les sous couches en carton pour y placer les boutons poussoirs et les différents câbles.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 05/04/2017 Séance 3 : Encore beaucoup de choses à faire !</div>===<br />
<br />
Bien que ce soit notre dernière séance officielle, nous savions que nous allions avoir besoin de beaucoup de temps pour terminer ce projet ! <br />
<br />
==== Partie électronique ====<br />
[[Fichier:fpga.png|||vignette|upright=2|]]<br />
Le but de cette séance était de finaliser le FPGA et d'ajouter les blocs reception.vhdl et emission.vhdl fournis par M. Boé, ils nous permettent de gerer facilement la conversion serie / parallèle en asynchrone. Ainsi nous pouvons tester notre FPGA et nous rendre compte que ça ne marche pas, il y a un problème que nous n'arrivons pas à résoudre.<br />
Compte tenu du temps imparti, et du fait que la nanoboard n'était pas "embarquable", nous avons décidé de nous concentrer sur l'arduino afin d'avoir quelque chose qui fonctionne.<br />
<br />
==== Partie informatique ====<br />
<br />
<br />
L'objectif de la séance était la mise en place de l'interface WEB, notamment pour le jeu Guitar Hero. <br />
<br />
Nous avons utilisé un canvas Javascript afin de dessiner un interface similaire a celle du jeu original.<br />
<br />
==== Partie mécanique ====<br />
<br />
La troisième séance était destinée à l’élaboration du jeu de Simon. Une première idée était de créer quatre pièces plates, composées de multiples leds, qu'il faudrait actionner via une simple pression. Cependant, nous nous sommes dit qu'une seule LED pour une couleur, suffisait à indiquer la combinaison à reproduire. <br />
<br />
Le tout devait être assez grand pour contenir la carte arduino ainsi que toute la connectique, sans pour autant être trop encombrant, tout en étant assez ergonomique et agréable au regard.<br />
<br />
Nous avons donc décidé de créer un support creux qui contiendrait la partie électronique , au dessus duquel nous placerions les 4 pièces de couleur avec une LED pour chaque couleur.<br />
<br />
Nous savions dès lors, qu'un travail long minutieux nous attendait.<br />
<br />
Ainsi nous avons fait de nombreux croquis avec les différentes pièces et leurs dimensions éventuelles. Des pièces que nous allions réaliser uniquement en impression 3D. Un travail similaire a été réalisé pour la guitare, afin de ne pas percer la guitare à de mauvais endroits, et pour agencé les différents parties à ajouter sur la guitare de la meilleure façon possible. Pour résumer cette séance, nous avons réalisé tous les croquis nécessaires à la réalisation de la guitare et du Simon.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Séance supplémentaire : Terminons ce Projet !</div>===<br />
<br />
Il n'y a pas eu un nombre précis de "séances supplémentaires". Chacun des membres du groupe travaillait soit chez lui, soit à l'école de manière régulière, afin d'avancer sa partie le plus rapidement possible.<br />
<br />
==== Partie électronique ====<br />
[[Fichier:pcb1.jpg|left|vignette|upright=0.8|]]<br />
[[Fichier:pcb2.jpg|right|vignette|upright=0.8|]]<br />
Pour le Simon, il a fallut souder les câbles aux boutons et aux leds ( avec leur résistance ). Pour se faire, on a utilisé un circuit à pastilles qui se place entre l'arduino et les boutons/led. Cela permet de prendre moins de place et de faire plus propre qu'une breadboard.<br />
<br />
=== Partie informatique ===<br />
<br />
La partie FPGA n'étant pas fonctionelle, il a fallut le remplacer par un Arduino. <br />
<br />
Le code de l'Arduino consiste en une succession d'étapes pour jouer. Tout d'abord il faut recevoir via le port série la séquence totale du Simon, sous la forme de chaîne de caractères. Par exemple si le message reçu est "RVBR", alors la séquence totale du Simon sera Rouge Vert Bleu Rouge. Ainsi une fonction reception_message a été codée, qui attend la réception série de la séquence. <br />
<br />
Dans l'algorithme du jeu en lui même on a une variable globale qui stocke l'état de la partie, et une qui stocke l'étape de la séquence. Ainsi en fonction de l'état de la partie on va soit jouer la séquence sur les leds, lire l'état des boutons, ou provoquer un game over.<br />
<br />
La fonction playSequence va parcourir la séquence totale jusqu'à l'étape actuelle et va allumer les différentes leds en conséquence.<br />
<br />
La fonction readSequence va elle lire l'état successif des boutons et le comparer à la séquence actuelle. Si il y a une erreur, on sort de la fonction, et l'état de la partie devient un game over. Sinon, on continue et on appelle playSequence en incrémentant l'étape. En cas de réussite de la séquence, les 4 leds s'allument pour indiquer lé réussite et le passage au niveau supérieur.<br />
<br />
Coté websockets, c'est facile, dès qu'on reçoit un message par le client, on l'envoie à l'arduino ( bien qu'on aurait du vérifier la conformité du message ), l'arduino ne lira le message que si on est en étape de lecture de la séquence, donc après un game over par exemple. <br />
<br />
==== Partie mécanique : Suite et fin de la confection de la guitare et du jeu de Simon====<br />
<br />
Comme nous l'avons prédit, la plus grosse partie du travail réalisé a dû être faite lors de séances supplémentaires ou par travail personnel chez soi.<br />
<br />
Après avoir réalisé les croquis, il était essentiel de créer rapidement les différents supports. En effet, cela nous permettait d'avoir du temps pour éventuellement recommencer et revoir les axes de travail en cas d'impossibilité de réalisation pour quelconque raison. De plus, une fois la partie mécanique terminée, nous pouvions l'utiliser comme support pour les tests électroniques. Enfin, cela nous laissait du temps en fin de projet pour décorer notre projet, que nous voulions personnalisé afin d'en être le plus satisfaits possible. <br />
<br />
Un gros travail de modélisation à dû être fait sur FREECAD. Le support du jeu de Simon fut la pièce la plus simple à réaliser (un cylindre semi fermé, de 7 cm de rayon).<br />
<br />
Puis une simple découpe grâce à une scie permettrait de faire réceptacle pour une "croix porteuse" sur laquelle serait disposés les touches du Simon.<br />
<br />
De la même façon que pour la guitare, les touches seraient placées au dessus de boutons poussoirs. Ces derniers seront collés sur la croix. <br />
[[Fichier:tg.jpg||right|vignette|upright=1.5|]]<br />
Une fois ceci fait, il fallait réaliser le plus important du jeu : les touches à actionner ! <br />
<br />
Pour cela, il était préférable de conserver la forme cylindrique du support en modélisant 4 pièces, d'un quart de disque chacune. Par soucis de fixation sur la croix et par envie d’esthétisme, les touches seraient un peu incurvées pour donner une forme moins géométrique au rendu final. <br />
<br />
De plus, elles seront perforées pour laisser passer une LED de la même couleur que la touche sur laquelle elle se trouve. Ainsi l'utilisateur pourra mémoriser les touches à activer via le système lumineux des LEDs. <br />
<br />
Enfin, un cylindre permettant l'accroche sur la croix à été prévu sur la partie inférieure de les touches du Simon. (suite à une impression peu précise, ce cylindre sera « fondu » pour épouser la forme de la croix sans jeu dans la fixation.)<br />
<br />
[[Fichier:touc2.jpg||left|vignette|upright=1.7|]]<br />
Vint ensuite le moment de la création ! L'impression de ces pièces étant la plus complexe, nous pensions qu'il serait nécessaire de les recommencer plusieurs fois. La WitBox du Fabricarium (la plus précise des imprimantes mise à notre disposition) a réalisé une impression assez laborieuse. Un gros travail de ponçage à donc dû être réalisé, car le support nécessaire pour imprimer cette pièce « incurvée » avait donné de nombreuses bavures sur la surface des touches. Afin que le toucher reste agréable, nous avons donc retravaillé les pièces.<br />
<br />
<br />
Une fois ceci fait, nous avons essayé de les positionner sur la croix prévue à cet effet. Une fois encore, nous étions confronté aux limites de l'impression 3D. Les dimensions du « cylindre pillier » étant non précise, et cette partie étant trop fine pour être sciée sans rupture de la pièce, nous avons décidé de faire « fondre » cette partie et de la placer, encore chaude sur la partie en forme de croix. Cela permettait une fixation sûre et une dimension épousant parfaitement les formes du support. L'inconvénient fut que cette méthode, peu précise, n'a fait qu'accentuer les erreurs d'impressions au niveaux du visuel. Effectivement, les 4 pièces ne semblent pas régulières et le disque qu'elles sont censées former (ensemble de 4 quarts de disque) ne semble pas parfait.[[Fichier:bttt.jpg||right|vignette|upright=1.5|]][[Fichier:socle.jpg||right|vignette|upright=1.5|]]<br />
<br />
<br />
Nous décidons cependant de conserver ce léger défaut, car si nous recommencions nous risquerions d'être de nouveau confronté au même souci, l'erreur n'étant pas uniquement dû à notre manipulation mais également à l'imprimante 3D. <br />
<br />
<br />
L'impression du socle était la plus longue à imprimer (près de 6 heures) .Après l'avoir un peu scié comme prévu, cette pièce était également prête à être peinte. Nous avons fait de même avec la croix à placer sur le socle et servant de support aux quatre touches du Simon. Cette impression étant rapide et facile, un seul essai suffit pour obtenir notre version définitive. L'impression fut dans ce cas, parfaitement aux mesures souhaitées dans le fichier .stl (bien que réalisé avec une imprimante de moins bonne qualité que la WitBox). Ainsi les boutons poussoirs que nous avions à positionner dessus tenaient sans souci par un simple encastrement. Par la suite, par mesure de sécurité, <br />
nous avons tout de même rajouté un point de colle en dessous des boutons pour éviter tout désencastrement non souhaité. <br />
[[Fichier:tr.jpg||left|vignette|upright=1.4|]]<br />
<br />
<br />
<br />
En parallèle, nous avons travaillé sur les différentes couches d'épaisseur de la guitare. Dans un premier temps il était nécessaire de retirer une partie dans le manche pour y placer les boutons poussoirs. Cette étape aurait pu être réalisé rapidement avec la découpeuse laser, mais celle ci étant en panne, nous l'avons fait via une perceuse et un foret au Fabricarium. Le résultat était un peu moins net mais convenable cependant. De plus le "trou" sera caché par la pièce contenant les touches. Une fois la couche de bois travaillée, nous avons creusé la partie cartonnée afin de pouvoir y laisser passer les différents câbles liant les boutons poussoirs (situés sous les touches du manche de la guitare) à une breadboard (sur la partie basse de l'instrument).<br />
<br />
Afin que les câbles sortent de la guitare de façon propre, nous avons percé 4 trous à la base du manche. Ainsi de chaque trou ressortira deux fils de connectique ( un pour l'entrée du bouton poussoir et un pour la sortie).<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:tt.jpg||left|vignette|upright=2|]]<br />
Ceci étant terminé, il fallait passer à la conception des touches de la guitare.[[Fichier:touc.jpg||right|vignette|upright=2.2|]]<br />
C'est en observant une imprimante 3D du Fabricarium qu'une idée de modèle touche vue le jour. Nous allions faire une seule et unique pièces pour les 4 touches.<br />
Fine, elle pourrait être facilement pliée sous une pression du doigts pour actionner un bouton poussoir situé en dessous de chacune des 4 touches.suffirait juste de peindre les 4 touches de couleurs différentes pour les différencier.<br />
Cette pièce serait fixée sur le manche de la guitare, couvrant une couche de bois perforée et une cartonnée « creusée » pour laisser passer la connectique jusqu'à la partie inférieure de la guitare.<br />
<br />
Finalement, il aura fallut quelques heures supplémentaires des séances pour avoir toutes nos partie modéliser sur FREECAD et prête à être imprimées, qu'elles soient destinées au Simon ou au Guitar Hero.<br />
<br />
L'heure est donc à la réalisation ! Les impressions 3D se sont faites sur l'imprimante d'un des membre du groupe ainsi que sur celles du Fabricarium. <br />
<br />
Les touches qui actionneraient les boutons poussoirs étaient les plus à même d'être à recommencer. En effet, un problème de fixation, ou encore une rigidité trop grande empêcherait l'actionnement du bouton et serait donc inutilisable. Ainsi nous avons commencé par imprimer les touches (pour la guitare et pour le simon). Dans un premier temps, nous nous sommes occupés de la pièce pour la guitare. La première impression fut décevante, car trop épaisse (8mm) , la pièce ne pliait pas sous la pression des doigts et n’actionnait donc pas les boutons placés dessous.<br />
<br />
Ce pourquoi nous avons lancé immédiatement une nouvelle impression avec 3mm d'épaisseur. Les tests étant concluants, nous n'avions plus qu'à la peindre de 4 couleurs différentes pour symboliser les 4 touches du guitar hero. <br />
<br />
<br />
Ceci commença par la réalisation de soudures des boutons poussoirs avec les fils. Ces fils seraient ensuite placés sous la couche de bois, dans la couche de carton. Cette étape fut rapidement terminée.<br />
<br />
Les 8 boutons poussoirs étaient prêts ! Quatre pour la guitare, quatre pour le jeu de Simon.<br />
<br />
Finalement, toutes les pièces étant réalisées, il fallait réaliser un travail d'assemblage, et de finitions (au niveaux des couches de peinture notamment). <br />
<br />
Nous nous sommes préalablement assuré que tous les boutons poussoirs étaient fonctionnels et que les soudures étaient correctement réalisées grâce à des tests rapides avec la carte arduino.<br />
<br />
<br />
[[Fichier:led.jpg||left|vignette|upright=1.2|]][[Fichier:end.jpg||RIGHT|vignette|upright=1.3|]]<br />
Enfin, il ne restait plus qu'à peindre nos différentes pièces.<br />
<br />
Premièrement nous avons appliqué deux couches de blanc sur chacune des pièces. Puis sur celles qui nécessitaient une couleur précise ( en autre : les touches de la guitare et du Simon), nous avons repassé deux couches de couleur dessus.<br />
Puis, nous avons assemblé toutes les pièces entre elles pour obtenir le résultat final ! <br />
<br />
L'assemblage des différentes couches de la guitare à d'abord était provisoirement fait avec de la colle forte. Si le collage venait à céder, nous utiliserons sans doute des vis ou des accroches en plastique pour maintenir le tout en place.<br />
<br />
Nous en avons profité pour utiliser la peinture restantes pour décorer un peu notre guitare et ainsi la personnaliser comme bon nous semblait.<br />
<br />
<br />
<br />
<br />
<br />
Finalement, le résultat est plus que satisfaisant ! Les quatre couleurs primaires étant vives, elles donnent un aspect coloré et joyeux à notre projet ! Les quatre touches du Simon, surmontées d'une LED de la même couleur que la touche, permettent une utilisation claire et facile du « jeu de Simon ».<br />
<br />
<br />
Dans la globalité, nous sommes assez fiers du résultat de la partie mécanique ! Que ce soit du "jeu de Simon" ou de la Guitare du "Guitar Héro", les boutons poussoirs sont activables facilement (voir la vidéo de démonstration en cliquant sur le lien suivant :[https://youtu.be/3-p--BhHGr4] ). De plus le résultat est assez agréable à regarder ou encore facile a prendre en main. <br />
<br />
<br />
<br />
La partie mécanique étant bien avancée avant la fin du projet, nous avons décidé de procéder à certaines améliorations. En effet, les tests des parties électronique et informatique pouvaient donc s’effectuer sur le Simon et la guitare ainsi réalisée. Ainsi dans tous les cas nous avions deux prototypes à présenter à la fin du projet.<br />
<br />
En parallèle, une version plus élaborée de la guitare pouvait ainsi être en construction.<br />
Pour se faire, nous avons repris le fichier SVG explicité lors de la première séance et nous lui avons rajouté un rectangle rouge au niveau du manche, pour une découpe plus propre à la découpeuse laser, et moins fragilisante pour le bois.<br />
<br />
[[Fichier:entretoise.jpg||right|vignette|upright=1.5|]]<br />
[[Fichier:cote.jpg||left|vignette|upright=1.5|]]<br />
<br />
<br />
De plus pour gagner en propreté, nous avons placé un PCB pour éviter l’encombrement.<br />
Enfin, nous avons pris la décision de laisser la guitare creuse, afin de pouvoir mieux voir le contenu électronique à l’intérieur et de garder un aspect plus propre et épuré de la guitare.<br />
<br />
Pour ce faire, nous allons utiliser des entretoises qui permettront une largeur de guitare homogène. Afin d’éviter une pliure du bois au niveau des touches (et ainsi éviter que les touches ne soient pas actionnées car pas d’opposition de force), nous avons insisté sur les entretoises au-dessous des touches (que nous avons pris soin de fixer avec de la colle pour éviter de fragiliser le bois au niveau du manche en le perçant).<br />
<br />
Finalement, les touches sont activables facilement, une fois la guitare prise en main. Un signal logique bas est bien transmis une fois les touches appuyées. Et il est bien détecté par l’arduino. <br />
<br />
[[Fichier:guitaredroite.jpg||center|vignette|upright=2|]]<br />
<br />
<br />
<br />
Désormais, la partie mécanique étant terminée et fonctionnelle, il faut la lier à la partie informatique et électronique. Nous allons perfectionner la partie FPGA et Arduino pour exploiter pleinement les deux supports (guitare et jeu de Simon) ainsi réalisés.<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Conclusion </div>==<br />
<br />
<br />
En conclusion, Le jeu de Simon est terminé et est fonctionnel''. En effet le serveur websocket envoie une combinaison de couleur, composée par un utilisateur, à l’arduino, qu’un second utilisateur devra tenter de reproduire (couleur par couleur, en reprenant du début à chaque fois, avec une couleur en plus à chaque tour). Le Jeu de Simon est terminé : L’objectif principal de notre projet est donc réalisé.<br />
<br />
Cependant, le Guitar Héro n’a pas pu être abouti. Nous avions précisé dès le début du projet que nous tâcherions de finir le Simon en priorité et de faire le Guitare Héro ensuite. La guitare est finalisée et fonctionnelle. Nous n’étions donc pas si loin de terminer les deux projets. <br />
Nous sommes globalement satisfaits du travail réalisé et de la prestation proposée. En effet en sachant que nous avions deux projets en simultané (bien que très ressemblant entre eux) nous avons su terminer le premier et bien avancer sur le second. Le but principal était de nous amuser, de prendre du plaisir dans la réalisation d'un projet et de faire quelque chose qui nous plaisait avant tout, l’objectif est atteint.<br />
Le FPGA n'a pas pu être aboutit non plus, et c'est dommage, car c'est une technologie intéressante, et c'est plus optimisé et rapide qu'une Arduino. <br />
<br />
Ce projet fut très intéressant car il nous a permis de mettre en application certains de nos cours étudiés cette année en IMA3, mais également d’en apprendre énormément par nous même à force de pratique et de recherches personnelles. Pour l’ensemble des membres du groupe, ce projet a été la confirmation de l’intérêt porté aux systèmes communiquants, et nous a donc convaincu de choisir la filière SC à partir du semestre 8 en IMA4.<br />
<br />
<br />
La démonstration du fonctionnement du Jeu de Simon, est disponible à l'adresse suivante : https://youtu.be/RbgPtALDmFw .</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=Projet_IMA3_P3,_2016/2017,_TD1&diff=44306Projet IMA3 P3, 2016/2017, TD12017-06-18T20:25:56Z<p>Adurot : /* Partie électronique */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 25px; padding: 20px; font-weight: bold; text-align: center; font-size: 98%; background: #6060FF; vertical-align: top; width: 99%;"> Projet IMA3-SC 2016/2017 : Le Jeu de Simon et le Guitar Hero </div>=<br />
<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Cahier des Charges </div>==<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Description du système </div>===<br />
<br />
* L'objectif principal de notre projet est de réaliser un '''jeu''' qui utilise à la fois les '''lumières''' et le '''son'''. Pour cela, nous avons pensé à deux versions : '''le Simon''' et un jeu du type '''Guitar Hero'''.<br />
<br />
* Le '''Simon''' est constitué de '''quatre boutons de couleurs différentes''' : un bleu, un rouge, un vert et un jaune. Le jeu va '''afficher''' une séquence de couleurs qui sont chacune '''associées à un son'''. Le joueur doit ensuite se '''souvenir''' de la suite (en s'aidant du son et des couleurs comme moyen mnémotechnique) pour la '''reproduire''' dans le '''bon ordre''' en '''appuyant sur les boutons'''.<br />
<br />
* Le jeu '''Guitar Hero''', quant à lui, est un jeu où il faut '''actionner des boutons de couleur précise''', '''au moment où elles apparaissent''' sur une barre de défilement, '''à l'écran'''. Ces différentes '''activations''', aux '''bons moments''', permettent de '''réaliser une mélodie''' plus ou moins complexe selon la difficulté de la chanson à reproduire. Le tout est effectué grâce à '''une guitare connectée''', afin de pousser l'expérience de '''simulation''' un peu plus loin. Si nous réalisons, ce jeu, il faut '''prendre en compte''' un '''affichage''' plus '''complexe'''. De plus, le '''Guitar Hero''' ajoute '''une notion de temps de réponse''', plus '''difficile à gérer'''. Ce temps de réponse permet de laisser une '''courte marge d'erreur''' dans la '''réactivité de l'utilisateur''', pour '''simuler pleinement''' l'utilisation d'une '''guitare électrique'''.<br />
<br />
<br />
Nous avons choisis de d'abord nous concentrer sur le '''Simon''' et de faire le jeu '''Guitar Hero''' seulement '''si nous avons le temps'''.<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Le matériel </div>===<br />
<br />
Pour ce '''projet''' nous utiliserons :<br />
<br />
* Une '''page internet''' sur l'ordinateur pour pouvoir '''modifier les différents aspects du jeu''' : les '''règles du jeu''', la '''musique''' jouée par le Simon ou bien la '''difficulté'''<br />
<br />
* Le '''Raspberry Pi''', utilisée en tant que serveur, va envoyer les données en série ( qui seront traitées par le FPGA ), de les recupérer, et de faire l'algorithme.<br />
<br />
* Une '''carte Arduino''' pour '''relier''' la Raspberry Pi aux composants dans un premier temps : elle nous permet de '''coder en C''' (au lieu d'un langage assembleur) pour '''créer des programmes''' et '''gérer''' les différents '''modules''' tel que les '''boutons''' et les '''LEDs'''. Elle permettra une '''simulation''' momentanée du '''FPGA''', afin que nous puissions avancer sur la partie informatique, sans attendre d'en avoir fini avec la partie FPGA.<br />
<br />
* Une fois le programme et les interactions fonctionnels, nous '''remplacerons''' l'Arduino par une '''FPGA''' qui est '''circuit logique programmable''' : on peut '''modifier les circuits logiques''' à l'intérieur mais '''on ne peut pas créer un programme''' avec un '''langage''' de plus '''haut niveau'''. Nous devrons donc utiliser des '''logiciels tiers''' qui nous permettront de placer des '''portes logiques''' (ET, OU,...) pour '''créer notre programme en assembleur'''.<br />
<br />
* Pour ce qui est de la '''partie mécanique''', nous réaliserons une '''guitare en bois''' pour le''' "Guitar Hero"''' ainsi qu'un''' "jeu de Simon"''' réalisé via l''''impression 3D.'''<br />
<br />
* Si le temps nous le permet, nous utiliserons un '''Xbee''' pour créer une '''connexion sans fil''', afin '''d'expérimenter''' un '''module nouveau''' et '''acquérir''' de '''nouvelles compétences'''.<br />
<br />
*Nous utiliserons également des '''composants électroniques''' tels que des '''boutons poussoirs''', des '''LEDs''' ou une '''matrice de LEDs''' pour l'affichage dans le cas du jeu de Simon, ainsi que de '''"l'essentiel"''' pour un '''système communiquant''' (à savoir '''résistances''', '''fils électriques''', etc...)<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Description des séances </div>==<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 21/03/17 Séance 1 : Répartition des tâches et premiers pas </div>===<br />
<br />
La première séance fut''' consacrée à la répartition des rôles''' et à la '''prise de conscience '''de la '''difficulté des différentes tâches'''. L''''idée''' de faire un '''« jeu de Simon » '''que nous''' amélioreront '''ensuite en '''« guitar hero »''' a cependant été '''conservée'''.<br />
<br />
==== Partie électronique ====<br />
<br />
Nous avons décidé de concentrer deux personnes sur le FPGA car c'est un élément très complexe et complètement nouveau.<br />
Nous allons en effet devoir reflechir à très bas niveau avec simplement des registres et des portes logiques.<br />
<br />
L'objectif du composant sera de récupérer un message contenant les boutons sur lesquelles appuyer. <br />
Une fois ce message reçu, le FPGA va comparer le bouton saisi par l'utilisateur avec le bouton demander. <br />
S'il est correct, le FPGA va passer à la couleur suivante, sinon il va renvoyer un message pour dire à la Raspberry (ou l'ordinateur) que l'utilisateur s'est trompé.<br />
<br />
Pour commencer, nous réalisons le tutoriel pour allumer une LED qui va nous permettre de comprendre le fonctionnement de Altium Designer.<br />
Cela nous a pris du temps mais nous avons pu réaliser d'autres essaies avec des registres à décalages et des boutons.<br />
<br />
Nous avons ensuite directement commencer le Simon :<br />
Le choix a été fait d'utiliser des registres à décalages pour récupérer la séquence de couleur envoyé par l'ordinateur/la raspberry. <br />
Nous allons en effet stocker toute la séquence de la "partie" car sinon il faudrait gérer beaucoup d'échange entre l'ordinateur et le FPGA ce qui est lourd en Altium et fait perdre du temps réaction du programme.<br />
<br />
D'un point de vue technique, utiliser un registre à décalage semble être la meilleur méthode pour récupérer un à un les bits qui arrivent sur la liaison série puis nous utilisons 4 registres à décalage : 1 pour chaque couleur.<br />
Pour chacun des registres nous aurons donc une séquence comme suit : 0100010010111. Les 1 correspondent aux moments ou il faut appuyer sur la couleur et les 0 aux moments ou il ne faut pas appuyer sur cette couleur. <br />
Nous devons donc également gérer les clocks des registres "couleurs". Ces registres doivent arrêter leur clock lorsque les bits de chaque couleur est à 0.<br />
<br />
Le registre pour la liaison série sera la clock du système puisqu'elle doit lire toute la séquence mais elle doit également s'arrêter lorsque le FPGA arrive à la fin de la séquence. Pour lui indiquer la fin de la séquence nous avons choisit le mot 0000 car il y aura toujours un bouton à appuyer pour le jeu Simon.<br />
<br />
==== Partie informatique ====<br />
<br />
L'objectif ici était la découverte des technologies à utiliser pour le système. Notamment une Arduino en liaison série à un PC et un serveur Websockets codé en C.<br />
La partie programmation arduino ne fut pas un problème. En effet, ce n'était pas la première fois que nous utilisions cet outil, et donc la mise en place de la liaison série fut très rapide.<br />
Ce n'est cependant pas le cas de la communication websockets. Bien que l'exemple de code fourni par M. Redon soit fonctionnel, le code n'en reste pas moins complexe à comprendre. Il fallait donc réussir à modifier le code du serveur websockets, afin de relier les deux systèmes entre eux.<br />
<br />
==== Partie mécanique : un modèle de guitare à découper====<br />
<br />
<br />
Dans cette première séance, nous avons décidé de focaliser nos premiers efforts sur la''' partie mécanique''' du '''"guitar hero"'''. En effet, le '''« jeu de simon »''' pouvait être avancé '''plus tard''' car plus''' facile''' à '''modéliser''' et à''' réaliser.'''[[Fichier:1.jpg||right|vignette|upright=2|]]<br />
Nous sommes alors partis sur l'idée de créer une''' maquette de guitare''', sur laquelle nous allions '''disposer''' différents '''boutons de couleur''', '''actionnables''' grâce à une '''pression''' sur le manche de l'instrument. Nous avions une '''ligne directrice''' mais pas encore d''''idée précise''' de comment allait être réalisé la guitare, ni même '''ce à quoi elle allait ressembler'''.<br />
<br />
<br />
Nous avons décidé de découper la '''guitare en bois''' qui nous servirait de support pour notre '''« guitar hero »''' grâce à la''' découpeuse laser'''. Pour se faire, un '''fichier conforme à la découpe''' devait être réalisé. <br />
Ainsi nous avons donc pris une '''image de guitare''' depuis '''internet'''. Dans le logiciel''' « GIMP »''', nous avons ensuite '''repassé les contours de l'instrument en rouge'''. Une fois ceci fait, nous avons''' effacé l'image de la guitare originale '''pour ne''' garder que les contours rouges'''. Enfin après '''quelques réglages''', l''''export en fichier SVG '''permettait une '''découpe précise'''. Les contours de la guitare sont disponibles ci contre (cliquez sur l'image pour bien voir).<br />
<br />
A la '''fin de la séance''', la '''guitare''' était''' prête à être réalisée '''et nous avons décidé de faire l'intégralité du''' « jeu de simon »''' via '''l'impression 3D'''. Cependant, aucune grande avancée n'a eu lieu sur la partie mécanique du jeu de Simon lors de cette séance.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 28/03/17 Séance 2 : Poursuite du Projet et rencontre des premiers problèmes </div>===<br />
<br />
La '''deuxième séance''' fut davantage '''productive''', car chacun de nous savait les différentes '''tâches''' qu'il lui '''restait à accomplir'''.<br />
<br />
==== Partie électronique ====<br />
Nous nous sommes rendu compte qu'utiliser le registre à décalage pour la liaison série comme nous le faisions n'était pas possible.<br />
En effet, la liaison série est en asynchrone et nous ne connaissance donc pas la clock. <br />
Nous ne pouvons donc pas utiliser cette clock pour le registre à décalage car sinon nous risquons de ne pas lire assez vite (ou trop vite) et donc récupérer trop de valeurs ou en rater.<br />
<br />
Le professeur nous a donc indiqué qu'il nous mettrait à disposition un module qui va s'occuper justement de lire la liaison série et de garder la séquence et de ressortir le message en parallèle.<br />
Ce composant envoie également sur un autre pin un 1 à chaque fois qu'un bit est envoyé par la liaison série (et reçu par le composant).<br />
Nous utilisons, selon ses conseils, un module analogique-digital qui va nous permettre de simuler l'envoi de la séquence.<br />
Après plusieurs tentatives nous avons un programme qui fonctionne correctement pour recevoir les valeurs. Il nous reste à comparer l'appui d'un bouton et la couleur à presser.<br />
<br />
==== Partie informatique ====<br />
<br />
L'écriture du programme de communication fut terminé assez rapidement. Mais il ne fonctionnait pas...<br />
En effet, un problème s'opérait lors de l'appel de la liaison série par le serveur websocket à réception d'un message.<br />
<br />
L'incompréhension régnait un peu, car à nos yeux tout était sensé fonctionner. Le principe était assez simple : à réception d'un message par le serveur websockets, ce dernier devait ouvrir une communication série sur le port TTY_USB0 (ou TTY_ACM0 en fonction de l'arduino) à 9600 bauds, y transférer le message reçu, puis refermer la communication.<br />
<br />
Après un long moment de doute, le problème fut résolu. Ce dernier était assez idiot. En effet, notre fonction d'envoi de message via le port série s'appelait : " send(..) ". Il s'avère qu'une fonction d'une des librairies utilisées se nomme de la même manière. Il y avait donc conflit et empêchait le programme de fonctionner correctement.<br />
<br />
Nous avons donc pu relier l'ordinateur à un montage de prototypage Arduino/LEDs afin de tester le bon fonctionnement du programme. Une combinaison de 4 LED devait s'allumer à réception d'un caractère. Il fallait donc envoyé un message compris entre 0(aucune LED allumée) et 15(toutes les LED allumées). Cependant, le début de la table ASCII ne représente pas des caractères. Le serveur envoie donc un message alphabétique compris entre 65 ('A') et 80 ('P') et l'arduino interprète ceci comme une valeur de 0 a 15<br />
<br />
==== Partie mécanique : découpe de la guitare, modélisation et impression d'un prototype de touches pour cette dernière ====<br />
<br />
[[Fichier:pp.jpg||left|vignette|upright=0.8|]]Cette séance fut entamée par la '''découpe de la guitare''' grâce à la '''découpeuse laser''' du '''Fabricarium de Polytech'''. Dans un premier temps il a d'abord était nécessaire '''« d'apprivoiser »''' la '''découpeuse''' et d''''apprendre à bien la configurer''' pour obtenir le résultat souhaité, sans risques. Un '''premier essai''' a d'abord était réalisé dans du '''carton''' pour pouvoir '''juger des différentes dimensions''' de la guitare.<br />
Enfin, une '''seconde version''', en''' bois''', fut réalisée durant cette séance. Finalement nous décidons de partir sur l'idée d'une '''guitare réalisée en 4 couches d'épaisseur''' : '''2 extérieures en bois''' ( une de '''face''', '''décorée''' avec les '''boutons à actionner''' et la carte '''arduino''' et une '''seconde''', '''arrière''', de '''protection'''), et '''deux intérieures en carton'''('''creusées''' pour laisser passer les '''fils de connectiques''').<br />
<br />
'''Note''' : Malheureusement, une des '''couche en bois''' a était '''cassée''' par la suite lors de la confection de la guitare. La''' panne prolongée''' de la '''découpeuse laser''' nous a contraint à '''renoncer à l'idée d'une quatrième couche en bois''' de protection.[[Fichier:po.jpg||right|vignette|upright=1.2|]]<br />
<br />
<br />
De plus, via le '''logiciel de modélisation FreeCAD''', nous avons commencé à concevoir deux '''prototypes''' de '''« touches »''' (boutons) pour la guitare. <br />
<br />
L'idée était de créer des '''surfaces larges''' (pouvant recueillir '''une phalange de doigts au minimum''') faisant office de '''touches''', en dessous desquelles nous '''insérerions''' un '''bouton poussoir''' 4 pins (fournis par les professeurs). La '''création de touches plus larges''' était '''indispensable'''. En effet, les '''boutons poussoirs''' étaient bien '''trop petits''' pour avoir un '''actionnement facile et agréable'''.<br />
Nous avons pu lancer l''''impression des touches''' à la''' fin de la séance'''. Cependant, les différents '''tests '''et les''' défauts d'impression''' nous ont fait comprendre qu'il serait''' difficile de « glisser » un bouton poussoir '''dans une '''touche '''avec un '''espace '''assez''' étroit '''pour le maintenir, sans pour autant '''bloquer son actionnement''' lorsqu'une '''pression''' était appliquée. De plus, la''' fixation''' risquait d'être assez '''complexe'''. <br />
Nous avons alors décidé de faire un tout '''autre type de touche''' mais avec le '''même fonctionnement'''. Pour cela nous allions avoir besoin de''' modéliser et d'imprimer '''de nouveaux un '''prototype de touche'''.<br />
Il allait ensuite falloir''' percer la première couche en bois de la guitare'''. Puis il serait également nécessaire de '''creuser les sous couches''' en carton pour y placer les boutons poussoirs et les différents câbles.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 05/04/2017 Séance 3 : Encore beaucoup de choses à faire !</div>===<br />
<br />
Bien que ce soit notre '''dernière séance officielle''', nous savions que nous allions avoir '''besoin''' de '''beaucoup de temps''' pour''' terminer ce projet '''! <br />
<br />
==== Partie électronique ====<br />
[[Fichier:fpga.png|||vignette|upright=2|]]<br />
Le but de cette séance était de finaliser le FPGA et d'ajouter les blocs reception.vhdl et emission.vhdl fournis par M. Boé, ils nous permettent de gerer facilement la conversion serie / parallèle en asynchrone. Ainsi nous pouvons tester notre FPGA et nous rendre compte que ça ne marche pas, il y a un problème que nous n'arrivons pas à résoudre.<br />
Compte tenu du temps imparti, et du fait que la nanoboard n'était pas "embarquable", nous avons décidé de nous concentrer sur l'arduino afin d'avoir quelque chose qui fonctionne.<br />
<br />
==== Partie informatique ====<br />
<br />
<br />
L'objectif de la séance était la mise en place de l'interface WEB, notamment pour le jeu Guitar Hero. <br />
<br />
Nous avons utilisé un canvas Javascript afin de dessiner un interface similaire a celle du jeu original.<br />
<br />
==== Partie mécanique ====<br />
<br />
La troisième séance était destinée à '''l’élaboration du jeu de Simon'''. Une première idée était de '''créer quatre pièces plates''', composées de''' multiples leds''', qu'il faudrait''' actionner''' via une simple''' pression'''. Cependant, nous nous sommes dit '''qu'une seule LED pour une couleur''', suffisait à '''indiquer''' la '''combinaison''' à reproduire. <br />
<br />
Le tout devait être assez '''grand''' pour '''contenir la carte arduino''' ainsi que toute la '''connectique''', '''sans''' pour autant '''être''' trop '''encombrant''', tout en étant assez '''ergonomique''' et '''agréable au regard'''.<br />
<br />
Nous avons donc décidé de '''créer un support creux ''' qui '''contiendrait la partie électronique ''', au dessus duquel nous placerions '''les 4 pièces de couleur''' avec '''une LED pour chaque couleur'''.<br />
<br />
Nous savions dès lors, qu'un '''travail long minutieux''' nous attendait.<br />
<br />
Ainsi nous avons fait de '''nombreux croquis''' avec les '''différentes pièces''' et leurs '''dimensions éventuelles'''. Des pièces que nous allions réaliser uniquement en '''impression 3D'''. Un '''travail similaire''' a été réalisé pour '''la guitare''', afin de ne pas '''percer la guitare à de mauvais endroits''', et pour '''agencé les différents parties''' à ajouter sur la guitare de la '''meilleure façon possible'''. Pour '''résumer''' cette séance, nous avons '''réalisé tous les croquis nécessaires à la réalisation''' de la '''guitare''' et du '''Simon'''.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Séance supplémentaire : Terminons ce Projet !</div>===<br />
<br />
Il n'y a pas eu un '''nombre précis de "séances supplémentaires".''' '''Chacun''' des membres du groupe travaillait '''soit chez lui''', '''soit à l'école''' de '''manière régulière''', afin '''d'avancer sa partie''' le plus '''rapidement''' possible.<br />
<br />
==== Partie électronique ====<br />
[[Fichier:pcb1.jpg|left|vignette|upright=0.8|]]<br />
[[Fichier:pcb2.jpg|right|vignette|upright=0.8|]]<br />
Pour le Simon, il a fallut souder les câbles aux boutons et aux leds ( avec leur résistance ). Pour se faire, on a utilisé un circuit à pastilles qui se place entre l'arduino et les boutons/led. Cela permet de prendre moins de place et de faire plus propre qu'une breadboard.<br />
<br />
=== Partie informatique ===<br />
<br />
La partie FPGA n'étant pas fonctionelle, il a fallut le remplacer par un Arduino. <br />
<br />
Le code de l'Arduino consiste en une succession d'étapes pour jouer. Tout d'abord il faut recevoir via le port série la séquence totale du Simon, sous la forme de chaîne de caractères. Par exemple si le message reçu est "RVBR", alors la séquence totale du Simon sera Rouge Vert Bleu Rouge. Ainsi une fonction reception_message a été codée, qui attend la réception série de la séquence. <br />
<br />
Dans l'algorithme du jeu en lui même on a une variable globale qui stocke l'état de la partie, et une qui stocke l'étape de la séquence. Ainsi en fonction de l'état de la partie on va soit jouer la séquence sur les leds, lire l'état des boutons, ou provoquer un game over.<br />
<br />
La fonction playSequence va parcourir la séquence totale jusqu'à l'étape actuelle et va allumer les différentes leds en conséquence.<br />
<br />
La fonction readSequence va elle lire l'état successif des boutons et le comparer à la séquence actuelle. Si il y a une erreur, on sort de la fonction, et l'état de la partie devient un game over. Sinon, on continue et on appelle playSequence en incrémentant l'étape. En cas de réussite de la séquence, les 4 leds s'allument pour indiquer lé réussite et le passage au niveau supérieur.<br />
<br />
Coté websockets, c'est facile, dès qu'on reçoit un message par le client, on l'envoie à l'arduino ( bien qu'on aurait du vérifier la conformité du message ), l'arduino ne lira le message que si on est en étape de lecture de la séquence, donc après un game over par exemple. <br />
<br />
==== Partie mécanique : Suite et fin de la confection de la guitare et du jeu de Simon====<br />
<br />
Comme nous l'avons prédit, la plus '''grosse partie du travail''' réalisé a dû être faite lors de '''séances supplémentaires''' ou par '''travail personnel chez soi'''.<br />
<br />
Après avoir réalisé '''les croquis''', il était essentiel de '''créer rapidement les différents supports'''. En effet, cela nous permettait d'avoir du '''temps''' pour éventuellement''' recommencer et revoir les axes de travail en cas d'impossibilité de réalisation''' pour quelconque raison. De plus, une fois la''' partie mécanique terminée''', nous pouvions l''''utiliser''' comme '''support '''pour les '''tests électroniques'''. Enfin, cela nous laissait du temps en fin de projet pour '''décorer notre projet''', que nous voulions '''personnalisé''' afin d'en être '''le plus satisfaits possible'''. <br />
<br />
Un''' gros travail de modélisation''' à dû être fait sur '''FREECAD'''. Le '''support''' du jeu de Simon fut la pièce la plus '''simple '''à réaliser (un '''cylindre''' semi fermé, de '''7 cm de rayon''').<br />
<br />
Puis une simple''' découpe '''grâce à une '''scie''' permettrait de faire''' réceptacle''' pour une''' "croix porteuse" '''sur laquelle serait disposés les '''touches du Simon'''.<br />
<br />
De la même façon que pour la guitare, '''les touches''' seraient placées '''au dessus de boutons poussoirs'''. Ces derniers seront '''collés sur la croix'''. <br />
[[Fichier:tg.jpg||right|vignette|upright=1.5|]]<br />
Une fois ceci fait, il fallait '''réaliser le plus important du jeu''' : '''les touches à actionner '''! <br />
<br />
Pour cela, il était préférable de conserver la '''forme cylindrique '''du support en modélisant '''4 pièces''', d'un '''quart de disque''' chacune. Par soucis de '''fixation '''sur la croix et par envie d’'''esthétisme''', les touches seraient un peu '''incurvées''' pour donner une forme '''moins géométrique''' au rendu final. <br />
<br />
De plus, elles seront''' perforées''' pour laisser passer une '''LED''' de la même couleur que la touche sur laquelle elle se trouve. Ainsi l'utilisateur pourra '''mémoriser les touches à activer''' via le système '''lumineux''' des '''LEDs'''. <br />
<br />
Enfin, un '''cylindre permettant l'accroche''' sur la croix à été prévu sur la '''partie inférieure''' de les''' touches du Simon'''. (suite à une impression peu précise, '''ce cylindre sera « fondu »''' pour épouser la forme de la croix '''sans jeu dans la fixation'''.)<br />
<br />
[[Fichier:touc2.jpg||left|vignette|upright=1.7|]]<br />
Vint ensuite le''' moment de la création''' ! '''L'impression de ces pièces''' étant la plus '''complexe''', nous pensions qu'il serait nécessaire de les recommencer plusieurs fois. La '''WitBox du Fabricarium''' (la plus précise des imprimantes mise à notre disposition) a réalisé une '''impression assez laborieuse'''. Un gros travail de '''ponçage''' à donc dû être réalisé, car le support nécessaire pour imprimer cette pièce « incurvée » avait donné de '''nombreuses bavures''' sur la '''surface des touches'''. Afin que le '''toucher''' reste '''agréable''', nous avons donc '''retravaillé les pièces'''.<br />
<br />
<br />
Une fois ceci fait, nous avons '''essayé de les positionner''' sur la''' croix''' prévue à cet effet. Une fois encore, nous étions '''confronté aux limites de l'impression 3D'''. Les '''dimensions du « cylindre pillier » '''étant non précise, et cette partie étant''' trop fine pour être sciée''' '''sans rupture''' de la pièce, nous avons décidé de faire '''« fondre » '''cette partie et de la placer, encore chaude sur la partie en forme de croix. Cela permettait une''' fixation sûre''' et une '''dimension épousant parfaitement les formes du support'''. L'inconvénient fut que cette''' méthode, peu précise''', n'a fait qu''''accentuer les erreurs d'impressions''' au niveaux du '''visuel'''. Effectivement, les 4 pièces ne '''semblent pas régulières''' et le '''disque''' qu'elles sont censées former (ensemble de 4 quarts de disque) ne semble '''pas parfait'''.[[Fichier:bttt.jpg||right|vignette|upright=1.5|]][[Fichier:socle.jpg||right|vignette|upright=1.5|]]<br />
<br />
<br />
Nous décidons cependant de '''conserver ce léger défaut''', car si nous recommencions nous risquerions d'être de nouveau''' confronté au même souci''', l''''erreur''' n'étant pas uniquement dû à notre '''manipulation''' mais également à l''''imprimante 3D'''. <br />
<br />
<br />
L'impression du '''socle''' était la plus''' longue à imprimer''' (près de 6 heures) .Après l'avoir un peu '''scié''' comme prévu, cette pièce était également''' prête à être peinte'''. Nous avons fait de même avec la '''croix '''à placer sur le socle et servant de '''support''' aux '''quatre touches''' du Simon. Cette impression étant '''rapide et facile''', un seul essai suffit pour obtenir notre '''version définitive'''. L'impression fut dans ce cas, parfaitement aux '''mesures souhaitées''' dans le fichier .stl (bien que réalisé avec une imprimante de moins bonne qualité que la WitBox). Ainsi les '''boutons poussoirs '''que nous avions à positionner dessus tenaient sans souci '''par un simple encastrement'''. Par la suite, par '''mesure de sécurité''', <br />
nous avons tout de même rajouté un '''point de colle''' en dessous des''' boutons ''' pour éviter tout '''désencastrement non souhaité'''. <br />
[[Fichier:tr.jpg||left|vignette|upright=1.4|]]<br />
<br />
<br />
<br />
En parallèle, nous avons travaillé sur les '''différentes couches d'épaisseur''' de la ''' guitare'''. Dans un premier temps il était nécessaire de '''retirer une partie dans le manche''' pour y placer les boutons poussoirs. Cette étape aurait pu être réalisé rapidement avec la '''découpeuse laser''', mais celle ci étant '''en panne''', nous l'avons fait via '''une perceuse et un foret au Fabricarium'''. Le résultat était un '''peu moins net''' mais '''convenable cependant'''. De plus le '''"trou"''' sera '''caché''' par la pièce contenant '''les touches'''. Une fois la couche de bois travaillée, nous avons '''creusé '''la''' partie cartonnée''' afin de pouvoir y laisser passer les différents '''câbles '''liant les''' boutons poussoirs''' (situés sous les touches du manche de la guitare) à une '''breadboard''' (sur la partie basse de l'instrument).<br />
<br />
Afin que les '''câbles sortent de la guitare de façon propre''', nous avons percé '''4 trous à la base du manche'''. Ainsi de chaque''' trou''' ressortira '''deux fils de connectique''' ( un pour l'entrée du bouton poussoir et un pour la sortie).<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:tt.jpg||left|vignette|upright=2|]]<br />
Ceci étant terminé, il fallait passer à la '''conception des touches de la guitare'''.[[Fichier:touc.jpg||right|vignette|upright=2.2|]]<br />
C'est en '''observant''' une imprimante 3D du Fabricarium qu''''une idée de modèle touche vue le jour'''. Nous allions faire '''une seule et unique pièces''' pour les''' 4 touches'''.<br />
'''Fine''', elle pourrait être facilement '''pliée''' sous une '''pression du doigts''' pour '''actionner un bouton poussoir''' situé en '''dessous''' de chacune des 4 touches.suffirait juste de '''peindre les 4 touches de couleurs différentes''' pour les différencier.<br />
Cette pièce serait '''fixée sur le manche de la guitare''', couvrant une''' couche de bois perforée''' et une '''cartonnée « creusée »''' pour '''laisser passer la connectique '''jusqu'à la partie inférieure de la guitare.<br />
<br />
Finalement, il aura fallut '''quelques heures supplémentaires''' des séances pour avoir '''toutes nos partie modéliser sur FREECAD ''' et '''prête à être imprimées''', qu'elles soient destinées au '''Simon''' ou au '''Guitar Hero'''.<br />
<br />
L'heure est donc à la '''réalisation''' ! Les '''impressions 3D '''se sont faites sur l'imprimante d''''un des membre du groupe''' ainsi que sur celles du''' Fabricarium'''. <br />
<br />
Les''' touches''' qui actionneraient les boutons poussoirs étaient les plus à même d'être à''' recommencer'''. En effet, un '''problème de fixation''', ou encore une '''rigidité trop grande''' '''empêcherait''' l'actionnement du '''bouton '''et serait donc '''inutilisable'''. Ainsi nous avons '''commencé par imprimer les touches''' (pour la guitare et pour le simon). Dans un premier temps, nous nous sommes occupés de la pièce '''pour la guitare'''. La première '''impression '''fut''' décevante''', car''' trop épaisse '''(8mm) , la pièce''' ne pliait pas''' sous la pression des doigts et n’'''actionnait donc pas les boutons''' placés dessous.<br />
<br />
Ce pourquoi nous avons lancé immédiatement une '''nouvelle impression''' avec 3mm d'épaisseur. Les '''tests étant concluants''', nous n'avions plus qu'à la''' peindre''' de '''4 couleurs différentes '''pour symboliser les 4 touches du guitar hero. <br />
<br />
<br />
Ceci commença par la réalisation de '''soudures''' des '''boutons poussoirs''' avec les '''fils'''. Ces fils seraient ensuite placés '''sous '''la couche de '''bois''', '''dans''' la couche de '''carton'''. Cette étape fut '''rapidement terminée'''.<br />
<br />
Les '''8 boutons poussoirs étaient prêts '''! '''Quatre''' pour la''' guitare''',''' quatre '''pour le jeu de '''Simon'''.<br />
<br />
Finalement,''' toutes les pièces étant réalisées''', il fallait réaliser''' un travail d'assemblage''', et de '''finitions ''' (au niveaux des couches de peinture notamment). <br />
<br />
Nous nous sommes préalablement''' assuré '''que tous les '''boutons poussoirs étaient fonctionnels '''et que les''' soudures '''étaient '''correctement réalisées''' grâce à des''' tests rapides''' avec la '''carte arduino.'''<br />
<br />
<br />
[[Fichier:led.jpg||left|vignette|upright=1.2|]][[Fichier:end.jpg||RIGHT|vignette|upright=1.3|]]<br />
Enfin, il ne restait plus qu'à '''peindre''' nos différentes''' pièces'''.<br />
<br />
Premièrement nous avons '''appliqué deux couches de blanc''' sur '''chacune des pièces'''. Puis sur celles qui nécessitaient une '''couleur précise''' ( en autre : les touches de la guitare et du Simon), nous avons repassé '''deux couches''' de '''couleur''' dessus.<br />
Puis, nous avons '''assemblé toutes les pièces''' entre elles pour '''obtenir le résultat final''' ! <br />
<br />
L''''assemblage''' des différentes '''couches de la guitare''' à d'abord était '''provisoirement fait '''avec de la '''colle forte'''. Si le collage venait à '''céder''', nous utiliserons sans doute des''' vis '''ou des '''accroches '''en plastique pour maintenir le tout en place.<br />
<br />
Nous en avons profité pour utiliser la peinture restantes pour décorer un peu notre guitare et ainsi la personnaliser comme bon nous semblait.<br />
<br />
<br />
<br />
<br />
<br />
Finalement, le''' résultat''' est plus que '''satisfaisant '''! Les quatre '''couleurs primaires''' étant '''vives''', elles donnent un aspect '''coloré''' et '''joyeux''' à notre '''projet''' ! Les quatre '''touches du Simon''', '''surmontées''' d'une '''LED''' de la même couleur que la touche, permettent une '''utilisation claire et facile '''du « jeu de Simon ».<br />
<br />
<br />
Dans la '''globalité''', nous sommes assez '''fiers''' du résultat de la '''partie mécanique''' ! Que ce soit du ''' "jeu de Simon" '''ou de la '''Guitare''' du '''"Guitar Héro"''', les '''boutons poussoirs''' sont''' activables facilement '''(voir la vidéo de démonstration en cliquant sur le lien suivant :[https://youtu.be/3-p--BhHGr4] ). De plus le''' résultat est assez agréable''' à '''regarder''' ou encore '''facile a prendre en main'''. <br />
<br />
<br />
<br />
La '''partie mécanique '''étant bien '''avancée''' avant la fin du projet, nous avons décidé de''' procéder à certaines améliorations'''. En effet, les tests des parties électronique et informatique pouvaient donc s’effectuer sur le Simon et la guitare ainsi réalisée. Ainsi dans tous les cas nous avions '''deux prototypes''' à présenter à la fin du projet.<br />
<br />
En parallèle,''' une version plus élaborée''' de la guitare pouvait ainsi être en '''construction'''.<br />
Pour se faire, nous avons repris le fichier SVG explicité lors de la première séance et nous lui avons rajouté un rectangle rouge au niveau du manche, pour une '''découpe plus propre''' à la découpeuse laser, et '''moins fragilisante''' pour le bois.<br />
<br />
[[Fichier:entretoise.jpg||right|vignette|upright=1.5|]]<br />
[[Fichier:cote.jpg||left|vignette|upright=1.5|]]<br />
<br />
<br />
De plus pour gagner en '''propreté''', nous avons placé un PCB pour éviter l’encombrement.<br />
Enfin, nous avons pris la décision de laisser la''' guitare creuse''', afin de pouvoir '''mieux voir le contenu électronique''' à l’intérieur et de garder un '''aspect plus propre et épuré''' de la guitare.<br />
<br />
Pour ce faire, nous allons utiliser des '''entretoises''' qui permettront une largeur de guitare homogène. Afin d’éviter une pliure du bois au niveau des touches (et ainsi éviter que les touches ne soient pas actionnées car pas d’opposition de force), nous avons insisté sur les''' entretoises au-dessous des touches '''(que nous avons pris soin de fixer avec de la colle pour éviter de fragiliser le bois au niveau du manche en le perçant).<br />
<br />
Finalement, les '''touches sont activables facilement''', une fois la guitare prise en main. Un signal logique bas est bien transmis une fois les '''touches appuyées'''. Et il est '''bien détecté''' par''' l’arduino'''. <br />
<br />
[[Fichier:guitaredroite.jpg||center|vignette|upright=2|]]<br />
<br />
<br />
<br />
Désormais, la '''partie mécanique '''étant''' terminée et fonctionnelle''', il faut la '''lier à la partie informatique et électronique'''. Nous allons '''perfectionner la partie FPGA''' et''' Arduino '''pour''' exploiter''' pleinement les '''deux supports '''(guitare et jeu de Simon) ainsi réalisés.<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Conclusion </div>==<br />
<br />
<br />
En conclusion, Le '''jeu de Simon''' est '''terminé''' et est '''fonctionnel''. En effet le '''serveur websocket''' envoie une '''combinaison''' de couleur, composée par un utilisateur, à '''l’arduino''', qu’un second utilisateur devra tenter de '''reproduire''' (couleur par couleur, en reprenant du début à chaque fois, avec une couleur en plus à chaque tour). Le '''Jeu de Simon est terminé ''': '''L’objectif principal''' de notre projet est donc '''réalisé'''.<br />
<br />
Cependant, le '''Guitar Héro''' n’a pas pu être abouti. Nous avions précisé dès le début du projet que nous tâcherions de '''finir le Simon en priorité''' et de faire le Guitare Héro ensuite. La '''guitare est finalisée''' et '''fonctionnelle'''. Nous n’étions donc pas si loin de terminer les deux projets. <br />
Nous sommes globalement '''satisfaits''' du '''travail réalisé''' et de la''' prestation proposée'''. En effet en sachant que nous avions deux projets en simultané (bien que très ressemblant entre eux) nous avons su '''terminer le premier''' et '''bien avancer sur le second'''. Le '''but principal''' était de '''nous amuser''', de '''prendre du plaisir dans la réalisation d'un projet''' et de '''faire quelque chose qui nous plaisait avant tout''', '''l’objectif''' est '''atteint'''.<br />
Le FPGA n'a pas pu être aboutit non plus, et c'est dommage, car c'est une technologie intéressante, et c'est plus optimisé et rapide qu'une Arduino. <br />
<br />
Ce projet fut très '''intéressant''' car il nous a permis de '''mettre en application''' certains de nos '''cours étudiés''' cette année en IMA3, mais également d’en '''apprendre''' énormément '''par nous même''' à force de '''pratique '''et de''' recherches personnelles'''. Pour l’ensemble des membres du groupe, ce projet a été la confirmation de '''l’intérêt '''porté aux '''systèmes communiquants''', et nous a donc '''convaincu de choisir''' la '''filière SC''' à partir du semestre 8 en '''IMA4'''.<br />
<br />
<br />
La démonstration du fonctionnement du Jeu de Simon, est disponible à l'adresse suivante : https://youtu.be/RbgPtALDmFw .</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=Projet_IMA3_P3,_2016/2017,_TD1&diff=44304Projet IMA3 P3, 2016/2017, TD12017-06-18T20:24:58Z<p>Adurot : /* Partie électronique */</p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 25px; padding: 20px; font-weight: bold; text-align: center; font-size: 98%; background: #6060FF; vertical-align: top; width: 99%;"> Projet IMA3-SC 2016/2017 : Le Jeu de Simon et le Guitar Hero </div>=<br />
<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Cahier des Charges </div>==<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Description du système </div>===<br />
<br />
* L'objectif principal de notre projet est de réaliser un '''jeu''' qui utilise à la fois les '''lumières''' et le '''son'''. Pour cela, nous avons pensé à deux versions : '''le Simon''' et un jeu du type '''Guitar Hero'''.<br />
<br />
* Le '''Simon''' est constitué de '''quatre boutons de couleurs différentes''' : un bleu, un rouge, un vert et un jaune. Le jeu va '''afficher''' une séquence de couleurs qui sont chacune '''associées à un son'''. Le joueur doit ensuite se '''souvenir''' de la suite (en s'aidant du son et des couleurs comme moyen mnémotechnique) pour la '''reproduire''' dans le '''bon ordre''' en '''appuyant sur les boutons'''.<br />
<br />
* Le jeu '''Guitar Hero''', quant à lui, est un jeu où il faut '''actionner des boutons de couleur précise''', '''au moment où elles apparaissent''' sur une barre de défilement, '''à l'écran'''. Ces différentes '''activations''', aux '''bons moments''', permettent de '''réaliser une mélodie''' plus ou moins complexe selon la difficulté de la chanson à reproduire. Le tout est effectué grâce à '''une guitare connectée''', afin de pousser l'expérience de '''simulation''' un peu plus loin. Si nous réalisons, ce jeu, il faut '''prendre en compte''' un '''affichage''' plus '''complexe'''. De plus, le '''Guitar Hero''' ajoute '''une notion de temps de réponse''', plus '''difficile à gérer'''. Ce temps de réponse permet de laisser une '''courte marge d'erreur''' dans la '''réactivité de l'utilisateur''', pour '''simuler pleinement''' l'utilisation d'une '''guitare électrique'''.<br />
<br />
<br />
Nous avons choisis de d'abord nous concentrer sur le '''Simon''' et de faire le jeu '''Guitar Hero''' seulement '''si nous avons le temps'''.<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Le matériel </div>===<br />
<br />
Pour ce '''projet''' nous utiliserons :<br />
<br />
* Une '''page internet''' sur l'ordinateur pour pouvoir '''modifier les différents aspects du jeu''' : les '''règles du jeu''', la '''musique''' jouée par le Simon ou bien la '''difficulté'''<br />
<br />
* Le '''Raspberry Pi''', utilisée en tant que serveur, va envoyer les données en série ( qui seront traitées par le FPGA ), de les recupérer, et de faire l'algorithme.<br />
<br />
* Une '''carte Arduino''' pour '''relier''' la Raspberry Pi aux composants dans un premier temps : elle nous permet de '''coder en C''' (au lieu d'un langage assembleur) pour '''créer des programmes''' et '''gérer''' les différents '''modules''' tel que les '''boutons''' et les '''LEDs'''. Elle permettra une '''simulation''' momentanée du '''FPGA''', afin que nous puissions avancer sur la partie informatique, sans attendre d'en avoir fini avec la partie FPGA.<br />
<br />
* Une fois le programme et les interactions fonctionnels, nous '''remplacerons''' l'Arduino par une '''FPGA''' qui est '''circuit logique programmable''' : on peut '''modifier les circuits logiques''' à l'intérieur mais '''on ne peut pas créer un programme''' avec un '''langage''' de plus '''haut niveau'''. Nous devrons donc utiliser des '''logiciels tiers''' qui nous permettront de placer des '''portes logiques''' (ET, OU,...) pour '''créer notre programme en assembleur'''.<br />
<br />
* Pour ce qui est de la '''partie mécanique''', nous réaliserons une '''guitare en bois''' pour le''' "Guitar Hero"''' ainsi qu'un''' "jeu de Simon"''' réalisé via l''''impression 3D.'''<br />
<br />
* Si le temps nous le permet, nous utiliserons un '''Xbee''' pour créer une '''connexion sans fil''', afin '''d'expérimenter''' un '''module nouveau''' et '''acquérir''' de '''nouvelles compétences'''.<br />
<br />
*Nous utiliserons également des '''composants électroniques''' tels que des '''boutons poussoirs''', des '''LEDs''' ou une '''matrice de LEDs''' pour l'affichage dans le cas du jeu de Simon, ainsi que de '''"l'essentiel"''' pour un '''système communiquant''' (à savoir '''résistances''', '''fils électriques''', etc...)<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Description des séances </div>==<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 21/03/17 Séance 1 : Répartition des tâches et premiers pas </div>===<br />
<br />
La première séance fut''' consacrée à la répartition des rôles''' et à la '''prise de conscience '''de la '''difficulté des différentes tâches'''. L''''idée''' de faire un '''« jeu de Simon » '''que nous''' amélioreront '''ensuite en '''« guitar hero »''' a cependant été '''conservée'''.<br />
<br />
==== Partie électronique ====<br />
<br />
Nous avons décidé de concentrer deux personnes sur le FPGA car c'est un élément très complexe et complètement nouveau.<br />
Nous allons en effet devoir reflechir à très bas niveau avec simplement des registres et des portes logiques.<br />
<br />
L'objectif du composant sera de récupérer un message contenant les boutons sur lesquelles appuyer. <br />
Une fois ce message reçu, le FPGA va comparer le bouton saisi par l'utilisateur avec le bouton demander. <br />
S'il est correct, le FPGA va passer à la couleur suivante, sinon il va renvoyer un message pour dire à la Raspberry (ou l'ordinateur) que l'utilisateur s'est trompé.<br />
<br />
Pour commencer, nous réalisons le tutoriel pour allumer une LED qui va nous permettre de comprendre le fonctionnement de Altium Designer.<br />
Cela nous a pris du temps mais nous avons pu réaliser d'autres essaies avec des registres à décalages et des boutons.<br />
<br />
Nous avons ensuite directement commencer le Simon :<br />
Le choix a été fait d'utiliser des registres à décalages pour récupérer la séquence de couleur envoyé par l'ordinateur/la raspberry. <br />
Nous allons en effet stocker toute la séquence de la "partie" car sinon il faudrait gérer beaucoup d'échange entre l'ordinateur et le FPGA ce qui est lourd en Altium et fait perdre du temps réaction du programme.<br />
<br />
D'un point de vue technique, utiliser un registre à décalage semble être la meilleur méthode pour récupérer un à un les bits qui arrivent sur la liaison série puis nous utilisons 4 registres à décalage : 1 pour chaque couleur.<br />
Pour chacun des registres nous aurons donc une séquence comme suit : 0100010010111. Les 1 correspondent aux moments ou il faut appuyer sur la couleur et les 0 aux moments ou il ne faut pas appuyer sur cette couleur. <br />
Nous devons donc également gérer les clocks des registres "couleurs". Ces registres doivent arrêter leur clock lorsque les bits de chaque couleur est à 0.<br />
<br />
Le registre pour la liaison série sera la clock du système puisqu'elle doit lire toute la séquence mais elle doit également s'arrêter lorsque le FPGA arrive à la fin de la séquence. Pour lui indiquer la fin de la séquence nous avons choisit le mot 0000 car il y aura toujours un bouton à appuyer pour le jeu Simon.<br />
<br />
==== Partie informatique ====<br />
<br />
L'objectif ici était la découverte des technologies à utiliser pour le système. Notamment une Arduino en liaison série à un PC et un serveur Websockets codé en C.<br />
La partie programmation arduino ne fut pas un problème. En effet, ce n'était pas la première fois que nous utilisions cet outil, et donc la mise en place de la liaison série fut très rapide.<br />
Ce n'est cependant pas le cas de la communication websockets. Bien que l'exemple de code fourni par M. Redon soit fonctionnel, le code n'en reste pas moins complexe à comprendre. Il fallait donc réussir à modifier le code du serveur websockets, afin de relier les deux systèmes entre eux.<br />
<br />
==== Partie mécanique : un modèle de guitare à découper====<br />
<br />
<br />
Dans cette première séance, nous avons décidé de focaliser nos premiers efforts sur la''' partie mécanique''' du '''"guitar hero"'''. En effet, le '''« jeu de simon »''' pouvait être avancé '''plus tard''' car plus''' facile''' à '''modéliser''' et à''' réaliser.'''[[Fichier:1.jpg||right|vignette|upright=2|]]<br />
Nous sommes alors partis sur l'idée de créer une''' maquette de guitare''', sur laquelle nous allions '''disposer''' différents '''boutons de couleur''', '''actionnables''' grâce à une '''pression''' sur le manche de l'instrument. Nous avions une '''ligne directrice''' mais pas encore d''''idée précise''' de comment allait être réalisé la guitare, ni même '''ce à quoi elle allait ressembler'''.<br />
<br />
<br />
Nous avons décidé de découper la '''guitare en bois''' qui nous servirait de support pour notre '''« guitar hero »''' grâce à la''' découpeuse laser'''. Pour se faire, un '''fichier conforme à la découpe''' devait être réalisé. <br />
Ainsi nous avons donc pris une '''image de guitare''' depuis '''internet'''. Dans le logiciel''' « GIMP »''', nous avons ensuite '''repassé les contours de l'instrument en rouge'''. Une fois ceci fait, nous avons''' effacé l'image de la guitare originale '''pour ne''' garder que les contours rouges'''. Enfin après '''quelques réglages''', l''''export en fichier SVG '''permettait une '''découpe précise'''. Les contours de la guitare sont disponibles ci contre (cliquez sur l'image pour bien voir).<br />
<br />
A la '''fin de la séance''', la '''guitare''' était''' prête à être réalisée '''et nous avons décidé de faire l'intégralité du''' « jeu de simon »''' via '''l'impression 3D'''. Cependant, aucune grande avancée n'a eu lieu sur la partie mécanique du jeu de Simon lors de cette séance.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 28/03/17 Séance 2 : Poursuite du Projet et rencontre des premiers problèmes </div>===<br />
<br />
La '''deuxième séance''' fut davantage '''productive''', car chacun de nous savait les différentes '''tâches''' qu'il lui '''restait à accomplir'''.<br />
<br />
==== Partie électronique ====<br />
Nous nous sommes rendu compte qu'utiliser le registre à décalage pour la liaison série comme nous le faisions n'était pas possible.<br />
En effet, la liaison série est en asynchrone et nous ne connaissance donc pas la clock. <br />
Nous ne pouvons donc pas utiliser cette clock pour le registre à décalage car sinon nous risquons de ne pas lire assez vite (ou trop vite) et donc récupérer trop de valeurs ou en rater.<br />
<br />
Le professeur nous a donc indiqué qu'il nous mettrait à disposition un module qui va s'occuper justement de lire la liaison série et de garder la séquence et de ressortir le message en parallèle.<br />
Ce composant envoie également sur un autre pin un 1 à chaque fois qu'un bit est envoyé par la liaison série (et reçu par le composant).<br />
Nous utilisons, selon ses conseils, un module analogique-digital qui va nous permettre de simuler l'envoi de la séquence.<br />
Après plusieurs tentatives nous avons un programme qui fonctionne correctement pour recevoir les valeurs. Il nous reste à comparer l'appui d'un bouton et la couleur à presser.<br />
<br />
==== Partie informatique ====<br />
<br />
L'écriture du programme de communication fut terminé assez rapidement. Mais il ne fonctionnait pas...<br />
En effet, un problème s'opérait lors de l'appel de la liaison série par le serveur websocket à réception d'un message.<br />
<br />
L'incompréhension régnait un peu, car à nos yeux tout était sensé fonctionner. Le principe était assez simple : à réception d'un message par le serveur websockets, ce dernier devait ouvrir une communication série sur le port TTY_USB0 (ou TTY_ACM0 en fonction de l'arduino) à 9600 bauds, y transférer le message reçu, puis refermer la communication.<br />
<br />
Après un long moment de doute, le problème fut résolu. Ce dernier était assez idiot. En effet, notre fonction d'envoi de message via le port série s'appelait : " send(..) ". Il s'avère qu'une fonction d'une des librairies utilisées se nomme de la même manière. Il y avait donc conflit et empêchait le programme de fonctionner correctement.<br />
<br />
Nous avons donc pu relier l'ordinateur à un montage de prototypage Arduino/LEDs afin de tester le bon fonctionnement du programme. Une combinaison de 4 LED devait s'allumer à réception d'un caractère. Il fallait donc envoyé un message compris entre 0(aucune LED allumée) et 15(toutes les LED allumées). Cependant, le début de la table ASCII ne représente pas des caractères. Le serveur envoie donc un message alphabétique compris entre 65 ('A') et 80 ('P') et l'arduino interprète ceci comme une valeur de 0 a 15<br />
<br />
==== Partie mécanique : découpe de la guitare, modélisation et impression d'un prototype de touches pour cette dernière ====<br />
<br />
[[Fichier:pp.jpg||left|vignette|upright=0.8|]]Cette séance fut entamée par la '''découpe de la guitare''' grâce à la '''découpeuse laser''' du '''Fabricarium de Polytech'''. Dans un premier temps il a d'abord était nécessaire '''« d'apprivoiser »''' la '''découpeuse''' et d''''apprendre à bien la configurer''' pour obtenir le résultat souhaité, sans risques. Un '''premier essai''' a d'abord était réalisé dans du '''carton''' pour pouvoir '''juger des différentes dimensions''' de la guitare.<br />
Enfin, une '''seconde version''', en''' bois''', fut réalisée durant cette séance. Finalement nous décidons de partir sur l'idée d'une '''guitare réalisée en 4 couches d'épaisseur''' : '''2 extérieures en bois''' ( une de '''face''', '''décorée''' avec les '''boutons à actionner''' et la carte '''arduino''' et une '''seconde''', '''arrière''', de '''protection'''), et '''deux intérieures en carton'''('''creusées''' pour laisser passer les '''fils de connectiques''').<br />
<br />
'''Note''' : Malheureusement, une des '''couche en bois''' a était '''cassée''' par la suite lors de la confection de la guitare. La''' panne prolongée''' de la '''découpeuse laser''' nous a contraint à '''renoncer à l'idée d'une quatrième couche en bois''' de protection.[[Fichier:po.jpg||right|vignette|upright=1.2|]]<br />
<br />
<br />
De plus, via le '''logiciel de modélisation FreeCAD''', nous avons commencé à concevoir deux '''prototypes''' de '''« touches »''' (boutons) pour la guitare. <br />
<br />
L'idée était de créer des '''surfaces larges''' (pouvant recueillir '''une phalange de doigts au minimum''') faisant office de '''touches''', en dessous desquelles nous '''insérerions''' un '''bouton poussoir''' 4 pins (fournis par les professeurs). La '''création de touches plus larges''' était '''indispensable'''. En effet, les '''boutons poussoirs''' étaient bien '''trop petits''' pour avoir un '''actionnement facile et agréable'''.<br />
Nous avons pu lancer l''''impression des touches''' à la''' fin de la séance'''. Cependant, les différents '''tests '''et les''' défauts d'impression''' nous ont fait comprendre qu'il serait''' difficile de « glisser » un bouton poussoir '''dans une '''touche '''avec un '''espace '''assez''' étroit '''pour le maintenir, sans pour autant '''bloquer son actionnement''' lorsqu'une '''pression''' était appliquée. De plus, la''' fixation''' risquait d'être assez '''complexe'''. <br />
Nous avons alors décidé de faire un tout '''autre type de touche''' mais avec le '''même fonctionnement'''. Pour cela nous allions avoir besoin de''' modéliser et d'imprimer '''de nouveaux un '''prototype de touche'''.<br />
Il allait ensuite falloir''' percer la première couche en bois de la guitare'''. Puis il serait également nécessaire de '''creuser les sous couches''' en carton pour y placer les boutons poussoirs et les différents câbles.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 05/04/2017 Séance 3 : Encore beaucoup de choses à faire !</div>===<br />
<br />
Bien que ce soit notre '''dernière séance officielle''', nous savions que nous allions avoir '''besoin''' de '''beaucoup de temps''' pour''' terminer ce projet '''! <br />
<br />
==== Partie électronique ====<br />
[[Fichier:fpga.png|||vignette|upright=2|]]<br />
Le but de cette séance était de finaliser le FPGA et d'ajouter les blocs reception.vhdl et emission.vhdl fournis par M. Boé, ils nous permettent de gerer facilement la conversion serie / parallèle en asynchrone. Ainsi nous pouvons tester notre FPGA et nous rendre compte que ça ne marche pas, il y a un problème que nous n'arrivons pas à résoudre.<br />
Compte tenu du temps imparti, et du fait que la nanoboard n'était pas "embarquable", nous avons décidé de nous concentrer sur l'arduino afin d'avoir quelque chose qui fonctionne.<br />
<br />
==== Partie informatique ====<br />
<br />
<br />
L'objectif de la séance était la mise en place de l'interface WEB, notamment pour le jeu Guitar Hero. <br />
<br />
Nous avons utilisé un canvas Javascript afin de dessiner un interface similaire a celle du jeu original.<br />
<br />
==== Partie mécanique ====<br />
<br />
La troisième séance était destinée à '''l’élaboration du jeu de Simon'''. Une première idée était de '''créer quatre pièces plates''', composées de''' multiples leds''', qu'il faudrait''' actionner''' via une simple''' pression'''. Cependant, nous nous sommes dit '''qu'une seule LED pour une couleur''', suffisait à '''indiquer''' la '''combinaison''' à reproduire. <br />
<br />
Le tout devait être assez '''grand''' pour '''contenir la carte arduino''' ainsi que toute la '''connectique''', '''sans''' pour autant '''être''' trop '''encombrant''', tout en étant assez '''ergonomique''' et '''agréable au regard'''.<br />
<br />
Nous avons donc décidé de '''créer un support creux ''' qui '''contiendrait la partie électronique ''', au dessus duquel nous placerions '''les 4 pièces de couleur''' avec '''une LED pour chaque couleur'''.<br />
<br />
Nous savions dès lors, qu'un '''travail long minutieux''' nous attendait.<br />
<br />
Ainsi nous avons fait de '''nombreux croquis''' avec les '''différentes pièces''' et leurs '''dimensions éventuelles'''. Des pièces que nous allions réaliser uniquement en '''impression 3D'''. Un '''travail similaire''' a été réalisé pour '''la guitare''', afin de ne pas '''percer la guitare à de mauvais endroits''', et pour '''agencé les différents parties''' à ajouter sur la guitare de la '''meilleure façon possible'''. Pour '''résumer''' cette séance, nous avons '''réalisé tous les croquis nécessaires à la réalisation''' de la '''guitare''' et du '''Simon'''.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Séance supplémentaire : Terminons ce Projet !</div>===<br />
<br />
Il n'y a pas eu un '''nombre précis de "séances supplémentaires".''' '''Chacun''' des membres du groupe travaillait '''soit chez lui''', '''soit à l'école''' de '''manière régulière''', afin '''d'avancer sa partie''' le plus '''rapidement''' possible.<br />
<br />
==== Partie électronique ====<br />
<br />
Pour le Simon, il a fallut souder les câbles aux boutons et aux leds ( avec leur résistance ). Pour se faire, on a utilisé un circuit à pastilles qui se place entre l'arduino et les boutons/led. Cela permet de prendre moins de place et de faire plus propre qu'une breadboard.<br />
[[Fichier:pcb1.jpg|left|vignette|upright=0.8|]]<br />
[[Fichier:pcb2.jpg|right|vignette|upright=0.8|]]<br />
<br />
=== Partie informatique ===<br />
<br />
La partie FPGA n'étant pas fonctionelle, il a fallut le remplacer par un Arduino. <br />
<br />
Le code de l'Arduino consiste en une succession d'étapes pour jouer. Tout d'abord il faut recevoir via le port série la séquence totale du Simon, sous la forme de chaîne de caractères. Par exemple si le message reçu est "RVBR", alors la séquence totale du Simon sera Rouge Vert Bleu Rouge. Ainsi une fonction reception_message a été codée, qui attend la réception série de la séquence. <br />
<br />
Dans l'algorithme du jeu en lui même on a une variable globale qui stocke l'état de la partie, et une qui stocke l'étape de la séquence. Ainsi en fonction de l'état de la partie on va soit jouer la séquence sur les leds, lire l'état des boutons, ou provoquer un game over.<br />
<br />
La fonction playSequence va parcourir la séquence totale jusqu'à l'étape actuelle et va allumer les différentes leds en conséquence.<br />
<br />
La fonction readSequence va elle lire l'état successif des boutons et le comparer à la séquence actuelle. Si il y a une erreur, on sort de la fonction, et l'état de la partie devient un game over. Sinon, on continue et on appelle playSequence en incrémentant l'étape. En cas de réussite de la séquence, les 4 leds s'allument pour indiquer lé réussite et le passage au niveau supérieur.<br />
<br />
Coté websockets, c'est facile, dès qu'on reçoit un message par le client, on l'envoie à l'arduino ( bien qu'on aurait du vérifier la conformité du message ), l'arduino ne lira le message que si on est en étape de lecture de la séquence, donc après un game over par exemple. <br />
<br />
==== Partie mécanique : Suite et fin de la confection de la guitare et du jeu de Simon====<br />
<br />
Comme nous l'avons prédit, la plus '''grosse partie du travail''' réalisé a dû être faite lors de '''séances supplémentaires''' ou par '''travail personnel chez soi'''.<br />
<br />
Après avoir réalisé '''les croquis''', il était essentiel de '''créer rapidement les différents supports'''. En effet, cela nous permettait d'avoir du '''temps''' pour éventuellement''' recommencer et revoir les axes de travail en cas d'impossibilité de réalisation''' pour quelconque raison. De plus, une fois la''' partie mécanique terminée''', nous pouvions l''''utiliser''' comme '''support '''pour les '''tests électroniques'''. Enfin, cela nous laissait du temps en fin de projet pour '''décorer notre projet''', que nous voulions '''personnalisé''' afin d'en être '''le plus satisfaits possible'''. <br />
<br />
Un''' gros travail de modélisation''' à dû être fait sur '''FREECAD'''. Le '''support''' du jeu de Simon fut la pièce la plus '''simple '''à réaliser (un '''cylindre''' semi fermé, de '''7 cm de rayon''').<br />
<br />
Puis une simple''' découpe '''grâce à une '''scie''' permettrait de faire''' réceptacle''' pour une''' "croix porteuse" '''sur laquelle serait disposés les '''touches du Simon'''.<br />
<br />
De la même façon que pour la guitare, '''les touches''' seraient placées '''au dessus de boutons poussoirs'''. Ces derniers seront '''collés sur la croix'''. <br />
[[Fichier:tg.jpg||right|vignette|upright=1.5|]]<br />
Une fois ceci fait, il fallait '''réaliser le plus important du jeu''' : '''les touches à actionner '''! <br />
<br />
Pour cela, il était préférable de conserver la '''forme cylindrique '''du support en modélisant '''4 pièces''', d'un '''quart de disque''' chacune. Par soucis de '''fixation '''sur la croix et par envie d’'''esthétisme''', les touches seraient un peu '''incurvées''' pour donner une forme '''moins géométrique''' au rendu final. <br />
<br />
De plus, elles seront''' perforées''' pour laisser passer une '''LED''' de la même couleur que la touche sur laquelle elle se trouve. Ainsi l'utilisateur pourra '''mémoriser les touches à activer''' via le système '''lumineux''' des '''LEDs'''. <br />
<br />
Enfin, un '''cylindre permettant l'accroche''' sur la croix à été prévu sur la '''partie inférieure''' de les''' touches du Simon'''. (suite à une impression peu précise, '''ce cylindre sera « fondu »''' pour épouser la forme de la croix '''sans jeu dans la fixation'''.)<br />
<br />
[[Fichier:touc2.jpg||left|vignette|upright=1.7|]]<br />
Vint ensuite le''' moment de la création''' ! '''L'impression de ces pièces''' étant la plus '''complexe''', nous pensions qu'il serait nécessaire de les recommencer plusieurs fois. La '''WitBox du Fabricarium''' (la plus précise des imprimantes mise à notre disposition) a réalisé une '''impression assez laborieuse'''. Un gros travail de '''ponçage''' à donc dû être réalisé, car le support nécessaire pour imprimer cette pièce « incurvée » avait donné de '''nombreuses bavures''' sur la '''surface des touches'''. Afin que le '''toucher''' reste '''agréable''', nous avons donc '''retravaillé les pièces'''.<br />
<br />
<br />
Une fois ceci fait, nous avons '''essayé de les positionner''' sur la''' croix''' prévue à cet effet. Une fois encore, nous étions '''confronté aux limites de l'impression 3D'''. Les '''dimensions du « cylindre pillier » '''étant non précise, et cette partie étant''' trop fine pour être sciée''' '''sans rupture''' de la pièce, nous avons décidé de faire '''« fondre » '''cette partie et de la placer, encore chaude sur la partie en forme de croix. Cela permettait une''' fixation sûre''' et une '''dimension épousant parfaitement les formes du support'''. L'inconvénient fut que cette''' méthode, peu précise''', n'a fait qu''''accentuer les erreurs d'impressions''' au niveaux du '''visuel'''. Effectivement, les 4 pièces ne '''semblent pas régulières''' et le '''disque''' qu'elles sont censées former (ensemble de 4 quarts de disque) ne semble '''pas parfait'''.[[Fichier:bttt.jpg||right|vignette|upright=1.5|]][[Fichier:socle.jpg||right|vignette|upright=1.5|]]<br />
<br />
<br />
Nous décidons cependant de '''conserver ce léger défaut''', car si nous recommencions nous risquerions d'être de nouveau''' confronté au même souci''', l''''erreur''' n'étant pas uniquement dû à notre '''manipulation''' mais également à l''''imprimante 3D'''. <br />
<br />
<br />
L'impression du '''socle''' était la plus''' longue à imprimer''' (près de 6 heures) .Après l'avoir un peu '''scié''' comme prévu, cette pièce était également''' prête à être peinte'''. Nous avons fait de même avec la '''croix '''à placer sur le socle et servant de '''support''' aux '''quatre touches''' du Simon. Cette impression étant '''rapide et facile''', un seul essai suffit pour obtenir notre '''version définitive'''. L'impression fut dans ce cas, parfaitement aux '''mesures souhaitées''' dans le fichier .stl (bien que réalisé avec une imprimante de moins bonne qualité que la WitBox). Ainsi les '''boutons poussoirs '''que nous avions à positionner dessus tenaient sans souci '''par un simple encastrement'''. Par la suite, par '''mesure de sécurité''', <br />
nous avons tout de même rajouté un '''point de colle''' en dessous des''' boutons ''' pour éviter tout '''désencastrement non souhaité'''. <br />
[[Fichier:tr.jpg||left|vignette|upright=1.4|]]<br />
<br />
<br />
<br />
En parallèle, nous avons travaillé sur les '''différentes couches d'épaisseur''' de la ''' guitare'''. Dans un premier temps il était nécessaire de '''retirer une partie dans le manche''' pour y placer les boutons poussoirs. Cette étape aurait pu être réalisé rapidement avec la '''découpeuse laser''', mais celle ci étant '''en panne''', nous l'avons fait via '''une perceuse et un foret au Fabricarium'''. Le résultat était un '''peu moins net''' mais '''convenable cependant'''. De plus le '''"trou"''' sera '''caché''' par la pièce contenant '''les touches'''. Une fois la couche de bois travaillée, nous avons '''creusé '''la''' partie cartonnée''' afin de pouvoir y laisser passer les différents '''câbles '''liant les''' boutons poussoirs''' (situés sous les touches du manche de la guitare) à une '''breadboard''' (sur la partie basse de l'instrument).<br />
<br />
Afin que les '''câbles sortent de la guitare de façon propre''', nous avons percé '''4 trous à la base du manche'''. Ainsi de chaque''' trou''' ressortira '''deux fils de connectique''' ( un pour l'entrée du bouton poussoir et un pour la sortie).<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:tt.jpg||left|vignette|upright=2|]]<br />
Ceci étant terminé, il fallait passer à la '''conception des touches de la guitare'''.[[Fichier:touc.jpg||right|vignette|upright=2.2|]]<br />
C'est en '''observant''' une imprimante 3D du Fabricarium qu''''une idée de modèle touche vue le jour'''. Nous allions faire '''une seule et unique pièces''' pour les''' 4 touches'''.<br />
'''Fine''', elle pourrait être facilement '''pliée''' sous une '''pression du doigts''' pour '''actionner un bouton poussoir''' situé en '''dessous''' de chacune des 4 touches.suffirait juste de '''peindre les 4 touches de couleurs différentes''' pour les différencier.<br />
Cette pièce serait '''fixée sur le manche de la guitare''', couvrant une''' couche de bois perforée''' et une '''cartonnée « creusée »''' pour '''laisser passer la connectique '''jusqu'à la partie inférieure de la guitare.<br />
<br />
Finalement, il aura fallut '''quelques heures supplémentaires''' des séances pour avoir '''toutes nos partie modéliser sur FREECAD ''' et '''prête à être imprimées''', qu'elles soient destinées au '''Simon''' ou au '''Guitar Hero'''.<br />
<br />
L'heure est donc à la '''réalisation''' ! Les '''impressions 3D '''se sont faites sur l'imprimante d''''un des membre du groupe''' ainsi que sur celles du''' Fabricarium'''. <br />
<br />
Les''' touches''' qui actionneraient les boutons poussoirs étaient les plus à même d'être à''' recommencer'''. En effet, un '''problème de fixation''', ou encore une '''rigidité trop grande''' '''empêcherait''' l'actionnement du '''bouton '''et serait donc '''inutilisable'''. Ainsi nous avons '''commencé par imprimer les touches''' (pour la guitare et pour le simon). Dans un premier temps, nous nous sommes occupés de la pièce '''pour la guitare'''. La première '''impression '''fut''' décevante''', car''' trop épaisse '''(8mm) , la pièce''' ne pliait pas''' sous la pression des doigts et n’'''actionnait donc pas les boutons''' placés dessous.<br />
<br />
Ce pourquoi nous avons lancé immédiatement une '''nouvelle impression''' avec 3mm d'épaisseur. Les '''tests étant concluants''', nous n'avions plus qu'à la''' peindre''' de '''4 couleurs différentes '''pour symboliser les 4 touches du guitar hero. <br />
<br />
<br />
Ceci commença par la réalisation de '''soudures''' des '''boutons poussoirs''' avec les '''fils'''. Ces fils seraient ensuite placés '''sous '''la couche de '''bois''', '''dans''' la couche de '''carton'''. Cette étape fut '''rapidement terminée'''.<br />
<br />
Les '''8 boutons poussoirs étaient prêts '''! '''Quatre''' pour la''' guitare''',''' quatre '''pour le jeu de '''Simon'''.<br />
<br />
Finalement,''' toutes les pièces étant réalisées''', il fallait réaliser''' un travail d'assemblage''', et de '''finitions ''' (au niveaux des couches de peinture notamment). <br />
<br />
Nous nous sommes préalablement''' assuré '''que tous les '''boutons poussoirs étaient fonctionnels '''et que les''' soudures '''étaient '''correctement réalisées''' grâce à des''' tests rapides''' avec la '''carte arduino.'''<br />
<br />
<br />
[[Fichier:led.jpg||left|vignette|upright=1.2|]][[Fichier:end.jpg||RIGHT|vignette|upright=1.3|]]<br />
Enfin, il ne restait plus qu'à '''peindre''' nos différentes''' pièces'''.<br />
<br />
Premièrement nous avons '''appliqué deux couches de blanc''' sur '''chacune des pièces'''. Puis sur celles qui nécessitaient une '''couleur précise''' ( en autre : les touches de la guitare et du Simon), nous avons repassé '''deux couches''' de '''couleur''' dessus.<br />
Puis, nous avons '''assemblé toutes les pièces''' entre elles pour '''obtenir le résultat final''' ! <br />
<br />
L''''assemblage''' des différentes '''couches de la guitare''' à d'abord était '''provisoirement fait '''avec de la '''colle forte'''. Si le collage venait à '''céder''', nous utiliserons sans doute des''' vis '''ou des '''accroches '''en plastique pour maintenir le tout en place.<br />
<br />
Nous en avons profité pour utiliser la peinture restantes pour décorer un peu notre guitare et ainsi la personnaliser comme bon nous semblait.<br />
<br />
<br />
<br />
<br />
<br />
Finalement, le''' résultat''' est plus que '''satisfaisant '''! Les quatre '''couleurs primaires''' étant '''vives''', elles donnent un aspect '''coloré''' et '''joyeux''' à notre '''projet''' ! Les quatre '''touches du Simon''', '''surmontées''' d'une '''LED''' de la même couleur que la touche, permettent une '''utilisation claire et facile '''du « jeu de Simon ».<br />
<br />
<br />
Dans la '''globalité''', nous sommes assez '''fiers''' du résultat de la '''partie mécanique''' ! Que ce soit du ''' "jeu de Simon" '''ou de la '''Guitare''' du '''"Guitar Héro"''', les '''boutons poussoirs''' sont''' activables facilement '''(voir la vidéo de démonstration en cliquant sur le lien suivant :[https://youtu.be/3-p--BhHGr4] ). De plus le''' résultat est assez agréable''' à '''regarder''' ou encore '''facile a prendre en main'''. <br />
<br />
<br />
<br />
La '''partie mécanique '''étant bien '''avancée''' avant la fin du projet, nous avons décidé de''' procéder à certaines améliorations'''. En effet, les tests des parties électronique et informatique pouvaient donc s’effectuer sur le Simon et la guitare ainsi réalisée. Ainsi dans tous les cas nous avions '''deux prototypes''' à présenter à la fin du projet.<br />
<br />
En parallèle,''' une version plus élaborée''' de la guitare pouvait ainsi être en '''construction'''.<br />
Pour se faire, nous avons repris le fichier SVG explicité lors de la première séance et nous lui avons rajouté un rectangle rouge au niveau du manche, pour une '''découpe plus propre''' à la découpeuse laser, et '''moins fragilisante''' pour le bois.<br />
<br />
[[Fichier:entretoise.jpg||right|vignette|upright=1.5|]]<br />
[[Fichier:cote.jpg||left|vignette|upright=1.5|]]<br />
<br />
<br />
De plus pour gagner en '''propreté''', nous avons placé un PCB pour éviter l’encombrement.<br />
Enfin, nous avons pris la décision de laisser la''' guitare creuse''', afin de pouvoir '''mieux voir le contenu électronique''' à l’intérieur et de garder un '''aspect plus propre et épuré''' de la guitare.<br />
<br />
Pour ce faire, nous allons utiliser des '''entretoises''' qui permettront une largeur de guitare homogène. Afin d’éviter une pliure du bois au niveau des touches (et ainsi éviter que les touches ne soient pas actionnées car pas d’opposition de force), nous avons insisté sur les''' entretoises au-dessous des touches '''(que nous avons pris soin de fixer avec de la colle pour éviter de fragiliser le bois au niveau du manche en le perçant).<br />
<br />
Finalement, les '''touches sont activables facilement''', une fois la guitare prise en main. Un signal logique bas est bien transmis une fois les '''touches appuyées'''. Et il est '''bien détecté''' par''' l’arduino'''. <br />
<br />
[[Fichier:guitaredroite.jpg||center|vignette|upright=2|]]<br />
<br />
<br />
<br />
Désormais, la '''partie mécanique '''étant''' terminée et fonctionnelle''', il faut la '''lier à la partie informatique et électronique'''. Nous allons '''perfectionner la partie FPGA''' et''' Arduino '''pour''' exploiter''' pleinement les '''deux supports '''(guitare et jeu de Simon) ainsi réalisés.<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Conclusion </div>==<br />
<br />
<br />
En conclusion, Le '''jeu de Simon''' est '''terminé''' et est '''fonctionnel''. En effet le '''serveur websocket''' envoie une '''combinaison''' de couleur, composée par un utilisateur, à '''l’arduino''', qu’un second utilisateur devra tenter de '''reproduire''' (couleur par couleur, en reprenant du début à chaque fois, avec une couleur en plus à chaque tour). Le '''Jeu de Simon est terminé ''': '''L’objectif principal''' de notre projet est donc '''réalisé'''.<br />
<br />
Cependant, le '''Guitar Héro''' n’a pas pu être abouti. Nous avions précisé dès le début du projet que nous tâcherions de '''finir le Simon en priorité''' et de faire le Guitare Héro ensuite. La '''guitare est finalisée''' et '''fonctionnelle'''. Nous n’étions donc pas si loin de terminer les deux projets. <br />
Nous sommes globalement '''satisfaits''' du '''travail réalisé''' et de la''' prestation proposée'''. En effet en sachant que nous avions deux projets en simultané (bien que très ressemblant entre eux) nous avons su '''terminer le premier''' et '''bien avancer sur le second'''. Le '''but principal''' était de '''nous amuser''', de '''prendre du plaisir dans la réalisation d'un projet''' et de '''faire quelque chose qui nous plaisait avant tout''', '''l’objectif''' est '''atteint'''.<br />
Le FPGA n'a pas pu être aboutit non plus, et c'est dommage, car c'est une technologie intéressante, et c'est plus optimisé et rapide qu'une Arduino. <br />
<br />
Ce projet fut très '''intéressant''' car il nous a permis de '''mettre en application''' certains de nos '''cours étudiés''' cette année en IMA3, mais également d’en '''apprendre''' énormément '''par nous même''' à force de '''pratique '''et de''' recherches personnelles'''. Pour l’ensemble des membres du groupe, ce projet a été la confirmation de '''l’intérêt '''porté aux '''systèmes communiquants''', et nous a donc '''convaincu de choisir''' la '''filière SC''' à partir du semestre 8 en '''IMA4'''.<br />
<br />
<br />
La démonstration du fonctionnement du Jeu de Simon, est disponible à l'adresse suivante : https://youtu.be/RbgPtALDmFw .</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=Projet_IMA3_P3,_2016/2017,_TD1&diff=44302Projet IMA3 P3, 2016/2017, TD12017-06-18T20:22:21Z<p>Adurot : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 25px; padding: 20px; font-weight: bold; text-align: center; font-size: 98%; background: #6060FF; vertical-align: top; width: 99%;"> Projet IMA3-SC 2016/2017 : Le Jeu de Simon et le Guitar Hero </div>=<br />
<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Cahier des Charges </div>==<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Description du système </div>===<br />
<br />
* L'objectif principal de notre projet est de réaliser un '''jeu''' qui utilise à la fois les '''lumières''' et le '''son'''. Pour cela, nous avons pensé à deux versions : '''le Simon''' et un jeu du type '''Guitar Hero'''.<br />
<br />
* Le '''Simon''' est constitué de '''quatre boutons de couleurs différentes''' : un bleu, un rouge, un vert et un jaune. Le jeu va '''afficher''' une séquence de couleurs qui sont chacune '''associées à un son'''. Le joueur doit ensuite se '''souvenir''' de la suite (en s'aidant du son et des couleurs comme moyen mnémotechnique) pour la '''reproduire''' dans le '''bon ordre''' en '''appuyant sur les boutons'''.<br />
<br />
* Le jeu '''Guitar Hero''', quant à lui, est un jeu où il faut '''actionner des boutons de couleur précise''', '''au moment où elles apparaissent''' sur une barre de défilement, '''à l'écran'''. Ces différentes '''activations''', aux '''bons moments''', permettent de '''réaliser une mélodie''' plus ou moins complexe selon la difficulté de la chanson à reproduire. Le tout est effectué grâce à '''une guitare connectée''', afin de pousser l'expérience de '''simulation''' un peu plus loin. Si nous réalisons, ce jeu, il faut '''prendre en compte''' un '''affichage''' plus '''complexe'''. De plus, le '''Guitar Hero''' ajoute '''une notion de temps de réponse''', plus '''difficile à gérer'''. Ce temps de réponse permet de laisser une '''courte marge d'erreur''' dans la '''réactivité de l'utilisateur''', pour '''simuler pleinement''' l'utilisation d'une '''guitare électrique'''.<br />
<br />
<br />
Nous avons choisis de d'abord nous concentrer sur le '''Simon''' et de faire le jeu '''Guitar Hero''' seulement '''si nous avons le temps'''.<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Le matériel </div>===<br />
<br />
Pour ce '''projet''' nous utiliserons :<br />
<br />
* Une '''page internet''' sur l'ordinateur pour pouvoir '''modifier les différents aspects du jeu''' : les '''règles du jeu''', la '''musique''' jouée par le Simon ou bien la '''difficulté'''<br />
<br />
* Le '''Raspberry Pi''', utilisée en tant que serveur, va envoyer les données en série ( qui seront traitées par le FPGA ), de les recupérer, et de faire l'algorithme.<br />
<br />
* Une '''carte Arduino''' pour '''relier''' la Raspberry Pi aux composants dans un premier temps : elle nous permet de '''coder en C''' (au lieu d'un langage assembleur) pour '''créer des programmes''' et '''gérer''' les différents '''modules''' tel que les '''boutons''' et les '''LEDs'''. Elle permettra une '''simulation''' momentanée du '''FPGA''', afin que nous puissions avancer sur la partie informatique, sans attendre d'en avoir fini avec la partie FPGA.<br />
<br />
* Une fois le programme et les interactions fonctionnels, nous '''remplacerons''' l'Arduino par une '''FPGA''' qui est '''circuit logique programmable''' : on peut '''modifier les circuits logiques''' à l'intérieur mais '''on ne peut pas créer un programme''' avec un '''langage''' de plus '''haut niveau'''. Nous devrons donc utiliser des '''logiciels tiers''' qui nous permettront de placer des '''portes logiques''' (ET, OU,...) pour '''créer notre programme en assembleur'''.<br />
<br />
* Pour ce qui est de la '''partie mécanique''', nous réaliserons une '''guitare en bois''' pour le''' "Guitar Hero"''' ainsi qu'un''' "jeu de Simon"''' réalisé via l''''impression 3D.'''<br />
<br />
* Si le temps nous le permet, nous utiliserons un '''Xbee''' pour créer une '''connexion sans fil''', afin '''d'expérimenter''' un '''module nouveau''' et '''acquérir''' de '''nouvelles compétences'''.<br />
<br />
*Nous utiliserons également des '''composants électroniques''' tels que des '''boutons poussoirs''', des '''LEDs''' ou une '''matrice de LEDs''' pour l'affichage dans le cas du jeu de Simon, ainsi que de '''"l'essentiel"''' pour un '''système communiquant''' (à savoir '''résistances''', '''fils électriques''', etc...)<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Description des séances </div>==<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 21/03/17 Séance 1 : Répartition des tâches et premiers pas </div>===<br />
<br />
La première séance fut''' consacrée à la répartition des rôles''' et à la '''prise de conscience '''de la '''difficulté des différentes tâches'''. L''''idée''' de faire un '''« jeu de Simon » '''que nous''' amélioreront '''ensuite en '''« guitar hero »''' a cependant été '''conservée'''.<br />
<br />
==== Partie électronique ====<br />
<br />
Nous avons décidé de concentrer deux personnes sur le FPGA car c'est un élément très complexe et complètement nouveau.<br />
Nous allons en effet devoir reflechir à très bas niveau avec simplement des registres et des portes logiques.<br />
<br />
L'objectif du composant sera de récupérer un message contenant les boutons sur lesquelles appuyer. <br />
Une fois ce message reçu, le FPGA va comparer le bouton saisi par l'utilisateur avec le bouton demander. <br />
S'il est correct, le FPGA va passer à la couleur suivante, sinon il va renvoyer un message pour dire à la Raspberry (ou l'ordinateur) que l'utilisateur s'est trompé.<br />
<br />
Pour commencer, nous réalisons le tutoriel pour allumer une LED qui va nous permettre de comprendre le fonctionnement de Altium Designer.<br />
Cela nous a pris du temps mais nous avons pu réaliser d'autres essaies avec des registres à décalages et des boutons.<br />
<br />
Nous avons ensuite directement commencer le Simon :<br />
Le choix a été fait d'utiliser des registres à décalages pour récupérer la séquence de couleur envoyé par l'ordinateur/la raspberry. <br />
Nous allons en effet stocker toute la séquence de la "partie" car sinon il faudrait gérer beaucoup d'échange entre l'ordinateur et le FPGA ce qui est lourd en Altium et fait perdre du temps réaction du programme.<br />
<br />
D'un point de vue technique, utiliser un registre à décalage semble être la meilleur méthode pour récupérer un à un les bits qui arrivent sur la liaison série puis nous utilisons 4 registres à décalage : 1 pour chaque couleur.<br />
Pour chacun des registres nous aurons donc une séquence comme suit : 0100010010111. Les 1 correspondent aux moments ou il faut appuyer sur la couleur et les 0 aux moments ou il ne faut pas appuyer sur cette couleur. <br />
Nous devons donc également gérer les clocks des registres "couleurs". Ces registres doivent arrêter leur clock lorsque les bits de chaque couleur est à 0.<br />
<br />
Le registre pour la liaison série sera la clock du système puisqu'elle doit lire toute la séquence mais elle doit également s'arrêter lorsque le FPGA arrive à la fin de la séquence. Pour lui indiquer la fin de la séquence nous avons choisit le mot 0000 car il y aura toujours un bouton à appuyer pour le jeu Simon.<br />
<br />
==== Partie informatique ====<br />
<br />
L'objectif ici était la découverte des technologies à utiliser pour le système. Notamment une Arduino en liaison série à un PC et un serveur Websockets codé en C.<br />
La partie programmation arduino ne fut pas un problème. En effet, ce n'était pas la première fois que nous utilisions cet outil, et donc la mise en place de la liaison série fut très rapide.<br />
Ce n'est cependant pas le cas de la communication websockets. Bien que l'exemple de code fourni par M. Redon soit fonctionnel, le code n'en reste pas moins complexe à comprendre. Il fallait donc réussir à modifier le code du serveur websockets, afin de relier les deux systèmes entre eux.<br />
<br />
==== Partie mécanique : un modèle de guitare à découper====<br />
<br />
<br />
Dans cette première séance, nous avons décidé de focaliser nos premiers efforts sur la''' partie mécanique''' du '''"guitar hero"'''. En effet, le '''« jeu de simon »''' pouvait être avancé '''plus tard''' car plus''' facile''' à '''modéliser''' et à''' réaliser.'''[[Fichier:1.jpg||right|vignette|upright=2|]]<br />
Nous sommes alors partis sur l'idée de créer une''' maquette de guitare''', sur laquelle nous allions '''disposer''' différents '''boutons de couleur''', '''actionnables''' grâce à une '''pression''' sur le manche de l'instrument. Nous avions une '''ligne directrice''' mais pas encore d''''idée précise''' de comment allait être réalisé la guitare, ni même '''ce à quoi elle allait ressembler'''.<br />
<br />
<br />
Nous avons décidé de découper la '''guitare en bois''' qui nous servirait de support pour notre '''« guitar hero »''' grâce à la''' découpeuse laser'''. Pour se faire, un '''fichier conforme à la découpe''' devait être réalisé. <br />
Ainsi nous avons donc pris une '''image de guitare''' depuis '''internet'''. Dans le logiciel''' « GIMP »''', nous avons ensuite '''repassé les contours de l'instrument en rouge'''. Une fois ceci fait, nous avons''' effacé l'image de la guitare originale '''pour ne''' garder que les contours rouges'''. Enfin après '''quelques réglages''', l''''export en fichier SVG '''permettait une '''découpe précise'''. Les contours de la guitare sont disponibles ci contre (cliquez sur l'image pour bien voir).<br />
<br />
A la '''fin de la séance''', la '''guitare''' était''' prête à être réalisée '''et nous avons décidé de faire l'intégralité du''' « jeu de simon »''' via '''l'impression 3D'''. Cependant, aucune grande avancée n'a eu lieu sur la partie mécanique du jeu de Simon lors de cette séance.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 28/03/17 Séance 2 : Poursuite du Projet et rencontre des premiers problèmes </div>===<br />
<br />
La '''deuxième séance''' fut davantage '''productive''', car chacun de nous savait les différentes '''tâches''' qu'il lui '''restait à accomplir'''.<br />
<br />
==== Partie électronique ====<br />
Nous nous sommes rendu compte qu'utiliser le registre à décalage pour la liaison série comme nous le faisions n'était pas possible.<br />
En effet, la liaison série est en asynchrone et nous ne connaissance donc pas la clock. <br />
Nous ne pouvons donc pas utiliser cette clock pour le registre à décalage car sinon nous risquons de ne pas lire assez vite (ou trop vite) et donc récupérer trop de valeurs ou en rater.<br />
<br />
Le professeur nous a donc indiqué qu'il nous mettrait à disposition un module qui va s'occuper justement de lire la liaison série et de garder la séquence et de ressortir le message en parallèle.<br />
Ce composant envoie également sur un autre pin un 1 à chaque fois qu'un bit est envoyé par la liaison série (et reçu par le composant).<br />
Nous utilisons, selon ses conseils, un module analogique-digital qui va nous permettre de simuler l'envoi de la séquence.<br />
Après plusieurs tentatives nous avons un programme qui fonctionne correctement pour recevoir les valeurs. Il nous reste à comparer l'appui d'un bouton et la couleur à presser.<br />
<br />
==== Partie informatique ====<br />
<br />
L'écriture du programme de communication fut terminé assez rapidement. Mais il ne fonctionnait pas...<br />
En effet, un problème s'opérait lors de l'appel de la liaison série par le serveur websocket à réception d'un message.<br />
<br />
L'incompréhension régnait un peu, car à nos yeux tout était sensé fonctionner. Le principe était assez simple : à réception d'un message par le serveur websockets, ce dernier devait ouvrir une communication série sur le port TTY_USB0 (ou TTY_ACM0 en fonction de l'arduino) à 9600 bauds, y transférer le message reçu, puis refermer la communication.<br />
<br />
Après un long moment de doute, le problème fut résolu. Ce dernier était assez idiot. En effet, notre fonction d'envoi de message via le port série s'appelait : " send(..) ". Il s'avère qu'une fonction d'une des librairies utilisées se nomme de la même manière. Il y avait donc conflit et empêchait le programme de fonctionner correctement.<br />
<br />
Nous avons donc pu relier l'ordinateur à un montage de prototypage Arduino/LEDs afin de tester le bon fonctionnement du programme. Une combinaison de 4 LED devait s'allumer à réception d'un caractère. Il fallait donc envoyé un message compris entre 0(aucune LED allumée) et 15(toutes les LED allumées). Cependant, le début de la table ASCII ne représente pas des caractères. Le serveur envoie donc un message alphabétique compris entre 65 ('A') et 80 ('P') et l'arduino interprète ceci comme une valeur de 0 a 15<br />
<br />
==== Partie mécanique : découpe de la guitare, modélisation et impression d'un prototype de touches pour cette dernière ====<br />
<br />
[[Fichier:pp.jpg||left|vignette|upright=0.8|]]Cette séance fut entamée par la '''découpe de la guitare''' grâce à la '''découpeuse laser''' du '''Fabricarium de Polytech'''. Dans un premier temps il a d'abord était nécessaire '''« d'apprivoiser »''' la '''découpeuse''' et d''''apprendre à bien la configurer''' pour obtenir le résultat souhaité, sans risques. Un '''premier essai''' a d'abord était réalisé dans du '''carton''' pour pouvoir '''juger des différentes dimensions''' de la guitare.<br />
Enfin, une '''seconde version''', en''' bois''', fut réalisée durant cette séance. Finalement nous décidons de partir sur l'idée d'une '''guitare réalisée en 4 couches d'épaisseur''' : '''2 extérieures en bois''' ( une de '''face''', '''décorée''' avec les '''boutons à actionner''' et la carte '''arduino''' et une '''seconde''', '''arrière''', de '''protection'''), et '''deux intérieures en carton'''('''creusées''' pour laisser passer les '''fils de connectiques''').<br />
<br />
'''Note''' : Malheureusement, une des '''couche en bois''' a était '''cassée''' par la suite lors de la confection de la guitare. La''' panne prolongée''' de la '''découpeuse laser''' nous a contraint à '''renoncer à l'idée d'une quatrième couche en bois''' de protection.[[Fichier:po.jpg||right|vignette|upright=1.2|]]<br />
<br />
<br />
De plus, via le '''logiciel de modélisation FreeCAD''', nous avons commencé à concevoir deux '''prototypes''' de '''« touches »''' (boutons) pour la guitare. <br />
<br />
L'idée était de créer des '''surfaces larges''' (pouvant recueillir '''une phalange de doigts au minimum''') faisant office de '''touches''', en dessous desquelles nous '''insérerions''' un '''bouton poussoir''' 4 pins (fournis par les professeurs). La '''création de touches plus larges''' était '''indispensable'''. En effet, les '''boutons poussoirs''' étaient bien '''trop petits''' pour avoir un '''actionnement facile et agréable'''.<br />
Nous avons pu lancer l''''impression des touches''' à la''' fin de la séance'''. Cependant, les différents '''tests '''et les''' défauts d'impression''' nous ont fait comprendre qu'il serait''' difficile de « glisser » un bouton poussoir '''dans une '''touche '''avec un '''espace '''assez''' étroit '''pour le maintenir, sans pour autant '''bloquer son actionnement''' lorsqu'une '''pression''' était appliquée. De plus, la''' fixation''' risquait d'être assez '''complexe'''. <br />
Nous avons alors décidé de faire un tout '''autre type de touche''' mais avec le '''même fonctionnement'''. Pour cela nous allions avoir besoin de''' modéliser et d'imprimer '''de nouveaux un '''prototype de touche'''.<br />
Il allait ensuite falloir''' percer la première couche en bois de la guitare'''. Puis il serait également nécessaire de '''creuser les sous couches''' en carton pour y placer les boutons poussoirs et les différents câbles.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 05/04/2017 Séance 3 : Encore beaucoup de choses à faire !</div>===<br />
<br />
Bien que ce soit notre '''dernière séance officielle''', nous savions que nous allions avoir '''besoin''' de '''beaucoup de temps''' pour''' terminer ce projet '''! <br />
<br />
==== Partie électronique ====<br />
Le but de cette séance était de finaliser le FPGA et d'ajouter les blocs reception.vhdl et emission.vhdl fournis par M. Boé, ils nous permettent de gerer facilement la conversion serie / parallèle en asynchrone. Ainsi nous pouvons tester notre FPGA et nous rendre compte que ça ne marche pas, il y a un problème que nous n'arrivons pas à résoudre.<br />
Compte tenu du temps imparti, et du fait que la nanoboard n'était pas "embarquable", nous avons décidé de nous concentrer sur l'arduino afin d'avoir quelque chose qui fonctionne.<br />
[[Fichier:fpga.png|||vignette|upright=2|]]<br />
<br />
==== Partie informatique ====<br />
<br />
<br />
L'objectif de la séance était la mise en place de l'interface WEB, notamment pour le jeu Guitar Hero. <br />
<br />
Nous avons utilisé un canvas Javascript afin de dessiner un interface similaire a celle du jeu original.<br />
<br />
==== Partie mécanique ====<br />
<br />
La troisième séance était destinée à '''l’élaboration du jeu de Simon'''. Une première idée était de '''créer quatre pièces plates''', composées de''' multiples leds''', qu'il faudrait''' actionner''' via une simple''' pression'''. Cependant, nous nous sommes dit '''qu'une seule LED pour une couleur''', suffisait à '''indiquer''' la '''combinaison''' à reproduire. <br />
<br />
Le tout devait être assez '''grand''' pour '''contenir la carte arduino''' ainsi que toute la '''connectique''', '''sans''' pour autant '''être''' trop '''encombrant''', tout en étant assez '''ergonomique''' et '''agréable au regard'''.<br />
<br />
Nous avons donc décidé de '''créer un support creux ''' qui '''contiendrait la partie électronique ''', au dessus duquel nous placerions '''les 4 pièces de couleur''' avec '''une LED pour chaque couleur'''.<br />
<br />
Nous savions dès lors, qu'un '''travail long minutieux''' nous attendait.<br />
<br />
Ainsi nous avons fait de '''nombreux croquis''' avec les '''différentes pièces''' et leurs '''dimensions éventuelles'''. Des pièces que nous allions réaliser uniquement en '''impression 3D'''. Un '''travail similaire''' a été réalisé pour '''la guitare''', afin de ne pas '''percer la guitare à de mauvais endroits''', et pour '''agencé les différents parties''' à ajouter sur la guitare de la '''meilleure façon possible'''. Pour '''résumer''' cette séance, nous avons '''réalisé tous les croquis nécessaires à la réalisation''' de la '''guitare''' et du '''Simon'''.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Séance supplémentaire : Terminons ce Projet !</div>===<br />
<br />
Il n'y a pas eu un '''nombre précis de "séances supplémentaires".''' '''Chacun''' des membres du groupe travaillait '''soit chez lui''', '''soit à l'école''' de '''manière régulière''', afin '''d'avancer sa partie''' le plus '''rapidement''' possible.<br />
<br />
==== Partie électronique ====<br />
<br />
Pour le Simon, il a fallut souder les câbles aux boutons et aux leds ( avec leur résistance ). Pour se faire, on a utilisé un circuit à pastilles qui se place entre l'arduino et les boutons/led. Cela permet de prendre moins de place et de faire plus propre qu'une breadboard.<br />
[[Fichier:pcb1.jpg|left|vignette|upright=0.8|]]<br />
[[Fichier:pcb2.jpg|right|vignette|upright=0.8|]]<br />
<br />
=== Partie informatique ===<br />
<br />
La partie FPGA n'étant pas fonctionelle, il a fallut le remplacer par un Arduino. <br />
<br />
Le code de l'Arduino consiste en une succession d'étapes pour jouer. Tout d'abord il faut recevoir via le port série la séquence totale du Simon, sous la forme de chaîne de caractères. Par exemple si le message reçu est "RVBR", alors la séquence totale du Simon sera Rouge Vert Bleu Rouge. Ainsi une fonction reception_message a été codée, qui attend la réception série de la séquence. <br />
<br />
Dans l'algorithme du jeu en lui même on a une variable globale qui stocke l'état de la partie, et une qui stocke l'étape de la séquence. Ainsi en fonction de l'état de la partie on va soit jouer la séquence sur les leds, lire l'état des boutons, ou provoquer un game over.<br />
<br />
La fonction playSequence va parcourir la séquence totale jusqu'à l'étape actuelle et va allumer les différentes leds en conséquence.<br />
<br />
La fonction readSequence va elle lire l'état successif des boutons et le comparer à la séquence actuelle. Si il y a une erreur, on sort de la fonction, et l'état de la partie devient un game over. Sinon, on continue et on appelle playSequence en incrémentant l'étape. En cas de réussite de la séquence, les 4 leds s'allument pour indiquer lé réussite et le passage au niveau supérieur.<br />
<br />
Coté websockets, c'est facile, dès qu'on reçoit un message par le client, on l'envoie à l'arduino ( bien qu'on aurait du vérifier la conformité du message ), l'arduino ne lira le message que si on est en étape de lecture de la séquence, donc après un game over par exemple. <br />
<br />
==== Partie mécanique : Suite et fin de la confection de la guitare et du jeu de Simon====<br />
<br />
Comme nous l'avons prédit, la plus '''grosse partie du travail''' réalisé a dû être faite lors de '''séances supplémentaires''' ou par '''travail personnel chez soi'''.<br />
<br />
Après avoir réalisé '''les croquis''', il était essentiel de '''créer rapidement les différents supports'''. En effet, cela nous permettait d'avoir du '''temps''' pour éventuellement''' recommencer et revoir les axes de travail en cas d'impossibilité de réalisation''' pour quelconque raison. De plus, une fois la''' partie mécanique terminée''', nous pouvions l''''utiliser''' comme '''support '''pour les '''tests électroniques'''. Enfin, cela nous laissait du temps en fin de projet pour '''décorer notre projet''', que nous voulions '''personnalisé''' afin d'en être '''le plus satisfaits possible'''. <br />
<br />
Un''' gros travail de modélisation''' à dû être fait sur '''FREECAD'''. Le '''support''' du jeu de Simon fut la pièce la plus '''simple '''à réaliser (un '''cylindre''' semi fermé, de '''7 cm de rayon''').<br />
<br />
Puis une simple''' découpe '''grâce à une '''scie''' permettrait de faire''' réceptacle''' pour une''' "croix porteuse" '''sur laquelle serait disposés les '''touches du Simon'''.<br />
<br />
De la même façon que pour la guitare, '''les touches''' seraient placées '''au dessus de boutons poussoirs'''. Ces derniers seront '''collés sur la croix'''. <br />
[[Fichier:tg.jpg||right|vignette|upright=1.5|]]<br />
Une fois ceci fait, il fallait '''réaliser le plus important du jeu''' : '''les touches à actionner '''! <br />
<br />
Pour cela, il était préférable de conserver la '''forme cylindrique '''du support en modélisant '''4 pièces''', d'un '''quart de disque''' chacune. Par soucis de '''fixation '''sur la croix et par envie d’'''esthétisme''', les touches seraient un peu '''incurvées''' pour donner une forme '''moins géométrique''' au rendu final. <br />
<br />
De plus, elles seront''' perforées''' pour laisser passer une '''LED''' de la même couleur que la touche sur laquelle elle se trouve. Ainsi l'utilisateur pourra '''mémoriser les touches à activer''' via le système '''lumineux''' des '''LEDs'''. <br />
<br />
Enfin, un '''cylindre permettant l'accroche''' sur la croix à été prévu sur la '''partie inférieure''' de les''' touches du Simon'''. (suite à une impression peu précise, '''ce cylindre sera « fondu »''' pour épouser la forme de la croix '''sans jeu dans la fixation'''.)<br />
<br />
[[Fichier:touc2.jpg||left|vignette|upright=1.7|]]<br />
Vint ensuite le''' moment de la création''' ! '''L'impression de ces pièces''' étant la plus '''complexe''', nous pensions qu'il serait nécessaire de les recommencer plusieurs fois. La '''WitBox du Fabricarium''' (la plus précise des imprimantes mise à notre disposition) a réalisé une '''impression assez laborieuse'''. Un gros travail de '''ponçage''' à donc dû être réalisé, car le support nécessaire pour imprimer cette pièce « incurvée » avait donné de '''nombreuses bavures''' sur la '''surface des touches'''. Afin que le '''toucher''' reste '''agréable''', nous avons donc '''retravaillé les pièces'''.<br />
<br />
<br />
Une fois ceci fait, nous avons '''essayé de les positionner''' sur la''' croix''' prévue à cet effet. Une fois encore, nous étions '''confronté aux limites de l'impression 3D'''. Les '''dimensions du « cylindre pillier » '''étant non précise, et cette partie étant''' trop fine pour être sciée''' '''sans rupture''' de la pièce, nous avons décidé de faire '''« fondre » '''cette partie et de la placer, encore chaude sur la partie en forme de croix. Cela permettait une''' fixation sûre''' et une '''dimension épousant parfaitement les formes du support'''. L'inconvénient fut que cette''' méthode, peu précise''', n'a fait qu''''accentuer les erreurs d'impressions''' au niveaux du '''visuel'''. Effectivement, les 4 pièces ne '''semblent pas régulières''' et le '''disque''' qu'elles sont censées former (ensemble de 4 quarts de disque) ne semble '''pas parfait'''.[[Fichier:bttt.jpg||right|vignette|upright=1.5|]][[Fichier:socle.jpg||right|vignette|upright=1.5|]]<br />
<br />
<br />
Nous décidons cependant de '''conserver ce léger défaut''', car si nous recommencions nous risquerions d'être de nouveau''' confronté au même souci''', l''''erreur''' n'étant pas uniquement dû à notre '''manipulation''' mais également à l''''imprimante 3D'''. <br />
<br />
<br />
L'impression du '''socle''' était la plus''' longue à imprimer''' (près de 6 heures) .Après l'avoir un peu '''scié''' comme prévu, cette pièce était également''' prête à être peinte'''. Nous avons fait de même avec la '''croix '''à placer sur le socle et servant de '''support''' aux '''quatre touches''' du Simon. Cette impression étant '''rapide et facile''', un seul essai suffit pour obtenir notre '''version définitive'''. L'impression fut dans ce cas, parfaitement aux '''mesures souhaitées''' dans le fichier .stl (bien que réalisé avec une imprimante de moins bonne qualité que la WitBox). Ainsi les '''boutons poussoirs '''que nous avions à positionner dessus tenaient sans souci '''par un simple encastrement'''. Par la suite, par '''mesure de sécurité''', <br />
nous avons tout de même rajouté un '''point de colle''' en dessous des''' boutons ''' pour éviter tout '''désencastrement non souhaité'''. <br />
[[Fichier:tr.jpg||left|vignette|upright=1.4|]]<br />
<br />
<br />
<br />
En parallèle, nous avons travaillé sur les '''différentes couches d'épaisseur''' de la ''' guitare'''. Dans un premier temps il était nécessaire de '''retirer une partie dans le manche''' pour y placer les boutons poussoirs. Cette étape aurait pu être réalisé rapidement avec la '''découpeuse laser''', mais celle ci étant '''en panne''', nous l'avons fait via '''une perceuse et un foret au Fabricarium'''. Le résultat était un '''peu moins net''' mais '''convenable cependant'''. De plus le '''"trou"''' sera '''caché''' par la pièce contenant '''les touches'''. Une fois la couche de bois travaillée, nous avons '''creusé '''la''' partie cartonnée''' afin de pouvoir y laisser passer les différents '''câbles '''liant les''' boutons poussoirs''' (situés sous les touches du manche de la guitare) à une '''breadboard''' (sur la partie basse de l'instrument).<br />
<br />
Afin que les '''câbles sortent de la guitare de façon propre''', nous avons percé '''4 trous à la base du manche'''. Ainsi de chaque''' trou''' ressortira '''deux fils de connectique''' ( un pour l'entrée du bouton poussoir et un pour la sortie).<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:tt.jpg||left|vignette|upright=2|]]<br />
Ceci étant terminé, il fallait passer à la '''conception des touches de la guitare'''.[[Fichier:touc.jpg||right|vignette|upright=2.2|]]<br />
C'est en '''observant''' une imprimante 3D du Fabricarium qu''''une idée de modèle touche vue le jour'''. Nous allions faire '''une seule et unique pièces''' pour les''' 4 touches'''.<br />
'''Fine''', elle pourrait être facilement '''pliée''' sous une '''pression du doigts''' pour '''actionner un bouton poussoir''' situé en '''dessous''' de chacune des 4 touches.suffirait juste de '''peindre les 4 touches de couleurs différentes''' pour les différencier.<br />
Cette pièce serait '''fixée sur le manche de la guitare''', couvrant une''' couche de bois perforée''' et une '''cartonnée « creusée »''' pour '''laisser passer la connectique '''jusqu'à la partie inférieure de la guitare.<br />
<br />
Finalement, il aura fallut '''quelques heures supplémentaires''' des séances pour avoir '''toutes nos partie modéliser sur FREECAD ''' et '''prête à être imprimées''', qu'elles soient destinées au '''Simon''' ou au '''Guitar Hero'''.<br />
<br />
L'heure est donc à la '''réalisation''' ! Les '''impressions 3D '''se sont faites sur l'imprimante d''''un des membre du groupe''' ainsi que sur celles du''' Fabricarium'''. <br />
<br />
Les''' touches''' qui actionneraient les boutons poussoirs étaient les plus à même d'être à''' recommencer'''. En effet, un '''problème de fixation''', ou encore une '''rigidité trop grande''' '''empêcherait''' l'actionnement du '''bouton '''et serait donc '''inutilisable'''. Ainsi nous avons '''commencé par imprimer les touches''' (pour la guitare et pour le simon). Dans un premier temps, nous nous sommes occupés de la pièce '''pour la guitare'''. La première '''impression '''fut''' décevante''', car''' trop épaisse '''(8mm) , la pièce''' ne pliait pas''' sous la pression des doigts et n’'''actionnait donc pas les boutons''' placés dessous.<br />
<br />
Ce pourquoi nous avons lancé immédiatement une '''nouvelle impression''' avec 3mm d'épaisseur. Les '''tests étant concluants''', nous n'avions plus qu'à la''' peindre''' de '''4 couleurs différentes '''pour symboliser les 4 touches du guitar hero. <br />
<br />
<br />
Ceci commença par la réalisation de '''soudures''' des '''boutons poussoirs''' avec les '''fils'''. Ces fils seraient ensuite placés '''sous '''la couche de '''bois''', '''dans''' la couche de '''carton'''. Cette étape fut '''rapidement terminée'''.<br />
<br />
Les '''8 boutons poussoirs étaient prêts '''! '''Quatre''' pour la''' guitare''',''' quatre '''pour le jeu de '''Simon'''.<br />
<br />
Finalement,''' toutes les pièces étant réalisées''', il fallait réaliser''' un travail d'assemblage''', et de '''finitions ''' (au niveaux des couches de peinture notamment). <br />
<br />
Nous nous sommes préalablement''' assuré '''que tous les '''boutons poussoirs étaient fonctionnels '''et que les''' soudures '''étaient '''correctement réalisées''' grâce à des''' tests rapides''' avec la '''carte arduino.'''<br />
<br />
<br />
[[Fichier:led.jpg||left|vignette|upright=1.2|]][[Fichier:end.jpg||RIGHT|vignette|upright=1.3|]]<br />
Enfin, il ne restait plus qu'à '''peindre''' nos différentes''' pièces'''.<br />
<br />
Premièrement nous avons '''appliqué deux couches de blanc''' sur '''chacune des pièces'''. Puis sur celles qui nécessitaient une '''couleur précise''' ( en autre : les touches de la guitare et du Simon), nous avons repassé '''deux couches''' de '''couleur''' dessus.<br />
Puis, nous avons '''assemblé toutes les pièces''' entre elles pour '''obtenir le résultat final''' ! <br />
<br />
L''''assemblage''' des différentes '''couches de la guitare''' à d'abord était '''provisoirement fait '''avec de la '''colle forte'''. Si le collage venait à '''céder''', nous utiliserons sans doute des''' vis '''ou des '''accroches '''en plastique pour maintenir le tout en place.<br />
<br />
Nous en avons profité pour utiliser la peinture restantes pour décorer un peu notre guitare et ainsi la personnaliser comme bon nous semblait.<br />
<br />
<br />
<br />
<br />
<br />
Finalement, le''' résultat''' est plus que '''satisfaisant '''! Les quatre '''couleurs primaires''' étant '''vives''', elles donnent un aspect '''coloré''' et '''joyeux''' à notre '''projet''' ! Les quatre '''touches du Simon''', '''surmontées''' d'une '''LED''' de la même couleur que la touche, permettent une '''utilisation claire et facile '''du « jeu de Simon ».<br />
<br />
<br />
Dans la '''globalité''', nous sommes assez '''fiers''' du résultat de la '''partie mécanique''' ! Que ce soit du ''' "jeu de Simon" '''ou de la '''Guitare''' du '''"Guitar Héro"''', les '''boutons poussoirs''' sont''' activables facilement '''(voir la vidéo de démonstration en cliquant sur le lien suivant :[https://youtu.be/3-p--BhHGr4] ). De plus le''' résultat est assez agréable''' à '''regarder''' ou encore '''facile a prendre en main'''. <br />
<br />
<br />
<br />
La '''partie mécanique '''étant bien '''avancée''' avant la fin du projet, nous avons décidé de''' procéder à certaines améliorations'''. En effet, les tests des parties électronique et informatique pouvaient donc s’effectuer sur le Simon et la guitare ainsi réalisée. Ainsi dans tous les cas nous avions '''deux prototypes''' à présenter à la fin du projet.<br />
<br />
En parallèle,''' une version plus élaborée''' de la guitare pouvait ainsi être en '''construction'''.<br />
Pour se faire, nous avons repris le fichier SVG explicité lors de la première séance et nous lui avons rajouté un rectangle rouge au niveau du manche, pour une '''découpe plus propre''' à la découpeuse laser, et '''moins fragilisante''' pour le bois.<br />
<br />
[[Fichier:entretoise.jpg||right|vignette|upright=1.5|]]<br />
[[Fichier:cote.jpg||left|vignette|upright=1.5|]]<br />
<br />
<br />
De plus pour gagner en '''propreté''', nous avons placé un PCB pour éviter l’encombrement.<br />
Enfin, nous avons pris la décision de laisser la''' guitare creuse''', afin de pouvoir '''mieux voir le contenu électronique''' à l’intérieur et de garder un '''aspect plus propre et épuré''' de la guitare.<br />
<br />
Pour ce faire, nous allons utiliser des '''entretoises''' qui permettront une largeur de guitare homogène. Afin d’éviter une pliure du bois au niveau des touches (et ainsi éviter que les touches ne soient pas actionnées car pas d’opposition de force), nous avons insisté sur les''' entretoises au-dessous des touches '''(que nous avons pris soin de fixer avec de la colle pour éviter de fragiliser le bois au niveau du manche en le perçant).<br />
<br />
Finalement, les '''touches sont activables facilement''', une fois la guitare prise en main. Un signal logique bas est bien transmis une fois les '''touches appuyées'''. Et il est '''bien détecté''' par''' l’arduino'''. <br />
<br />
[[Fichier:guitaredroite.jpg||center|vignette|upright=2|]]<br />
<br />
<br />
<br />
Désormais, la '''partie mécanique '''étant''' terminée et fonctionnelle''', il faut la '''lier à la partie informatique et électronique'''. Nous allons '''perfectionner la partie FPGA''' et''' Arduino '''pour''' exploiter''' pleinement les '''deux supports '''(guitare et jeu de Simon) ainsi réalisés.<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Conclusion </div>==<br />
<br />
<br />
En conclusion, Le '''jeu de Simon''' est '''terminé''' et est '''fonctionnel''. En effet le '''serveur websocket''' envoie une '''combinaison''' de couleur, composée par un utilisateur, à '''l’arduino''', qu’un second utilisateur devra tenter de '''reproduire''' (couleur par couleur, en reprenant du début à chaque fois, avec une couleur en plus à chaque tour). Le '''Jeu de Simon est terminé ''': '''L’objectif principal''' de notre projet est donc '''réalisé'''.<br />
<br />
Cependant, le '''Guitar Héro''' n’a pas pu être abouti. Nous avions précisé dès le début du projet que nous tâcherions de '''finir le Simon en priorité''' et de faire le Guitare Héro ensuite. La '''guitare est finalisée''' et '''fonctionnelle'''. Nous n’étions donc pas si loin de terminer les deux projets. <br />
Nous sommes globalement '''satisfaits''' du '''travail réalisé''' et de la''' prestation proposée'''. En effet en sachant que nous avions deux projets en simultané (bien que très ressemblant entre eux) nous avons su '''terminer le premier''' et '''bien avancer sur le second'''. Le '''but principal''' était de '''nous amuser''', de '''prendre du plaisir dans la réalisation d'un projet''' et de '''faire quelque chose qui nous plaisait avant tout''', '''l’objectif''' est '''atteint'''.<br />
Le FPGA n'a pas pu être aboutit non plus, et c'est dommage, car c'est une technologie intéressante, et c'est plus optimisé et rapide qu'une Arduino. <br />
<br />
Ce projet fut très '''intéressant''' car il nous a permis de '''mettre en application''' certains de nos '''cours étudiés''' cette année en IMA3, mais également d’en '''apprendre''' énormément '''par nous même''' à force de '''pratique '''et de''' recherches personnelles'''. Pour l’ensemble des membres du groupe, ce projet a été la confirmation de '''l’intérêt '''porté aux '''systèmes communiquants''', et nous a donc '''convaincu de choisir''' la '''filière SC''' à partir du semestre 8 en '''IMA4'''.<br />
<br />
<br />
La démonstration du fonctionnement du Jeu de Simon, est disponible à l'adresse suivante : https://youtu.be/RbgPtALDmFw .</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=Projet_IMA3_P3,_2016/2017,_TD1&diff=44300Projet IMA3 P3, 2016/2017, TD12017-06-18T20:18:30Z<p>Adurot : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 25px; padding: 20px; font-weight: bold; text-align: center; font-size: 98%; background: #6060FF; vertical-align: top; width: 99%;"> Projet IMA3-SC 2016/2017 : Le Jeu de Simon et le Guitar Hero </div>=<br />
<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Cahier des Charges </div>==<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Description du système </div>===<br />
<br />
* L'objectif principal de notre projet est de réaliser un '''jeu''' qui utilise à la fois les '''lumières''' et le '''son'''. Pour cela, nous avons pensé à deux versions : '''le Simon''' et un jeu du type '''Guitar Hero'''.<br />
<br />
* Le '''Simon''' est constitué de '''quatre boutons de couleurs différentes''' : un bleu, un rouge, un vert et un jaune. Le jeu va '''afficher''' une séquence de couleurs qui sont chacune '''associées à un son'''. Le joueur doit ensuite se '''souvenir''' de la suite (en s'aidant du son et des couleurs comme moyen mnémotechnique) pour la '''reproduire''' dans le '''bon ordre''' en '''appuyant sur les boutons'''.<br />
<br />
* Le jeu '''Guitar Hero''', quant à lui, est un jeu où il faut '''actionner des boutons de couleur précise''', '''au moment où elles apparaissent''' sur une barre de défilement, '''à l'écran'''. Ces différentes '''activations''', aux '''bons moments''', permettent de '''réaliser une mélodie''' plus ou moins complexe selon la difficulté de la chanson à reproduire. Le tout est effectué grâce à '''une guitare connectée''', afin de pousser l'expérience de '''simulation''' un peu plus loin. Si nous réalisons, ce jeu, il faut '''prendre en compte''' un '''affichage''' plus '''complexe'''. De plus, le '''Guitar Hero''' ajoute '''une notion de temps de réponse''', plus '''difficile à gérer'''. Ce temps de réponse permet de laisser une '''courte marge d'erreur''' dans la '''réactivité de l'utilisateur''', pour '''simuler pleinement''' l'utilisation d'une '''guitare électrique'''.<br />
<br />
<br />
Nous avons choisis de d'abord nous concentrer sur le '''Simon''' et de faire le jeu '''Guitar Hero''' seulement '''si nous avons le temps'''.<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Le matériel </div>===<br />
<br />
Pour ce '''projet''' nous utiliserons :<br />
<br />
* Une '''page internet''' sur l'ordinateur pour pouvoir '''modifier les différents aspects du jeu''' : les '''règles du jeu''', la '''musique''' jouée par le Simon ou bien la '''difficulté'''<br />
<br />
* Le '''Raspberry Pi''', utilisée en tant que serveur, va envoyer les données en série ( qui seront traitées par le FPGA ), de les recupérer, et de faire l'algorithme.<br />
<br />
* Une '''carte Arduino''' pour '''relier''' la Raspberry Pi aux composants dans un premier temps : elle nous permet de '''coder en C''' (au lieu d'un langage assembleur) pour '''créer des programmes''' et '''gérer''' les différents '''modules''' tel que les '''boutons''' et les '''LEDs'''. Elle permettra une '''simulation''' momentanée du '''FPGA''', afin que nous puissions avancer sur la partie informatique, sans attendre d'en avoir fini avec la partie FPGA.<br />
<br />
* Une fois le programme et les interactions fonctionnels, nous '''remplacerons''' l'Arduino par une '''FPGA''' qui est '''circuit logique programmable''' : on peut '''modifier les circuits logiques''' à l'intérieur mais '''on ne peut pas créer un programme''' avec un '''langage''' de plus '''haut niveau'''. Nous devrons donc utiliser des '''logiciels tiers''' qui nous permettront de placer des '''portes logiques''' (ET, OU,...) pour '''créer notre programme en assembleur'''.<br />
<br />
* Pour ce qui est de la '''partie mécanique''', nous réaliserons une '''guitare en bois''' pour le''' "Guitar Hero"''' ainsi qu'un''' "jeu de Simon"''' réalisé via l''''impression 3D.'''<br />
<br />
* Si le temps nous le permet, nous utiliserons un '''Xbee''' pour créer une '''connexion sans fil''', afin '''d'expérimenter''' un '''module nouveau''' et '''acquérir''' de '''nouvelles compétences'''.<br />
<br />
*Nous utiliserons également des '''composants électroniques''' tels que des '''boutons poussoirs''', des '''LEDs''' ou une '''matrice de LEDs''' pour l'affichage dans le cas du jeu de Simon, ainsi que de '''"l'essentiel"''' pour un '''système communiquant''' (à savoir '''résistances''', '''fils électriques''', etc...)<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Description des séances </div>==<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 21/03/17 Séance 1 : Répartition des tâches et premiers pas </div>===<br />
<br />
La première séance fut''' consacrée à la répartition des rôles''' et à la '''prise de conscience '''de la '''difficulté des différentes tâches'''. L''''idée''' de faire un '''« jeu de Simon » '''que nous''' amélioreront '''ensuite en '''« guitar hero »''' a cependant été '''conservée'''.<br />
<br />
==== Partie électronique ====<br />
<br />
Nous avons décider de concentrer deux personnes sur le FPGA car c'est un élément très complexe et complètement nouveau.<br />
Nous allons en effet devoir coder à très bas niveau avec simplement des registres et des portes logiques.<br />
<br />
L'objectif du composant sera de récupérer un message contenant les boutons sur lesquelles appuyer. <br />
Une fois ce message reçu, le FPGA va comparer le bouton saisi par l'utilisateur avec le bouton demander. <br />
S'il est correct, le fpga va passer à la couleur suivante, sinon il va renvoyer un message pour dire à la Raspberry (ou l'ordinateur) que l'utilisateur s'est trompé.<br />
<br />
Pour commencer, nous réalisons le tutoriel pour allumer une LED qui va nous permettre de comprendre le fonctionnement de Altium Designer.<br />
Cela nous a pris du temps mais nous avons pu réaliser d'autres essaies avec des registres à décalages et des boutons.<br />
<br />
Nous avons ensuite directement commencer le Simon :<br />
Le choix a été fait d'utiliser des registres à décalages pour récupérer la séquence de couleur envoyé par l'ordinateur/la raspberry. <br />
Nous allons en effet stocker toute la séquence de la "partie" car sinon il faudrait gérer beaucoup d'échange entre l'ordinateur et le FPGA ce qui est lourd en Altium et fait perdre du temps réaction du programme.<br />
<br />
D'un point de vue technique, utiliser un registre à décalage semble être la meilleur méthode pour récupérer un à un les bits qui arrivent sur la liaison série puis nous utilisons 4 registres à décalage : 1 pour chaque couleur.<br />
Pour chacun des registres nous aurons donc une séquence comme suit : 0100010010111. Les 1 correspondent aux moments ou il faut appuyer sur la couleur et les 0 aux moments ou il ne faut pas appuyer sur cette couleur. <br />
Nous devons donc également gérer les clocks des registres "couleurs". Ces registres doivent arrêter leur clock lorsque les bits de chaque couleur est à 0.<br />
<br />
Le registre pour la liaison série sera la clock du système puisqu'elle doit lire toute la séquence mais elle doit également s'arrêter lorsque le FPGA arrive à la fin de la séquence. Pour lui indiquer la fin de la séquence nous avons choisit le mot 0000 car il y aura toujours un bouton à appuyer pour le jeu Simon.<br />
<br />
==== Partie informatique ====<br />
<br />
L'objectif ici était la découverte des technologies à utiliser pour le système. Notamment une Arduino en liaison série à un PC et un serveur Websockets codé en C.<br />
La partie programmation arduino ne fut pas un problème. En effet, ce n'était pas la première fois que nous utilisions cet outil, et donc la mise en place de la liaison série fut très rapide.<br />
Ce n'est cependant pas le cas de la communication websockets. Bien que l'exemple de code fourni par M. Redon soit fonctionnel, le code n'en reste pas moins complexe à comprendre. Il fallait donc réussir à modifier le code du serveur websockets, afin de relier les deux systèmes entre eux.<br />
<br />
==== Partie mécanique : un modèle de guitare à découper====<br />
<br />
<br />
Dans cette première séance, nous avons décidé de focaliser nos premiers efforts sur la''' partie mécanique''' du '''"guitar hero"'''. En effet, le '''« jeu de simon »''' pouvait être avancé '''plus tard''' car plus''' facile''' à '''modéliser''' et à''' réaliser.'''[[Fichier:1.jpg||right|vignette|upright=2|]]<br />
Nous sommes alors partis sur l'idée de créer une''' maquette de guitare''', sur laquelle nous allions '''disposer''' différents '''boutons de couleur''', '''actionnables''' grâce à une '''pression''' sur le manche de l'instrument. Nous avions une '''ligne directrice''' mais pas encore d''''idée précise''' de comment allait être réalisé la guitare, ni même '''ce à quoi elle allait ressembler'''.<br />
<br />
<br />
Nous avons décidé de découper la '''guitare en bois''' qui nous servirait de support pour notre '''« guitar hero »''' grâce à la''' découpeuse laser'''. Pour se faire, un '''fichier conforme à la découpe''' devait être réalisé. <br />
Ainsi nous avons donc pris une '''image de guitare''' depuis '''internet'''. Dans le logiciel''' « GIMP »''', nous avons ensuite '''repassé les contours de l'instrument en rouge'''. Une fois ceci fait, nous avons''' effacé l'image de la guitare originale '''pour ne''' garder que les contours rouges'''. Enfin après '''quelques réglages''', l''''export en fichier SVG '''permettait une '''découpe précise'''. Les contours de la guitare sont disponibles ci contre (cliquez sur l'image pour bien voir).<br />
<br />
A la '''fin de la séance''', la '''guitare''' était''' prête à être réalisée '''et nous avons décidé de faire l'intégralité du''' « jeu de simon »''' via '''l'impression 3D'''. Cependant, aucune grande avancée n'a eu lieu sur la partie mécanique du jeu de Simon lors de cette séance.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 28/03/17 Séance 2 : Poursuite du Projet et rencontre des premiers problèmes </div>===<br />
<br />
La '''deuxième séance''' fut davantage '''productive''', car chacun de nous savait les différentes '''tâches''' qu'il lui '''restait à accomplir'''.<br />
<br />
==== Partie électronique ====<br />
Nous nous sommes rendu compte qu'utiliser le registre à décalage pour la liaison série comme nous le faisions n'était pas possible.<br />
En effet, la liaison série est en asynchrone et nous ne connaissance donc pas la clock. <br />
Nous ne pouvons donc pas utiliser cette clock pour le registre à décalage car sinon nous risquons de ne pas lire assez vite (ou trop vite) et donc récupérer trop de valeurs ou en rater.<br />
<br />
Le professeur nous a donc indiquer qu'il nous mettrai à disposition un module qui va s'occuper justement de lire la liaison série et de garder la séquence et de ressortir le message en parallèle.<br />
Ce composant envoie également sur un autre pin un 1 à chaque fois qu'un bit est envoyé par la liaison série (et reçu par le composant).<br />
Nous utilisons, selon ces conseils, un module analogique-digital qui va nous permettre de simuler l'envoi de la séquence.<br />
Après plusieurs tentative nous avons un programme qui fonctionne correctement pour recevoir les valeurs. Il nous reste à comparer l'appuie d'un bouton et la couleur à presser.<br />
<br />
==== Partie informatique ====<br />
<br />
L'écriture du programme de communication fut terminé assez rapidement. Mais il ne fonctionnait pas...<br />
En effet, un problème s'opérait lors de l'appel de la liaison série par le serveur websocket à réception d'un message.<br />
<br />
L'incompréhension régnait un peu, car à nos yeux tout était sensé fonctionner. Le principe était assez simple : à reception d'un message par le serveur websockets, ce dernier devait ouvrir une communication série sur le port TTY_USB0 (ou TTY_ACM0 en fonction de l'arduino) à 9600 bauds, y transférer le message reçu, puis refermer la communication.<br />
<br />
Après un long moment de doute, le problème fut résolu. Ce dernier était assez idiot. En effet, notre fonction d'envoi de message via le port série s'appelait : " send(..) ". Il s'avère qu'une fonction d'une des librairies utilisées se nomme de la même manière. Il y avait donc conflit et empêchait le programme de fonctionner correctement.<br />
<br />
Nous avons donc pu relier l'ordinateur à un montage de prototypage Arduino/LEDs afin de tester le bon fonctionnement du programme. Une combinaison de 4 LED devait s'allumer à réception d'un caractère. Il fallait donc envoyé un message compris entre 0(aucune LED allumée) et 15(toutes les LED allumées). Cependant, le début de la table ASCII ne représente pas des caractères. Le serveur envoie donc un message alphabétique compris entre 65 ('A') et 80 ('P') et l'arduino interprète ceci comme une valeur de 0 a 15<br />
<br />
==== Partie mécanique : découpe de la guitare, modélisation et impression d'un prototype de touches pour cette dernière ====<br />
<br />
[[Fichier:pp.jpg||left|vignette|upright=0.8|]]Cette séance fut entamée par la '''découpe de la guitare''' grâce à la '''découpeuse laser''' du '''Fabricarium de Polytech'''. Dans un premier temps il a d'abord était nécessaire '''« d'apprivoiser »''' la '''découpeuse''' et d''''apprendre à bien la configurer''' pour obtenir le résultat souhaité, sans risques. Un '''premier essai''' a d'abord était réalisé dans du '''carton''' pour pouvoir '''juger des différentes dimensions''' de la guitare.<br />
Enfin, une '''seconde version''', en''' bois''', fut réalisée durant cette séance. Finalement nous décidons de partir sur l'idée d'une '''guitare réalisée en 4 couches d'épaisseur''' : '''2 extérieures en bois''' ( une de '''face''', '''décorée''' avec les '''boutons à actionner''' et la carte '''arduino''' et une '''seconde''', '''arrière''', de '''protection'''), et '''deux intérieures en carton'''('''creusées''' pour laisser passer les '''fils de connectiques''').<br />
<br />
'''Note''' : Malheureusement, une des '''couche en bois''' a était '''cassée''' par la suite lors de la confection de la guitare. La''' panne prolongée''' de la '''découpeuse laser''' nous a contraint à '''renoncer à l'idée d'une quatrième couche en bois''' de protection.[[Fichier:po.jpg||right|vignette|upright=1.2|]]<br />
<br />
<br />
De plus, via le '''logiciel de modélisation FreeCAD''', nous avons commencé à concevoir deux '''prototypes''' de '''« touches »''' (boutons) pour la guitare. <br />
<br />
L'idée était de créer des '''surfaces larges''' (pouvant recueillir '''une phalange de doigts au minimum''') faisant office de '''touches''', en dessous desquelles nous '''insérerions''' un '''bouton poussoir''' 4 pins (fournis par les professeurs). La '''création de touches plus larges''' était '''indispensable'''. En effet, les '''boutons poussoirs''' étaient bien '''trop petits''' pour avoir un '''actionnement facile et agréable'''.<br />
Nous avons pu lancer l''''impression des touches''' à la''' fin de la séance'''. Cependant, les différents '''tests '''et les''' défauts d'impression''' nous ont fait comprendre qu'il serait''' difficile de « glisser » un bouton poussoir '''dans une '''touche '''avec un '''espace '''assez''' étroit '''pour le maintenir, sans pour autant '''bloquer son actionnement''' lorsqu'une '''pression''' était appliquée. De plus, la''' fixation''' risquait d'être assez '''complexe'''. <br />
Nous avons alors décidé de faire un tout '''autre type de touche''' mais avec le '''même fonctionnement'''. Pour cela nous allions avoir besoin de''' modéliser et d'imprimer '''de nouveaux un '''prototype de touche'''.<br />
Il allait ensuite falloir''' percer la première couche en bois de la guitare'''. Puis il serait également nécessaire de '''creuser les sous couches''' en carton pour y placer les boutons poussoirs et les différents câbles.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 05/04/2017 Séance 3 : Encore beaucoup de choses à faire !</div>===<br />
<br />
Bien que ce soit notre '''dernière séance officielle''', nous savions que nous allions avoir '''besoin''' de '''beaucoup de temps''' pour''' terminer ce projet '''! <br />
<br />
==== Partie électronique ====<br />
Le but de cette séance était de finaliser le FPGA et d'ajouter les blocs reception.vhdl et emission.vhdl fournis par M. Boé, ils nous permettent de gerer facilement la conversion serie / parallèle en asynchrone. Ainsi nous pouvons tester notre FPGA et nous rendre compte que ça ne marche pas, il y a un problème que nous n'arrivons pas à résoudre.<br />
Compte tenu du temps imparti, et du fait que la nanoboard n'était pas "embarquable", nous avons décidé de nous concentrer sur l'arduino afin d'avoir quelque chose qui fonctionne.<br />
[[Fichier:fpga.png|||vignette|upright=2|]]<br />
<br />
==== Partie informatique ====<br />
<br />
<br />
L'objectif de la séance était la mise en place de l'interface WEB, notamment pour le jeu Guitar Hero. <br />
<br />
Nous avons utilisé un canvas Javascript afin de dessiner un interface similaire a celle du jeu original.<br />
<br />
==== Partie mécanique ====<br />
<br />
La troisième séance était destinée à '''l’élaboration du jeu de Simon'''. Une première idée était de '''créer quatre pièces plates''', composées de''' multiples leds''', qu'il faudrait''' actionner''' via une simple''' pression'''. Cependant, nous nous sommes dit '''qu'une seule LED pour une couleur''', suffisait à '''indiquer''' la '''combinaison''' à reproduire. <br />
<br />
Le tout devait être assez '''grand''' pour '''contenir la carte arduino''' ainsi que toute la '''connectique''', '''sans''' pour autant '''être''' trop '''encombrant''', tout en étant assez '''ergonomique''' et '''agréable au regard'''.<br />
<br />
Nous avons donc décidé de '''créer un support creux ''' qui '''contiendrait la partie électronique ''', au dessus duquel nous placerions '''les 4 pièces de couleur''' avec '''une LED pour chaque couleur'''.<br />
<br />
Nous savions dès lors, qu'un '''travail long minutieux''' nous attendait.<br />
<br />
Ainsi nous avons fait de '''nombreux croquis''' avec les '''différentes pièces''' et leurs '''dimensions éventuelles'''. Des pièces que nous allions réaliser uniquement en '''impression 3D'''. Un '''travail similaire''' a été réalisé pour '''la guitare''', afin de ne pas '''percer la guitare à de mauvais endroits''', et pour '''agencé les différents parties''' à ajouter sur la guitare de la '''meilleure façon possible'''. Pour '''résumer''' cette séance, nous avons '''réalisé tous les croquis nécessaires à la réalisation''' de la '''guitare''' et du '''Simon'''.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Séance supplémentaire : Terminons ce Projet !</div>===<br />
<br />
Il n'y a pas eu un '''nombre précis de "séances supplémentaires".''' '''Chacun''' des membres du groupe travaillait '''soit chez lui''', '''soit à l'école''' de '''manière régulière''', afin '''d'avancer sa partie''' le plus '''rapidement''' possible.<br />
<br />
==== Partie électronique ====<br />
<br />
Pour le Simon, il a fallut souder les câbles aux boutons et aux leds ( avec leur résistance ). Pour se faire, on a utilisé un circuit à pastilles qui se place entre l'arduino et les boutons/led. Cela permet de prendre moins de place et de faire plus propre qu'une breadboard.<br />
[[Fichier:pcb1.jpg|left|vignette|upright=0.8|]]<br />
[[Fichier:pcb2.jpg|right|vignette|upright=0.8|]]<br />
<br />
=== Partie informatique ===<br />
<br />
La partie FPGA n'étant pas fonctionelle, il a fallut le remplacer par un Arduino. <br />
<br />
Le code de l'Arduino consiste en une succession d'étapes pour jouer. Tout d'abord il faut recevoir via le port série la séquence totale du Simon, sous la forme de chaîne de caractères. Par exemple si le message reçu est "RVBR", alors la séquence totale du Simon sera Rouge Vert Bleu Rouge. Ainsi une fonction reception_message a été codée, qui attend la réception série de la séquence. <br />
<br />
Dans l'algorithme du jeu en lui même on a une variable globale qui stocke l'état de la partie, et une qui stocke l'étape de la séquence. Ainsi en fonction de l'état de la partie on va soit jouer la séquence sur les leds, lire l'état des boutons, ou provoquer un game over.<br />
<br />
La fonction playSequence va parcourir la séquence totale jusqu'à l'étape actuelle et va allumer les différentes leds en conséquence.<br />
<br />
La fonction readSequence va elle lire l'état successif des boutons et le comparer à la séquence actuelle. Si il y a une erreur, on sort de la fonction, et l'état de la partie devient un game over. Sinon, on continue et on appelle playSequence en incrémentant l'étape. En cas de réussite de la séquence, les 4 leds s'allument pour indiquer lé réussite et le passage au niveau supérieur.<br />
<br />
Coté websockets, c'est facile, dès qu'on reçoit un message par le client, on l'envoie à l'arduino ( bien qu'on aurait du vérifier la conformité du message ), l'arduino ne lira le message que si on est en étape de lecture de la séquence, donc après un game over par exemple. <br />
<br />
==== Partie mécanique : Suite et fin de la confection de la guitare et du jeu de Simon====<br />
<br />
Comme nous l'avons prédit, la plus '''grosse partie du travail''' réalisé a dû être faite lors de '''séances supplémentaires''' ou par '''travail personnel chez soi'''.<br />
<br />
Après avoir réalisé '''les croquis''', il était essentiel de '''créer rapidement les différents supports'''. En effet, cela nous permettait d'avoir du '''temps''' pour éventuellement''' recommencer et revoir les axes de travail en cas d'impossibilité de réalisation''' pour quelconque raison. De plus, une fois la''' partie mécanique terminée''', nous pouvions l''''utiliser''' comme '''support '''pour les '''tests électroniques'''. Enfin, cela nous laissait du temps en fin de projet pour '''décorer notre projet''', que nous voulions '''personnalisé''' afin d'en être '''le plus satisfaits possible'''. <br />
<br />
Un''' gros travail de modélisation''' à dû être fait sur '''FREECAD'''. Le '''support''' du jeu de Simon fut la pièce la plus '''simple '''à réaliser (un '''cylindre''' semi fermé, de '''7 cm de rayon''').<br />
<br />
Puis une simple''' découpe '''grâce à une '''scie''' permettrait de faire''' réceptacle''' pour une''' "croix porteuse" '''sur laquelle serait disposés les '''touches du Simon'''.<br />
<br />
De la même façon que pour la guitare, '''les touches''' seraient placées '''au dessus de boutons poussoirs'''. Ces derniers seront '''collés sur la croix'''. <br />
[[Fichier:tg.jpg||right|vignette|upright=1.5|]]<br />
Une fois ceci fait, il fallait '''réaliser le plus important du jeu''' : '''les touches à actionner '''! <br />
<br />
Pour cela, il était préférable de conserver la '''forme cylindrique '''du support en modélisant '''4 pièces''', d'un '''quart de disque''' chacune. Par soucis de '''fixation '''sur la croix et par envie d’'''esthétisme''', les touches seraient un peu '''incurvées''' pour donner une forme '''moins géométrique''' au rendu final. <br />
<br />
De plus, elles seront''' perforées''' pour laisser passer une '''LED''' de la même couleur que la touche sur laquelle elle se trouve. Ainsi l'utilisateur pourra '''mémoriser les touches à activer''' via le système '''lumineux''' des '''LEDs'''. <br />
<br />
Enfin, un '''cylindre permettant l'accroche''' sur la croix à été prévu sur la '''partie inférieure''' de les''' touches du Simon'''. (suite à une impression peu précise, '''ce cylindre sera « fondu »''' pour épouser la forme de la croix '''sans jeu dans la fixation'''.)<br />
<br />
[[Fichier:touc2.jpg||left|vignette|upright=1.7|]]<br />
Vint ensuite le''' moment de la création''' ! '''L'impression de ces pièces''' étant la plus '''complexe''', nous pensions qu'il serait nécessaire de les recommencer plusieurs fois. La '''WitBox du Fabricarium''' (la plus précise des imprimantes mise à notre disposition) a réalisé une '''impression assez laborieuse'''. Un gros travail de '''ponçage''' à donc dû être réalisé, car le support nécessaire pour imprimer cette pièce « incurvée » avait donné de '''nombreuses bavures''' sur la '''surface des touches'''. Afin que le '''toucher''' reste '''agréable''', nous avons donc '''retravaillé les pièces'''.<br />
<br />
<br />
Une fois ceci fait, nous avons '''essayé de les positionner''' sur la''' croix''' prévue à cet effet. Une fois encore, nous étions '''confronté aux limites de l'impression 3D'''. Les '''dimensions du « cylindre pillier » '''étant non précise, et cette partie étant''' trop fine pour être sciée''' '''sans rupture''' de la pièce, nous avons décidé de faire '''« fondre » '''cette partie et de la placer, encore chaude sur la partie en forme de croix. Cela permettait une''' fixation sûre''' et une '''dimension épousant parfaitement les formes du support'''. L'inconvénient fut que cette''' méthode, peu précise''', n'a fait qu''''accentuer les erreurs d'impressions''' au niveaux du '''visuel'''. Effectivement, les 4 pièces ne '''semblent pas régulières''' et le '''disque''' qu'elles sont censées former (ensemble de 4 quarts de disque) ne semble '''pas parfait'''.[[Fichier:bttt.jpg||right|vignette|upright=1.5|]][[Fichier:socle.jpg||right|vignette|upright=1.5|]]<br />
<br />
<br />
Nous décidons cependant de '''conserver ce léger défaut''', car si nous recommencions nous risquerions d'être de nouveau''' confronté au même souci''', l''''erreur''' n'étant pas uniquement dû à notre '''manipulation''' mais également à l''''imprimante 3D'''. <br />
<br />
<br />
L'impression du '''socle''' était la plus''' longue à imprimer''' (près de 6 heures) .Après l'avoir un peu '''scié''' comme prévu, cette pièce était également''' prête à être peinte'''. Nous avons fait de même avec la '''croix '''à placer sur le socle et servant de '''support''' aux '''quatre touches''' du Simon. Cette impression étant '''rapide et facile''', un seul essai suffit pour obtenir notre '''version définitive'''. L'impression fut dans ce cas, parfaitement aux '''mesures souhaitées''' dans le fichier .stl (bien que réalisé avec une imprimante de moins bonne qualité que la WitBox). Ainsi les '''boutons poussoirs '''que nous avions à positionner dessus tenaient sans souci '''par un simple encastrement'''. Par la suite, par '''mesure de sécurité''', <br />
nous avons tout de même rajouté un '''point de colle''' en dessous des''' boutons ''' pour éviter tout '''désencastrement non souhaité'''. <br />
[[Fichier:tr.jpg||left|vignette|upright=1.4|]]<br />
<br />
<br />
<br />
En parallèle, nous avons travaillé sur les '''différentes couches d'épaisseur''' de la ''' guitare'''. Dans un premier temps il était nécessaire de '''retirer une partie dans le manche''' pour y placer les boutons poussoirs. Cette étape aurait pu être réalisé rapidement avec la '''découpeuse laser''', mais celle ci étant '''en panne''', nous l'avons fait via '''une perceuse et un foret au Fabricarium'''. Le résultat était un '''peu moins net''' mais '''convenable cependant'''. De plus le '''"trou"''' sera '''caché''' par la pièce contenant '''les touches'''. Une fois la couche de bois travaillée, nous avons '''creusé '''la''' partie cartonnée''' afin de pouvoir y laisser passer les différents '''câbles '''liant les''' boutons poussoirs''' (situés sous les touches du manche de la guitare) à une '''breadboard''' (sur la partie basse de l'instrument).<br />
<br />
Afin que les '''câbles sortent de la guitare de façon propre''', nous avons percé '''4 trous à la base du manche'''. Ainsi de chaque''' trou''' ressortira '''deux fils de connectique''' ( un pour l'entrée du bouton poussoir et un pour la sortie).<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:tt.jpg||left|vignette|upright=2|]]<br />
Ceci étant terminé, il fallait passer à la '''conception des touches de la guitare'''.[[Fichier:touc.jpg||right|vignette|upright=2.2|]]<br />
C'est en '''observant''' une imprimante 3D du Fabricarium qu''''une idée de modèle touche vue le jour'''. Nous allions faire '''une seule et unique pièces''' pour les''' 4 touches'''.<br />
'''Fine''', elle pourrait être facilement '''pliée''' sous une '''pression du doigts''' pour '''actionner un bouton poussoir''' situé en '''dessous''' de chacune des 4 touches.suffirait juste de '''peindre les 4 touches de couleurs différentes''' pour les différencier.<br />
Cette pièce serait '''fixée sur le manche de la guitare''', couvrant une''' couche de bois perforée''' et une '''cartonnée « creusée »''' pour '''laisser passer la connectique '''jusqu'à la partie inférieure de la guitare.<br />
<br />
Finalement, il aura fallut '''quelques heures supplémentaires''' des séances pour avoir '''toutes nos partie modéliser sur FREECAD ''' et '''prête à être imprimées''', qu'elles soient destinées au '''Simon''' ou au '''Guitar Hero'''.<br />
<br />
L'heure est donc à la '''réalisation''' ! Les '''impressions 3D '''se sont faites sur l'imprimante d''''un des membre du groupe''' ainsi que sur celles du''' Fabricarium'''. <br />
<br />
Les''' touches''' qui actionneraient les boutons poussoirs étaient les plus à même d'être à''' recommencer'''. En effet, un '''problème de fixation''', ou encore une '''rigidité trop grande''' '''empêcherait''' l'actionnement du '''bouton '''et serait donc '''inutilisable'''. Ainsi nous avons '''commencé par imprimer les touches''' (pour la guitare et pour le simon). Dans un premier temps, nous nous sommes occupés de la pièce '''pour la guitare'''. La première '''impression '''fut''' décevante''', car''' trop épaisse '''(8mm) , la pièce''' ne pliait pas''' sous la pression des doigts et n’'''actionnait donc pas les boutons''' placés dessous.<br />
<br />
Ce pourquoi nous avons lancé immédiatement une '''nouvelle impression''' avec 3mm d'épaisseur. Les '''tests étant concluants''', nous n'avions plus qu'à la''' peindre''' de '''4 couleurs différentes '''pour symboliser les 4 touches du guitar hero. <br />
<br />
<br />
Ceci commença par la réalisation de '''soudures''' des '''boutons poussoirs''' avec les '''fils'''. Ces fils seraient ensuite placés '''sous '''la couche de '''bois''', '''dans''' la couche de '''carton'''. Cette étape fut '''rapidement terminée'''.<br />
<br />
Les '''8 boutons poussoirs étaient prêts '''! '''Quatre''' pour la''' guitare''',''' quatre '''pour le jeu de '''Simon'''.<br />
<br />
Finalement,''' toutes les pièces étant réalisées''', il fallait réaliser''' un travail d'assemblage''', et de '''finitions ''' (au niveaux des couches de peinture notamment). <br />
<br />
Nous nous sommes préalablement''' assuré '''que tous les '''boutons poussoirs étaient fonctionnels '''et que les''' soudures '''étaient '''correctement réalisées''' grâce à des''' tests rapides''' avec la '''carte arduino.'''<br />
<br />
<br />
[[Fichier:led.jpg||left|vignette|upright=1.2|]][[Fichier:end.jpg||RIGHT|vignette|upright=1.3|]]<br />
Enfin, il ne restait plus qu'à '''peindre''' nos différentes''' pièces'''.<br />
<br />
Premièrement nous avons '''appliqué deux couches de blanc''' sur '''chacune des pièces'''. Puis sur celles qui nécessitaient une '''couleur précise''' ( en autre : les touches de la guitare et du Simon), nous avons repassé '''deux couches''' de '''couleur''' dessus.<br />
Puis, nous avons '''assemblé toutes les pièces''' entre elles pour '''obtenir le résultat final''' ! <br />
<br />
L''''assemblage''' des différentes '''couches de la guitare''' à d'abord était '''provisoirement fait '''avec de la '''colle forte'''. Si le collage venait à '''céder''', nous utiliserons sans doute des''' vis '''ou des '''accroches '''en plastique pour maintenir le tout en place.<br />
<br />
Nous en avons profité pour utiliser la peinture restantes pour décorer un peu notre guitare et ainsi la personnaliser comme bon nous semblait.<br />
<br />
<br />
<br />
<br />
<br />
Finalement, le''' résultat''' est plus que '''satisfaisant '''! Les quatre '''couleurs primaires''' étant '''vives''', elles donnent un aspect '''coloré''' et '''joyeux''' à notre '''projet''' ! Les quatre '''touches du Simon''', '''surmontées''' d'une '''LED''' de la même couleur que la touche, permettent une '''utilisation claire et facile '''du « jeu de Simon ».<br />
<br />
<br />
Dans la '''globalité''', nous sommes assez '''fiers''' du résultat de la '''partie mécanique''' ! Que ce soit du ''' "jeu de Simon" '''ou de la '''Guitare''' du '''"Guitar Héro"''', les '''boutons poussoirs''' sont''' activables facilement '''(voir la vidéo de démonstration en cliquant sur le lien suivant :[https://youtu.be/3-p--BhHGr4] ). De plus le''' résultat est assez agréable''' à '''regarder''' ou encore '''facile a prendre en main'''. <br />
<br />
<br />
<br />
La '''partie mécanique '''étant bien '''avancée''' avant la fin du projet, nous avons décidé de''' procéder à certaines améliorations'''. En effet, les tests des parties électronique et informatique pouvaient donc s’effectuer sur le Simon et la guitare ainsi réalisée. Ainsi dans tous les cas nous avions '''deux prototypes''' à présenter à la fin du projet.<br />
<br />
En parallèle,''' une version plus élaborée''' de la guitare pouvait ainsi être en '''construction'''.<br />
Pour se faire, nous avons repris le fichier SVG explicité lors de la première séance et nous lui avons rajouté un rectangle rouge au niveau du manche, pour une '''découpe plus propre''' à la découpeuse laser, et '''moins fragilisante''' pour le bois.<br />
<br />
[[Fichier:entretoise.jpg||right|vignette|upright=1.5|]]<br />
[[Fichier:cote.jpg||left|vignette|upright=1.5|]]<br />
<br />
<br />
De plus pour gagner en '''propreté''', nous avons placé un PCB pour éviter l’encombrement.<br />
Enfin, nous avons pris la décision de laisser la''' guitare creuse''', afin de pouvoir '''mieux voir le contenu électronique''' à l’intérieur et de garder un '''aspect plus propre et épuré''' de la guitare.<br />
<br />
Pour ce faire, nous allons utiliser des '''entretoises''' qui permettront une largeur de guitare homogène. Afin d’éviter une pliure du bois au niveau des touches (et ainsi éviter que les touches ne soient pas actionnées car pas d’opposition de force), nous avons insisté sur les''' entretoises au-dessous des touches '''(que nous avons pris soin de fixer avec de la colle pour éviter de fragiliser le bois au niveau du manche en le perçant).<br />
<br />
Finalement, les '''touches sont activables facilement''', une fois la guitare prise en main. Un signal logique bas est bien transmis une fois les '''touches appuyées'''. Et il est '''bien détecté''' par''' l’arduino'''. <br />
<br />
[[Fichier:guitaredroite.jpg||center|vignette|upright=2|]]<br />
<br />
<br />
<br />
Désormais, la '''partie mécanique '''étant''' terminée et fonctionnelle''', il faut la '''lier à la partie informatique et électronique'''. Nous allons '''perfectionner la partie FPGA''' et''' Arduino '''pour''' exploiter''' pleinement les '''deux supports '''(guitare et jeu de Simon) ainsi réalisés.<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Conclusion </div>==<br />
<br />
<br />
En conclusion, Le '''jeu de Simon''' est '''terminé''' et est '''fonctionnel''. En effet le '''serveur websocket''' envoie une '''combinaison''' de couleur, composée par un utilisateur, à '''l’arduino''', qu’un second utilisateur devra tenter de '''reproduire''' (couleur par couleur, en reprenant du début à chaque fois, avec une couleur en plus à chaque tour). Le '''Jeu de Simon est terminé ''': '''L’objectif principal''' de notre projet est donc '''réalisé'''.<br />
<br />
Cependant, le '''Guitar Héro''' n’a pas pu être abouti. Nous avions précisé dès le début du projet que nous tâcherions de '''finir le Simon en priorité''' et de faire le Guitare Héro ensuite. La '''guitare est finalisée''' et '''fonctionnelle'''. Nous n’étions donc pas si loin de terminer les deux projets. <br />
Nous sommes globalement '''satisfaits''' du '''travail réalisé''' et de la''' prestation proposée'''. En effet en sachant que nous avions deux projets en simultané (bien que très ressemblant entre eux) nous avons su '''terminer le premier''' et '''bien avancer sur le second'''. Le '''but principal''' était de '''nous amuser''', de '''prendre du plaisir dans la réalisation d'un projet''' et de '''faire quelque chose qui nous plaisait avant tout''', '''l’objectif''' est '''atteint'''.<br />
Le FPGA n'a pas pu être aboutit non plus, et c'est dommage, car c'est une technologie intéressante, et c'est plus optimisé et rapide qu'une Arduino. <br />
<br />
Ce projet fut très '''intéressant''' car il nous a permis de '''mettre en application''' certains de nos '''cours étudiés''' cette année en IMA3, mais également d’en '''apprendre''' énormément '''par nous même''' à force de '''pratique '''et de''' recherches personnelles'''. Pour l’ensemble des membres du groupe, ce projet a été la confirmation de '''l’intérêt '''porté aux '''systèmes communiquants''', et nous a donc '''convaincu de choisir''' la '''filière SC''' à partir du semestre 8 en '''IMA4'''.<br />
<br />
<br />
La démonstration du fonctionnement du Jeu de Simon, est disponible à l'adresse suivante : https://youtu.be/RbgPtALDmFw .</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=Projet_IMA3_P3,_2016/2017,_TD1&diff=44296Projet IMA3 P3, 2016/2017, TD12017-06-18T20:11:14Z<p>Adurot : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 25px; padding: 20px; font-weight: bold; text-align: center; font-size: 98%; background: #6060FF; vertical-align: top; width: 99%;"> Projet IMA3-SC 2016/2017 : Le Jeu de Simon et le Guitar Hero </div>=<br />
<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Cahier des Charges </div>==<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Description du système </div>===<br />
<br />
* L'objectif principal de notre projet est de réaliser un '''jeu''' qui utilise à la fois les '''lumières''' et le '''son'''. Pour cela, nous avons pensé à deux versions : '''le Simon''' et un jeu du type '''Guitar Hero'''.<br />
<br />
* Le '''Simon''' est constitué de '''quatre boutons de couleurs différentes''' : un bleu, un rouge, un vert et un jaune. Le jeu va '''afficher''' une séquence de couleurs qui sont chacune '''associées à un son'''. Le joueur doit ensuite se '''souvenir''' de la suite (en s'aidant du son et des couleurs comme moyen mnémotechnique) pour la '''reproduire''' dans le '''bon ordre''' en '''appuyant sur les boutons'''.<br />
<br />
* Le jeu '''Guitar Hero''', quant à lui, est un jeu où il faut '''actionner des boutons de couleur précise''', '''au moment où elles apparaissent''' sur une barre de défilement, '''à l'écran'''. Ces différentes '''activations''', aux '''bons moments''', permettent de '''réaliser une mélodie''' plus ou moins complexe selon la difficulté de la chanson à reproduire. Le tout est effectué grâce à '''une guitare connectée''', afin de pousser l'expérience de '''simulation''' un peu plus loin. Si nous réalisons, ce jeu, il faut '''prendre en compte''' un '''affichage''' plus '''complexe'''. De plus, le '''Guitar Hero''' ajoute '''une notion de temps de réponse''', plus '''difficile à gérer'''. Ce temps de réponse permet de laisser une '''courte marge d'erreur''' dans la '''réactivité de l'utilisateur''', pour '''simuler pleinement''' l'utilisation d'une '''guitare électrique'''.<br />
<br />
<br />
Nous avons choisis de d'abord nous concentrer sur le '''Simon''' et de faire le jeu '''Guitar Hero''' seulement '''si nous avons le temps'''.<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Le matériel </div>===<br />
<br />
Pour ce '''projet''' nous utiliserons :<br />
<br />
* Une '''page internet''' sur l'ordinateur pour pouvoir '''modifier les différents aspects du jeu''' : les '''règles du jeu''', la '''musique''' jouée par le Simon ou bien la '''difficulté'''<br />
<br />
* Le '''Raspberry Pi''', utilisée en tant que serveur, va envoyer les données en série ( qui seront traitées par le FPGA ), de les recupérer, et de faire l'algorithme.<br />
<br />
* Une '''carte Arduino''' pour '''relier''' la Raspberry Pi aux composants dans un premier temps : elle nous permet de '''coder en C''' (au lieu d'un langage assembleur) pour '''créer des programmes''' et '''gérer''' les différents '''modules''' tel que les '''boutons''' et les '''LEDs'''. Elle permettra une '''simulation''' momentanée du '''FPGA''', afin que nous puissions avancer sur la partie informatique, sans attendre d'en avoir fini avec la partie FPGA.<br />
<br />
* Une fois le programme et les interactions fonctionnels, nous '''remplacerons''' l'Arduino par une '''FPGA''' qui est '''circuit logique programmable''' : on peut '''modifier les circuits logiques''' à l'intérieur mais '''on ne peut pas créer un programme''' avec un '''langage''' de plus '''haut niveau'''. Nous devrons donc utiliser des '''logiciels tiers''' qui nous permettront de placer des '''portes logiques''' (ET, OU,...) pour '''créer notre programme en assembleur'''.<br />
<br />
* Pour ce qui est de la '''partie mécanique''', nous réaliserons une '''guitare en bois''' pour le''' "Guitar Hero"''' ainsi qu'un''' "jeu de Simon"''' réalisé via l''''impression 3D.'''<br />
<br />
* Si le temps nous le permet, nous utiliserons un '''Xbee''' pour créer une '''connexion sans fil''', afin '''d'expérimenter''' un '''module nouveau''' et '''acquérir''' de '''nouvelles compétences'''.<br />
<br />
*Nous utiliserons également des '''composants électroniques''' tels que des '''boutons poussoirs''', des '''LEDs''' ou une '''matrice de LEDs''' pour l'affichage dans le cas du jeu de Simon, ainsi que de '''"l'essentiel"''' pour un '''système communiquant''' (à savoir '''résistances''', '''fils électriques''', etc...)<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Description des séances </div>==<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 21/03/17 Séance 1 : Répartition des tâches et premiers pas </div>===<br />
<br />
La première séance fut''' consacrée à la répartition des rôles''' et à la '''prise de conscience '''de la '''difficulté des différentes tâches'''. L''''idée''' de faire un '''« jeu de Simon » '''que nous''' amélioreront '''ensuite en '''« guitar hero »''' a cependant été '''conservée'''.<br />
<br />
==== Partie électronique ====<br />
<br />
Nous avons décider de concentrer deux personnes sur le FPGA car c'est un élément très complexe et complètement nouveau.<br />
Nous allons en effet devoir coder à très bas niveau avec simplement des registres et des portes logiques.<br />
<br />
L'objectif du composant sera de récupérer un message contenant les boutons sur lesquelles appuyer. <br />
Une fois ce message reçu, le FPGA va comparer le bouton saisi par l'utilisateur avec le bouton demander. <br />
S'il est correct, le fpga va passer à la couleur suivante, sinon il va renvoyer un message pour dire à la Raspberry (ou l'ordinateur) que l'utilisateur s'est trompé.<br />
<br />
Pour commencer, nous réalisons le tutoriel pour allumer une LED qui va nous permettre de comprendre le fonctionnement de Altium Designer.<br />
Cela nous a pris du temps mais nous avons pu réaliser d'autres essaies avec des registres à décalages et des boutons.<br />
<br />
Nous avons ensuite directement commencer le Simon :<br />
Le choix a été fait d'utiliser des registres à décalages pour récupérer la séquence de couleur envoyé par l'ordinateur/la raspberry. <br />
Nous allons en effet stocker toute la séquence de la "partie" car sinon il faudrait gérer beaucoup d'échange entre l'ordinateur et le FPGA ce qui est lourd en Altium et fait perdre du temps réaction du programme.<br />
<br />
D'un point de vue technique, utiliser un registre à décalage semble être la meilleur méthode pour récupérer un à un les bits qui arrivent sur la liaison série puis nous utilisons 4 registres à décalage : 1 pour chaque couleur.<br />
Pour chacun des registres nous aurons donc une séquence comme suit : 0100010010111. Les 1 correspondent aux moments ou il faut appuyer sur la couleur et les 0 aux moments ou il ne faut pas appuyer sur cette couleur. <br />
Nous devons donc également gérer les clocks des registres "couleurs". Ces registres doivent arrêter leur clock lorsque les bits de chaque couleur est à 0.<br />
<br />
Le registre pour la liaison série sera la clock du système puisqu'elle doit lire toute la séquence mais elle doit également s'arrêter lorsque le FPGA arrive à la fin de la séquence. Pour lui indiquer la fin de la séquence nous avons choisit le mot 0000 car il y aura toujours un bouton à appuyer pour le jeu Simon.<br />
<br />
==== Partie informatique ====<br />
<br />
L'objectif ici était la découverte des technologies a utilisé pour le système. Notamment une Arduino en liaison série à un PC et un serveur Websockets codé en C.<br />
La partie programmation arduino ne fut pas un problème. En effet, ce n'était pas la première fois que nous utilisions cet outil, et donc la mise en place de la liaison série fut très rapide.<br />
Ce n'est cependant pas le cas de la communication websockets. Bien que l'exemple de code fourni par M. Redon soit fonctionnel, le code n'en reste pas moins complexe à comprendre. Il fallait donc réussir à modifier le code du serveur websockets, afin de relier les deux systèmes entre eux.<br />
<br />
==== Partie mécanique : un modèle de guitare à découper====<br />
<br />
<br />
Dans cette première séance, nous avons décidé de focaliser nos premiers efforts sur la''' partie mécanique''' du '''"guitar hero"'''. En effet, le '''« jeu de simon »''' pouvait être avancé '''plus tard''' car plus''' facile''' à '''modéliser''' et à''' réaliser.'''[[Fichier:1.jpg||right|vignette|upright=2|]]<br />
Nous sommes alors partis sur l'idée de créer une''' maquette de guitare''', sur laquelle nous allions '''disposer''' différents '''boutons de couleur''', '''actionnables''' grâce à une '''pression''' sur le manche de l'instrument. Nous avions une '''ligne directrice''' mais pas encore d''''idée précise''' de comment allait être réalisé la guitare, ni même '''ce à quoi elle allait ressembler'''.<br />
<br />
<br />
Nous avons décidé de découper la '''guitare en bois''' qui nous servirait de support pour notre '''« guitar hero »''' grâce à la''' découpeuse laser'''. Pour se faire, un '''fichier conforme à la découpe''' devait être réalisé. <br />
Ainsi nous avons donc pris une '''image de guitare''' depuis '''internet'''. Dans le logiciel''' « GIMP »''', nous avons ensuite '''repassé les contours de l'instrument en rouge'''. Une fois ceci fait, nous avons''' effacé l'image de la guitare originale '''pour ne''' garder que les contours rouges'''. Enfin après '''quelques réglages''', l''''export en fichier SVG '''permettait une '''découpe précise'''. Les contours de la guitare sont disponibles ci contre (cliquez sur l'image pour bien voir).<br />
<br />
A la '''fin de la séance''', la '''guitare''' était''' prête à être réalisée '''et nous avons décidé de faire l'intégralité du''' « jeu de simon »''' via '''l'impression 3D'''. Cependant, aucune grande avancée n'a eu lieu sur la partie mécanique du jeu de Simon lors de cette séance.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 28/03/17 Séance 2 : Poursuite du Projet et rencontre des premiers problèmes </div>===<br />
<br />
La '''deuxième séance''' fut davantage '''productive''', car chacun de nous savait les différentes '''tâches''' qu'il lui '''restait à accomplir'''.<br />
<br />
==== Partie électronique ====<br />
Nous nous sommes rendu compte qu'utiliser le registre à décalage pour la liaison série comme nous le faisions n'était pas possible.<br />
En effet, la liaison série est en asynchrone et nous ne connaissance donc pas la clock. <br />
Nous ne pouvons donc pas utiliser cette clock pour le registre à décalage car sinon nous risquons de ne pas lire assez vite (ou trop vite) et donc récupérer trop de valeurs ou en rater.<br />
<br />
Le professeur nous a donc indiquer qu'il nous mettrai à disposition un module qui va s'occuper justement de lire la liaison série et de garder la séquence et de ressortir le message en parallèle.<br />
Ce composant envoie également sur un autre pin un 1 à chaque fois qu'un bit est envoyé par la liaison série (et reçu par le composant).<br />
Nous utilisons, selon ces conseils, un module analogique-digital qui va nous permettre de simuler l'envoi de la séquence.<br />
Après plusieurs tentative nous avons un programme qui fonctionne correctement pour recevoir les valeurs. Il nous reste à comparer l'appuie d'un bouton et la couleur à presser.<br />
<br />
==== Partie informatique ====<br />
<br />
L'écriture du programme de communication fut terminé assez rapidement. Mais il ne fonctionnait pas...<br />
En effet, un problème s'opérait lors de l'appel de la liaison série par le serveur websocket à réception d'un message.<br />
<br />
L'incompréhension régnait un peu, car à nos yeux tout était sensé fonctionner. Le principe était assez simple : à reception d'un message par le serveur websockets, ce dernier devait ouvrir une communication série sur le port TTY_USB0 (ou TTY_ACM0 en fonction de l'arduino) à 9600 bauds, y transférer le message reçu, puis refermer la communication.<br />
<br />
Après un long moment de doute, le problème fut résolu. Ce dernier était assez idiot. En effet, notre fonction d'envoi de message via le port série s'appelait : " send(..) ". Il s'avère qu'une fonction d'une des librairies utilisées se nomme de la même manière. Il y avait donc conflit et empêchait le programme de fonctionner correctement.<br />
<br />
Nous avons donc pu relier l'ordinateur à un montage de prototypage Arduino/LEDs afin de tester le bon fonctionnement du programme. Une combinaison de 4 LED devait s'allumer à réception d'un caractère. Il fallait donc envoyé un message compris entre 0(aucune LED allumée) et 15(toutes les LED allumées). Cependant, le début de la table ASCII ne représente pas des caractères. Le serveur envoie donc un message alphabétique compris entre 65 ('A') et 80 ('P') et l'arduino interprète ceci comme une valeur de 0 a 15<br />
<br />
==== Partie mécanique : découpe de la guitare, modélisation et impression d'un prototype de touches pour cette dernière ====<br />
<br />
[[Fichier:pp.jpg||left|vignette|upright=0.8|]]Cette séance fut entamée par la '''découpe de la guitare''' grâce à la '''découpeuse laser''' du '''Fabricarium de Polytech'''. Dans un premier temps il a d'abord était nécessaire '''« d'apprivoiser »''' la '''découpeuse''' et d''''apprendre à bien la configurer''' pour obtenir le résultat souhaité, sans risques. Un '''premier essai''' a d'abord était réalisé dans du '''carton''' pour pouvoir '''juger des différentes dimensions''' de la guitare.<br />
Enfin, une '''seconde version''', en''' bois''', fut réalisée durant cette séance. Finalement nous décidons de partir sur l'idée d'une '''guitare réalisée en 4 couches d'épaisseur''' : '''2 extérieures en bois''' ( une de '''face''', '''décorée''' avec les '''boutons à actionner''' et la carte '''arduino''' et une '''seconde''', '''arrière''', de '''protection'''), et '''deux intérieures en carton'''('''creusées''' pour laisser passer les '''fils de connectiques''').<br />
<br />
'''Note''' : Malheureusement, une des '''couche en bois''' a était '''cassée''' par la suite lors de la confection de la guitare. La''' panne prolongée''' de la '''découpeuse laser''' nous a contraint à '''renoncer à l'idée d'une quatrième couche en bois''' de protection.[[Fichier:po.jpg||right|vignette|upright=1.2|]]<br />
<br />
<br />
De plus, via le '''logiciel de modélisation FreeCAD''', nous avons commencé à concevoir deux '''prototypes''' de '''« touches »''' (boutons) pour la guitare. <br />
<br />
L'idée était de créer des '''surfaces larges''' (pouvant recueillir '''une phalange de doigts au minimum''') faisant office de '''touches''', en dessous desquelles nous '''insérerions''' un '''bouton poussoir''' 4 pins (fournis par les professeurs). La '''création de touches plus larges''' était '''indispensable'''. En effet, les '''boutons poussoirs''' étaient bien '''trop petits''' pour avoir un '''actionnement facile et agréable'''.<br />
Nous avons pu lancer l''''impression des touches''' à la''' fin de la séance'''. Cependant, les différents '''tests '''et les''' défauts d'impression''' nous ont fait comprendre qu'il serait''' difficile de « glisser » un bouton poussoir '''dans une '''touche '''avec un '''espace '''assez''' étroit '''pour le maintenir, sans pour autant '''bloquer son actionnement''' lorsqu'une '''pression''' était appliquée. De plus, la''' fixation''' risquait d'être assez '''complexe'''. <br />
Nous avons alors décidé de faire un tout '''autre type de touche''' mais avec le '''même fonctionnement'''. Pour cela nous allions avoir besoin de''' modéliser et d'imprimer '''de nouveaux un '''prototype de touche'''.<br />
Il allait ensuite falloir''' percer la première couche en bois de la guitare'''. Puis il serait également nécessaire de '''creuser les sous couches''' en carton pour y placer les boutons poussoirs et les différents câbles.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 05/04/2017 Séance 3 : Encore beaucoup de choses à faire !</div>===<br />
<br />
Bien que ce soit notre '''dernière séance officielle''', nous savions que nous allions avoir '''besoin''' de '''beaucoup de temps''' pour''' terminer ce projet '''! <br />
<br />
==== Partie électronique ====<br />
Au final notre FPGA n'est pas fonctionnel, suite à des tests en utilisant le port série, nous avons intégré les circuits reception.vhdl et emission.vhdl fournis par M. Boé. Mais le résultat n'est pas au rendez vous.<br />
<br />
[[Fichier:fpga.png|||vignette|upright=2|]]<br />
<br />
==== Partie informatique ====<br />
<br />
<br />
L'objectif de la séance était la mise en place de l'interface WEB, notamment pour le jeu Guitar Hero. <br />
<br />
Nous avons utilisé un canvas Javascript afin de dessiner un interface similaire a celle du jeu original.<br />
<br />
==== Partie mécanique ====<br />
<br />
La troisième séance était destinée à '''l’élaboration du jeu de Simon'''. Une première idée était de '''créer quatre pièces plates''', composées de''' multiples leds''', qu'il faudrait''' actionner''' via une simple''' pression'''. Cependant, nous nous sommes dit '''qu'une seule LED pour une couleur''', suffisait à '''indiquer''' la '''combinaison''' à reproduire. <br />
<br />
Le tout devait être assez '''grand''' pour '''contenir la carte arduino''' ainsi que toute la '''connectique''', '''sans''' pour autant '''être''' trop '''encombrant''', tout en étant assez '''ergonomique''' et '''agréable au regard'''.<br />
<br />
Nous avons donc décidé de '''créer un support creux ''' qui '''contiendrait la partie électronique ''', au dessus duquel nous placerions '''les 4 pièces de couleur''' avec '''une LED pour chaque couleur'''.<br />
<br />
Nous savions dès lors, qu'un '''travail long minutieux''' nous attendait.<br />
<br />
Ainsi nous avons fait de '''nombreux croquis''' avec les '''différentes pièces''' et leurs '''dimensions éventuelles'''. Des pièces que nous allions réaliser uniquement en '''impression 3D'''. Un '''travail similaire''' a été réalisé pour '''la guitare''', afin de ne pas '''percer la guitare à de mauvais endroits''', et pour '''agencé les différents parties''' à ajouter sur la guitare de la '''meilleure façon possible'''. Pour '''résumer''' cette séance, nous avons '''réalisé tous les croquis nécessaires à la réalisation''' de la '''guitare''' et du '''Simon'''.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Séance supplémentaire : Terminons ce Projet !</div>===<br />
<br />
Il n'y a pas eu un '''nombre précis de "séances supplémentaires".''' '''Chacun''' des membres du groupe travaillait '''soit chez lui''', '''soit à l'école''' de '''manière régulière''', afin '''d'avancer sa partie''' le plus '''rapidement''' possible.<br />
<br />
==== Partie électronique ====<br />
<br />
Pour le Simon, il a fallut souder les câbles aux boutons et aux leds ( avec leur résistance ). Pour se faire, on a utilisé un circuit à pastilles qui se place entre l'arduino et les boutons/led. Cela permet de prendre moins de place et de faire plus propre qu'une breadboard.<br />
[[Fichier:pcb1.jpg|left|vignette|upright=0.8|]]<br />
[[Fichier:pcb2.jpg|right|vignette|upright=0.8|]]<br />
<br />
=== Partie informatique ===<br />
<br />
La partie FPGA n'étant pas fonctionelle, il a fallut le remplacer par un Arduino. <br />
<br />
Le code de l'Arduino consiste en une succession d'étapes pour jouer. Tout d'abord il faut recevoir via le port série la séquence totale du Simon, sous la forme de chaîne de caractères. Par exemple si le message reçu est "RVBR", alors la séquence totale du Simon sera Rouge Vert Bleu Rouge. Ainsi une fonction reception_message a été codée, qui attend la réception série de la séquence. <br />
<br />
Dans l'algorithme du jeu en lui même on a une variable globale qui stocke l'état de la partie, et une qui stocke l'étape de la séquence. Ainsi en fonction de l'état de la partie on va soit jouer la séquence sur les leds, lire l'état des boutons, ou provoquer un game over.<br />
<br />
La fonction playSequence va parcourir la séquence totale jusqu'à l'étape actuelle et va allumer les différentes leds en conséquence.<br />
<br />
La fonction readSequence va elle lire l'état successif des boutons et le comparer à la séquence actuelle. Si il y a une erreur, on sort de la fonction, et l'état de la partie devient un game over. Sinon, on continue et on appelle playSequence en incrémentant l'étape. En cas de réussite de la séquence, les 4 leds s'allument pour indiquer lé réussite et le passage au niveau supérieur.<br />
<br />
Coté websockets, c'est facile, dès qu'on reçoit un message par le client, on l'envoie à l'arduino ( bien qu'on aurait du vérifier la conformité du message ), l'arduino ne lira le message que si on est en étape de lecture de la séquence, donc après un game over par exemple. <br />
<br />
==== Partie mécanique : Suite et fin de la confection de la guitare et du jeu de Simon====<br />
<br />
Comme nous l'avons prédit, la plus '''grosse partie du travail''' réalisé a dû être faite lors de '''séances supplémentaires''' ou par '''travail personnel chez soi'''.<br />
<br />
Après avoir réalisé '''les croquis''', il était essentiel de '''créer rapidement les différents supports'''. En effet, cela nous permettait d'avoir du '''temps''' pour éventuellement''' recommencer et revoir les axes de travail en cas d'impossibilité de réalisation''' pour quelconque raison. De plus, une fois la''' partie mécanique terminée''', nous pouvions l''''utiliser''' comme '''support '''pour les '''tests électroniques'''. Enfin, cela nous laissait du temps en fin de projet pour '''décorer notre projet''', que nous voulions '''personnalisé''' afin d'en être '''le plus satisfaits possible'''. <br />
<br />
Un''' gros travail de modélisation''' à dû être fait sur '''FREECAD'''. Le '''support''' du jeu de Simon fut la pièce la plus '''simple '''à réaliser (un '''cylindre''' semi fermé, de '''7 cm de rayon''').<br />
<br />
Puis une simple''' découpe '''grâce à une '''scie''' permettrait de faire''' réceptacle''' pour une''' "croix porteuse" '''sur laquelle serait disposés les '''touches du Simon'''.<br />
<br />
De la même façon que pour la guitare, '''les touches''' seraient placées '''au dessus de boutons poussoirs'''. Ces derniers seront '''collés sur la croix'''. <br />
[[Fichier:tg.jpg||right|vignette|upright=1.5|]]<br />
Une fois ceci fait, il fallait '''réaliser le plus important du jeu''' : '''les touches à actionner '''! <br />
<br />
Pour cela, il était préférable de conserver la '''forme cylindrique '''du support en modélisant '''4 pièces''', d'un '''quart de disque''' chacune. Par soucis de '''fixation '''sur la croix et par envie d’'''esthétisme''', les touches seraient un peu '''incurvées''' pour donner une forme '''moins géométrique''' au rendu final. <br />
<br />
De plus, elles seront''' perforées''' pour laisser passer une '''LED''' de la même couleur que la touche sur laquelle elle se trouve. Ainsi l'utilisateur pourra '''mémoriser les touches à activer''' via le système '''lumineux''' des '''LEDs'''. <br />
<br />
Enfin, un '''cylindre permettant l'accroche''' sur la croix à été prévu sur la '''partie inférieure''' de les''' touches du Simon'''. (suite à une impression peu précise, '''ce cylindre sera « fondu »''' pour épouser la forme de la croix '''sans jeu dans la fixation'''.)<br />
<br />
[[Fichier:touc2.jpg||left|vignette|upright=1.7|]]<br />
Vint ensuite le''' moment de la création''' ! '''L'impression de ces pièces''' étant la plus '''complexe''', nous pensions qu'il serait nécessaire de les recommencer plusieurs fois. La '''WitBox du Fabricarium''' (la plus précise des imprimantes mise à notre disposition) a réalisé une '''impression assez laborieuse'''. Un gros travail de '''ponçage''' à donc dû être réalisé, car le support nécessaire pour imprimer cette pièce « incurvée » avait donné de '''nombreuses bavures''' sur la '''surface des touches'''. Afin que le '''toucher''' reste '''agréable''', nous avons donc '''retravaillé les pièces'''.<br />
<br />
<br />
Une fois ceci fait, nous avons '''essayé de les positionner''' sur la''' croix''' prévue à cet effet. Une fois encore, nous étions '''confronté aux limites de l'impression 3D'''. Les '''dimensions du « cylindre pillier » '''étant non précise, et cette partie étant''' trop fine pour être sciée''' '''sans rupture''' de la pièce, nous avons décidé de faire '''« fondre » '''cette partie et de la placer, encore chaude sur la partie en forme de croix. Cela permettait une''' fixation sûre''' et une '''dimension épousant parfaitement les formes du support'''. L'inconvénient fut que cette''' méthode, peu précise''', n'a fait qu''''accentuer les erreurs d'impressions''' au niveaux du '''visuel'''. Effectivement, les 4 pièces ne '''semblent pas régulières''' et le '''disque''' qu'elles sont censées former (ensemble de 4 quarts de disque) ne semble '''pas parfait'''.[[Fichier:bttt.jpg||right|vignette|upright=1.5|]][[Fichier:socle.jpg||right|vignette|upright=1.5|]]<br />
<br />
<br />
Nous décidons cependant de '''conserver ce léger défaut''', car si nous recommencions nous risquerions d'être de nouveau''' confronté au même souci''', l''''erreur''' n'étant pas uniquement dû à notre '''manipulation''' mais également à l''''imprimante 3D'''. <br />
<br />
<br />
L'impression du '''socle''' était la plus''' longue à imprimer''' (près de 6 heures) .Après l'avoir un peu '''scié''' comme prévu, cette pièce était également''' prête à être peinte'''. Nous avons fait de même avec la '''croix '''à placer sur le socle et servant de '''support''' aux '''quatre touches''' du Simon. Cette impression étant '''rapide et facile''', un seul essai suffit pour obtenir notre '''version définitive'''. L'impression fut dans ce cas, parfaitement aux '''mesures souhaitées''' dans le fichier .stl (bien que réalisé avec une imprimante de moins bonne qualité que la WitBox). Ainsi les '''boutons poussoirs '''que nous avions à positionner dessus tenaient sans souci '''par un simple encastrement'''. Par la suite, par '''mesure de sécurité''', <br />
nous avons tout de même rajouté un '''point de colle''' en dessous des''' boutons ''' pour éviter tout '''désencastrement non souhaité'''. <br />
[[Fichier:tr.jpg||left|vignette|upright=1.4|]]<br />
<br />
<br />
<br />
En parallèle, nous avons travaillé sur les '''différentes couches d'épaisseur''' de la ''' guitare'''. Dans un premier temps il était nécessaire de '''retirer une partie dans le manche''' pour y placer les boutons poussoirs. Cette étape aurait pu être réalisé rapidement avec la '''découpeuse laser''', mais celle ci étant '''en panne''', nous l'avons fait via '''une perceuse et un foret au Fabricarium'''. Le résultat était un '''peu moins net''' mais '''convenable cependant'''. De plus le '''"trou"''' sera '''caché''' par la pièce contenant '''les touches'''. Une fois la couche de bois travaillée, nous avons '''creusé '''la''' partie cartonnée''' afin de pouvoir y laisser passer les différents '''câbles '''liant les''' boutons poussoirs''' (situés sous les touches du manche de la guitare) à une '''breadboard''' (sur la partie basse de l'instrument).<br />
<br />
Afin que les '''câbles sortent de la guitare de façon propre''', nous avons percé '''4 trous à la base du manche'''. Ainsi de chaque''' trou''' ressortira '''deux fils de connectique''' ( un pour l'entrée du bouton poussoir et un pour la sortie).<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:tt.jpg||left|vignette|upright=2|]]<br />
Ceci étant terminé, il fallait passer à la '''conception des touches de la guitare'''.[[Fichier:touc.jpg||right|vignette|upright=2.2|]]<br />
C'est en '''observant''' une imprimante 3D du Fabricarium qu''''une idée de modèle touche vue le jour'''. Nous allions faire '''une seule et unique pièces''' pour les''' 4 touches'''.<br />
'''Fine''', elle pourrait être facilement '''pliée''' sous une '''pression du doigts''' pour '''actionner un bouton poussoir''' situé en '''dessous''' de chacune des 4 touches.suffirait juste de '''peindre les 4 touches de couleurs différentes''' pour les différencier.<br />
Cette pièce serait '''fixée sur le manche de la guitare''', couvrant une''' couche de bois perforée''' et une '''cartonnée « creusée »''' pour '''laisser passer la connectique '''jusqu'à la partie inférieure de la guitare.<br />
<br />
Finalement, il aura fallut '''quelques heures supplémentaires''' des séances pour avoir '''toutes nos partie modéliser sur FREECAD ''' et '''prête à être imprimées''', qu'elles soient destinées au '''Simon''' ou au '''Guitar Hero'''.<br />
<br />
L'heure est donc à la '''réalisation''' ! Les '''impressions 3D '''se sont faites sur l'imprimante d''''un des membre du groupe''' ainsi que sur celles du''' Fabricarium'''. <br />
<br />
Les''' touches''' qui actionneraient les boutons poussoirs étaient les plus à même d'être à''' recommencer'''. En effet, un '''problème de fixation''', ou encore une '''rigidité trop grande''' '''empêcherait''' l'actionnement du '''bouton '''et serait donc '''inutilisable'''. Ainsi nous avons '''commencé par imprimer les touches''' (pour la guitare et pour le simon). Dans un premier temps, nous nous sommes occupés de la pièce '''pour la guitare'''. La première '''impression '''fut''' décevante''', car''' trop épaisse '''(8mm) , la pièce''' ne pliait pas''' sous la pression des doigts et n’'''actionnait donc pas les boutons''' placés dessous.<br />
<br />
Ce pourquoi nous avons lancé immédiatement une '''nouvelle impression''' avec 3mm d'épaisseur. Les '''tests étant concluants''', nous n'avions plus qu'à la''' peindre''' de '''4 couleurs différentes '''pour symboliser les 4 touches du guitar hero. <br />
<br />
<br />
Ceci commença par la réalisation de '''soudures''' des '''boutons poussoirs''' avec les '''fils'''. Ces fils seraient ensuite placés '''sous '''la couche de '''bois''', '''dans''' la couche de '''carton'''. Cette étape fut '''rapidement terminée'''.<br />
<br />
Les '''8 boutons poussoirs étaient prêts '''! '''Quatre''' pour la''' guitare''',''' quatre '''pour le jeu de '''Simon'''.<br />
<br />
Finalement,''' toutes les pièces étant réalisées''', il fallait réaliser''' un travail d'assemblage''', et de '''finitions ''' (au niveaux des couches de peinture notamment). <br />
<br />
Nous nous sommes préalablement''' assuré '''que tous les '''boutons poussoirs étaient fonctionnels '''et que les''' soudures '''étaient '''correctement réalisées''' grâce à des''' tests rapides''' avec la '''carte arduino.'''<br />
<br />
<br />
[[Fichier:led.jpg||left|vignette|upright=1.2|]][[Fichier:end.jpg||RIGHT|vignette|upright=1.3|]]<br />
Enfin, il ne restait plus qu'à '''peindre''' nos différentes''' pièces'''.<br />
<br />
Premièrement nous avons '''appliqué deux couches de blanc''' sur '''chacune des pièces'''. Puis sur celles qui nécessitaient une '''couleur précise''' ( en autre : les touches de la guitare et du Simon), nous avons repassé '''deux couches''' de '''couleur''' dessus.<br />
Puis, nous avons '''assemblé toutes les pièces''' entre elles pour '''obtenir le résultat final''' ! <br />
<br />
L''''assemblage''' des différentes '''couches de la guitare''' à d'abord était '''provisoirement fait '''avec de la '''colle forte'''. Si le collage venait à '''céder''', nous utiliserons sans doute des''' vis '''ou des '''accroches '''en plastique pour maintenir le tout en place.<br />
<br />
Nous en avons profité pour utiliser la peinture restantes pour décorer un peu notre guitare et ainsi la personnaliser comme bon nous semblait.<br />
<br />
<br />
<br />
<br />
<br />
Finalement, le''' résultat''' est plus que '''satisfaisant '''! Les quatre '''couleurs primaires''' étant '''vives''', elles donnent un aspect '''coloré''' et '''joyeux''' à notre '''projet''' ! Les quatre '''touches du Simon''', '''surmontées''' d'une '''LED''' de la même couleur que la touche, permettent une '''utilisation claire et facile '''du « jeu de Simon ».<br />
<br />
<br />
Dans la '''globalité''', nous sommes assez '''fiers''' du résultat de la '''partie mécanique''' ! Que ce soit du ''' "jeu de Simon" '''ou de la '''Guitare''' du '''"Guitar Héro"''', les '''boutons poussoirs''' sont''' activables facilement '''(voir la vidéo de démonstration en cliquant sur le lien suivant :[https://youtu.be/3-p--BhHGr4] ). De plus le''' résultat est assez agréable''' à '''regarder''' ou encore '''facile a prendre en main'''. <br />
<br />
<br />
<br />
La '''partie mécanique '''étant bien '''avancée''' avant la fin du projet, nous avons décidé de''' procéder à certaines améliorations'''. En effet, les tests des parties électronique et informatique pouvaient donc s’effectuer sur le Simon et la guitare ainsi réalisée. Ainsi dans tous les cas nous avions '''deux prototypes''' à présenter à la fin du projet.<br />
<br />
En parallèle,''' une version plus élaborée''' de la guitare pouvait ainsi être en '''construction'''.<br />
Pour se faire, nous avons repris le fichier SVG explicité lors de la première séance et nous lui avons rajouté un rectangle rouge au niveau du manche, pour une '''découpe plus propre''' à la découpeuse laser, et '''moins fragilisante''' pour le bois.<br />
<br />
[[Fichier:entretoise.jpg||right|vignette|upright=1.5|]]<br />
[[Fichier:cote.jpg||left|vignette|upright=1.5|]]<br />
<br />
<br />
De plus pour gagner en '''propreté''', nous avons placé un PCB pour éviter l’encombrement.<br />
Enfin, nous avons pris la décision de laisser la''' guitare creuse''', afin de pouvoir '''mieux voir le contenu électronique''' à l’intérieur et de garder un '''aspect plus propre et épuré''' de la guitare.<br />
<br />
Pour ce faire, nous allons utiliser des '''entretoises''' qui permettront une largeur de guitare homogène. Afin d’éviter une pliure du bois au niveau des touches (et ainsi éviter que les touches ne soient pas actionnées car pas d’opposition de force), nous avons insisté sur les''' entretoises au-dessous des touches '''(que nous avons pris soin de fixer avec de la colle pour éviter de fragiliser le bois au niveau du manche en le perçant).<br />
<br />
Finalement, les '''touches sont activables facilement''', une fois la guitare prise en main. Un signal logique bas est bien transmis une fois les '''touches appuyées'''. Et il est '''bien détecté''' par''' l’arduino'''. <br />
<br />
[[Fichier:guitaredroite.jpg||center|vignette|upright=2|]]<br />
<br />
<br />
<br />
Désormais, la '''partie mécanique '''étant''' terminée et fonctionnelle''', il faut la '''lier à la partie informatique et électronique'''. Nous allons '''perfectionner la partie FPGA''' et''' Arduino '''pour''' exploiter''' pleinement les '''deux supports '''(guitare et jeu de Simon) ainsi réalisés.<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Conclusion </div>==<br />
<br />
<br />
En conclusion, Le '''jeu de Simon''' est '''terminé''' et est '''fonctionnel''. En effet le '''serveur websocket''' envoie une '''combinaison''' de couleur, composée par un utilisateur, à '''l’arduino''', qu’un second utilisateur devra tenter de '''reproduire''' (couleur par couleur, en reprenant du début à chaque fois, avec une couleur en plus à chaque tour). Le '''Jeu de Simon est terminé ''': '''L’objectif principal''' de notre projet est donc '''réalisé'''.<br />
<br />
Cependant, le '''Guitar Héro''' n’a pas pu être abouti. Nous avions précisé dès le début du projet que nous tâcherions de '''finir le Simon en priorité''' et de faire le Guitare Héro ensuite. La '''guitare est finalisée''' et '''fonctionnelle'''. Nous n’étions donc pas si loin de terminer les deux projets. <br />
Nous sommes globalement '''satisfaits''' du '''travail réalisé''' et de la''' prestation proposée'''. En effet en sachant que nous avions deux projets en simultané (bien que très ressemblant entre eux) nous avons su '''terminer le premier''' et '''bien avancer sur le second'''. Le '''but principal''' était de '''nous amuser''', de '''prendre du plaisir dans la réalisation d'un projet''' et de '''faire quelque chose qui nous plaisait avant tout''', '''l’objectif''' est '''atteint'''.<br />
Le FPGA n'a pas pu être aboutit non plus, et c'est dommage, car c'est une technologie intéressante, et c'est plus optimisé et rapide qu'une Arduino. <br />
<br />
Ce projet fut très '''intéressant''' car il nous a permis de '''mettre en application''' certains de nos '''cours étudiés''' cette année en IMA3, mais également d’en '''apprendre''' énormément '''par nous même''' à force de '''pratique '''et de''' recherches personnelles'''. Pour l’ensemble des membres du groupe, ce projet a été la confirmation de '''l’intérêt '''porté aux '''systèmes communiquants''', et nous a donc '''convaincu de choisir''' la '''filière SC''' à partir du semestre 8 en '''IMA4'''.<br />
<br />
<br />
La démonstration du fonctionnement du Jeu de Simon, est disponible à l'adresse suivante : https://youtu.be/RbgPtALDmFw .</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=Projet_IMA3_P3,_2016/2017,_TD1&diff=44295Projet IMA3 P3, 2016/2017, TD12017-06-18T20:09:35Z<p>Adurot : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 25px; padding: 20px; font-weight: bold; text-align: center; font-size: 98%; background: #6060FF; vertical-align: top; width: 99%;"> Projet IMA3-SC 2016/2017 : Le Jeu de Simon et le Guitar Hero </div>=<br />
<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Cahier des Charges </div>==<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Description du système </div>===<br />
<br />
* L'objectif principal de notre projet est de réaliser un '''jeu''' qui utilise à la fois les '''lumières''' et le '''son'''. Pour cela, nous avons pensé à deux versions : '''le Simon''' et un jeu du type '''Guitar Hero'''.<br />
<br />
* Le '''Simon''' est constitué de '''quatre boutons de couleurs différentes''' : un bleu, un rouge, un vert et un jaune. Le jeu va '''afficher''' une séquence de couleurs qui sont chacune '''associées à un son'''. Le joueur doit ensuite se '''souvenir''' de la suite (en s'aidant du son et des couleurs comme moyen mnémotechnique) pour la '''reproduire''' dans le '''bon ordre''' en '''appuyant sur les boutons'''.<br />
<br />
* Le jeu '''Guitar Hero''', quant à lui, est un jeu où il faut '''actionner des boutons de couleur précise''', '''au moment où elles apparaissent''' sur une barre de défilement, '''à l'écran'''. Ces différentes '''activations''', aux '''bons moments''', permettent de '''réaliser une mélodie''' plus ou moins complexe selon la difficulté de la chanson à reproduire. Le tout est effectué grâce à '''une guitare connectée''', afin de pousser l'expérience de '''simulation''' un peu plus loin. Si nous réalisons, ce jeu, il faut '''prendre en compte''' un '''affichage''' plus '''complexe'''. De plus, le '''Guitar Hero''' ajoute '''une notion de temps de réponse''', plus '''difficile à gérer'''. Ce temps de réponse permet de laisser une '''courte marge d'erreur''' dans la '''réactivité de l'utilisateur''', pour '''simuler pleinement''' l'utilisation d'une '''guitare électrique'''.<br />
<br />
<br />
Nous avons choisis de d'abord nous concentrer sur le '''Simon''' et de faire le jeu '''Guitar Hero''' seulement '''si nous avons le temps'''.<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Le matériel </div>===<br />
<br />
Pour ce '''projet''' nous utiliserons :<br />
<br />
* Une '''page internet''' sur l'ordinateur pour pouvoir '''modifier les différents aspects du jeu''' : les '''règles du jeu''', la '''musique''' jouée par le Simon ou bien la '''difficulté'''<br />
<br />
* Le '''Raspberry Pi''', utilisée en tant que serveur, va envoyer les données en série ( qui seront traitées par le FPGA ), de les recupérer, et de faire l'algorithme.<br />
<br />
* Une '''carte Arduino''' pour '''relier''' la Raspberry Pi aux composants dans un premier temps : elle nous permet de '''coder en C''' (au lieu d'un langage assembleur) pour '''créer des programmes''' et '''gérer''' les différents '''modules''' tel que les '''boutons''' et les '''LEDs'''. Elle permettra une '''simulation''' momentanée du '''FPGA''', afin que nous puissions avancer sur la partie informatique, sans attendre d'en avoir fini avec la partie FPGA.<br />
<br />
* Une fois le programme et les interactions fonctionnels, nous '''remplacerons''' l'Arduino par une '''FPGA''' qui est '''circuit logique programmable''' : on peut '''modifier les circuits logiques''' à l'intérieur mais '''on ne peut pas créer un programme''' avec un '''langage''' de plus '''haut niveau'''. Nous devrons donc utiliser des '''logiciels tiers''' qui nous permettront de placer des '''portes logiques''' (ET, OU,...) pour '''créer notre programme en assembleur'''.<br />
<br />
* Pour ce qui est de la '''partie mécanique''', nous réaliserons une '''guitare en bois''' pour le''' "Guitar Hero"''' ainsi qu'un''' "jeu de Simon"''' réalisé via l''''impression 3D.'''<br />
<br />
* Si le temps nous le permet, nous utiliserons un '''Xbee''' pour créer une '''connexion sans fil''', afin '''d'expérimenter''' un '''module nouveau''' et '''acquérir''' de '''nouvelles compétences'''.<br />
<br />
*Nous utiliserons également des '''composants électroniques''' tels que des '''boutons poussoirs''', des '''LEDs''' ou une '''matrice de LEDs''' pour l'affichage dans le cas du jeu de Simon, ainsi que de '''"l'essentiel"''' pour un '''système communiquant''' (à savoir '''résistances''', '''fils électriques''', etc...)<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Description des séances </div>==<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 21/03/17 Séance 1 : Répartition des tâches et premiers pas </div>===<br />
<br />
La première séance fut''' consacrée à la répartition des rôles''' et à la '''prise de conscience '''de la '''difficulté des différentes tâches'''. L''''idée''' de faire un '''« jeu de Simon » '''que nous''' amélioreront '''ensuite en '''« guitar hero »''' a cependant été '''conservée'''.<br />
<br />
==== Partie électronique ====<br />
<br />
Nous avons décider de concentrer deux personnes sur le FPGA car c'est un élément très complexe et complètement nouveau.<br />
Nous allons en effet devoir coder à très bas niveau avec simplement des registres et des portes logiques.<br />
<br />
L'objectif du composant sera de récupérer un message contenant les boutons sur lesquelles appuyer. <br />
Une fois ce message reçu, le FPGA va comparer le bouton saisit par l'utilisateur avec le bouton demander. <br />
S'il est correct, le fpga va passer à la couleur suivante, sinon il va renvoyer un message pour dire à la Raspberry (ou l'ordinateur) que l'utilisateur s'est trompé.<br />
<br />
Pour commencer, nous réalisons le tutoriel pour allumer une LED qui va nous permettre de comprendre le fonctionnement de Altium Designer.<br />
Cela nous a pris du temps mais nous avons pu réaliser d'autres essaies avec des registres à décalages et des boutons.<br />
<br />
Nous avons ensuite directement commencer le Simon :<br />
Le choix a été fait d'utiliser des registres à décalages pour récupérer la séquence de couleur envoyé par l'ordinateur/la raspberry. <br />
Nous allons en effet stocker toute la séquence de la "partie" car sinon il faudrait gérer beaucoup d'échange entre l'ordinateur et le FPGA ce qui est lourd en Altium et fait perdre du temps réaction du programme.<br />
<br />
D'un point de vue technique, utiliser un registre à décalage semble être la meilleur méthode pour récupérer un à un les bits qui arrivent sur la liaison série puis nous utilisons 4 registres à décalage : 1 pour chaque couleur.<br />
Pour chacun des registres nous aurons donc une séquence comme suit : 0100010010111. Les 1 correspondent aux moments ou il faut appuyer sur la couleur et les 0 aux moments ou il ne faut pas appuyer sur cette couleur. <br />
Nous devons donc également gérer les clocks des registres "couleurs". Ces registres doivent arrêter leur clock lorsque les bits de chaque couleur est à 0.<br />
<br />
Le registre pour la liaison série sera la clock du système puisqu'elle doit lire toute la séquence mais elle doit également s'arrêter lorsque le FPGA arrive à la fin de la séquence. Pour lui indiquer la fin de la séquence nous avons choisit le mot 0000 car il y aura toujours un bouton à appuyer pour le jeu Simon.<br />
<br />
==== Partie informatique ====<br />
<br />
L'objectif ici était la découverte des technologies a utilisé pour le système. Notamment une Arduino en liaison série à un PC et un serveur Websockets codé en C.<br />
La partie programmation arduino ne fut pas un problème. En effet, ce n'était pas la première fois que nous utilisions cet outil, et donc la mise en place de la liaison série fut très rapide.<br />
Ce n'est cependant pas le cas de la communication websockets. Bien que l'exemple de code fourni par M. Redon soit fonctionnel, le code n'en reste pas moins complexe à comprendre. Il fallait donc réussir à modifier le code du serveur websockets, afin de relier les deux systèmes entre eux.<br />
<br />
==== Partie mécanique : un modèle de guitare à découper====<br />
<br />
<br />
Dans cette première séance, nous avons décidé de focaliser nos premiers efforts sur la''' partie mécanique''' du '''"guitar hero"'''. En effet, le '''« jeu de simon »''' pouvait être avancé '''plus tard''' car plus''' facile''' à '''modéliser''' et à''' réaliser.'''[[Fichier:1.jpg||right|vignette|upright=2|]]<br />
Nous sommes alors partis sur l'idée de créer une''' maquette de guitare''', sur laquelle nous allions '''disposer''' différents '''boutons de couleur''', '''actionnables''' grâce à une '''pression''' sur le manche de l'instrument. Nous avions une '''ligne directrice''' mais pas encore d''''idée précise''' de comment allait être réalisé la guitare, ni même '''ce à quoi elle allait ressembler'''.<br />
<br />
<br />
Nous avons décidé de découper la '''guitare en bois''' qui nous servirait de support pour notre '''« guitar hero »''' grâce à la''' découpeuse laser'''. Pour se faire, un '''fichier conforme à la découpe''' devait être réalisé. <br />
Ainsi nous avons donc pris une '''image de guitare''' depuis '''internet'''. Dans le logiciel''' « GIMP »''', nous avons ensuite '''repassé les contours de l'instrument en rouge'''. Une fois ceci fait, nous avons''' effacé l'image de la guitare originale '''pour ne''' garder que les contours rouges'''. Enfin après '''quelques réglages''', l''''export en fichier SVG '''permettait une '''découpe précise'''. Les contours de la guitare sont disponibles ci contre (cliquez sur l'image pour bien voir).<br />
<br />
A la '''fin de la séance''', la '''guitare''' était''' prête à être réalisée '''et nous avons décidé de faire l'intégralité du''' « jeu de simon »''' via '''l'impression 3D'''. Cependant, aucune grande avancée n'a eu lieu sur la partie mécanique du jeu de Simon lors de cette séance.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 28/03/17 Séance 2 : Poursuite du Projet et rencontre des premiers problèmes </div>===<br />
<br />
La '''deuxième séance''' fut davantage '''productive''', car chacun de nous savait les différentes '''tâches''' qu'il lui '''restait à accomplir'''.<br />
<br />
==== Partie électronique ====<br />
Nous nous sommes rendu compte qu'utiliser le registre à décalage pour la liaison série comme nous le faisions n'était pas possible.<br />
En effet, la liaison série est en asynchrone et nous ne connaissance donc pas la clock. <br />
Nous ne pouvons donc pas utiliser cette clock pour le registre à décalage car sinon nous risquons de ne pas lire assez vite (ou trop vite) et donc récupérer trop de valeurs ou en rater.<br />
<br />
Le professeur nous a donc indiquer qu'il nous mettrai à disposition un module qui va s'occuper justement de lire la liaison série et de garder la séquence et de ressortir le message en parallèle.<br />
Ce composant envoie également sur un autre pin un 1 à chaque fois qu'un bit est envoyé par la liaison série (et reçu par le composant).<br />
Nous utilisons, selon ces conseils, un module analogique-digital qui va nous permettre de simuler l'envoie de la séquence.<br />
Après plusieurs tentative nous avons un programme qui fonctionne correctement pour recevoir les valeurs. Il nous reste à comparer l'appuie d'un bouton et la couleur à presser.<br />
<br />
==== Partie informatique ====<br />
<br />
L'écriture du programme de communication fut terminé assez rapidement. Mais il ne fonctionnait pas...<br />
En effet, un problème s'opérait lors de l'appel de la liaison série par le serveur websocket à réception d'un message.<br />
<br />
L'incompréhension régnait un peu, car à nos yeux tout était sensé fonctionner. Le principe était assez simple : à reception d'un message par le serveur websockets, ce dernier devait ouvrir une communication série sur le port TTY_USB0 (ou TTY_ACM0 en fonction de l'arduino) à 9600 bauds, y transférer le message reçu, puis refermer la communication.<br />
<br />
Après un long moment de doute, le problème fut résolu. Ce dernier était assez idiot. En effet, notre fonction d'envoie de message via le port série s'appelait : " send(..) ". Il s'avère qu'une fonction d'une des librairies utilisées se nomme de la même manière. Il y avait donc conflit et empêchait le programme de fonctionner correctement.<br />
<br />
Nous avons donc pu relier l'ordinateur à un montage de prototypage Arduino/LEDs afin de tester le bon fonctionnement du programme. Une combinaison de 4 LED devait s'allumer à réception d'un caractère. Il fallait donc envoyé un message compris entre 0(aucune LED allumée) et 15(toutes les LED allumées). Cependant, le début de la table ASCII ne représente pas des caractères. Le serveur envoie donc un message alphabétique compris entre 65 ('A') et 80 ('P') et l'arduino interprète ceci comme une valeur de 0 a 15<br />
<br />
==== Partie mécanique : découpe de la guitare, modélisation et impression d'un prototype de touches pour cette dernière ====<br />
<br />
[[Fichier:pp.jpg||left|vignette|upright=0.8|]]Cette séance fut entamée par la '''découpe de la guitare''' grâce à la '''découpeuse laser''' du '''Fabricarium de Polytech'''. Dans un premier temps il a d'abord était nécessaire '''« d'apprivoiser »''' la '''découpeuse''' et d''''apprendre à bien la configurer''' pour obtenir le résultat souhaité, sans risques. Un '''premier essai''' a d'abord était réalisé dans du '''carton''' pour pouvoir '''juger des différentes dimensions''' de la guitare.<br />
Enfin, une '''seconde version''', en''' bois''', fut réalisée durant cette séance. Finalement nous décidons de partir sur l'idée d'une '''guitare réalisée en 4 couches d'épaisseur''' : '''2 extérieures en bois''' ( une de '''face''', '''décorée''' avec les '''boutons à actionner''' et la carte '''arduino''' et une '''seconde''', '''arrière''', de '''protection'''), et '''deux intérieures en carton'''('''creusées''' pour laisser passer les '''fils de connectiques''').<br />
<br />
'''Note''' : Malheureusement, une des '''couche en bois''' a était '''cassée''' par la suite lors de la confection de la guitare. La''' panne prolongée''' de la '''découpeuse laser''' nous a contraint à '''renoncer à l'idée d'une quatrième couche en bois''' de protection.[[Fichier:po.jpg||right|vignette|upright=1.2|]]<br />
<br />
<br />
De plus, via le '''logiciel de modélisation FreeCAD''', nous avons commencé à concevoir deux '''prototypes''' de '''« touches »''' (boutons) pour la guitare. <br />
<br />
L'idée était de créer des '''surfaces larges''' (pouvant recueillir '''une phalange de doigts au minimum''') faisant office de '''touches''', en dessous desquelles nous '''insérerions''' un '''bouton poussoir''' 4 pins (fournis par les professeurs). La '''création de touches plus larges''' était '''indispensable'''. En effet, les '''boutons poussoirs''' étaient bien '''trop petits''' pour avoir un '''actionnement facile et agréable'''.<br />
Nous avons pu lancer l''''impression des touches''' à la''' fin de la séance'''. Cependant, les différents '''tests '''et les''' défauts d'impression''' nous ont fait comprendre qu'il serait''' difficile de « glisser » un bouton poussoir '''dans une '''touche '''avec un '''espace '''assez''' étroit '''pour le maintenir, sans pour autant '''bloquer son actionnement''' lorsqu'une '''pression''' était appliquée. De plus, la''' fixation''' risquait d'être assez '''complexe'''. <br />
Nous avons alors décidé de faire un tout '''autre type de touche''' mais avec le '''même fonctionnement'''. Pour cela nous allions avoir besoin de''' modéliser et d'imprimer '''de nouveaux un '''prototype de touche'''.<br />
Il allait ensuite falloir''' percer la première couche en bois de la guitare'''. Puis il serait également nécessaire de '''creuser les sous couches''' en carton pour y placer les boutons poussoirs et les différents câbles.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 05/04/2017 Séance 3 : Encore beaucoup de choses à faire !</div>===<br />
<br />
Bien que ce soit notre '''dernière séance officielle''', nous savions que nous allions avoir '''besoin''' de '''beaucoup de temps''' pour''' terminer ce projet '''! <br />
<br />
==== Partie électronique ====<br />
Au final notre FPGA n'est pas fonctionnel, suite à des tests en utilisant le port série, nous avons intégré les circuits reception.vhdl et emission.vhdl fournis par M. Boé. Mais le résultat n'est pas au rendez vous.<br />
<br />
[[Fichier:fpga.png|||vignette|upright=2|]]<br />
<br />
==== Partie informatique ====<br />
<br />
<br />
L'objectif de la séance était la mise en place de l'interface WEB, notamment pour le jeu Guitar Hero. <br />
<br />
Nous avons utilisé un canvas Javascript afin de dessiner un interface similaire a celle du jeu original.<br />
<br />
==== Partie mécanique ====<br />
<br />
La troisième séance était destinée à '''l’élaboration du jeu de Simon'''. Une première idée était de '''créer quatre pièces plates''', composées de''' multiples leds''', qu'il faudrait''' actionner''' via une simple''' pression'''. Cependant, nous nous sommes dit '''qu'une seule LED pour une couleur''', suffisait à '''indiquer''' la '''combinaison''' à reproduire. <br />
<br />
Le tout devait être assez '''grand''' pour '''contenir la carte arduino''' ainsi que toute la '''connectique''', '''sans''' pour autant '''être''' trop '''encombrant''', tout en étant assez '''ergonomique''' et '''agréable au regard'''.<br />
<br />
Nous avons donc décidé de '''créer un support creux ''' qui '''contiendrait la partie électronique ''', au dessus duquel nous placerions '''les 4 pièces de couleur''' avec '''une LED pour chaque couleur'''.<br />
<br />
Nous savions dès lors, qu'un '''travail long minutieux''' nous attendait.<br />
<br />
Ainsi nous avons fait de '''nombreux croquis''' avec les '''différentes pièces''' et leurs '''dimensions éventuelles'''. Des pièces que nous allions réaliser uniquement en '''impression 3D'''. Un '''travail similaire''' a été réalisé pour '''la guitare''', afin de ne pas '''percer la guitare à de mauvais endroits''', et pour '''agencé les différents parties''' à ajouter sur la guitare de la '''meilleure façon possible'''. Pour '''résumer''' cette séance, nous avons '''réalisé tous les croquis nécessaires à la réalisation''' de la '''guitare''' et du '''Simon'''.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Séance supplémentaire : Terminons ce Projet !</div>===<br />
<br />
Il n'y a pas eu un '''nombre précis de "séances supplémentaires".''' '''Chacun''' des membres du groupe travaillait '''soit chez lui''', '''soit à l'école''' de '''manière régulière''', afin '''d'avancer sa partie''' le plus '''rapidement''' possible.<br />
<br />
==== Partie électronique ====<br />
<br />
Pour le Simon, il a fallut souder les câbles aux boutons et aux leds ( avec leur résistance ). Pour se faire, on a utilisé un circuit à pastilles qui se place entre l'arduino et les boutons/led. Cela permet de prendre moins de place et de faire plus propre qu'une breadboard.<br />
[[Fichier:pcb1.jpg|left|vignette|upright=0.8|]]<br />
[[Fichier:pcb2.jpg|right|vignette|upright=0.8|]]<br />
<br />
=== Partie informatique ===<br />
<br />
La partie FPGA n'étant pas fonctionelle, il a fallut le remplacer par un Arduino. <br />
<br />
Le code de l'Arduino consiste en une succession d'étapes pour jouer. Tout d'abord il faut recevoir via le port série la séquence totale du Simon, sous la forme de chaîne de caractères. Par exemple si le message reçu est "RVBR", alors la séquence totale du Simon sera Rouge Vert Bleu Rouge. Ainsi une fonction reception_message a été codée, qui attend la réception série de la séquence. <br />
<br />
Dans l'algorithme du jeu en lui même on a une variable globale qui stocke l'état de la partie, et une qui stocke l'étape de la séquence. Ainsi en fonction de l'état de la partie on va soit jouer la séquence sur les leds, lire l'état des boutons, ou provoquer un game over.<br />
<br />
La fonction playSequence va parcourir la séquence totale jusqu'à l'étape actuelle et va allumer les différentes leds en conséquence.<br />
<br />
La fonction readSequence va elle lire l'état successif des boutons et le comparer à la séquence actuelle. Si il y a une erreur, on sort de la fonction, et l'état de la partie devient un game over. Sinon, on continue et on appelle playSequence en incrémentant l'étape. En cas de réussite de la séquence, les 4 leds s'allument pour indiquer lé réussite et le passage au niveau supérieur.<br />
<br />
Coté websockets, c'est facile, dès qu'on reçoit un message par le client, on l'envoie à l'arduino ( bien qu'on aurait du vérifier la conformité du message ), l'arduino ne lira le message que si on est en étape de lecture de la séquence, donc après un game over par exemple. <br />
<br />
==== Partie mécanique : Suite et fin de la confection de la guitare et du jeu de Simon====<br />
<br />
Comme nous l'avons prédit, la plus '''grosse partie du travail''' réalisé a dû être faite lors de '''séances supplémentaires''' ou par '''travail personnel chez soi'''.<br />
<br />
Après avoir réalisé '''les croquis''', il était essentiel de '''créer rapidement les différents supports'''. En effet, cela nous permettait d'avoir du '''temps''' pour éventuellement''' recommencer et revoir les axes de travail en cas d'impossibilité de réalisation''' pour quelconque raison. De plus, une fois la''' partie mécanique terminée''', nous pouvions l''''utiliser''' comme '''support '''pour les '''tests électroniques'''. Enfin, cela nous laissait du temps en fin de projet pour '''décorer notre projet''', que nous voulions '''personnalisé''' afin d'en être '''le plus satisfaits possible'''. <br />
<br />
Un''' gros travail de modélisation''' à dû être fait sur '''FREECAD'''. Le '''support''' du jeu de Simon fut la pièce la plus '''simple '''à réaliser (un '''cylindre''' semi fermé, de '''7 cm de rayon''').<br />
<br />
Puis une simple''' découpe '''grâce à une '''scie''' permettrait de faire''' réceptacle''' pour une''' "croix porteuse" '''sur laquelle serait disposés les '''touches du Simon'''.<br />
<br />
De la même façon que pour la guitare, '''les touches''' seraient placées '''au dessus de boutons poussoirs'''. Ces derniers seront '''collés sur la croix'''. <br />
[[Fichier:tg.jpg||right|vignette|upright=1.5|]]<br />
Une fois ceci fait, il fallait '''réaliser le plus important du jeu''' : '''les touches à actionner '''! <br />
<br />
Pour cela, il était préférable de conserver la '''forme cylindrique '''du support en modélisant '''4 pièces''', d'un '''quart de disque''' chacune. Par soucis de '''fixation '''sur la croix et par envie d’'''esthétisme''', les touches seraient un peu '''incurvées''' pour donner une forme '''moins géométrique''' au rendu final. <br />
<br />
De plus, elles seront''' perforées''' pour laisser passer une '''LED''' de la même couleur que la touche sur laquelle elle se trouve. Ainsi l'utilisateur pourra '''mémoriser les touches à activer''' via le système '''lumineux''' des '''LEDs'''. <br />
<br />
Enfin, un '''cylindre permettant l'accroche''' sur la croix à été prévu sur la '''partie inférieure''' de les''' touches du Simon'''. (suite à une impression peu précise, '''ce cylindre sera « fondu »''' pour épouser la forme de la croix '''sans jeu dans la fixation'''.)<br />
<br />
[[Fichier:touc2.jpg||left|vignette|upright=1.7|]]<br />
Vint ensuite le''' moment de la création''' ! '''L'impression de ces pièces''' étant la plus '''complexe''', nous pensions qu'il serait nécessaire de les recommencer plusieurs fois. La '''WitBox du Fabricarium''' (la plus précise des imprimantes mise à notre disposition) a réalisé une '''impression assez laborieuse'''. Un gros travail de '''ponçage''' à donc dû être réalisé, car le support nécessaire pour imprimer cette pièce « incurvée » avait donné de '''nombreuses bavures''' sur la '''surface des touches'''. Afin que le '''toucher''' reste '''agréable''', nous avons donc '''retravaillé les pièces'''.<br />
<br />
<br />
Une fois ceci fait, nous avons '''essayé de les positionner''' sur la''' croix''' prévue à cet effet. Une fois encore, nous étions '''confronté aux limites de l'impression 3D'''. Les '''dimensions du « cylindre pillier » '''étant non précise, et cette partie étant''' trop fine pour être sciée''' '''sans rupture''' de la pièce, nous avons décidé de faire '''« fondre » '''cette partie et de la placer, encore chaude sur la partie en forme de croix. Cela permettait une''' fixation sûre''' et une '''dimension épousant parfaitement les formes du support'''. L'inconvénient fut que cette''' méthode, peu précise''', n'a fait qu''''accentuer les erreurs d'impressions''' au niveaux du '''visuel'''. Effectivement, les 4 pièces ne '''semblent pas régulières''' et le '''disque''' qu'elles sont censées former (ensemble de 4 quarts de disque) ne semble '''pas parfait'''.[[Fichier:bttt.jpg||right|vignette|upright=1.5|]][[Fichier:socle.jpg||right|vignette|upright=1.5|]]<br />
<br />
<br />
Nous décidons cependant de '''conserver ce léger défaut''', car si nous recommencions nous risquerions d'être de nouveau''' confronté au même souci''', l''''erreur''' n'étant pas uniquement dû à notre '''manipulation''' mais également à l''''imprimante 3D'''. <br />
<br />
<br />
L'impression du '''socle''' était la plus''' longue à imprimer''' (près de 6 heures) .Après l'avoir un peu '''scié''' comme prévu, cette pièce était également''' prête à être peinte'''. Nous avons fait de même avec la '''croix '''à placer sur le socle et servant de '''support''' aux '''quatre touches''' du Simon. Cette impression étant '''rapide et facile''', un seul essai suffit pour obtenir notre '''version définitive'''. L'impression fut dans ce cas, parfaitement aux '''mesures souhaitées''' dans le fichier .stl (bien que réalisé avec une imprimante de moins bonne qualité que la WitBox). Ainsi les '''boutons poussoirs '''que nous avions à positionner dessus tenaient sans souci '''par un simple encastrement'''. Par la suite, par '''mesure de sécurité''', <br />
nous avons tout de même rajouté un '''point de colle''' en dessous des''' boutons ''' pour éviter tout '''désencastrement non souhaité'''. <br />
[[Fichier:tr.jpg||left|vignette|upright=1.4|]]<br />
<br />
<br />
<br />
En parallèle, nous avons travaillé sur les '''différentes couches d'épaisseur''' de la ''' guitare'''. Dans un premier temps il était nécessaire de '''retirer une partie dans le manche''' pour y placer les boutons poussoirs. Cette étape aurait pu être réalisé rapidement avec la '''découpeuse laser''', mais celle ci étant '''en panne''', nous l'avons fait via '''une perceuse et un foret au Fabricarium'''. Le résultat était un '''peu moins net''' mais '''convenable cependant'''. De plus le '''"trou"''' sera '''caché''' par la pièce contenant '''les touches'''. Une fois la couche de bois travaillée, nous avons '''creusé '''la''' partie cartonnée''' afin de pouvoir y laisser passer les différents '''câbles '''liant les''' boutons poussoirs''' (situés sous les touches du manche de la guitare) à une '''breadboard''' (sur la partie basse de l'instrument).<br />
<br />
Afin que les '''câbles sortent de la guitare de façon propre''', nous avons percé '''4 trous à la base du manche'''. Ainsi de chaque''' trou''' ressortira '''deux fils de connectique''' ( un pour l'entrée du bouton poussoir et un pour la sortie).<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:tt.jpg||left|vignette|upright=2|]]<br />
Ceci étant terminé, il fallait passer à la '''conception des touches de la guitare'''.[[Fichier:touc.jpg||right|vignette|upright=2.2|]]<br />
C'est en '''observant''' une imprimante 3D du Fabricarium qu''''une idée de modèle touche vue le jour'''. Nous allions faire '''une seule et unique pièces''' pour les''' 4 touches'''.<br />
'''Fine''', elle pourrait être facilement '''pliée''' sous une '''pression du doigts''' pour '''actionner un bouton poussoir''' situé en '''dessous''' de chacune des 4 touches.suffirait juste de '''peindre les 4 touches de couleurs différentes''' pour les différencier.<br />
Cette pièce serait '''fixée sur le manche de la guitare''', couvrant une''' couche de bois perforée''' et une '''cartonnée « creusée »''' pour '''laisser passer la connectique '''jusqu'à la partie inférieure de la guitare.<br />
<br />
Finalement, il aura fallut '''quelques heures supplémentaires''' des séances pour avoir '''toutes nos partie modéliser sur FREECAD ''' et '''prête à être imprimées''', qu'elles soient destinées au '''Simon''' ou au '''Guitar Hero'''.<br />
<br />
L'heure est donc à la '''réalisation''' ! Les '''impressions 3D '''se sont faites sur l'imprimante d''''un des membre du groupe''' ainsi que sur celles du''' Fabricarium'''. <br />
<br />
Les''' touches''' qui actionneraient les boutons poussoirs étaient les plus à même d'être à''' recommencer'''. En effet, un '''problème de fixation''', ou encore une '''rigidité trop grande''' '''empêcherait''' l'actionnement du '''bouton '''et serait donc '''inutilisable'''. Ainsi nous avons '''commencé par imprimer les touches''' (pour la guitare et pour le simon). Dans un premier temps, nous nous sommes occupés de la pièce '''pour la guitare'''. La première '''impression '''fut''' décevante''', car''' trop épaisse '''(8mm) , la pièce''' ne pliait pas''' sous la pression des doigts et n’'''actionnait donc pas les boutons''' placés dessous.<br />
<br />
Ce pourquoi nous avons lancé immédiatement une '''nouvelle impression''' avec 3mm d'épaisseur. Les '''tests étant concluants''', nous n'avions plus qu'à la''' peindre''' de '''4 couleurs différentes '''pour symboliser les 4 touches du guitar hero. <br />
<br />
<br />
Ceci commença par la réalisation de '''soudures''' des '''boutons poussoirs''' avec les '''fils'''. Ces fils seraient ensuite placés '''sous '''la couche de '''bois''', '''dans''' la couche de '''carton'''. Cette étape fut '''rapidement terminée'''.<br />
<br />
Les '''8 boutons poussoirs étaient prêts '''! '''Quatre''' pour la''' guitare''',''' quatre '''pour le jeu de '''Simon'''.<br />
<br />
Finalement,''' toutes les pièces étant réalisées''', il fallait réaliser''' un travail d'assemblage''', et de '''finitions ''' (au niveaux des couches de peinture notamment). <br />
<br />
Nous nous sommes préalablement''' assuré '''que tous les '''boutons poussoirs étaient fonctionnels '''et que les''' soudures '''étaient '''correctement réalisées''' grâce à des''' tests rapides''' avec la '''carte arduino.'''<br />
<br />
<br />
[[Fichier:led.jpg||left|vignette|upright=1.2|]][[Fichier:end.jpg||RIGHT|vignette|upright=1.3|]]<br />
Enfin, il ne restait plus qu'à '''peindre''' nos différentes''' pièces'''.<br />
<br />
Premièrement nous avons '''appliqué deux couches de blanc''' sur '''chacune des pièces'''. Puis sur celles qui nécessitaient une '''couleur précise''' ( en autre : les touches de la guitare et du Simon), nous avons repassé '''deux couches''' de '''couleur''' dessus.<br />
Puis, nous avons '''assemblé toutes les pièces''' entre elles pour '''obtenir le résultat final''' ! <br />
<br />
L''''assemblage''' des différentes '''couches de la guitare''' à d'abord était '''provisoirement fait '''avec de la '''colle forte'''. Si le collage venait à '''céder''', nous utiliserons sans doute des''' vis '''ou des '''accroches '''en plastique pour maintenir le tout en place.<br />
<br />
Nous en avons profité pour utiliser la peinture restantes pour décorer un peu notre guitare et ainsi la personnaliser comme bon nous semblait.<br />
<br />
<br />
<br />
<br />
<br />
Finalement, le''' résultat''' est plus que '''satisfaisant '''! Les quatre '''couleurs primaires''' étant '''vives''', elles donnent un aspect '''coloré''' et '''joyeux''' à notre '''projet''' ! Les quatre '''touches du Simon''', '''surmontées''' d'une '''LED''' de la même couleur que la touche, permettent une '''utilisation claire et facile '''du « jeu de Simon ».<br />
<br />
<br />
Dans la '''globalité''', nous sommes assez '''fiers''' du résultat de la '''partie mécanique''' ! Que ce soit du ''' "jeu de Simon" '''ou de la '''Guitare''' du '''"Guitar Héro"''', les '''boutons poussoirs''' sont''' activables facilement '''(voir la vidéo de démonstration en cliquant sur le lien suivant :[https://youtu.be/3-p--BhHGr4] ). De plus le''' résultat est assez agréable''' à '''regarder''' ou encore '''facile a prendre en main'''. <br />
<br />
<br />
<br />
La '''partie mécanique '''étant bien '''avancée''' avant la fin du projet, nous avons décidé de''' procéder à certaines améliorations'''. En effet, les tests des parties électronique et informatique pouvaient donc s’effectuer sur le Simon et la guitare ainsi réalisée. Ainsi dans tous les cas nous avions '''deux prototypes''' à présenter à la fin du projet.<br />
<br />
En parallèle,''' une version plus élaborée''' de la guitare pouvait ainsi être en '''construction'''.<br />
Pour se faire, nous avons repris le fichier SVG explicité lors de la première séance et nous lui avons rajouté un rectangle rouge au niveau du manche, pour une '''découpe plus propre''' à la découpeuse laser, et '''moins fragilisante''' pour le bois.<br />
<br />
[[Fichier:entretoise.jpg||right|vignette|upright=1.5|]]<br />
[[Fichier:cote.jpg||left|vignette|upright=1.5|]]<br />
<br />
<br />
De plus pour gagner en '''propreté''', nous avons placé un PCB pour éviter l’encombrement.<br />
Enfin, nous avons pris la décision de laisser la''' guitare creuse''', afin de pouvoir '''mieux voir le contenu électronique''' à l’intérieur et de garder un '''aspect plus propre et épuré''' de la guitare.<br />
<br />
Pour ce faire, nous allons utiliser des '''entretoises''' qui permettront une largeur de guitare homogène. Afin d’éviter une pliure du bois au niveau des touches (et ainsi éviter que les touches ne soient pas actionnées car pas d’opposition de force), nous avons insisté sur les''' entretoises au-dessous des touches '''(que nous avons pris soin de fixer avec de la colle pour éviter de fragiliser le bois au niveau du manche en le perçant).<br />
<br />
Finalement, les '''touches sont activables facilement''', une fois la guitare prise en main. Un signal logique bas est bien transmis une fois les '''touches appuyées'''. Et il est '''bien détecté''' par''' l’arduino'''. <br />
<br />
[[Fichier:guitaredroite.jpg||center|vignette|upright=2|]]<br />
<br />
<br />
<br />
Désormais, la '''partie mécanique '''étant''' terminée et fonctionnelle''', il faut la '''lier à la partie informatique et électronique'''. Nous allons '''perfectionner la partie FPGA''' et''' Arduino '''pour''' exploiter''' pleinement les '''deux supports '''(guitare et jeu de Simon) ainsi réalisés.<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Conclusion </div>==<br />
<br />
<br />
En conclusion, Le '''jeu de Simon''' est '''terminé''' et est '''fonctionnel''. En effet le '''serveur websocket''' envoie une '''combinaison''' de couleur, composée par un utilisateur, à '''l’arduino''', qu’un second utilisateur devra tenter de '''reproduire''' (couleur par couleur, en reprenant du début à chaque fois, avec une couleur en plus à chaque tour). Le '''Jeu de Simon est terminé ''': '''L’objectif principal''' de notre projet est donc '''réalisé'''.<br />
<br />
Cependant, le '''Guitar Héro''' n’a pas pu être abouti. Nous avions précisé dès le début du projet que nous tâcherions de '''finir le Simon en priorité''' et de faire le Guitare Héro ensuite. La '''guitare est finalisée''' et '''fonctionnelle'''. Nous n’étions donc pas si loin de terminer les deux projets. <br />
Nous sommes globalement '''satisfaits''' du '''travail réalisé''' et de la''' prestation proposée'''. En effet en sachant que nous avions deux projets en simultané (bien que très ressemblant entre eux) nous avons su '''terminer le premier''' et '''bien avancer sur le second'''. Le '''but principal''' était de '''nous amuser''', de '''prendre du plaisir dans la réalisation d'un projet''' et de '''faire quelque chose qui nous plaisait avant tout''', '''l’objectif''' est '''atteint'''.<br />
Le FPGA n'a pas pu être aboutit non plus, et c'est dommage, car c'est une technologie intéressante, et c'est plus optimisé et rapide qu'une Arduino. <br />
<br />
Ce projet fut très '''intéressant''' car il nous a permis de '''mettre en application''' certains de nos '''cours étudiés''' cette année en IMA3, mais également d’en '''apprendre''' énormément '''par nous même''' à force de '''pratique '''et de''' recherches personnelles'''. Pour l’ensemble des membres du groupe, ce projet a été la confirmation de '''l’intérêt '''porté aux '''systèmes communiquants''', et nous a donc '''convaincu de choisir''' la '''filière SC''' à partir du semestre 8 en '''IMA4'''.<br />
<br />
<br />
La démonstration du fonctionnement du Jeu de Simon, est disponible à l'adresse suivante : https://youtu.be/RbgPtALDmFw .</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=Projet_IMA3_P3,_2016/2017,_TD1&diff=44294Projet IMA3 P3, 2016/2017, TD12017-06-18T20:08:08Z<p>Adurot : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 25px; padding: 20px; font-weight: bold; text-align: center; font-size: 98%; background: #6060FF; vertical-align: top; width: 99%;"> Projet IMA3-SC 2016/2017 : Le Jeu de Simon et le Guitar Hero </div>=<br />
<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Cahier des Charges </div>==<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Description du système </div>===<br />
<br />
* L'objectif principal de notre projet est de réaliser un '''jeu''' qui utilise à la fois les '''lumières''' et le '''son'''. Pour cela, nous avons pensé à deux versions : '''le Simon''' et un jeu du type '''Guitar Hero'''.<br />
<br />
* Le '''Simon''' est constitué de '''quatre boutons de couleurs différentes''' : un bleu, un rouge, un vert et un jaune. Le jeu va '''afficher''' une séquence de couleurs qui sont chacune '''associées à un son'''. Le joueur doit ensuite se '''souvenir''' de la suite (en s'aidant du son et des couleurs comme moyen mnémotechnique) pour la '''reproduire''' dans le '''bon ordre''' en '''appuyant sur les boutons'''.<br />
<br />
* Le jeu '''Guitar Hero''', quant à lui, est un jeu où il faut '''actionner des boutons de couleur précise''', '''au moment où elles apparaissent''' sur une barre de défilement, '''à l'écran'''. Ces différentes '''activations''', aux '''bons moments''', permettent de '''réaliser une mélodie''' plus ou moins complexe selon la difficulté de la chanson à reproduire. Le tout est effectué grâce à '''une guitare connectée''', afin de pousser l'expérience de '''simulation''' un peu plus loin. Si nous réalisons, ce jeu, il faut '''prendre en compte''' un '''affichage''' plus '''complexe'''. De plus, le '''Guitar Hero''' ajoute '''une notion de temps de réponse''', plus '''difficile à gérer'''. Ce temps de réponse permet de laisser une '''courte marge d'erreur''' dans la '''réactivité de l'utilisateur''', pour '''simuler pleinement''' l'utilisation d'une '''guitare électrique'''.<br />
<br />
<br />
Nous avons choisis de d'abord nous concentrer sur le '''Simon''' et de faire le jeu '''Guitar Hero''' seulement '''si nous avons le temps'''.<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Le matériel </div>===<br />
<br />
Pour ce '''projet''' nous utiliserons :<br />
<br />
* Une '''page internet''' sur l'ordinateur pour pouvoir '''modifier les différents aspects du jeu''' : les '''règles du jeu''', la '''musique''' jouée par le Simon ou bien la '''difficulté'''<br />
<br />
* Le '''Raspberry Pi''', utilisée en tant que serveur, va envoyer les données en série ( qui seront traitées par le FPGA ), de les recupérer, et de faire l'algorithme.<br />
<br />
* Une '''carte Arduino''' pour '''relier''' la Raspberry Pi aux composants dans un premier temps : elle nous permet de '''coder en C''' (au lieu d'un langage assembleur) pour '''créer des programmes''' et '''gérer''' les différents '''modules''' tel que les '''boutons''' et les '''LEDs'''. Elle permettra une '''simulation''' momentanée du '''FPGA''', afin que nous puissions avancer sur la partie informatique, sans attendre d'en avoir fini avec la partie FPGA.<br />
<br />
* Une fois le programme et les interactions fonctionnels, nous '''remplacerons''' l'Arduino par une '''FPGA''' qui est '''circuit logique programmable''' : on peut '''modifier les circuits logiques''' à l'intérieur mais '''on ne peut pas créer un programme''' avec un '''langage''' de plus '''haut niveau'''. Nous devrons donc utiliser des '''logiciels tiers''' qui nous permettront de placer des '''portes logiques''' (ET, OU,...) pour '''créer notre programme en assembleur'''.<br />
<br />
* Pour ce qui est de la '''partie mécanique''', nous réaliserons une '''guitare en bois''' pour le''' "Guitar Hero"''' ainsi qu'un''' "jeu de Simon"''' réalisé via l''''impression 3D.'''<br />
<br />
* Si le temps nous le permet, nous utiliserons un '''Xbee''' pour créer une '''connexion sans fil''', afin '''d'expérimenter''' un '''module nouveau''' et '''acquérir''' de '''nouvelles compétences'''.<br />
<br />
*Nous utiliserons également des '''composants électroniques''' tels que des '''boutons poussoirs''', des '''LEDs''' ou une '''matrice de LEDs''' pour l'affichage dans le cas du jeu de Simon, ainsi que de '''"l'essentiel"''' pour un '''système communiquant''' (à savoir '''résistances''', '''fils électriques''', etc...)<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Description des séances </div>==<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 21/03/17 Séance 1 : Répartition des tâches et premiers pas </div>===<br />
<br />
La première séance fut''' consacrée à la répartition des rôles''' et à la '''prise de conscience '''de la '''difficulté des différentes tâches'''. L''''idée''' de faire un '''« jeu de Simon » '''que nous''' amélioreront '''ensuite en '''« guitar hero »''' a cependant était '''conservée'''.<br />
<br />
==== Partie électronique ====<br />
<br />
Nous avons décider de concentrer deux personnes sur le FPGA car c'est un élément très complexe et complètement nouveau.<br />
Nous allons en effet devoir coder à très bas niveau avec simplement des registres et des portes logiques.<br />
<br />
L'objectif du composant sera de récupérer un message contenant les boutons sur lesquelles appuyer. <br />
Une fois ce message reçu, le FPGA va comparer le bouton saisit par l'utilisateur avec le bouton demander. <br />
S'il est correct, le fpga va passer à la couleur suivante, sinon il va renvoyer un message pour dire à la Raspberry (ou l'ordinateur) que l'utilisateur s'est trompé.<br />
<br />
Pour commencer, nous réalisons le tutoriel pour allumer une LED qui va nous permettre de comprendre le fonctionnement de Altium Designer.<br />
Cela nous a pris du temps mais nous avons pu réaliser d'autres essaies avec des registres à décalages et des boutons.<br />
<br />
Nous avons ensuite directement commencer le Simon :<br />
Le choix a été fait d'utiliser des registres à décalages pour récupérer la séquence de couleur envoyé par l'ordinateur/la raspberry. <br />
Nous allons en effet stocker toute la séquence de la "partie" car sinon il faudrait gérer beaucoup d'échange entre l'ordinateur et le FPGA ce qui est lourd en Altium et fait perdre du temps réaction du programme.<br />
<br />
D'un point de vue technique, utiliser un registre à décalage semble être la meilleur méthode pour récupérer un à un les bits qui arrivent sur la liaison série puis nous utilisons 4 registres à décalage : 1 pour chaque couleur.<br />
Pour chacun des registres nous aurons donc une séquence comme suit : 0100010010111. Les 1 correspondent aux moments ou il faut appuyer sur la couleur et les 0 aux moments ou il ne faut pas appuyer sur cette couleur. <br />
Nous devons donc également gérer les clocks des registres "couleurs". Ces registres doivent arrêter leur clock lorsque les bits de chaque couleur est à 0.<br />
<br />
Le registre pour la liaison série sera la clock du système puisqu'elle doit lire toute la séquence mais elle doit également s'arrêter lorsque le FPGA arrive à la fin de la séquence. Pour lui indiquer la fin de la séquence nous avons choisit le mot 0000 car il y aura toujours un bouton à appuyer pour le jeu Simon.<br />
<br />
==== Partie informatique ====<br />
<br />
L'objectif ici était la découverte des technologies a utilisé pour le système. Notamment une Arduino en liaison série à un PC et un serveur Websockets codé en C.<br />
La partie programmation arduino ne fut pas un problème. En effet, ce n'était pas la première fois que nous utilisions cet outil, et donc la mise en place de la liaison série fut très rapide.<br />
Ce n'est cependant pas le cas de la communication websockets. Bien que l'exemple de code fourni par M. Redon soit fonctionnel, le code n'en reste pas moins complexe à comprendre. Il fallait donc réussir à modifier le code du serveur websockets, afin de relier les deux systèmes entre eux.<br />
<br />
==== Partie mécanique : un modèle de guitare à découper====<br />
<br />
<br />
Dans cette première séance, nous avons décidé de focaliser nos premiers efforts sur la''' partie mécanique''' du '''"guitar hero"'''. En effet, le '''« jeu de simon »''' pouvait être avancé '''plus tard''' car plus''' facile''' à '''modéliser''' et à''' réaliser.'''[[Fichier:1.jpg||right|vignette|upright=2|]]<br />
Nous sommes alors partis sur l'idée de créer une''' maquette de guitare''', sur laquelle nous allions '''disposer''' différents '''boutons de couleur''', '''actionnables''' grâce à une '''pression''' sur le manche de l'instrument. Nous avions une '''ligne directrice''' mais pas encore d''''idée précise''' de comment allait être réalisé la guitare, ni même '''ce à quoi elle allait ressembler'''.<br />
<br />
<br />
Nous avons décidé de découper la '''guitare en bois''' qui nous servirait de support pour notre '''« guitar hero »''' grâce à la''' découpeuse laser'''. Pour se faire, un '''fichier conforme à la découpe''' devait être réalisé. <br />
Ainsi nous avons donc pris une '''image de guitare''' depuis '''internet'''. Dans le logiciel''' « GIMP »''', nous avons ensuite '''repassé les contours de l'instrument en rouge'''. Une fois ceci fait, nous avons''' effacé l'image de la guitare originale '''pour ne''' garder que les contours rouges'''. Enfin après '''quelques réglages''', l''''export en fichier SVG '''permettait une '''découpe précise'''. Les contours de la guitare sont disponibles ci contre (cliquez sur l'image pour bien voir).<br />
<br />
A la '''fin de la séance''', la '''guitare''' était''' prête à être réalisée '''et nous avons décidé de faire l'intégralité du''' « jeu de simon »''' via '''l'impression 3D'''. Cependant, aucune grande avancée n'a eu lieu sur la partie mécanique du jeu de Simon lors de cette séance.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 28/03/17 Séance 2 : Poursuite du Projet et rencontre des premiers problèmes </div>===<br />
<br />
La '''deuxième séance''' fut davantage '''productive''', car chacun de nous savait les différentes '''tâches''' qu'il lui '''restait à accomplir'''.<br />
<br />
==== Partie électronique ====<br />
Nous nous sommes rendu compte qu'utiliser le registre à décalage pour la liaison série comme nous le faisions n'était pas possible.<br />
En effet, la liaison série est en asynchrone et nous ne connaissance donc pas la clock. <br />
Nous ne pouvons donc pas utiliser cette clock pour le registre à décalage car sinon nous risquons de ne pas lire assez vite (ou trop vite) et donc récupérer trop de valeurs ou en rater.<br />
<br />
Le professeur nous a donc indiquer qu'il nous mettrai à disposition un module qui va s'occuper justement de lire la liaison série et de garder la séquence et de ressortir le message en parallèle.<br />
Ce composant envoie également sur un autre pin un 1 à chaque fois qu'un bit est envoyé par la liaison série (et reçu par le composant).<br />
Nous utilisons, selon ces conseils, un module analogique-digital qui va nous permettre de simuler l'envoie de la séquence.<br />
Après plusieurs tentative nous avons un programme qui fonctionne correctement pour recevoir les valeurs. Il nous reste à comparer l'appuie d'un bouton et la couleur à presser.<br />
<br />
==== Partie informatique ====<br />
<br />
L'écriture du programme de communication fut terminé assez rapidement. Mais il ne fonctionnait pas...<br />
En effet, un problème s'opérait lors de l'appel de la liaison série par le serveur websocket à réception d'un message.<br />
<br />
L'incompréhension régnait un peu, car à nos yeux tout était sensé fonctionner. Le principe était assez simple : à reception d'un message par le serveur websockets, ce dernier devait ouvrir une communication série sur le port TTY_USB0 (ou TTY_ACM0 en fonction de l'arduino) à 9600 bauds, y transférer le message reçu, puis refermer la communication.<br />
<br />
Après un long moment de doute, le problème fut résolu. Ce dernier était assez idiot. En effet, notre fonction d'envoie de message via le port série s'appelait : " send(..) ". Il s'avère qu'une fonction d'une des librairies utilisées se nomme de la même manière. Il y avait donc conflit et empêchait le programme de fonctionner correctement.<br />
<br />
Nous avons donc pu relier l'ordinateur à un montage de prototypage Arduino/LEDs afin de tester le bon fonctionnement du programme. Une combinaison de 4 LED devait s'allumer à réception d'un caractère. Il fallait donc envoyé un message compris entre 0(aucune LED allumée) et 15(toutes les LED allumées). Cependant, le début de la table ASCII ne représente pas des caractères. Le serveur envoie donc un message alphabétique compris entre 65 ('A') et 80 ('P') et l'arduino interprète ceci comme une valeur de 0 a 15<br />
<br />
==== Partie mécanique : découpe de la guitare, modélisation et impression d'un prototype de touches pour cette dernière ====<br />
<br />
[[Fichier:pp.jpg||left|vignette|upright=0.8|]]Cette séance fut entamée par la '''découpe de la guitare''' grâce à la '''découpeuse laser''' du '''Fabricarium de Polytech'''. Dans un premier temps il a d'abord était nécessaire '''« d'apprivoiser »''' la '''découpeuse''' et d''''apprendre à bien la configurer''' pour obtenir le résultat souhaité, sans risques. Un '''premier essai''' a d'abord était réalisé dans du '''carton''' pour pouvoir '''juger des différentes dimensions''' de la guitare.<br />
Enfin, une '''seconde version''', en''' bois''', fut réalisée durant cette séance. Finalement nous décidons de partir sur l'idée d'une '''guitare réalisée en 4 couches d'épaisseur''' : '''2 extérieures en bois''' ( une de '''face''', '''décorée''' avec les '''boutons à actionner''' et la carte '''arduino''' et une '''seconde''', '''arrière''', de '''protection'''), et '''deux intérieures en carton'''('''creusées''' pour laisser passer les '''fils de connectiques''').<br />
<br />
'''Note''' : Malheureusement, une des '''couche en bois''' a était '''cassée''' par la suite lors de la confection de la guitare. La''' panne prolongée''' de la '''découpeuse laser''' nous a contraint à '''renoncer à l'idée d'une quatrième couche en bois''' de protection.[[Fichier:po.jpg||right|vignette|upright=1.2|]]<br />
<br />
<br />
De plus, via le '''logiciel de modélisation FreeCAD''', nous avons commencé à concevoir deux '''prototypes''' de '''« touches »''' (boutons) pour la guitare. <br />
<br />
L'idée était de créer des '''surfaces larges''' (pouvant recueillir '''une phalange de doigts au minimum''') faisant office de '''touches''', en dessous desquelles nous '''insérerions''' un '''bouton poussoir''' 4 pins (fournis par les professeurs). La '''création de touches plus larges''' était '''indispensable'''. En effet, les '''boutons poussoirs''' étaient bien '''trop petits''' pour avoir un '''actionnement facile et agréable'''.<br />
Nous avons pu lancer l''''impression des touches''' à la''' fin de la séance'''. Cependant, les différents '''tests '''et les''' défauts d'impression''' nous ont fait comprendre qu'il serait''' difficile de « glisser » un bouton poussoir '''dans une '''touche '''avec un '''espace '''assez''' étroit '''pour le maintenir, sans pour autant '''bloquer son actionnement''' lorsqu'une '''pression''' était appliquée. De plus, la''' fixation''' risquait d'être assez '''complexe'''. <br />
Nous avons alors décidé de faire un tout '''autre type de touche''' mais avec le '''même fonctionnement'''. Pour cela nous allions avoir besoin de''' modéliser et d'imprimer '''de nouveaux un '''prototype de touche'''.<br />
Il allait ensuite falloir''' percer la première couche en bois de la guitare'''. Puis il serait également nécessaire de '''creuser les sous couches''' en carton pour y placer les boutons poussoirs et les différents câbles.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 05/04/2017 Séance 3 : Encore beaucoup de choses à faire !</div>===<br />
<br />
Bien que ce soit notre '''dernière séance officielle''', nous savions que nous allions avoir '''besoin''' de '''beaucoup de temps''' pour''' terminer ce projet '''! <br />
<br />
==== Partie électronique ====<br />
Au final notre FPGA n'est pas fonctionnel, suite à des tests en utilisant le port série, nous avons intégré les circuits reception.vhdl et emission.vhdl fournis par M. Boé. Mais le résultat n'est pas au rendez vous.<br />
<br />
[[Fichier:fpga.png|||vignette|upright=2|]]<br />
<br />
==== Partie informatique ====<br />
<br />
<br />
L'objectif de la séance était la mise en place de l'interface WEB, notamment pour le jeu Guitar Hero. <br />
<br />
Nous avons utilisé un canvas Javascript afin de dessiner un interface similaire a celle du jeu original.<br />
<br />
==== Partie mécanique ====<br />
<br />
La troisième séance était destinée à '''l’élaboration du jeu de Simon'''. Une première idée était de '''créer quatre pièces plates''', composées de''' multiples leds''', qu'il faudrait''' actionner''' via une simple''' pression'''. Cependant, nous nous sommes dit '''qu'une seule LED pour une couleur''', suffisait à '''indiquer''' la '''combinaison''' à reproduire. <br />
<br />
Le tout devait être assez '''grand''' pour '''contenir la carte arduino''' ainsi que toute la '''connectique''', '''sans''' pour autant '''être''' trop '''encombrant''', tout en étant assez '''ergonomique''' et '''agréable au regard'''.<br />
<br />
Nous avons donc décidé de '''créer un support creux ''' qui '''contiendrait la partie électronique ''', au dessus duquel nous placerions '''les 4 pièces de couleur''' avec '''une LED pour chaque couleur'''.<br />
<br />
Nous savions dès lors, qu'un '''travail long minutieux''' nous attendait.<br />
<br />
Ainsi nous avons fait de '''nombreux croquis''' avec les '''différentes pièces''' et leurs '''dimensions éventuelles'''. Des pièces que nous allions réaliser uniquement en '''impression 3D'''. Un '''travail similaire''' a été réalisé pour '''la guitare''', afin de ne pas '''percer la guitare à de mauvais endroits''', et pour '''agencé les différents parties''' à ajouter sur la guitare de la '''meilleure façon possible'''. Pour '''résumer''' cette séance, nous avons '''réalisé tous les croquis nécessaires à la réalisation''' de la '''guitare''' et du '''Simon'''.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Séance supplémentaire : Terminons ce Projet !</div>===<br />
<br />
Il n'y a pas eu un '''nombre précis de "séances supplémentaires".''' '''Chacun''' des membres du groupe travaillait '''soit chez lui''', '''soit à l'école''' de '''manière régulière''', afin '''d'avancer sa partie''' le plus '''rapidement''' possible.<br />
<br />
==== Partie électronique ====<br />
<br />
Pour le Simon, il a fallut souder les câbles aux boutons et aux leds ( avec leur résistance ). Pour se faire, on a utilisé un circuit à pastilles qui se place entre l'arduino et les boutons/led. Cela permet de prendre moins de place et de faire plus propre qu'une breadboard.<br />
[[Fichier:pcb1.jpg|left|vignette|upright=0.8|]]<br />
[[Fichier:pcb2.jpg|right|vignette|upright=0.8|]]<br />
<br />
=== Partie informatique ===<br />
<br />
La partie FPGA n'étant pas fonctionelle, il a fallut le remplacer par un Arduino. <br />
<br />
Le code de l'Arduino consiste en une succession d'étapes pour jouer. Tout d'abord il faut recevoir via le port série la séquence totale du Simon, sous la forme de chaîne de caractères. Par exemple si le message reçu est "RVBR", alors la séquence totale du Simon sera Rouge Vert Bleu Rouge. Ainsi une fonction reception_message a été codée, qui attend la réception série de la séquence. <br />
<br />
Dans l'algorithme du jeu en lui même on a une variable globale qui stocke l'état de la partie, et une qui stocke l'étape de la séquence. Ainsi en fonction de l'état de la partie on va soit jouer la séquence sur les leds, lire l'état des boutons, ou provoquer un game over.<br />
<br />
La fonction playSequence va parcourir la séquence totale jusqu'à l'étape actuelle et va allumer les différentes leds en conséquence.<br />
<br />
La fonction readSequence va elle lire l'état successif des boutons et le comparer à la séquence actuelle. Si il y a une erreur, on sort de la fonction, et l'état de la partie devient un game over. Sinon, on continue et on appelle playSequence en incrémentant l'étape. En cas de réussite de la séquence, les 4 leds s'allument pour indiquer lé réussite et le passage au niveau supérieur.<br />
<br />
Coté websockets, c'est facile, dès qu'on reçoit un message par le client, on l'envoie à l'arduino ( bien qu'on aurait du vérifier la conformité du message ), l'arduino ne lira le message que si on est en étape de lecture de la séquence, donc après un game over par exemple. <br />
<br />
==== Partie mécanique : Suite et fin de la confection de la guitare et du jeu de Simon====<br />
<br />
Comme nous l'avons prédit, la plus '''grosse partie du travail''' réalisé a dû être faite lors de '''séances supplémentaires''' ou par '''travail personnel chez soi'''.<br />
<br />
Après avoir réalisé '''les croquis''', il était essentiel de '''créer rapidement les différents supports'''. En effet, cela nous permettait d'avoir du '''temps''' pour éventuellement''' recommencer et revoir les axes de travail en cas d'impossibilité de réalisation''' pour quelconque raison. De plus, une fois la''' partie mécanique terminée''', nous pouvions l''''utiliser''' comme '''support '''pour les '''tests électroniques'''. Enfin, cela nous laissait du temps en fin de projet pour '''décorer notre projet''', que nous voulions '''personnalisé''' afin d'en être '''le plus satisfaits possible'''. <br />
<br />
Un''' gros travail de modélisation''' à dû être fait sur '''FREECAD'''. Le '''support''' du jeu de Simon fut la pièce la plus '''simple '''à réaliser (un '''cylindre''' semi fermé, de '''7 cm de rayon''').<br />
<br />
Puis une simple''' découpe '''grâce à une '''scie''' permettrait de faire''' réceptacle''' pour une''' "croix porteuse" '''sur laquelle serait disposés les '''touches du Simon'''.<br />
<br />
De la même façon que pour la guitare, '''les touches''' seraient placées '''au dessus de boutons poussoirs'''. Ces derniers seront '''collés sur la croix'''. <br />
[[Fichier:tg.jpg||right|vignette|upright=1.5|]]<br />
Une fois ceci fait, il fallait '''réaliser le plus important du jeu''' : '''les touches à actionner '''! <br />
<br />
Pour cela, il était préférable de conserver la '''forme cylindrique '''du support en modélisant '''4 pièces''', d'un '''quart de disque''' chacune. Par soucis de '''fixation '''sur la croix et par envie d’'''esthétisme''', les touches seraient un peu '''incurvées''' pour donner une forme '''moins géométrique''' au rendu final. <br />
<br />
De plus, elles seront''' perforées''' pour laisser passer une '''LED''' de la même couleur que la touche sur laquelle elle se trouve. Ainsi l'utilisateur pourra '''mémoriser les touches à activer''' via le système '''lumineux''' des '''LEDs'''. <br />
<br />
Enfin, un '''cylindre permettant l'accroche''' sur la croix à été prévu sur la '''partie inférieure''' de les''' touches du Simon'''. (suite à une impression peu précise, '''ce cylindre sera « fondu »''' pour épouser la forme de la croix '''sans jeu dans la fixation'''.)<br />
<br />
[[Fichier:touc2.jpg||left|vignette|upright=1.7|]]<br />
Vint ensuite le''' moment de la création''' ! '''L'impression de ces pièces''' étant la plus '''complexe''', nous pensions qu'il serait nécessaire de les recommencer plusieurs fois. La '''WitBox du Fabricarium''' (la plus précise des imprimantes mise à notre disposition) a réalisé une '''impression assez laborieuse'''. Un gros travail de '''ponçage''' à donc dû être réalisé, car le support nécessaire pour imprimer cette pièce « incurvée » avait donné de '''nombreuses bavures''' sur la '''surface des touches'''. Afin que le '''toucher''' reste '''agréable''', nous avons donc '''retravaillé les pièces'''.<br />
<br />
<br />
Une fois ceci fait, nous avons '''essayé de les positionner''' sur la''' croix''' prévue à cet effet. Une fois encore, nous étions '''confronté aux limites de l'impression 3D'''. Les '''dimensions du « cylindre pillier » '''étant non précise, et cette partie étant''' trop fine pour être sciée''' '''sans rupture''' de la pièce, nous avons décidé de faire '''« fondre » '''cette partie et de la placer, encore chaude sur la partie en forme de croix. Cela permettait une''' fixation sûre''' et une '''dimension épousant parfaitement les formes du support'''. L'inconvénient fut que cette''' méthode, peu précise''', n'a fait qu''''accentuer les erreurs d'impressions''' au niveaux du '''visuel'''. Effectivement, les 4 pièces ne '''semblent pas régulières''' et le '''disque''' qu'elles sont censées former (ensemble de 4 quarts de disque) ne semble '''pas parfait'''.[[Fichier:bttt.jpg||right|vignette|upright=1.5|]][[Fichier:socle.jpg||right|vignette|upright=1.5|]]<br />
<br />
<br />
Nous décidons cependant de '''conserver ce léger défaut''', car si nous recommencions nous risquerions d'être de nouveau''' confronté au même souci''', l''''erreur''' n'étant pas uniquement dû à notre '''manipulation''' mais également à l''''imprimante 3D'''. <br />
<br />
<br />
L'impression du '''socle''' était la plus''' longue à imprimer''' (près de 6 heures) .Après l'avoir un peu '''scié''' comme prévu, cette pièce était également''' prête à être peinte'''. Nous avons fait de même avec la '''croix '''à placer sur le socle et servant de '''support''' aux '''quatre touches''' du Simon. Cette impression étant '''rapide et facile''', un seul essai suffit pour obtenir notre '''version définitive'''. L'impression fut dans ce cas, parfaitement aux '''mesures souhaitées''' dans le fichier .stl (bien que réalisé avec une imprimante de moins bonne qualité que la WitBox). Ainsi les '''boutons poussoirs '''que nous avions à positionner dessus tenaient sans souci '''par un simple encastrement'''. Par la suite, par '''mesure de sécurité''', <br />
nous avons tout de même rajouté un '''point de colle''' en dessous des''' boutons ''' pour éviter tout '''désencastrement non souhaité'''. <br />
[[Fichier:tr.jpg||left|vignette|upright=1.4|]]<br />
<br />
<br />
<br />
En parallèle, nous avons travaillé sur les '''différentes couches d'épaisseur''' de la ''' guitare'''. Dans un premier temps il était nécessaire de '''retirer une partie dans le manche''' pour y placer les boutons poussoirs. Cette étape aurait pu être réalisé rapidement avec la '''découpeuse laser''', mais celle ci étant '''en panne''', nous l'avons fait via '''une perceuse et un foret au Fabricarium'''. Le résultat était un '''peu moins net''' mais '''convenable cependant'''. De plus le '''"trou"''' sera '''caché''' par la pièce contenant '''les touches'''. Une fois la couche de bois travaillée, nous avons '''creusé '''la''' partie cartonnée''' afin de pouvoir y laisser passer les différents '''câbles '''liant les''' boutons poussoirs''' (situés sous les touches du manche de la guitare) à une '''breadboard''' (sur la partie basse de l'instrument).<br />
<br />
Afin que les '''câbles sortent de la guitare de façon propre''', nous avons percé '''4 trous à la base du manche'''. Ainsi de chaque''' trou''' ressortira '''deux fils de connectique''' ( un pour l'entrée du bouton poussoir et un pour la sortie).<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:tt.jpg||left|vignette|upright=2|]]<br />
Ceci étant terminé, il fallait passer à la '''conception des touches de la guitare'''.[[Fichier:touc.jpg||right|vignette|upright=2.2|]]<br />
C'est en '''observant''' une imprimante 3D du Fabricarium qu''''une idée de modèle touche vue le jour'''. Nous allions faire '''une seule et unique pièces''' pour les''' 4 touches'''.<br />
'''Fine''', elle pourrait être facilement '''pliée''' sous une '''pression du doigts''' pour '''actionner un bouton poussoir''' situé en '''dessous''' de chacune des 4 touches.suffirait juste de '''peindre les 4 touches de couleurs différentes''' pour les différencier.<br />
Cette pièce serait '''fixée sur le manche de la guitare''', couvrant une''' couche de bois perforée''' et une '''cartonnée « creusée »''' pour '''laisser passer la connectique '''jusqu'à la partie inférieure de la guitare.<br />
<br />
Finalement, il aura fallut '''quelques heures supplémentaires''' des séances pour avoir '''toutes nos partie modéliser sur FREECAD ''' et '''prête à être imprimées''', qu'elles soient destinées au '''Simon''' ou au '''Guitar Hero'''.<br />
<br />
L'heure est donc à la '''réalisation''' ! Les '''impressions 3D '''se sont faites sur l'imprimante d''''un des membre du groupe''' ainsi que sur celles du''' Fabricarium'''. <br />
<br />
Les''' touches''' qui actionneraient les boutons poussoirs étaient les plus à même d'être à''' recommencer'''. En effet, un '''problème de fixation''', ou encore une '''rigidité trop grande''' '''empêcherait''' l'actionnement du '''bouton '''et serait donc '''inutilisable'''. Ainsi nous avons '''commencé par imprimer les touches''' (pour la guitare et pour le simon). Dans un premier temps, nous nous sommes occupés de la pièce '''pour la guitare'''. La première '''impression '''fut''' décevante''', car''' trop épaisse '''(8mm) , la pièce''' ne pliait pas''' sous la pression des doigts et n’'''actionnait donc pas les boutons''' placés dessous.<br />
<br />
Ce pourquoi nous avons lancé immédiatement une '''nouvelle impression''' avec 3mm d'épaisseur. Les '''tests étant concluants''', nous n'avions plus qu'à la''' peindre''' de '''4 couleurs différentes '''pour symboliser les 4 touches du guitar hero. <br />
<br />
<br />
Ceci commença par la réalisation de '''soudures''' des '''boutons poussoirs''' avec les '''fils'''. Ces fils seraient ensuite placés '''sous '''la couche de '''bois''', '''dans''' la couche de '''carton'''. Cette étape fut '''rapidement terminée'''.<br />
<br />
Les '''8 boutons poussoirs étaient prêts '''! '''Quatre''' pour la''' guitare''',''' quatre '''pour le jeu de '''Simon'''.<br />
<br />
Finalement,''' toutes les pièces étant réalisées''', il fallait réaliser''' un travail d'assemblage''', et de '''finitions ''' (au niveaux des couches de peinture notamment). <br />
<br />
Nous nous sommes préalablement''' assuré '''que tous les '''boutons poussoirs étaient fonctionnels '''et que les''' soudures '''étaient '''correctement réalisées''' grâce à des''' tests rapides''' avec la '''carte arduino.'''<br />
<br />
<br />
[[Fichier:led.jpg||left|vignette|upright=1.2|]][[Fichier:end.jpg||RIGHT|vignette|upright=1.3|]]<br />
Enfin, il ne restait plus qu'à '''peindre''' nos différentes''' pièces'''.<br />
<br />
Premièrement nous avons '''appliqué deux couches de blanc''' sur '''chacune des pièces'''. Puis sur celles qui nécessitaient une '''couleur précise''' ( en autre : les touches de la guitare et du Simon), nous avons repassé '''deux couches''' de '''couleur''' dessus.<br />
Puis, nous avons '''assemblé toutes les pièces''' entre elles pour '''obtenir le résultat final''' ! <br />
<br />
L''''assemblage''' des différentes '''couches de la guitare''' à d'abord était '''provisoirement fait '''avec de la '''colle forte'''. Si le collage venait à '''céder''', nous utiliserons sans doute des''' vis '''ou des '''accroches '''en plastique pour maintenir le tout en place.<br />
<br />
Nous en avons profité pour utiliser la peinture restantes pour décorer un peu notre guitare et ainsi la personnaliser comme bon nous semblait.<br />
<br />
<br />
<br />
<br />
<br />
Finalement, le''' résultat''' est plus que '''satisfaisant '''! Les quatre '''couleurs primaires''' étant '''vives''', elles donnent un aspect '''coloré''' et '''joyeux''' à notre '''projet''' ! Les quatre '''touches du Simon''', '''surmontées''' d'une '''LED''' de la même couleur que la touche, permettent une '''utilisation claire et facile '''du « jeu de Simon ».<br />
<br />
<br />
Dans la '''globalité''', nous sommes assez '''fiers''' du résultat de la '''partie mécanique''' ! Que ce soit du ''' "jeu de Simon" '''ou de la '''Guitare''' du '''"Guitar Héro"''', les '''boutons poussoirs''' sont''' activables facilement '''(voir la vidéo de démonstration en cliquant sur le lien suivant :[https://youtu.be/3-p--BhHGr4] ). De plus le''' résultat est assez agréable''' à '''regarder''' ou encore '''facile a prendre en main'''. <br />
<br />
<br />
<br />
La '''partie mécanique '''étant bien '''avancée''' avant la fin du projet, nous avons décidé de''' procéder à certaines améliorations'''. En effet, les tests des parties électronique et informatique pouvaient donc s’effectuer sur le Simon et la guitare ainsi réalisée. Ainsi dans tous les cas nous avions '''deux prototypes''' à présenter à la fin du projet.<br />
<br />
En parallèle,''' une version plus élaborée''' de la guitare pouvait ainsi être en '''construction'''.<br />
Pour se faire, nous avons repris le fichier SVG explicité lors de la première séance et nous lui avons rajouté un rectangle rouge au niveau du manche, pour une '''découpe plus propre''' à la découpeuse laser, et '''moins fragilisante''' pour le bois.<br />
<br />
[[Fichier:entretoise.jpg||right|vignette|upright=1.5|]]<br />
[[Fichier:cote.jpg||left|vignette|upright=1.5|]]<br />
<br />
<br />
De plus pour gagner en '''propreté''', nous avons placé un PCB pour éviter l’encombrement.<br />
Enfin, nous avons pris la décision de laisser la''' guitare creuse''', afin de pouvoir '''mieux voir le contenu électronique''' à l’intérieur et de garder un '''aspect plus propre et épuré''' de la guitare.<br />
<br />
Pour ce faire, nous allons utiliser des '''entretoises''' qui permettront une largeur de guitare homogène. Afin d’éviter une pliure du bois au niveau des touches (et ainsi éviter que les touches ne soient pas actionnées car pas d’opposition de force), nous avons insisté sur les''' entretoises au-dessous des touches '''(que nous avons pris soin de fixer avec de la colle pour éviter de fragiliser le bois au niveau du manche en le perçant).<br />
<br />
Finalement, les '''touches sont activables facilement''', une fois la guitare prise en main. Un signal logique bas est bien transmis une fois les '''touches appuyées'''. Et il est '''bien détecté''' par''' l’arduino'''. <br />
<br />
[[Fichier:guitaredroite.jpg||center|vignette|upright=2|]]<br />
<br />
<br />
<br />
Désormais, la '''partie mécanique '''étant''' terminée et fonctionnelle''', il faut la '''lier à la partie informatique et électronique'''. Nous allons '''perfectionner la partie FPGA''' et''' Arduino '''pour''' exploiter''' pleinement les '''deux supports '''(guitare et jeu de Simon) ainsi réalisés.<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Conclusion </div>==<br />
<br />
<br />
En conclusion, Le '''jeu de Simon''' est '''terminé''' et est '''fonctionnel''. En effet le '''serveur websocket''' envoie une '''combinaison''' de couleur, composée par un utilisateur, à '''l’arduino''', qu’un second utilisateur devra tenter de '''reproduire''' (couleur par couleur, en reprenant du début à chaque fois, avec une couleur en plus à chaque tour). Le '''Jeu de Simon est terminé ''': '''L’objectif principal''' de notre projet est donc '''réalisé'''.<br />
<br />
Cependant, le '''Guitar Héro''' n’a pas pu être abouti. Nous avions précisé dès le début du projet que nous tâcherions de '''finir le Simon en priorité''' et de faire le Guitare Héro ensuite. La '''guitare est finalisée''' et '''fonctionnelle'''. Nous n’étions donc pas si loin de terminer les deux projets. <br />
Nous sommes globalement '''satisfaits''' du '''travail réalisé''' et de la''' prestation proposée'''. En effet en sachant que nous avions deux projets en simultané (bien que très ressemblant entre eux) nous avons su '''terminer le premier''' et '''bien avancer sur le second'''. Le '''but principal''' était de '''nous amuser''', de '''prendre du plaisir dans la réalisation d'un projet''' et de '''faire quelque chose qui nous plaisait avant tout''', '''l’objectif''' est '''atteint'''.<br />
Le FPGA n'a pas pu être aboutit non plus, et c'est dommage, car c'est une technologie intéressante, et c'est plus optimisé et rapide qu'une Arduino. <br />
<br />
Ce projet fut très '''intéressant''' car il nous a permis de '''mettre en application''' certains de nos '''cours étudiés''' cette année en IMA3, mais également d’en '''apprendre''' énormément '''par nous même''' à force de '''pratique '''et de''' recherches personnelles'''. Pour l’ensemble des membres du groupe, ce projet a été la confirmation de '''l’intérêt '''porté aux '''systèmes communiquants''', et nous a donc '''convaincu de choisir''' la '''filière SC''' à partir du semestre 8 en '''IMA4'''.<br />
<br />
<br />
La démonstration du fonctionnement du Jeu de Simon, est disponible à l'adresse suivante : https://youtu.be/RbgPtALDmFw .</div>Adurothttps://wiki-ima.plil.fr/mediawiki//index.php?title=Projet_IMA3_P3,_2016/2017,_TD1&diff=44293Projet IMA3 P3, 2016/2017, TD12017-06-18T20:03:45Z<p>Adurot : </p>
<hr />
<div>=<div class="mcwiki-header" style="border-radius: 25px; padding: 20px; font-weight: bold; text-align: center; font-size: 98%; background: #6060FF; vertical-align: top; width: 99%;"> Projet IMA3-SC 2016/2017 : Le Jeu de Simon et le Guitar Hero </div>=<br />
<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Cahier des Charges </div>==<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Description du système </div>===<br />
<br />
* L'objectif principal de notre projet est de réaliser un '''jeu''' qui utilise à la fois les '''lumières''' et le '''son'''. Pour cela, nous avons pensé à deux versions : '''le Simon''' et un jeu du type '''Guitar Hero'''.<br />
<br />
* Le '''Simon''' est constitué de '''quatre boutons de couleurs différentes''' : un bleu, un rouge, un vert et un jaune. Le jeu va '''afficher''' une séquence de couleurs qui sont chacune '''associées à un son'''. Le joueur doit ensuite se '''souvenir''' de la suite (en s'aidant du son et des couleurs comme moyen mnémotechnique) pour la '''reproduire''' dans le '''bon ordre''' en '''appuyant sur les boutons'''.<br />
<br />
* Le jeu '''Guitar Hero''', quant à lui, est un jeu où il faut '''actionner des boutons de couleur précise''', '''au moment où elles apparaissent''' sur une barre de défilement, '''à l'écran'''. Ces différentes '''activations''', aux '''bons moments''', permettent de '''réaliser une mélodie''' plus ou moins complexe selon la difficulté de la chanson à reproduire. Le tout est effectué grâce à '''une guitare connectée''', afin de pousser l'expérience de '''simulation''' un peu plus loin. Si nous réalisons, ce jeu, il faut '''prendre en compte''' un '''affichage''' plus '''complexe'''. De plus, le '''Guitar Hero''' ajoute '''une notion de temps de réponse''', plus '''difficile à gérer'''. Ce temps de réponse permet de laisser une '''courte marge d'erreur''' dans la '''réactivité de l'utilisateur''', pour '''simuler pleinement''' l'utilisation d'une '''guitare électrique'''.<br />
<br />
<br />
Nous avons choisis de d'abord nous concentrer sur le '''Simon''' et de faire le jeu '''Guitar Hero''' seulement '''si nous avons le temps'''.<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Le matériel </div>===<br />
<br />
Pour ce '''projet''' nous utiliserons :<br />
<br />
* Une '''page internet''' sur l'ordinateur pour pouvoir '''modifier les différents aspects du jeu''' : les '''règles du jeu''', la '''musique''' jouée par le Simon ou bien la '''difficulté'''<br />
<br />
* Le '''Raspberry Pi''', utilisée en tant que serveur, va envoyer les données en série ( qui seront traitées par le FPGA ), de les recupérer, et de faire l'algorithme.<br />
<br />
* Une '''carte Arduino''' pour '''relier''' la Raspberry Pi aux composants dans un premier temps : elle nous permet de '''coder en C''' (au lieu d'un langage assembleur) pour '''créer des programmes''' et '''gérer''' les différents '''modules''' tel que les '''boutons''' et les '''LEDs'''. Elle permettra une '''simulation''' momentanée du '''FPGA''', afin que nous puissions avancer sur la partie informatique, sans attendre d'en avoir fini avec la partie FPGA.<br />
<br />
* Une fois le programme et les interactions fonctionnels, nous '''remplacerons''' l'Arduino par une '''FPGA''' qui est '''circuit logique programmable''' : on peut '''modifier les circuits logiques''' à l'intérieur mais '''on ne peut pas créer un programme''' avec un '''langage''' de plus '''haut niveau'''. Nous devrons donc utiliser des '''logiciels tiers''' qui nous permettront de placer des '''portes logiques''' (ET, OU,...) pour '''créer notre programme en assembleur'''.<br />
<br />
* Pour ce qui est de la '''partie mécanique''', nous réaliserons une '''guitare en bois''' pour le''' "Guitar Hero"''' ainsi qu'un''' "jeu de Simon"''' réalisé via l''''impression 3D.'''<br />
<br />
* Si le temps nous le permet, nous utiliserons un '''Xbee''' pour créer une '''connexion sans fil''', afin '''d'expérimenter''' un '''module nouveau''' et '''acquérir''' de '''nouvelles compétences'''.<br />
<br />
*Nous utiliserons également des '''composants électroniques''' tels que des '''boutons poussoirs''', des '''LEDs''' ou une '''matrice de LEDs''' pour l'affichage dans le cas du jeu de Simon, ainsi que de '''"l'essentiel"''' pour un '''système communiquant''' (à savoir '''résistances''', '''fils électriques''', etc...)<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Description des séances </div>==<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 21/03/17 Séance 1 : Répartition des tâches et premiers pas </div>===<br />
<br />
La première séance fut''' consacrée à la répartition des rôles''' et à la '''prise de conscience '''de la '''difficulté des différentes tâches'''. L''''idée''' de faire un '''« jeu de Simon » '''que nous''' amélioreront '''ensuite en '''« guitar hero »''' a cependant était '''conservée'''.<br />
<br />
==== Partie électronique ====<br />
<br />
Nous avons décider de concentrer deux personnes sur le FPGA car c'est un élément très complexe et complètement nouveau.<br />
Nous allons en effet devoir coder à très bas niveau avec simplement des registres et des portes logiques.<br />
<br />
L'objectif du composant sera de récupérer un message contenant les boutons sur lesquelles appuyer. <br />
Une fois ce message reçu, le FPGA va comparer le bouton saisit par l'utilisateur avec le bouton demander. <br />
S'il est correct, le fpga va passer à la couleur suivante, sinon il va renvoyer un message pour dire à la Raspberry (ou l'ordinateur) que l'utilisateur s'est trompé.<br />
<br />
Pour commencer, nous réalisons le tutoriel pour allumer une LED qui va nous permettre de comprendre le fonctionnement de Altium Designer.<br />
Cela nous a pris du temps mais nous avons pu réaliser d'autres essaies avec des registres à décalages et des boutons.<br />
<br />
Nous avons ensuite directement commencer le Simon :<br />
Le choix a été fait d'utiliser des registres à décalages pour récupérer la séquence de couleur envoyé par l'ordinateur/la raspberry. <br />
Nous allons en effet stocker toute la séquence de la "partie" car sinon il faudrait gérer beaucoup d'échange entre l'ordinateur et le FPGA ce qui est lourd en Altium et fait perdre du temps réaction du programme.<br />
<br />
D'un point de vue technique, utiliser un registre à décalage semble être la meilleur méthode pour récupérer un à un les bits qui arrivent sur la liaison série puis nous utilisons 4 registres à décalage : 1 pour chaque couleur.<br />
Pour chacun des registres nous aurons donc une séquence comme suit : 0100010010111. Les 1 correspondent aux moments ou il faut appuyer sur la couleur et les 0 aux moments ou il ne faut pas appuyer sur cette couleur. <br />
Nous devons donc également gérer les clocks des registres "couleurs". Ces registres doivent arrêter leur clock lorsque les bits de chaque couleur est à 0.<br />
<br />
Le registre pour la liaison série sera la clock du système puisqu'elle doit lire toute la séquence mais elle doit également s'arrêter lorsque le FPGA arrive à la fin de la séquence. Pour lui indiquer la fin de la séquence nous avons choisit le mot 0000 car il y aura toujours un bouton à appuyer pour le jeu Simon.<br />
<br />
==== Partie informatique ====<br />
<br />
L'objectif ici était la découverte des technologies a utilisé pour le système. Notamment une Arduino en liaison série à un PC et un serveur Websockets codé en C.<br />
La partie programmation arduino ne fut pas un problème. En effet, ce n'était pas la première fois que nous utilisions cet outil, et donc la mise en place de la liaison série fut très rapide.<br />
Ce n'est cependant pas le cas de la communication websockets. Bien que l'exemple de code fourni par M. Redon soit fonctionnel, le code n'en reste pas moins complexe à comprendre. Il fallait donc réussir à modifier le code du serveur websockets, afin de relier les deux systèmes entre eux.<br />
<br />
==== Partie mécanique : un modèle de guitare à découper====<br />
<br />
<br />
Dans cette première séance, nous avons décidé de focaliser nos premiers efforts sur la''' partie mécanique''' du '''"guitar hero"'''. En effet, le '''« jeu de simon »''' pouvait être avancé '''plus tard''' car plus''' facile''' à '''modéliser''' et à''' réaliser.'''[[Fichier:1.jpg||right|vignette|upright=2|]]<br />
Nous sommes alors partis sur l'idée de créer une''' maquette de guitare''', sur laquelle nous allions '''disposer''' différents '''boutons de couleur''', '''actionnables''' grâce à une '''pression''' sur le manche de l'instrument. Nous avions une '''ligne directrice''' mais pas encore d''''idée précise''' de comment allait être réalisé la guitare, ni même '''ce à quoi elle allait ressembler'''.<br />
<br />
<br />
Nous avons décidé de découper la '''guitare en bois''' qui nous servirait de support pour notre '''« guitar hero »''' grâce à la''' découpeuse laser'''. Pour se faire, un '''fichier conforme à la découpe''' devait être réalisé. <br />
Ainsi nous avons donc pris une '''image de guitare''' depuis '''internet'''. Dans le logiciel''' « GIMP »''', nous avons ensuite '''repassé les contours de l'instrument en rouge'''. Une fois ceci fait, nous avons''' effacé l'image de la guitare originale '''pour ne''' garder que les contours rouges'''. Enfin après '''quelques réglages''', l''''export en fichier SVG '''permettait une '''découpe précise'''. Les contours de la guitare sont disponibles ci contre (cliquez sur l'image pour bien voir).<br />
<br />
A la '''fin de la séance''', la '''guitare''' était''' prête à être réalisée '''et nous avons décidé de faire l'intégralité du''' « jeu de simon »''' via '''l'impression 3D'''. Cependant, aucune grande avancée n'a eu lieu sur la partie mécanique du jeu de Simon lors de cette séance.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 28/03/17 Séance 2 : Poursuite du Projet et rencontre des premiers problèmes </div>===<br />
<br />
La '''deuxième séance''' fut davantage '''productive''', car chacun de nous savait les différentes '''tâches''' qu'il lui '''restait à accomplir'''.<br />
<br />
==== Partie électronique ====<br />
Nous nous sommes rendu compte qu'utiliser le registre à décalage pour la liaison série comme nous le faisions n'était pas possible.<br />
En effet, la liaison série est en asynchrone et nous ne connaissance donc pas la clock. <br />
Nous ne pouvons donc pas utiliser cette clock pour le registre à décalage car sinon nous risquons de ne pas lire assez vite (ou trop vite) et donc récupérer trop de valeurs ou en rater.<br />
<br />
Le professeur nous a donc indiquer qu'il nous mettrai à disposition un module qui va s'occuper justement de lire la liaison série et de garder la séquence et de ressortir le message en parallèle.<br />
Ce composant envoie également sur un autre pin un 1 à chaque fois qu'un bit est envoyé par la liaison série (et reçu par le composant).<br />
Nous utilisons, selon ces conseils, un module analogique-digital qui va nous permettre de simuler l'envoie de la séquence.<br />
Après plusieurs tentative nous avons un programme qui fonctionne correctement pour recevoir les valeurs. Il nous reste à comparer l'appuie d'un bouton et la couleur à presser.<br />
<br />
==== Partie informatique ====<br />
<br />
L'écriture du programme de communication fut terminé assez rapidement. Mais il ne fonctionnait pas...<br />
En effet, un problème s'opérait lors de l'appel de la liaison série par le serveur websocket à réception d'un message.<br />
<br />
L'incompréhension régnait un peu, car à nos yeux tout était sensé fonctionner. Le principe était assez simple : à reception d'un message par le serveur websockets, ce dernier devait ouvrir une communication série sur le port TTY_USB0 (ou TTY_ACM0 en fonction de l'arduino) à 9600 bauds, y transférer le message reçu, puis refermer la communication.<br />
<br />
Après un long moment de doute, le problème fut résolu. Ce dernier était assez idiot. En effet, notre fonction d'envoie de message via le port série s'appelait : " send(..) ". Il s'avère qu'une fonction d'une des librairies utilisées se nomme de la même manière. Il y avait donc conflit et empêchait le programme de fonctionner correctement.<br />
<br />
Nous avons donc pu relier l'ordinateur à un montage de prototypage Arduino/LEDs afin de tester le bon fonctionnement du programme. Une combinaison de 4 LED devait s'allumer à réception d'un caractère. Il fallait donc envoyé un message compris entre 0(aucune LED allumée) et 15(toutes les LED allumées). Cependant, le début de la table ASCII ne représente pas des caractères. Le serveur envoie donc un message alphabétique compris entre 65 ('A') et 80 ('P') et l'arduino interprète ceci comme une valeur de 0 a 15<br />
<br />
==== Partie mécanique : découpe de la guitare, modélisation et impression d'un prototype de touches pour cette dernière ====<br />
<br />
[[Fichier:pp.jpg||left|vignette|upright=0.8|]]Cette séance fut entamée par la '''découpe de la guitare''' grâce à la '''découpeuse laser''' du '''Fabricarium de Polytech'''. Dans un premier temps il a d'abord était nécessaire '''« d'apprivoiser »''' la '''découpeuse''' et d''''apprendre à bien la configurer''' pour obtenir le résultat souhaité, sans risques. Un '''premier essai''' a d'abord était réalisé dans du '''carton''' pour pouvoir '''juger des différentes dimensions''' de la guitare.<br />
Enfin, une '''seconde version''', en''' bois''', fut réalisée durant cette séance. Finalement nous décidons de partir sur l'idée d'une '''guitare réalisée en 4 couches d'épaisseur''' : '''2 extérieures en bois''' ( une de '''face''', '''décorée''' avec les '''boutons à actionner''' et la carte '''arduino''' et une '''seconde''', '''arrière''', de '''protection'''), et '''deux intérieures en carton'''('''creusées''' pour laisser passer les '''fils de connectiques''').<br />
<br />
'''Note''' : Malheureusement, une des '''couche en bois''' a était '''cassée''' par la suite lors de la confection de la guitare. La''' panne prolongée''' de la '''découpeuse laser''' nous a contraint à '''renoncer à l'idée d'une quatrième couche en bois''' de protection.[[Fichier:po.jpg||right|vignette|upright=1.2|]]<br />
<br />
<br />
De plus, via le '''logiciel de modélisation FreeCAD''', nous avons commencé à concevoir deux '''prototypes''' de '''« touches »''' (boutons) pour la guitare. <br />
<br />
L'idée était de créer des '''surfaces larges''' (pouvant recueillir '''une phalange de doigts au minimum''') faisant office de '''touches''', en dessous desquelles nous '''insérerions''' un '''bouton poussoir''' 4 pins (fournis par les professeurs). La '''création de touches plus larges''' était '''indispensable'''. En effet, les '''boutons poussoirs''' étaient bien '''trop petits''' pour avoir un '''actionnement facile et agréable'''.<br />
Nous avons pu lancer l''''impression des touches''' à la''' fin de la séance'''. Cependant, les différents '''tests '''et les''' défauts d'impression''' nous ont fait comprendre qu'il serait''' difficile de « glisser » un bouton poussoir '''dans une '''touche '''avec un '''espace '''assez''' étroit '''pour le maintenir, sans pour autant '''bloquer son actionnement''' lorsqu'une '''pression''' était appliquée. De plus, la''' fixation''' risquait d'être assez '''complexe'''. <br />
Nous avons alors décidé de faire un tout '''autre type de touche''' mais avec le '''même fonctionnement'''. Pour cela nous allions avoir besoin de''' modéliser et d'imprimer '''de nouveaux un '''prototype de touche'''.<br />
Il allait ensuite falloir''' percer la première couche en bois de la guitare'''. Puis il serait également nécessaire de '''creuser les sous couches''' en carton pour y placer les boutons poussoirs et les différents câbles.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> 05/04/2017 Séance 3 : Encore beaucoup de choses à faire !</div>===<br />
<br />
Bien que ce soit notre '''dernière séance officielle''', nous savions que nous allions avoir '''besoin''' de '''beaucoup de temps''' pour''' terminer ce projet '''! <br />
<br />
==== Partie électronique ====<br />
Au final notre FPGA n'est pas fonctionnel, suite à des tests en utilisant le port série, nous avons intégré les circuits reception.vhdl et emission.vhdl fournis par M. Boé. Mais le résultat n'est pas au rendez vous.<br />
<br />
[[Fichier:fpga.png|||vignette|upright=2|]]<br />
<br />
==== Partie informatique ====<br />
<br />
<br />
L'objectif de la séance était la mise en place de l'interface WEB, notamment pour le jeu Guitar Hero. <br />
<br />
Nous avons utilisé un canvas Javascript afin de dessiner un interface similaire a celle du jeu original.<br />
<br />
==== Partie mécanique ====<br />
<br />
La troisième séance était destinée à '''l’élaboration du jeu de Simon'''. Une première idée était de '''créer quatre pièces plates''', composées de''' multiples leds''', qu'il faudrait''' actionner''' via une simple''' pression'''. Cependant, nous nous sommes dit '''qu'une seule LED pour une couleur''', suffisait à '''indiquer''' la '''combinaison''' à reproduire. <br />
<br />
Le tout devait être assez '''grand''' pour '''contenir la carte arduino''' ainsi que toute la '''connectique''', '''sans''' pour autant '''être''' trop '''encombrant''', tout en étant assez '''ergonomique''' et '''agréable au regard'''.<br />
<br />
Nous avons donc décidé de '''créer un support creux ''' qui '''contiendrait la partie électronique ''', au dessus duquel nous placerions '''les 4 pièces de couleur''' avec '''une LED pour chaque couleur'''.<br />
<br />
Nous savions dès lors, qu'un '''travail long minutieux''' nous attendait.<br />
<br />
Ainsi nous avons fait de '''nombreux croquis''' avec les '''différentes pièces''' et leurs '''dimensions éventuelles'''. Des pièces que nous allions réaliser uniquement en '''impression 3D'''. Un '''travail similaire''' a été réalisé pour '''la guitare''', afin de ne pas '''percer la guitare à de mauvais endroits''', et pour '''agencé les différents parties''' à ajouter sur la guitare de la '''meilleure façon possible'''. Pour '''résumer''' cette séance, nous avons '''réalisé tous les croquis nécessaires à la réalisation''' de la '''guitare''' et du '''Simon'''.<br />
<br />
<br />
<br />
===<div class="mcwiki-header" style="border-radius: 15px; padding: 10px; font-weight: bold; text-align: center; font-size: 80%; background: #BBBBFF; vertical-align: top; width: 99%;"> Séance supplémentaire : Terminons ce Projet !</div>===<br />
<br />
Il n'y a pas eu un '''nombre précis de "séances supplémentaires".''' '''Chacun''' des membres du groupe travaillait '''soit chez lui''', '''soit à l'école''' de '''manière régulière''', afin '''d'avancer sa partie''' le plus '''rapidement''' possible.<br />
<br />
==== Partie électronique ====<br />
<br />
Pour le Simon, il a fallut souder les câbles aux boutons et aux leds ( avec leur résistance ). Pour se faire, on a utilisé un circuit à pastilles qui se place entre l'arduino et les boutons/led. Cela permet de prendre moins de place et de faire plus propre qu'une breadboard.<br />
[[Fichier:pcb1.jpg|left|vignette|upright=0.8|]]<br />
[[Fichier:pcb2.jpg|right|vignette|upright=0.8|]]<br />
<br />
=== Partie informatique ===<br />
<br />
La partie FPGA n'étant pas fonctionelle, il a fallut le remplacer par un Arduino. <br />
<br />
Le code de l'Arduino consiste en une succession d'étapes pour jouer. Tout d'abord il faut recevoir via le port série la séquence totale du Simon, sous la forme de chaîne de caractères. Par exemple si le message reçu est "RVBR", alors la séquence totale du Simon sera Rouge Vert Bleu Rouge. Ainsi une fonction reception_message a été codée, qui attend la réception série de la séquence. <br />
<br />
Dans l'algorithme du jeu en lui même on a une variable globale qui stocke l'état de la partie, et une qui stocke l'étape de la séquence. Ainsi en fonction de l'état de la partie on va soit jouer la séquence sur les leds, lire l'état des boutons, ou provoquer un game over.<br />
<br />
La fonction playSequence va parcourir la séquence totale jusqu'à l'étape actuelle et va allumer les différentes leds en conséquence.<br />
<br />
La fonction readSequence va elle lire l'état successif des boutons et le comparer à la séquence actuelle. Si il y a une erreur, on sort de la fonction, et l'état de la partie devient un game over. Sinon, on continue et on appelle playSequence en incrémentant l'étape. En cas de réussite de la séquence, les 4 leds s'allument pour indiquer lé réussite et le passage au niveau supérieur.<br />
<br />
Coté websockets, c'est facile, dès qu'on reçoit un message par le client, on l'envoie à l'arduino ( bien qu'on aurait du vérifier la conformité du message ), l'arduino ne lira le message que si on est en étape de lecture de la séquence, donc après un game over par exemple. <br />
<br />
==== Partie mécanique : Suite et fin de la confection de la guitare et du jeu de Simon====<br />
<br />
Comme nous l'avons prédit, la plus '''grosse partie du travail''' réalisé a dû être faite lors de '''séances supplémentaires''' ou par '''travail personnel chez soi'''.<br />
<br />
Après avoir réalisé '''les croquis''', il était essentiel de '''créer rapidement les différents supports'''. En effet, cela nous permettait d'avoir du '''temps''' pour éventuellement''' recommencer et revoir les axes de travail en cas d'impossibilité de réalisation''' pour quelconque raison. De plus, une fois la''' partie mécanique terminée''', nous pouvions l''''utiliser''' comme '''support '''pour les '''tests électroniques'''. Enfin, cela nous laissait du temps en fin de projet pour '''décorer notre projet''', que nous voulions '''personnalisé''' afin d'en être '''le plus satisfaits possible'''. <br />
<br />
Un''' gros travail de modélisation''' à dû être fait sur '''FREECAD'''. Le '''support''' du jeu de Simon fut la pièce la plus '''simple '''à réaliser (un '''cylindre''' semi fermé, de '''7 cm de rayon''').<br />
<br />
Puis une simple''' découpe '''grâce à une '''scie''' permettrait de faire''' réceptacle''' pour une''' "croix porteuse" '''sur laquelle serait disposés les '''touches du Simon'''.<br />
<br />
De la même façon que pour la guitare, '''les touches''' seraient placées '''au dessus de boutons poussoirs'''. Ces derniers seront '''collés sur la croix'''. <br />
[[Fichier:tg.jpg||right|vignette|upright=1.5|]]<br />
Une fois ceci fait, il fallait '''réaliser le plus important du jeu''' : '''les touches à actionner '''! <br />
<br />
Pour cela, il était préférable de conserver la '''forme cylindrique '''du support en modélisant '''4 pièces''', d'un '''quart de disque''' chacune. Par soucis de '''fixation '''sur la croix et par envie d’'''esthétisme''', les touches seraient un peu '''incurvées''' pour donner une forme '''moins géométrique''' au rendu final. <br />
<br />
De plus, elles seront''' perforées''' pour laisser passer une '''LED''' de la même couleur que la touche sur laquelle elle se trouve. Ainsi l'utilisateur pourra '''mémoriser les touches à activer''' via le système '''lumineux''' des '''LEDs'''. <br />
<br />
Enfin, un '''cylindre permettant l'accroche''' sur la croix à été prévu sur la '''partie inférieure''' de les''' touches du Simon'''. (suite à une impression peu précise, '''ce cylindre sera « fondu »''' pour épouser la forme de la croix '''sans jeu dans la fixation'''.)<br />
<br />
[[Fichier:touc2.jpg||left|vignette|upright=1.7|]]<br />
Vint ensuite le''' moment de la création''' ! '''L'impression de ces pièces''' étant la plus '''complexe''', nous pensions qu'il serait nécessaire de les recommencer plusieurs fois. La '''WitBox du Fabricarium''' (la plus précise des imprimantes mise à notre disposition) a réalisé une '''impression assez laborieuse'''. Un gros travail de '''ponçage''' à donc dû être réalisé, car le support nécessaire pour imprimer cette pièce « incurvée » avait donné de '''nombreuses bavures''' sur la '''surface des touches'''. Afin que le '''toucher''' reste '''agréable''', nous avons donc '''retravaillé les pièces'''.<br />
<br />
<br />
Une fois ceci fait, nous avons '''essayé de les positionner''' sur la''' croix''' prévue à cet effet. Une fois encore, nous étions '''confronté aux limites de l'impression 3D'''. Les '''dimensions du « cylindre pillier » '''étant non précise, et cette partie étant''' trop fine pour être sciée''' '''sans rupture''' de la pièce, nous avons décidé de faire '''« fondre » '''cette partie et de la placer, encore chaude sur la partie en forme de croix. Cela permettait une''' fixation sûre''' et une '''dimension épousant parfaitement les formes du support'''. L'inconvénient fut que cette''' méthode, peu précise''', n'a fait qu''''accentuer les erreurs d'impressions''' au niveaux du '''visuel'''. Effectivement, les 4 pièces ne '''semblent pas régulières''' et le '''disque''' qu'elles sont censées former (ensemble de 4 quarts de disque) ne semble '''pas parfait'''.[[Fichier:bttt.jpg||right|vignette|upright=1.5|]][[Fichier:socle.jpg||right|vignette|upright=1.5|]]<br />
<br />
<br />
Nous décidons cependant de '''conserver ce léger défaut''', car si nous recommencions nous risquerions d'être de nouveau''' confronté au même souci''', l''''erreur''' n'étant pas uniquement dû à notre '''manipulation''' mais également à l''''imprimante 3D'''. <br />
<br />
<br />
L'impression du '''socle''' était la plus''' longue à imprimer''' (près de 6 heures) .Après l'avoir un peu '''scié''' comme prévu, cette pièce était également''' prête à être peinte'''. Nous avons fait de même avec la '''croix '''à placer sur le socle et servant de '''support''' aux '''quatre touches''' du Simon. Cette impression étant '''rapide et facile''', un seul essai suffit pour obtenir notre '''version définitive'''. L'impression fut dans ce cas, parfaitement aux '''mesures souhaitées''' dans le fichier .stl (bien que réalisé avec une imprimante de moins bonne qualité que la WitBox). Ainsi les '''boutons poussoirs '''que nous avions à positionner dessus tenaient sans souci '''par un simple encastrement'''. Par la suite, par '''mesure de sécurité''', <br />
nous avons tout de même rajouté un '''point de colle''' en dessous des''' boutons ''' pour éviter tout '''désencastrement non souhaité'''. <br />
[[Fichier:tr.jpg||left|vignette|upright=1.4|]]<br />
<br />
<br />
<br />
En parallèle, nous avons travaillé sur les '''différentes couches d'épaisseur''' de la ''' guitare'''. Dans un premier temps il était nécessaire de '''retirer une partie dans le manche''' pour y placer les boutons poussoirs. Cette étape aurait pu être réalisé rapidement avec la '''découpeuse laser''', mais celle ci étant '''en panne''', nous l'avons fait via '''une perceuse et un foret au Fabricarium'''. Le résultat était un '''peu moins net''' mais '''convenable cependant'''. De plus le '''"trou"''' sera '''caché''' par la pièce contenant '''les touches'''. Une fois la couche de bois travaillée, nous avons '''creusé '''la''' partie cartonnée''' afin de pouvoir y laisser passer les différents '''câbles '''liant les''' boutons poussoirs''' (situés sous les touches du manche de la guitare) à une '''breadboard''' (sur la partie basse de l'instrument).<br />
<br />
Afin que les '''câbles sortent de la guitare de façon propre''', nous avons percé '''4 trous à la base du manche'''. Ainsi de chaque''' trou''' ressortira '''deux fils de connectique''' ( un pour l'entrée du bouton poussoir et un pour la sortie).<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Fichier:tt.jpg||left|vignette|upright=2|]]<br />
Ceci étant terminé, il fallait passer à la '''conception des touches de la guitare'''.[[Fichier:touc.jpg||right|vignette|upright=2.2|]]<br />
C'est en '''observant''' une imprimante 3D du Fabricarium qu''''une idée de modèle touche vue le jour'''. Nous allions faire '''une seule et unique pièces''' pour les''' 4 touches'''.<br />
'''Fine''', elle pourrait être facilement '''pliée''' sous une '''pression du doigts''' pour '''actionner un bouton poussoir''' situé en '''dessous''' de chacune des 4 touches.suffirait juste de '''peindre les 4 touches de couleurs différentes''' pour les différencier.<br />
Cette pièce serait '''fixée sur le manche de la guitare''', couvrant une''' couche de bois perforée''' et une '''cartonnée « creusée »''' pour '''laisser passer la connectique '''jusqu'à la partie inférieure de la guitare.<br />
<br />
Finalement, il aura fallut '''quelques heures supplémentaires''' des séances pour avoir '''toutes nos partie modéliser sur FREECAD ''' et '''prête à être imprimées''', qu'elles soient destinées au '''Simon''' ou au '''Guitar Hero'''.<br />
<br />
L'heure est donc à la '''réalisation''' ! Les '''impressions 3D '''se sont faites sur l'imprimante d''''un des membre du groupe''' ainsi que sur celles du''' Fabricarium'''. <br />
<br />
Les''' touches''' qui actionneraient les boutons poussoirs étaient les plus à même d'être à''' recommencer'''. En effet, un '''problème de fixation''', ou encore une '''rigidité trop grande''' '''empêcherait''' l'actionnement du '''bouton '''et serait donc '''inutilisable'''. Ainsi nous avons '''commencé par imprimer les touches''' (pour la guitare et pour le simon). Dans un premier temps, nous nous sommes occupés de la pièce '''pour la guitare'''. La première '''impression '''fut''' décevante''', car''' trop épaisse '''(8mm) , la pièce''' ne pliait pas''' sous la pression des doigts et n’'''actionnait donc pas les boutons''' placés dessous.<br />
<br />
Ce pourquoi nous avons lancé immédiatement une '''nouvelle impression''' avec 3mm d'épaisseur. Les '''tests étant concluants''', nous n'avions plus qu'à la''' peindre''' de '''4 couleurs différentes '''pour symboliser les 4 touches du guitar hero. <br />
<br />
<br />
Ceci commença par la réalisation de '''soudures''' des '''boutons poussoirs''' avec les '''fils'''. Ces fils seraient ensuite placés '''sous '''la couche de '''bois''', '''dans''' la couche de '''carton'''. Cette étape fut '''rapidement terminée'''.<br />
<br />
Les '''8 boutons poussoirs étaient prêts '''! '''Quatre''' pour la''' guitare''',''' quatre '''pour le jeu de '''Simon'''.<br />
<br />
Finalement,''' toutes les pièces étant réalisées''', il fallait réaliser''' un travail d'assemblage''', et de '''finitions ''' (au niveaux des couches de peinture notamment). <br />
<br />
Nous nous sommes préalablement''' assuré '''que tous les '''boutons poussoirs étaient fonctionnels '''et que les''' soudures '''étaient '''correctement réalisées''' grâce à des''' tests rapides''' avec la '''carte arduino.'''<br />
<br />
<br />
[[Fichier:led.jpg||left|vignette|upright=1.2|]][[Fichier:end.jpg||RIGHT|vignette|upright=1.3|]]<br />
Enfin, il ne restait plus qu'à '''peindre''' nos différentes''' pièces'''.<br />
<br />
Premièrement nous avons '''appliqué deux couches de blanc''' sur '''chacune des pièces'''. Puis sur celles qui nécessitaient une '''couleur précise''' ( en autre : les touches de la guitare et du Simon), nous avons repassé '''deux couches''' de '''couleur''' dessus.<br />
Puis, nous avons '''assemblé toutes les pièces''' entre elles pour '''obtenir le résultat final''' ! <br />
<br />
L''''assemblage''' des différentes '''couches de la guitare''' à d'abord était '''provisoirement fait '''avec de la '''colle forte'''. Si le collage venait à '''céder''', nous utiliserons sans doute des''' vis '''ou des '''accroches '''en plastique pour maintenir le tout en place.<br />
<br />
Nous en avons profité pour utiliser la peinture restantes pour décorer un peu notre guitare et ainsi la personnaliser comme bon nous semblait.<br />
<br />
<br />
<br />
<br />
<br />
Finalement, le''' résultat''' est plus que '''satisfaisant '''! Les quatre '''couleurs primaires''' étant '''vives''', elles donnent un aspect '''coloré''' et '''joyeux''' à notre '''projet''' ! Les quatre '''touches du Simon''', '''surmontées''' d'une '''LED''' de la même couleur que la touche, permettent une '''utilisation claire et facile '''du « jeu de Simon ».<br />
<br />
<br />
Dans la '''globalité''', nous sommes assez '''fiers''' du résultat de la '''partie mécanique''' ! Que ce soit du ''' "jeu de Simon" '''ou de la '''Guitare''' du '''"Guitar Héro"''', les '''boutons poussoirs''' sont''' activables facilement '''(voir la vidéo de démonstration en cliquant sur le lien suivant :[https://youtu.be/3-p--BhHGr4] ). De plus le''' résultat est assez agréable''' à '''regarder''' ou encore '''facile a prendre en main'''. <br />
<br />
<br />
<br />
La '''partie mécanique '''étant bien '''avancée''' avant la fin du projet, nous avons décidé de''' procéder à certaines améliorations'''. En effet, les tests des parties électronique et informatique pouvaient donc s’effectuer sur le Simon et la guitare ainsi réalisée. Ainsi dans tous les cas nous avions '''deux prototypes''' à présenter à la fin du projet.<br />
<br />
En parallèle,''' une version plus élaborée''' de la guitare pouvait ainsi être en '''construction'''.<br />
Pour se faire, nous avons repris le fichier SVG explicité lors de la première séance et nous lui avons rajouté un rectangle rouge au niveau du manche, pour une '''découpe plus propre''' à la découpeuse laser, et '''moins fragilisante''' pour le bois.<br />
<br />
[[Fichier:entretoise.jpg||right|vignette|upright=1.5|]]<br />
[[Fichier:cote.jpg||left|vignette|upright=1.5|]]<br />
<br />
<br />
De plus pour faciliter la '''conduction du courant''' et gagner en '''propreté''', nous avons placé un '''circuit électrique''' pour éviter l’encombrement.<br />
Enfin, nous avons pris la décision de laisser la''' guitare creuse''', afin de pouvoir '''mieux voir le contenu électronique''' à l’intérieur et de garder un '''aspect plus propre et épuré''' de la guitare.<br />
<br />
Pour ce faire, nous allons utiliser des '''entretoises''' qui permettront une largeur de guitare homogène. Afin d’éviter une pliure du bois au niveau des touches (et ainsi éviter que les touches ne soient pas actionnées car pas d’opposition de force), nous avons insisté sur les''' entretoises au-dessous des touches '''(que nous avons pris soin de fixer avec de la colle pour éviter de fragiliser le bois au niveau du manche en le perçant).<br />
<br />
Finalement, les '''touches sont activables facilement''', une fois la guitare prise en main. Le '''courant''' est bien '''transmis''' une fois les '''touches appuyées'''. Et leur '''signal''' est '''bien détecté''' par''' l’arduino'''. <br />
<br />
[[Fichier:guitaredroite.jpg||center|vignette|upright=2|]]<br />
<br />
<br />
<br />
Désormais, la '''partie mécanique '''étant''' terminée et fonctionnelle''', il faut la '''lier à la partie informatique et électronique'''. Nous allons '''perfectionner la partie FPGA''' et''' Arduino '''pour''' exploiter''' pleinement les '''deux supports '''(guitare et jeu de Simon) ainsi réalisés.<br />
<br />
==<div class="mcwiki-header" style="border-radius: 20px; padding: 15px; font-weight: bold; text-align: center; font-size: 90%; background: #8888FF; vertical-align: top; width: 99%;"> Conclusion </div>==<br />
<br />
<br />
En conclusion, Le '''jeu de Simon''' est '''terminé''' et est '''fonctionnel''. En effet le '''serveur websocket''' envoie une '''combinaison''' de couleur, composée par un utilisateur, à '''l’arduino''', qu’un second utilisateur devra tenter de '''reproduire''' (couleur par couleur, en reprenant du début à chaque fois, avec une couleur en plus à chaque tour). Le '''Jeu de Simon est terminé ''': '''L’objectif principal''' de notre projet est donc '''réalisé'''.<br />
<br />
Cependant, le '''Guitar Héro''' n’a pas pu être abouti. Nous avions précisé dès le début du projet que nous tâcherions de '''finir le Simon en priorité''' et de faire le Guitare Héro ensuite. La '''guitare est finalisée''' et '''fonctionnelle'''. Nous n’étions donc pas si loin de terminer les deux projets. <br />
Nous sommes globalement '''satisfaits''' du '''travail réalisé''' et de la''' prestation proposée'''. En effet en sachant que nous avions deux projets en simultané (bien que très ressemblant entre eux) nous avons su '''terminer le premier''' et '''bien avancer sur le second'''. Le '''but principal''' était de '''nous amuser''', de '''prendre du plaisir dans la réalisation d'un projet''' et de '''faire quelque chose qui nous plaisait avant tout''', '''l’objectif''' est '''atteint'''. <br />
<br />
Ce projet fut très '''intéressant''' car il nous a permis de '''mettre en application''' certains de nos '''cours étudiés''' cette année en IMA3, mais également d’en '''apprendre''' énormément '''par nous même''' à force de '''pratique '''et de''' recherches personnelles'''. Pour l’ensemble des membres du groupe, ce projet a été la confirmation de '''l’intérêt '''porté aux '''systèmes communiquants''', et nous a donc '''convaincu de choisir''' la '''filière SC''' à partir du semestre 8 en '''IMA4'''.<br />
<br />
<br />
La démonstration du fonctionnement du Jeu de Simon, est disponible à l'adresse suivante : https://youtu.be/RbgPtALDmFw .</div>Adurot