Le serveur en livrée blanche

Dans une chorégraphie stylisée, il se déplace sur cette scène chargée. Évitant les obstacles, il se penche, distribue sourires et paroles, puis reprend sa danse incessante. Installée sur la terrasse du café, j'admire ses jambes longues et élégantes, ses bras vigoureux, et sa tenue immaculée de serveur en livrée blanche. Nos regards se croisent. Ses grands cils font ressortir ses prunelles sombres et profonde. Il s'approche de moi un sourire aux lèvres. C'est alors que la question fuse sans que je puisse me retenir : «Aimez-vous la petite reine ? ». Sa bouche s'entrouvre de surprise. Embarrassée je fixe ses yeux, ses pupilles d'un noir de jais. Prise d'un brusque vertige, j'ai l'impression de me noyer dans son regard interrogateur. Je chancelle, puis tombe pour me réveiller subitement la tête affalée sur le table.  Je jette un œil vers le parallélépipède rouge et noir qui trône sur le bureau. Quelles associations d'idées ont pu me faire rêver d'un serveur tournant à la force, des mollets, d'un homme pédalant pour maintenir le serveur à flot ? Je secoue la tête, il est temps que je me replonge dans la configuration de cet autre serveur : ryzom core.

A suivre.

Ouiiiii, un serveur, un serveur ! Hoooo qu'il a l'air beau en plus... *-*

Je regardais autours de moi mal à l'aise. Il régnait un étrange atmosphère dans cet antre au plancher noir. Le plafond et les murs étaient rouges, sans aucune  lumière naturelle pour les éclairer si ce n'étaient des bougies disséminées un peu partout.  Je repensais à la raison de ma visite en ce lieu quand une dame à l'age indéfinissable fit son apparition derrière l'autel. J'hésitais quant à la marche à suivre. Ma recherche sur internet m'avais mené en ce lieu  singulier. Lorsque j'avais expliqué mon souci avec le serveur, un vieux barbu sur un forum m'avait envoyé vers cette adresse avec une lettre de recommandation. Il m'avait expliqué  que la propriétaire était une magicienne des serveurs, capable d'asservir n'importe lequel par ses scripts diaboliques. Cela répondait à mes attentes, mais à voir le les items éparpillés dans cet antre je me demandais si nous parlions bien de la même chose. Je pris mon courage à deux mains et tendis à la dame ma liste de courses ainsi que la lettre de recommandation.

La dame se plongea dans la lecture de mon cahier de charge puis, après un moment, leva son regard scrutateur vers moi.

- « Vous voulez qu'il vous obéisse au doigt et à l'œil ? Vous êtes tombée au bon endroit. »

J'acquiesçais, enfin sur un terrain que je maîtrisais, puis elle ajouta :

- « Ah, vous voulez qu'il vous soit soumis, qu'il applique vos ordres sans questionnement ? »

Je ressentais un mal aise alors que son regard se portait soudain vers un coin sombre de la caverne. Divers items en cuir noir y était suspendus ainsi que des cordes de toutes tailles. Sans me laisser répondre elle continua son monologue en se dirigeant vers le fond de la salle :

- « Je note que vous avez besoin de câbles pour vous attacher ses services, ajouta-t-elle le sourire aux lèvres ».

- « Je me suis sans doute mal exprimée, j'ai indiqué que j'avais des soucis avec le sans fil et que j'aurais besoin de câbles résistants afin de mieux communiquer avec lui. »

Elle hocha la tête en continuant sa lecture puis me demanda étonnée en tapotant la feuille :
- « Vous voulez qu'il soit rapide ? »

Je soupirais : « Il faut qu'il soit véloce. Je veux qu'il réagisse au quart de tour lorsque je l'allume. »

La dame ajouta :  « Il faudra prévoir une alimentation saine avec toutes ses dépenses. »

- « Justement, je cherche une alimentation plus respectueuse de la nature, en électrons recyclables. »

- « Ah là je comprends mieux : qu'il fasse des étincelles ! Concernant vos scripts et plugins je n'ai pas ces articles en magasin, par contre je peux vous proposer toute une gamme de plugs ineffables qui permettront d'étendre le champ de réaction de votre serveur... ».

Prétextant un malaise dû à la fumée des bougies, je me retrouvais sur le trottoir. Je regardais à nouveau le nom de l'enseigne : « Au paradis du serveur maitre/esclave » et tout en m'éloignant à grands pas, je me disais que j'allais  avoir une sérieuse conversation avec le barbu du forum.


A suivre

Je vais aborder ici un sujet qui vous intéresse, celui de ce serveur qui fait rêver certaines et même certains ! J'ai amoncelé un grand nombre de notes et je me rends compte qu'il faudrait trop de temps pour développer toutes les parties que je voulais. Alors je sabre dans ces notes et j'attaque directement le vif du sujet : la préparation d'un serveur « RyzomCore ». Je reviendrai plus tard sur ses autres sujets (j'espère en avoir le temps) plus tard.

Je vous invite à considérer ce fil comme un journal, un blog, où je partagerai avec vous mes expériences, tests et idées sur le serveur. N'hésitez à intervenir ici pour répondre ou posez des questions : ce n'est pas un fil de discussion privé, et j'espère au contraire qu'il sera vivant. A noter aussi, que si je parle en mon nom personnel, tout ce que est dit n'aurait pu être fait sans l'aide et les retours de daeldir.


Ma première expérience (enfin dans le cadre de khagnat) de configuration d'un serveur  RyzomCore date de quelques mois. A l'époque j'avais fait tourner le serveur sur mon portable, une machine en architecture 64bits sous LMDE (Linux Mint Debian Edition. Pour les curieux http://www.linuxmint.com/download_lmde.php). Cependant l'impossibilité de faire tourner le client linux correctement suite à des soucis de driver graphique m'avait empêché d'explorer plus avant ce monde et sa configuration. Ci-dessous un screen d'une connexion sur ce serveur avec en arrière plan le chat sur le canal IRC de notre projet et un bout de la page web d'administration des services du serveur en bas à droite.



La seconde expérience a été réalisé sur le serveur « ninm.net », essentiellement par daeldir, et là nous avons été confronté à un autre problème : nous n'avons pas été en mesure d'adapter la configuration de ryzomcore aux spécificités de la configuration apache/mysal/php de « ninm.net ». Après discussion avec daeldir, nous avons décidé de retenter l'expérience mais cette fois avec une machine virtuelle. Les raisons de ce choix sont multiples, mais avant cela, je vais ouvrir une parenthèse pour rappeler quelques notions sur les « machines virtuelles » :

Au sens large, la virtualisation consiste à simuler l'existence d'une machines physique (un ordinateur)  via un logiciel (programme) dédié. Vous connaissez sûrement les émulateurs de consoles de jeux sur PC ( exemple : NES, PS2, ...) ou de vieilles machines qui ne sont plus disponibles sur le marché (Amiga, Commodore 64, ...). Ici ce qui nous intéresse c'est d'émuler le fonctionnement d'un véritable ordinateur moderne.  La virtualisation nous permet alors de faire fonctionner un programme prévu initialement pour un système d'exploitation différent de celui que nous utilisons habituellement. Nous pouvons par exemple faire tourner une machine Windows sous Linux,  une machine linux sous windows, où même faire fonctionner Windows 8 sur un bon vieux windows XP.

En ce qui nous concerne, la virtualisation va nous permettre de créer une machine virtuelle destinée à installer et tester ryzomcore sans pour autant "polluer" notre environnement de travail principal. Autre point important : rappelez-vous comment nous changions de PC avant : il suffisait la plupart du temps de remettre l'ancien disque dur dans la nouvelle machine pour repartir avec tout son environnement de travail sur une machine plus puissante. Dans notre cas, nous avons besoin du logiciel d'émulation de la machine virtuelle et d'un fichier qui simule le contenu du disque dur qu'on appelle aussi « image disque ». Cette image disque est en fait le sésame, et est échangeable, et partageable ! Ainsi une fois cette machine virtuelle opérationnelle, il suffira (c'est presque vrai!) de copier l'image disque sur le serveur réel pour la faire fonctionner.De plus vous aller pouvoir récupérer cette image vous-même sur votre propre machine pour faire tourner un serveur ryzomcore en local.


Il existe différentes solutions de virtualisation par exemple Virtual PC ou VMWare. Nous avons opté pour VirtualBox ( https://www.virtualbox.org/ ) qui a le mérité d'être open-source, de fonctionner sous Linux, Windows et Mac, d'offrir un interface utilisateur graphique simple pour l'utilisateur lambda qui aimerait tester notre serveur sur sa propre machine, et un dernier argument et non des moindres pour l'utilisateur lambda, VirtualBox est disponible en français. De plus virtualbox permet aussi de configurer la machine virtuelle comme un service tournant en tâche de fond sur un serveur. Rien ne nous empêche par la suite de basculer sur un outil plus orienté serveur comme KVM ( http://www.linux-kvm.org/page/Main_Page ou ici pour une version française http://fr.wikipedia.org/wiki/Kernel-bas ... al_Machine ) sous linux, et pour cela le choix du format de l'image disque est important ( http://superuser.com/questions/360517/w ... vhd-or-hdd ). Ainsi dans ce qui suit j'ai opté pour le format VMDK, qui a l'avantage d'être un format reconnu partout et qui fonctionne avec VirtualBox sans perte de performance.

Autre remarque : vous pouvez vous interroger sur les performances d'une telle machine. Pour répondre de manière grossière mais pas si fausse, il faut savoir qu'aujourd'hui les technologies sont telles qu'en condition ordinaire un serveur n'utilise que 10 % des capacités du matériel. De plus les processeurs (depuis le pentium II et l'AMD K7) supportent des jeux d'instructions pour la virtualisation dénommés VT-x chez Intel et AMD-V sur les processeurs AMD.  De fait, les programmes virtualisés  s'exécutent à pleine vitesse sur le processeur. Les dégradations des performances sont essentiellement liées au fait de devoir réserver de la mémoire pour un système complet (système d'exploitation émulé + ses programmes), et le temps perdu dans l'exécution du système d'exploitation invité qui fait double jeu avec le vrai de la machine physique.

A présent je vais revenir sur les raisons du choix du recours à une machine virtuelle dans le cadre du serveur « ryzomcore » et « ninm.net »

• « Ryzom Core » est essentiellement testé par la communauté sur des distributions debian/ubuntu alors que ninm.net tourne actuellement sous une autre distribution et peut changer à l'avenir.
• La configuration apache/mysql/php est spécifique est n'est pour le moment pas compatible avec la configuration du compte du serveur « ninm.net », ou du moins notre maîtrise de « ryzom core » ne nous permet pas de le faire fonctionner sur cette configuration.
• « Ryzom Core » est essentiellement testé sur architecture 32bits (cf. les soucis de crash sur serveur 64bits), le serveur « ninm.net » est sur architecture 64bits.
• Au vu de notre maîtrise de « Ryzom Core » il n'est pas évident de garantir l'absence de faille de sécurité, qui pourrait compromettre le compte de ninm.net.

Point important : pour avoir un support de la communauté, il est préférable d'avoir une installation « standard ». Le recours à une machine virtuelle permet justement d'avoir cette configuration : un serveur tournant sur une distribution debian stable 32bits.

(Note importante : vous devez acceptez en lisant ce journal le fait que je puisse vous mentir pour simplifier certaines explications. Autre point important, j'appartiens à la race humaine et je peut donc me tromper, alors faite travailler votre cerveau et ne prenez pas tout ce que j'écris pour parole d'évangile )


Installation de VirtualBox

Sous windows :

Récupérer la dernière version de VirtualBox ici : https://www.virtualbox.org/wiki/Downloads.
La dernière au moment ou j'écris ce billet est la version 4.2.18 : http://download.virtualbox.org/virtualb ... 80-Win.exe.
Double cliquez sur l'exécutable et l'installation débute ; vous n'avez presque rien à faire à part cliquer sur le bouton suivant à chaque étape.
À la fin, un nouveau programme nommé VirtualBox est installé. Il ne vous reste plus qu'à le lancer !

Sous Linux :

Toutes les distributions proposent VirtualBox dans leurs dépôts. Cependant pour installer la dernière version, je vous conseille de passer directement par le dépôt d'oracle (si vous lui faite confiance). Pour cela sous debian ou toute distribution dérivée :

Ajouter avec votre éditeur favori le dépôt Oracle au fichier  « /etc/apt/sources.list » :

Code Sélectionner Étendre

deb http://download.virtualbox.org/virtualbox/debian wheezy contrib
Remplacer dans la ligne « whezzy » par votre version de la distribution (note :  pour la  LMDE, ou la debian testing actuelle gardez « wheezy »).

Récupérez la clef d'authentification des pakages Oracles :

Code Sélectionner Étendre

$ wget -q http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc -O- | sudo apt-key add -
Il ne reste qu'à installer le pakage :

Code Sélectionner Étendre

$ sudo apt-get update
$ sudo apt-get install virtualbox-4.2
Attention : le paquetage « dkms » doit être installé sur la machine afin de permettre la compilation des modules noyaux nécessaires au fonctionnement de virtualbox.

Source : https://www.virtualbox.org/wiki/Linux_Downloads

Configuration de la machine virtuelle

Remarque : Je vais détailler dans les billets suivants les manipulations à effectuer pour créer un serveur « ryzomcore » opérationnel. Cependant, vous n'êtes pas obligés de les reproduire car je mettrai à votre disposition cette machine virtuelle.


Première étape récupérer une image ISO du CD d'installation de Debian en architecture i386. [barre:14bjgrim]La version stable est la « Squeeze » version 6.0.7 en date du 23 février 2013 au moment où j'écris ces mots. La version 7.0 « wheezy » est annoncée pour ce mois de mai, on ne va pas s'en priver et je télécharge donc la version « testing », la futur 7.0 donc[/barre:14bjgrim]. La version stable est la 7.0 au moment où je vais poster ce billet. C'est celle-ci qu'il faut dont récupérer :

Code Sélectionner Étendre

$ wget –c /http://cdimage.debian.org/debian-cd/7.0.0/i386/iso-cd/debian-7.0.0-i386-netinst.iso
Au passage récupérons aussi le somme de contrôle SHA du l'image CD afin de vérifier qu'elle n'a pas été corrompue

Code Sélectionner Étendre

$ wget -c  http://cdimage.debian.org/debian-cd/7.0.0/i386/iso-cd/SHA512SUMS

Code Sélectionner Étendre

$ sha512sum -c SHA512SUMS
[ ...des messages d'erreurs pour toutes les autres images ISO non trouvées... ]
debian-7.0.0-i386-netinst.iso: OK

Il est temps d'installer la base de notre futur serveur

On peut créer un machine virtuelle entièrement via la ligne de commande en ce servant du programme VBoxManage. Cependant nous disposons d'une belle interface graphique, alors ne soyons pas masochiste (nous aurons tout le temps de le devenir avec la configuration de ryzomcore)  et utilisons là.  

Remarque personnelle : Il est important de noter que j'ai configuré VirtualBox pour qu'il positionne tous les fichiers au même endroit (Disque virtuel, configuration de la machine, log, etc.) : ouvrir le menu « Fichier » / « Paramètres » ou « Ctrl-G », dans l'onglet « Général » éditer le champ « Dossier par défaut des machines ». Chez moi cela donne : « /chemin-vers-mon-disque-externe/VM »


Commençons par cliquer sur le bouton « Nouvelle » pour ajouter une machine virtuelle


Il faut entrer le nom de la machine virtuelle, à savoir « kh-dev » dans notre cas. Ensuite il faut choisir le type du système d'exploitation « Linux » et la distribution « Debian ».



Cliquez sur le bouton suivant. Autant se faire plaisir. Ce n'est pas une machine optimisée pour un serveur mais plutôt une machine destinée au développement. Donc si votre configuration le permet,n'hésitez pas à lui attribuer de la mémoire et de l'espace physique voir du temps CPU.
Taillé mémoire : 2048 Mo (2 Go).
Cliquez sur suivant :
Sélectionnez « Créer un disque virtuel maintenant » puis cliquez sur « Créer »
Choisissez le format « VMDK » puis cliquez sur suivant.
Choisissez une image disque dont la taille est allouée dynamiquement puis cliquez sur suivant.
Nommez l'image disque « kh-dev » et gardez la taille par défaut de 8Go.


Maintenant que la machine virtuelle est créée, nous allons modifier quelques paramètres via le bouton « configuration »

0. Général
Pas de changement

1. Système :
1.1. Carte mère :
* Mémoire vive : 2Go
* Chipset : PIIX2
* Désactiver les IO-APIC, EFI, périphérique de pointage absolu
* Laissé actif : Horloge interne UTC
1.2. Processeur
* Nombre de CPU 1
* Ressources allouées : 100 %
* Fonction avancées : Activer PAE/NX
1.3. Accélération
Virtualisation matérielle :
Activer VT-X
Activer la pagination imbriquée

2. Affichage
2.1 Vidéo
Mémoire vidéo : 64Mo
Nombre d'écrans : 1
Fonctions avancées :  néant
2.2 Bureau à distance
Nonactif

3. Stockage 
Pas de changement

4. Son
Désactiver

5. Réseau
5.1 Carte 1
Pas de changement, la carte 1 est active et est configurée en mode "NAT".

6. Ports séries
Désactiver

7. USB
Activer le contrôleur USB ( émulation de la souris et du clavier de la machine virtuelle)
Désactiver le contrôleur ISB 2.0 (EHCI) – non nécessaire pour notre serveur


8. Dossiers partagés
Vu que nous serons en mode console sans copier/coller entre la machine virtuelle et notre machine hôte, on utilisera un dossier partagé pour échanges de quelques scripts


A présent on va ajouter l'image du CD d'installation de debian afin de booter dessus la machine virtuelle :



Dans « Configuration/ Stockage »
Sélectionner le disque vide sous le contrôleur IDE
Puis à droite cliquez  sur le bouton représentant un cdrom face au champ « Lecteur CD/DVD » afin de sélectionner l'image CD à monter.

La machine virtuelle est prête, il ne reste plus qu'à la booter pour débuter l'installation de notre serveur linux.

Installation de la distribution Debian Wheezy 32bits sur notre serveur :

Important : Nous avons téléchargé la version « Net Install »des CD d'installation de Debian. C'est une image ISO minimale et une connexion à internet est nécessaire pendant l'installation pour récupérer les paquets à installer. Si votre ordinateur dispose d'un accès au Net, ce qui devrait être sans doute le cas si vous lisez ce forum en même temps, il n'y a rien à faire de particulier. La machine virtuelle est configurée par défaut avec une carte réseau en NAT et saura accéder au réseau internet de manière transparente pour vous sans rien changer.

Autre remarque :J'ai opté pour une installation minimaliste sans X et sans applications. Les paquets nécessaires seront installés en fonction des besoins directement sur le serveur.

Il est temps de débuter l'installation en cliquant sur le bouton « Démarrer » pour booter notre machine virtuelle :



Je sélectionne : « Avanced options » puis « Expert install » dans le menu du bootloader

Linux se lance, puis dans le menu

- « Choose language » :
Language : French – Français
Pays : France
Paramètres régionaux (local) : France – fr_FR.UTF-8
Paramètres régionaux  supplémentaires : en_US.UTF-8
Paramètres régionaux du système : fr_FR.UTF-8

- « Configurer le clavier »
Disposition du clavier : Français

- « Détecter et monter le C »
Modules à charger :

• usb-storage (pas de changement)

- « Charger les composants d'installation à partir  du CD »
Composants d'installation à charger : ne rien cocher

- « Détecter le matériel réseau »
(fait en automatique)

- « Configurer le réseau »
Faut-il configurer le réseau automatiquement ? Oui
Délai d'attente : 3s
Indiquer le nom du système : "kh-dev"
domaine : "ninm.net"

- « Créer les utilisateur et choisir les mots de passe »
Faut-il activer les mots de passe cachés : Oui
Faut-il autoriser ls connexion du super utilisateur ? Oui
Mot de passe du super utilisateur ( « root » ) : *******
Faut-il créer un compte utilisateur ordinaire maintenant ? Oui
Nom complet du nouvel utilisateur : khanat
Identifiant pour le compte utilisateur : khanat
Mot de passe pour le nouvel utilisateur : ********

(Note pour les mots de passe, je vous les fournirait séparément avec l'image de la machine virtuelle)

- « Configurer l'horloge » :
Faut-i utiliser NTP pour régler l'horloge ? Non
# Serveur NTP : 0.debian.pool.ntp.org (celui par défaut)
Fuseau horaire : Europe/Paris

- « Détecter les disques »
(automatique )

- « Partitionner les disques »
Méthode de partitionnement : Assisté – utiliser un disque entier
Disque à partitionner : SCSI3 (0,0,0) (sda)- 8.6 GB ATA VBOX HARDDISK (par défaut)
Schéma de partitionnement : Tout dans une seule partition
Terminer le partitionnement et appliquer les changements sur les disques

- « Installer le système de base »
Noyau à installer : linux-image-i686-pae
[ note : Ce noyau nécessite PAE (« Physical Address Extension » - Extension d'Addresse Physique), donc il faut avoir activé l'option dans la machine virtuelle et disposer d'un processeur récent : Intel Pentium Pro/II/III/4/4M/D, Xeon, Core et Atom ; les AMD Geode NX, Athlon (K7), Duron, Opteron, Sempron, Turion ou Phenom ; les Transmeta Efficeon; VIA C7 ; et quelques autres processeurs. ]
Pilote à inclure sur l'image disque en mémoire « initrd » : image ciblée : seulement les pilotes nécessaires pour ce système.

- « Configurer l'outil de gestion des paquets »
Faut-il utiliser un miroir sur le réseau : Oui
[ note : le pc doit être connecté au réseau, et la machine virtuelle correctement configurée(voir ci-dessus) pour y accéder ]
Protocole de téléchargement des  fichiers : http
Pays du miroir pour l'archive Debian : France
Miroir de l'archive Debian :  ftp.fr.debian.org (défaut)
Mandataire HTTP : laisser ou vide ou en fonction de votre réseau si un proxy est nécessaire
Souhaitez-vous utiliser des logiciels non libres ? Non
Souhaitez-vous utiliser des logiciels de la section contrib ? Non
Services à utiliser : cocher « mise à jour de sécurité » et « mise à jour de la publication ».


- « Choisir et installer des logiciel »

Paquets à installer : décocher « virtualbox-ose-guest-x11 » ( pas de serveur X )
Souhaitez-vous participer à l'étude statistique sur l'utilisation des paquets: Non
Faut-il exécuter les programmes man et mandb avec les droits de l'utilisateur « man » : Non
Logiciel à installer : tout décocher ( on veut un système minimal )

- « Installer le programme de démarrage GRUB »
Installer le programme de démarrage GRUB sur le secteur d'amorçage : Oui

- « Terminer l'installation »
L'horloge système est-elle à 'heure universelle (UTC) ? Oui ( en fonction de votre système)

Il ne reste qu'à rebooter notre système après avoir veillé à retirer l'image du CD d'installation de notre machine virtuelle.Procédez comme pour l'ajout de l'image ISO, mais sélectionnez cette fois : « Ejecter le disque du lecteur virtuel ».

Après reboot on tombe sur le menu du bootloader de notre machine virtuelle :


Puis une fois  le système chargé, il ne reste plus qu'à nous connecter avec le compte « khanat » :

Installation d'un serveur SSH et configuration de la machine virtuelle afin de la rendre accessible de la machine hôte.

Nous avons installé un serveur Debian Linux en mode console, sans environnement graphique, c'est-à-dire sans Xorg. Toutes les manipulations et configurations de notre serveur se feront donc au travers de commandes et de textes que vous saisirez dans le shell. Le linuxien utilise copieusement le copier/collet via la souris. C'est un mode copier/coller différent du monde windows. Tout texte sélectionné dans n'importe quelle fenêtre avec la souris peut être inséré n'importe où par simple clic sur le bouton du milieu (pas de Ctrl-C/Ctrl-V du monde windows). Cela permet de copier les commandes d'une page web ou d'un manuel affiché et les coller dans la ligne de commande. Ressaisir les commandes en question à la main serait source d'erreurs, mais surtout du pur masochisme vu leur nombre et la complexité de celles-ci.

Mais voilà, nous avons sérieux problème. Le copier/copier linuxien ne fonctionne pas dans la fenêtre virtualbox. Plus exactement, il est impossible de copier les commande de ce fil de discussion par exemple (donc d'une fenêtre de votre machine hôte) puis les coller dans la ligne de commande de votre fenêtre virtualbox. Enfin ce n'est pas tout à fait vrai. Cela reste possible si vous installez l'environnement X et que vous ajoutiez des drivers spécifiques virtualbox qui permettront le copier/coller entre votre machine hôte et la machine virtuelle. Malheureusement il n'est pas question d'installer Xorg sur notre serveur.

A cela il existe toutefois une solution que a le mérite d'être doublement élégante. Enfin vous l'avez sans doute deviné en lisant le titre de ce sujet. Il s'agit de se connecter à la machine virtuelle via ssh.   La console ssh était un programme exécuté sur la machine hôte, le copier/coller avec les autres applications de la machine hôte comme le contenu de ce sujet qui s'affiche dans votre navigateur fonctionnera sans souci. Ah mais vous êtes peut-être sous windows là ? Dans ce dernier cas il ne vous reste qu'à changer d'orientation sexuelle :p.

La deuxième raison qui rend cette solution mignonne, c'est qu'avec l'utilisation de ssh, nous n'aurons plus besoin de cette interface graphique « VirtualBox » qui encombre notre bureau pour rien. Je vous montrerai donc comment lancer la machine virtuelle en tâche de fond via une ligne de commande.

Mais revenons à nos moutons et passons aux choses sérieuses :

Partie 1 – installation du serveur « ssh »

Lancez la machine virtuelle via l'interface graphique pour le moment et connectez-vous avec le compte root. Nous allons installer le démon « ssh » :

Code Sélectionner Étendre

# apt-get update
# apt-get install openssh-server
C'est terminé, le serveur ssh est opérationnel. Cela peut se vérifier via la commande netstat qui nous montre bien qu'un service est actif et en écoute sur le port 22, celui du protocole ssh.

Code Sélectionner Étendre

# netstat -tulpn | grep :22
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1971/sshd      
tcp6       0      0 :::22                   :::*                    LISTEN      1971/sshd
Si vous avez un doute, une tentative de connexion en localhost avec le compte « root » montre que le daemon « sshd » est bien actif :

Code Sélectionner Étendre

# ssh root@localhost
root@localhost's password:
Linux kh-dev 3.2.0-4-686-pae #1 SMP Debian 3.2.41-2+deb7u2 i686

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

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
#
Cependant pou des raisons de sécurité nous allons retirer l'accès root via ssh.  Il faudra passer par le compte « khanat » et utiliser la commande « su » pour obtenir les privilèges « root ». Pour cela on va éditer le fichier de configuration du serveur avec votre éditeur de texte  favori :

( Au passage, si ce n'est pas déjà fait, installez votre éditeur favori. De mon coté j'ai installé « vim » et « nano » sur ce serveur

Code Sélectionner Étendre

# apt-get install vim nano)

Code Sélectionner Étendre

# vi /etc/ssh/sshd_configNous allons juste modifier cette ligne

Code Sélectionner Étendre

PermitRootLogin yeset la changer en

Code Sélectionner Étendre

PermitRootLogin nopour interdire la connexion en root.

 On relance  le daemon « sshd » pour prendre en compte la nouvelle configuration :

Code Sélectionner Étendre

# /etc/init.d/ssh restart
[ ok ] Restarting OpenBSD Secure Shell server: sshd.
On tente de se connecter avec ssh au notre  serveur

Code Sélectionner Étendre

# ssh root@localhost
root@localhost's password:
Permission denied, please try again.
La tentative doit échouer.

Partie 2 – accéder à la machine virtuelle en ssh de la machine hôte

Vous pouvez à présent éteindre votre machine virtuelle. Nous n'aurons plus besoin de passer par l'interface graphique. Pour cela toujours avec le compte « root » saisissez dans la console de notre serveur virtuel :

Code Sélectionner Étendre

# shutdown -h now

Maintenant se pose une grave question. Comment nous connecter sur la machine virtuelle avec ssh ? En effet cette machine n'est rien d'autre qu'un programme qui tourne sur notre ordinateur. Elle ne dispose pas d'une véritable carte réseau et n'est pas identifiée par une adresse IP.

La réalité est plus complexe. Au travers des modules noyaux, virtualbox va simuler un faux routeur et permettre dans certains cas d'attribuer une véritable adresse IP à notre machine. Mais dans notre cas nous allons garder le fonctionnement en mode NAT et simplement créer une règle indiquant à notre ordinateur hôte de rediriger toutes les communications à destination du port 22 (celui de ssh) de notre machine physique vers le port 22 de notre machine virtuelle
Ah, mais cela ne peut marcher, nous sommes sous unix et l'on ne peut exploiter indûment les ports en dessous de 1024. Qu'à cela ne tienne nous utiliseront le port 2222 à  la place, ou tout autre port libre.

La règle sera : toute communication à destination du port 2222 de notre machine physique devra être redirigée sur le port 22 de notre machine virtuelle. Cette règle se crée via  la ligne de commande suivante sur votre machine hôte :

Code Sélectionner Étendre

$ VBoxManage modifyvm "kh-dev" --natpf1 "ssh,tcp,,2222,,22"
Note : vous pouvez obtenir le même résultat en passant par l'interface graphique. Dans l'écran de configuration de la première carte réseau de notre machine virtuelle, cliquez sur le bouton « Redirection de ports ». puis compléter les colonnes « nom de la règle », protocole, port sur la machine hôte, et port sur la machine virtuelle.



Attention cette manipulation doit être effectuée lorsque la machine virtuelle est éteinte.

Il ne reste plus qu'à relancer notre machine virtuelle et se connecter dessus via « ssh »
C'est là que je vais introduire des commandes consoles qui évitent de passer par l'interface graphique :

pour lancer la machine virtuelle dénommé « kh-dev » en ligne de commande sur la machine hôte tapez :

Code Sélectionner Étendre

$ VBoxManage startvm "kh-dev" --type headless
Noter qu'il faut compter le temps que le bootloader  choisissent automatiquement la première entrée du menu grub, puis que le système se charge avant de tenter une connexion « ssh », donc environ 20s chez moi :

Code Sélectionner Étendre

$ ssh khanat@localhost -p 2222 Cette commande tente de se connecter avec le compte « khanat » en local sur le port 2222 qui sera redirigé vers le port 22 de notre machine virtuelle où tourne le serveur ssh.



A présent vous êtes connecté sur la machine virtuelle via ssh, et lecopier/coller est opérationnel.

Pour éteindre cette machine, il faudra acquérir les droits "root" via la commande "su" puis saisir la commande d'extinction :

Code Sélectionner Étendre

$ su
# shutdown -h nowCela terminera aussi votre session ssh et ce tutorial

Mise en route, extinction et sauvegarde de l'état d'une machine virtuelle via le programme VboxManage :

Si vous voulez exécuter la machine virtuelle depuis un serveur sans interface graphique, utilisez la commande ( note : remplacez dans tous ces exemple « kh-dev » par le nom que vous avez attribué à votre machine virtuelle) :

Code Sélectionner Étendre

$ VBoxManage startvm "kh-dev" --type headless

Vous pouvez vous assurer qu'une machine virtuelle est lancée via la commande :

Code Sélectionner Étendre

$ VBoxManage showvminfo "kh-dev" | grep  "^State"
State:           running (since 2013-05-18T07:40:45.254000000)Note : le « grep "^State" » permet de n'afficher que la ligne contenant le statut d'exécution de la machine virtuelle

Vous pouvez éteindre la machine virtuelle via la commande :

Code Sélectionner Étendre

$ VBoxManage controlvm "kh-dev" poweroffToutefois je vous la déconseille vivement, car elle correspond à une extinction brutale de la machine par retrait de la prise électrique.
A la place je vous invite à vous connecter sur la machine virtuelle via ssh, à passer root, puis demander de la machine de s'éteindre proprement

Code Sélectionner Étendre

$ ssh khanat@localhost -p 2222
$ su
# shutdown -h now
Broadcast message from root@kh-dev (pts/1) (Sun May 19 03:01:52 2013):

The system is going down for system halt NOW!

root@kh-dev:~# Broadcast message from root@kh-dev (pts/1) (Sun May 19 03:01:52 2013):

The system is going down for system halt NOW!
Connection to localhost closed by remote host

Vous pouvez alors revérifiez l'état de la machine virtuelle via la commande :

Code Sélectionner Étendre

$ VBoxManage showvminfo "kh-dev" | grep  "^State"
State:           powered off (since 2013-05-19T01:02:01.529000000)

Plutôt que d'éteindre votre machine virtuelle, vous pouvez figer son fonctionnement à un instant t via l'option « savestate » de la commande VBoxManage. Cela ressemble beaucoup au mode « hibernation » des portables. A noter que dans ce cas vous perdez votre connexion ssh.

1) on vérifie que la machine virtuelle tourne bien

Code Sélectionner Étendre

$ VBoxManage showvminfo "kh-dev" | grep  "^State"
State:           running (since 2013-05-18T07:40:45.254000000)
2) on demande à virtualbox de sauvagrder son état et de l'arrêter

Code Sélectionner Étendre

$ VBoxManage controlvm "kh-dev" savestate
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
3) on peut vérifié qu'elle est à l'arrêt et dans l'état "sauvé" :

Code Sélectionner Étendre

$ VBoxManage showvminfo "kh-dev" | grep  "^State"
State:           saved (since 2013-05-18T08:46:56.000000000)
4) on utilise la commande standard pour la relancer

Code Sélectionner Étendre

$ VBoxManage startvm "kh-dev" --type headless
Waiting for VM "kh-dev" to power on...
VM "kh-dev" has been successfully started.
5) on peut s'assurer que la machine virtuelle a été correctement restaurée et tourne bien

Code Sélectionner Étendre

$ VBoxManage showvminfo "kh-dev" | grep  "^State"
State:           running (since 2013-05-18T08:48:14.259000000)

Retour sur VirtualBox

Je me rends comte à la relecture des billets précédents que j'assume un certain nombre de chose connues sur virtualbox, ce qui est une erreur de ma part.
Alors déjà voilà quelques définitions qui rendront plus clairs ces textes précédents

• La machine physique est votre ordinateur sur lequel tourne virtualbox et toutes vos applications.
• La machine virtuelle est l'ordinateur virtuel créé par VirtualBox. On utilise souvent l'acronyme VM pour la désigner

Dans le monde de la virtualisation on utilise fréquemment le concept d'hôte et d'invité.
La machine hôte est notre machine physique qui va héberger la machine virtuelle que l'on dénomme alors machine invitée.
On parle aussi du système hôte et système invité pour désigner le système d'exploitation de la machine physique/hôte et de la machine virtuelle/invitée


Important : Les touches de raccourci (si vous utilisez l'interface graphique virtualbox)

Il existe quelques raccourcis importants à connaître sur VirtualBox lorsque vous êtes sur la machine invité. Ces raccourcis utilisent la touche appelée génériquement « Host », définie par l'hôte. C'est par défaut la touche « contrôle droite » (« Ctrl ») de votre clavier.

Voici maintenant une présentation des principaux raccourcis :

• Host+F : passage en mode plein écran/mode fenêtré. Très utile pour passer en immersion totale dans la machinee virtuelle (excepté la présence de la barre d'outils en bas qui apparaît lorsque le pointeur de la souris atteint le bas de l'écran).
• Host+L : tente de fondre le bureau de l'invité dans celui de l'hôte. A essayer (demande la présence de l'extension « guests-additions »  et un environnment graphique comme windows ou Xorg sur la machine invité.
• Host+G : ajuste la taille de l'écran automatiquement. A activer pour profiter du plein écran (attention aux fautes de frappe entre Host+F et Host+G).
• Host+Suppr : envoie la combinaison « Ctrl+Alt+Suppr » à la machine invité.
• Host+S : enregistre l'état actuel de la VM (un « instantané »).
• Host+R : redémarrage de la VM.
• Host+P : mise en pause de la VM.
• Host+H : arrêt de la VM.
• Host+Q : quitte la VM (propose le type d'arrêt à effectuer).

Attention cependant à cette touche « Host ».  En général on utilise la touche « Ctrl » droite du clavier (question est-ce le cas aussi des gauch(er/ère)?), mais si vous utilisez celle de gauche pour une utilisation normale vous risquez d'être confronté à de grosses surprises : En effet, si vous voulez rechercher du texte dans votre VM, vous pourriez utiliser la combinaison de touche « Ctrl+F ». Ceci aura en fait pour effet de mettre la VM en plein écran. Pire, si vous faites « Ctrl+S », qui correspond en général à une sauvegarde, vous enregistrer un « instantané » de votre VM soit un fichier de plusieurs Go d'écrits à votre insu sur votre disque dur...

*regarde ses notes et hésite entre aborder le sujet du serveur ryzomcore ou traiter d'autres sujets qui restent importants*

Puisque pour installer et configurer un serveur ryzom core le site « dev.ryzom.com » est une source incontournable d'informations j'en profite pour faire un point sur son évolution :

Version anglaise ( source : http://dev.ryzom.com/projects/ryzom/wiki )

The entire 'dev.ryzom.com' website will be phased out in the coming months. The site has been put into read-only mode for non-developers and the content is in the process of being moved. Our new home will be: http://www.ryzomcore.org - which you may recognize as what used to be the developers blog. We have moved the source code to BitBucket already and merged the SF.net repository over, it will be left in place for history for some time. In addition to hosting source our issues will be hosted in BitBucket for the time being. We have an OnDemand license for JIRA but have decided not to use it for the time being. For forums and discussions we will be using Google Communities.

Traduction en français

L'ensemble du site web «dev.ryzom.com» va disparaître dans les mois à venir. Le site est à présent en lecture seule pour les non-développeurs et le contenu est en train d'être déplacé. Le projet sera hébergé à présent ici « www.ryzomcore.org » qui était autrefois le blog des développeurs. Nous avons déjà déplacé le code source sur BitBuck et fusionné celui-ci avec les sources du dépôt de SF.net.  Le dépôt SF.net sera laissé en place pour historique pendant un certain temps. La gestion du bugtracking sera également assurée par  BitBucket pour le moment. Pour les forums et discussions, nous utiliserons Google+.

Récapitulatif des nouveaux liens :

• Accueil : http://www.ryzomcore.org/
• Documentation : https://ryzomcore.atlassian.net/wiki/di ... +Core+Home
• Bug Tracking : https://bitbucket.org/ryzom/ryzomcore/i ... tatus=open
• Source Code : https://bitbucket.org/ryzom/ryzomcore
• Forum: https://plus.google.com/u/0/communities ... 2568269036  (pourquoi je déteste google+ ? *soupire* ... )

Préparations pour la compilation du serveur RyzomCore

Ce que je propose ici est une adaptation du tutoriel du site RyzomCore :

Ici pour le nouveau site communautaire :
https://ryzomcore.atlassian.net/wiki/di ... e+on+Linux
Où là pour l'ancien site :
http://dev.ryzom.com/projects/ryzom/wik ... LinuxCmake


Première partie : se connecter à notre serveur

Dans une console de votre machine hôte, lancez la machine virtuelle via la commande :

Code Sélectionner Étendre

$ VBoxManage startvm "kh-dev" --type headlessPuis connectez-vous via SSH :

Code Sélectionner Étendre

ssh khanat@localhost -p 2222
Deuxième partie : récupérer les sources

Les sources du projet RyzomCore sont hébergés sur un serveur « mercurial ». Pour rappel, mercurial est un SCM (Source Code Management), c'est-à-dire un outil de gestion de sources. Grosso modo, un SCM maintient un dépôt des sources d'un projet, gère les MAJ des développeurs et donc les conflits potentiels, mais surtout garde l'historique complet de ces MAJ. C'est avant tout un outil de travail collaboratif et orienté communauté.

(Pour en savoir plus sur mercurial voici une introduction en anglais : http://hginit.com/index.html et un autre en français : http://dblugeon.developpez.com/tutoriel ... ial/intro/ )

Nous allons installer le client mercurial sur notre serveur, pour cela il nous faut en premier acquérir les droits root :

Code Sélectionner Étendre

$ supuis demander l'installation du paquet mercurial :

Code Sélectionner Étendre

# apt-get install mercurialretour ensuite au compte khanat (on ne fait que les manipulations strictement nécessaires avec le compte root !) :

Code Sélectionner Étendre

# exit
$
Le dépôt mercurial se gère via le programme console « hg »
A présent positions-nous à la racine du dossier du compte khanat :

Code Sélectionner Étendre

$ cdRécupérons tous les fichiers du projet. On dit que l'on clone le dépôt

Code Sélectionner Étendre

$ hg clone https://bitbucket.org/ryzom/ryzomcoreNous nous positionnons à l'intérieur de ce nouveau dépôt local

Code Sélectionner Étendre

$ cd ryzomcorePuis nous tentons une MAJ du dossier – pull – et une fusion avec les modifications localement effectuées – update – (Note cette commande est plutôt destinée aux mises-à-jour futures des sources et ne fera rien ici, mais enfin puisque le tuto officiel dit qu'il la faut.... ) :

Code Sélectionner Étendre

$ hg pull && hg update
Retenons plutôt de cette dernière ligne que dans le futur, si nous voulons recompiler les sources après une MAJ importante du dépôt officiel, il faudra dans la console serveur saisir :

Code Sélectionner Étendre

$ cd ~/ryzomcore
$ hg pull && hg update

Troisième partie : installation des outils de compilation et des librairies annexes

Premièrement, il nous faut acquérir les droits root :

Code Sélectionner Étendre

$ suPuis intaller les outils de développement ainsi que les librairies nécessaires :

Code Sélectionner Étendre

# sudo apt-get install mercurial libcurl4-openssl-dev libluabind-dev libfreetype6-dev libx11-dev libgl1-mesa-dev libxxf86vm-dev libxrandr-dev libxrender-dev libopenal-dev libogg-dev libvorbis-dev libxml2-dev cmake build-essential libpng12-dev libjpeg62-dev rrdtool libmysqlclient-dev bison libxmu-dev autoconf automake
# exit
$
Note, le tuto officiel parle de « libsquish-dev » et « libwww-ssl-dev », mais ces librairies ne sont plus dans les dépôts officiels de la version Debian wheezy , nous procéderons donc autrement. Autre remarque « libmysqlclient-dev » remplace « libmysqlclient15-dev ». La librairie libwww sera récupéréee à partir des archives des anciens dépôts Debian :

Télécharger des paquets Debian à partir du dépôt d'archives :

Code Sélectionner Étendre

$ wget http://archive.debian.org/debian/pool/main/w/w3c-libwww/libwww0_5.4.0-11_i386.deb
$ wget http://archive.debian.org/debian/pool/main/w/w3c-libwww/libwww-dev_5.4.0-11_i386.debInstaller la librairie « expat » qui est une dépendance nécessaire à « libwww » avec le compte root :

Code Sélectionner Étendre

$ su
# apt-get install libexpat1-devInstaller manuellement les paquets de la librairie « libwww »

Code Sélectionner Étendre

# dpkg -i libwww0_5.4.0-11_i386.deb libwww-dev_5.4.0-11_i386.deb
# exit
$
Il nous faut aussi installer la librairie « cpptest » et « squish ». Le tuto officiel propose de récupérer ces librairies à partir de l'arborescence des sources de kervala ( http://hg.kervala.net/packaging/file/). Cependant je n'ai jamais réussi à les compiler. Passons donc par les sources des sites d'origines :


Intallation de cpptest. Note : pour l'installation de la librairie nous passons en « root » (commande su)

Code Sélectionner Étendre

$ wget -c http://freefr.dl.sourceforge.net/project/cpptest/cpptest/cpptest-1.1.2/cpptest-1.1.2.tar.gz
$ tar xzvf cpptest-1.1.2
$ cd cpptest-1.1.2
$ ./configure
$ make
$ su
# make install
# exit
$

Installation squish

Code Sélectionner Étendre

$ wget – c http://libsquish.googlecode.com/files/squish-1.10.tar.gz
$ tar xvf  squish-1.10.tar.gz
$ cd squish-1.10

Important : le code source de la librairie « squish » ne compile pas avec les dernières versions de gcc. Il faut apporter une correction mineur avant de lancer cette compilation :

Dans votre éditeur favori, ajoutez en ligne 24 du fichier « alpha.cpp » l'instruction « #include <limits.h> » comme le montre ce « diff » :

Code Sélectionner Étendre

$ diff -u alpha.cpp.origin alpha.cpp
--- alpha.cpp.origin 2013-04-16 16:01:05.814504052 +0200
+++ alpha.cpp 2013-04-16 16:01:32.270171459 +0200
@@ -24,6 +24,7 @@
    -------------------------------------------------------------------------- */
   
 #include "alpha.h"
+#include <limits.h>
 #include <algorithm>
 
 namespace squish {
Faire la même chose à la ligne 26 du fichier « singlecolourfit.cpp » :

Code Sélectionner Étendre

$ diff -u singlecolourfit.cpp.origin singlecolourfit.cpp
--- singlecolourfit.cpp.origin 2013-04-16 16:00:44.058777558 +0200
+++ singlecolourfit.cpp 2013-04-16 16:02:15.545627411 +0200
@@ -26,6 +26,7 @@
 #include "singlecolourfit.h"
 #include "colourset.h"
 #include "colourblock.h"
+#include <limits.h>
 
 namespace squish {
Maintenant nous pouvons compiler et installer la libraie. Pour l'installer, comme précédemment, il faudra acquérir les droits  « root » via la commande « su » :

Code Sélectionner Étendre

$ make
$ su
# make install
# exit
$
Il ne reste plus qu'à lancer la compilation, ce qui sera le sujet du prochain billet.

Avant de compiler les sources, il nous faut définir deux variables d'environnement. Pour ne pas avoir à y penser à chaque fois autant les ajouter à notre fichier de configuration du shell « .bashrc » :


Première partie : définition des variables d'environnement

Code Sélectionner Étendre

$ vim ~/ .bashrc Utilisez bien entendu votre éditeur favori pas forcément « vim », et ajouter les lignes suivantes à la fin du fichier « .bashrc » :

Code Sélectionner Étendre

export RYHOME="/home/khanat/ryzomcore/code"
export RYZOM_PATH="/home/khanat/ryzomcore/code/ryzom"
export PATH="$PATH:$RYZOM_PATH/tools/scripts/linux/"
Il faut relancer le shell pour qu'il prennent en compte ces changements :

Code Sélectionner Étendre

$ .    ~/.bashrcVous pouvez aussi vous déconnecter et vous reconnecter, le résultat final sera le même

Seconde partie : configuration de cmake

Créons  le dossier dans lequel aura lieu la compilation et positionnons nous dedans.

Code Sélectionner Étendre

$ mkdir $RYHOME/build
$ cd $RYHOME/build
A présent il faut lancer la commande « cmake » pour générer les « Makefile » nécessaires à la compilation. Il va falloir lui passer un certain nombre de paramètres qui explicite ce que nous voulons qu'il compile. Ces paramètres sont listés ici :
https://ryzomcore.atlassian.net/wiki/di ... ke+Options

Nous désirons compiler le serveur uniquement sans le client ryzom,donc :
WITH_RYZOM_CLIENT=OFF
Il nous faut la librairie NEL, mais nous n'avons pas besoin des unités de test ou des programmes d'exemples associés :
WITH_NEL=ON
WITH_NEL_TESTS=OFF
WITH_NEL_SAMPLES=OFF
Vu que nous ne compilons pas le client, mais uniquement le serveur, nous n'avons pas besoin de compiler avec NEL les drivers graphiques et audio :
WITH_SOUND=OFF
WITH_DRIVER_OPENAL=OFF
WITH_DRIVER_OPENGL=OFF
Et pour finir nous allons suivre la recommandation de la communauté en liant statiquement les librairies aux binaires du serveur :

If you happen to find the server constantly crashing and restarting, and in the admin panel it states that several of the processes are "*Chain Crashing*", a found fix is to cmake with the additional flags of -DWITH_STATIC=ON and -DWITH_STATIC_DRIVERS=ON.

et donc :
WITH_STATIC=ON
WITH_STATIC_DRIVERS=ON

Ces paramètres sont passés à « cmake » en ligne de commande via l'option « -D ». Donc au final nous devons saisir dans notre console :

Code Sélectionner Étendre

$ cmake -DWITH_NEL_TESTS=OFF -DWITH_RYZOM_CLIENT=OFF -DWITH_NEL=ON
  -DWITH_SOUND=OFF -DWITH_STATIC=ON -DWITH_STATIC_DRIVERS=ON
  -DWITH_DRIVER_OPENGL=OFF -DWITH_DRIVER_OPENAL=OFF
  -DWITH_NEL_SAMPLES=OFF
  ..
Attention à ne pas oublier les deux points « .. » à la fin

Troisième partie : Lancer la compilation.

Il ne reste plus qu'à lancer la compilation :

Code Sélectionner Étendre

$ make -j2
L'option « -j2 » permet d'exploiter les cœurs de votre processeur en lançant des compilations parallèles. La recommandation est de passer l'option « -j [nombre de cœurs du processeur]+1 ». Vu que nous avons configuré notre machine virtuelle avec un seul cœur, nous gardons la valeur « -j2 ».



Quatrième partie : quelques considérations concernant la compilation pour ceux qui veulent s'y essayer.

Il faut savoir que mon portable qui est équipé d'un processeur Intel iCore 5 quadri-coeur, mais que le cpu est réglé pour tourner à la vitesse minimale. Il est donc presque continuellement à 800Mhz au lieu 2,4Ghz. Sachant que je travaillais en même temps dessus et que j'ai même joué à Ryzom en même temps, il m'a fallu deux après-midi complètes pour compiler entièrement les sources de ryzom core. Pour info j'avais réservé 100% "cpu" d'un cœur de mon processeur à la machine virtuelle. Autre remarque, je n'ai jamais constaté de ralentissement de ma machine même en jouant à Ryzom alors que la machine virtuelle compilait en tâche de fond.

Donc n'hésitez pas à arrêter la compilation si vous voulez éteindre votre machine avec "Ctrl-C"

Code Sélectionner Étendre

...
[  8%] Built target nelmisc
[  8%] Built target nel3d_pch
^Cmake[1]: *** [nel/src/3d/CMakeFiles/nel3d.dir/all] Interrompre
make: *** [all] Interrompre
khanat@kh-dev:~/ryzomcore/code/build$
Éteignez proprement la machine :

Code Sélectionner Étendre

$ su
# shutdown -h now
Puis au prochain lancement de votre ordinateur, une fois connecté sur le serveur virtuel, saisissez :

Code Sélectionner Étendre

$ cd $RYHOME/build
$ make -j2
Et la compilation reprend là où elle c'était  arrêtée.

Je profite de ce billet pour jeter un pavé dans la marre. La machine virtuelle que nous venons d'installer n'est pas destinée à être le « serveur de jeu » officiel déployé sur le serveur « ninm.net ». Son nom est déjà un indice en lui même : « kh-dev » pour « khanat version développement ». Je vais donc m'expliquer sur ce sujet ici :

La raison remonte à une discussion avec Daeldir sur la taille de la future VM [comprendre ici taille du disque virtuel] en se basant sur l'espace occupé par le serveur de jeu seul (avec le serveur web et la base de données). Nous nous étions fixés la gageure de tout faire tenir dans un fichier 50 Mo. Ce choix n'est pas anodin, et je vais tenter d'en expliquer les raisons. Cependant je vais avoir un discours plus général et définir des objectifs pour cette machine virtuelle (VM) :

• Faire en sorte que l'empreinte disque/mémoire (taille) de la VM soit minimale.
• Pouvoir utiliser la VM localement chez soi ou sur le serveur sans avoir à modifier la configuration.
• Pouvoir mettre à jour facilement la VM suite à une re-compilation des sources ou une MAJ des data du jeu.

Je vais détailler rapidement ces trois points avant de développer essentiellement le point sur la taille de la VM.

(1) Le premier point concernant la taille du disque et avant tout un défi que nous nous sommes assignés au regard de la taille de l'archive du serveur sous windows proposé par Molator sur « dev.ryzom.com ». Il propose un zip de 44Mo contenant le serveur ryzom core + la base mysql + un serveur web Go2 qu'il suffit de dezziper sur une machine windows pour être opérationnel (cf. http://dev.ryzom.com/projects/ryzom/wik ... CoreServer ). Nous nous sommes dit alors que nous serions capable de faite tenir le serveur ryzom core sous une machine virtuelle linux de 50Mo avec cette fois le système d'exploitation inclus. Mais dans le fond cet objectif relève de considérations plus pratiques :

• Il est essentiel que la taille du disque soit minimale pour pouvoir l'uploader rapidement sur le serveur ou l'échanger pour des tests. Cas pratique : si votre image disque occupe 4 Go et qu'il faut 1 jour pour l'uploader sur le serveur, bonjour la réactivité suite à un problème !
• La seconde raison est tout simplement lié aux performances. Basiquement, une image disque plus petite, c'est une occupation moindre en mémoire des méta-data du disque pour virtualbox, donc plus de place pour les caches d'accès, et au final des performances améliorées.

(2) Le second point, pouvoir utiliser simplement la VM en local ou sur le serveur sans manipulations de configurations, concerne essentiellement la configuration réseau. Il me semble essentiel que n'importe qui puisse récupérer la VM sur sa machine personnelle et puisse la lancer directement sans se poser de question ni avoir à effectuer des manipulations en lisant  une documentation absconde de 50 pages. Pratiquement cela a une autre incidence importante par rapport au serveur réel du jeu. Cela veut dire qu'une fois que vous avez ajouté une quête par exemple, et que vous l'avez testé localement sur votre poste, vous pouvez uploader la VM sur le serveur sans vous poser de questions et être sûr qu'elle fonctionnera immédiatement. Au niveau maintenance c'est essentiel.

Personnellement je crois que cet objectif de « ZeroConf » est atteint ou presque. J'aborderai la configuration réseau du serveur dans un autre billet dédié et je clos donc ce sujet ici.

(3) Le troisième point concerne l'évolution du serveur de jeu. Il nous faut une méthode simple pour mettre à jour la VM dans les deux cas de figure suivants :

• recompilation du serveur suite une évolution des sources
• modification des data du jeu (ajout de quêtes, modification de zones, etc...)

Je pense de ce coté avoir des pistes prometteuses que j'évoquerai à la fin de ce billet. Toutefois il reste un « cas de figure » qui est encore assez « brumeux » pour moi. Celui des données des comptes joueur et des comptes CSR/Animation/Dev. Franchement je n'en sais pas assez pour m'avancer sur ce point et évaluer l'incidence des MAJ de la VM.  Sans mentir, assurer la continuité des «Ra » sur ce monde risque d'être risqué en ces premiers éons ou les brumes recouvrent encore le monde.

Minimiser la taille de la VM

A présent je vais revenir sur le premier objectif, une taille minimale pour la VM et développer l'idée tout en expliquant ce que nous voulons faire. Jetons un œil à la taille du fichier « kh-dev.vmdk », l'image disque du serveur de jeu installé dans ce fil de discussion.

Code Sélectionner Étendre

$ ls -la kh-dev.vmdk
-rw------- 1 liria liria 4345954304 avril  23 16:45 kh-dev.vmdk
L'image occupe 4 Go. Aie, notre objectif de 50Mo pour cette VM a été explosé avec un ratio de 1 à 100 ! On peut déjà imaginer les temps nécessaires pour uploader ou inversement récupérer cette image à partir du serveur « ninm.net »

Nous allons lancer la VM et nous connecter pour essayer de déterminer ce qui prend tant d'espace :

Code Sélectionner Étendre

$ VBoxManage startvm "kh-dev" --type headless( attendre que la machine boot effectivement et le service ssh soit lancé sinon la connexion échoue

Code Sélectionner Étendre

$ ssh khanat@localhost -p 2222
Partons du principe que cette machine est dédiée uniquement à l'exécution du serveur de jeu et rien d'autre. Demandons-nous ce que nous pouvons supprimer d'inutile. Nous allons nous servir de la commande unix « du » (disk usage) qui permet d'afficher l'espace occupé par un dossier et ses sous-dossiers.

Code Sélectionner Étendre

du -k /chemin/dossier  (affiche la taille en Ko du dossier et ses sous dossiers)
du -m /chemin/dossier  (affiche la taille en Mo du dossier et ses sous dossiers)

Première idée, les documentations installées avec les applications :

Code Sélectionner Étendre

$ du -m /usr/share/doc
86 /usr/share/doc
$ du -m /usr/share/man
26 /usr/share/man
86 + 26 =  112 Mo de doc inutiles pour notre serveur

Seconde idée : la base des « packages » debian, en effet la VM serveur est figée et à part la MAJ des binaires du serveur ou des data du jeu on ne devrait pas avoir à modifier le reste ( j'entends certains hurler, mais je reviendrai sur ce point plus tard l sujet des  MAJ de sécurité). Il va nous falloir des droits root pour accéder aux sous dossiers de « /var » :

Code Sélectionner Étendre

$ su
# du -m /var/cache/apt
1 ./archives/partial
302 ./archives
341 .

Total 340 Mo utilisés pour conserver les copies des paquets Debian installés sur cette VM et inutiles dans notre cas.

Code Sélectionner Étendre

# ls /var/cache/apt
apache2_2.2.22-13_i386.deb
apache2.2-bin_2.2.22-13_i386.deb
apache2.2-common_2.2.22-13_i386.deb
apache2-mpm-prefork_2.2.22-13_i386.deb
apache2-utils_2.2.22-13_i386.deb
autoconf_2.69-1_all.deb
automake_1%3a1.11.6-1_all.deb
...

Troisièmes idées : les outils de développement. Une fois le serveur compilé nous n'avons plus besoin de ces outils : gcc, g++, make, automake, bisons, ... ainsi que tous les sources d'entêtes des librairies utilisés pour la compilation.

Code Sélectionner Étendre

$ du -m /usr/include/
133 /usr/include/

133 Mo juste pour les entêtes, mais cela n'est  pas tout, il y a également les sources du serveur.

Du coup je ré-installe sur ma machine perso les sources du serveur ryzom pour avoir un référentiel de comparaison avant conpilation :

Code Sélectionner Étendre

$ mkdir ~/src
$ cd ~/src  hg clone https://bitbucket.org/ryzom/ryzomcore
$ du -m ryzomcore
252 ./ryzomcore/code
425 ./ryzomcore

420 Mo de sources ! Tient bizarrement il n'y a que 250 Mo dans le sous-dossier « code » de ryzomcore alors que ce dernier est vide et ne contient que ce dossier. Si on y regarde de plus, il y a en fait un sous-dossier caché, qui correspond aux méta données de gestion du dépôt (historique des modifications, etc...), et cela correspond à la différence.

Code Sélectionner Étendre

$ du -m ryzomcore/.hg
174 ./ryzomcore/.hg

Sans chercher plus loin nous avons déjà récupéré 1Go d'espace disque. Cependant procéder ainsi n'est pas la bonne démarche et ce n'est pas ainsi que nous l'avons envisagé avec Daeldir. C'est  ce que je vais introduire juste après. On va pouvoir enfin s'attaquer au cœur du sujet de ce  billet. *regarde l'heure* Zut c'est l'heure d'aller manger !


.... a suivre...