Outils du site

fr:installation_d_un_serveur_de_patchs

Installation d'un serveur de patchs

Les patches permettent de mettre à jour les données de votre client de jeu, et se téléchargent en lançant celui-ci, de façon à vous installer les fichiers les plus récents.

Une procédure est prévue pour créer les fichiers prenant en charge ces opérations, et un service dédié (via Apache) doit être mis en place pour que les clients puissent s'y connecter.

Nous partons du principe que l'identité utilisée pour les procédures expliquées ci-dessous (nommée gameserver par commodité) appartient au groupe “www-data” et que les fichiers et répertoires qu'il génère sont donc lisibles pour être servis par Apache. Il doit aussi être sudoer pour effectuer plusieurs opérations système.

Création des patchs

Préalable

Votre serveur doit avoir les paquets suivants installés :

  1. lzma
  2. xdelta

L'installation se fait rapidement :

~/$ sudo aptitude install lzma xdelta

La compilation des outils NeL de Ryzom Core nous a doté d'un utilitaire en ligne de commande nommé patch_gen. C'est avec lui que nous travaillerons.

Il faut également avoir les fichiers .bnp, qui servent à organiser les datas du jeu, et qui sont manipulés par l'exécutable bnp_make des outils NeL de Ryzom Core. Une autre section vous explique en détail la gestion des fichiers .bnp : Manipuler les données du client avec les .bnp.

Mise en place de la hiérarchie des données

Il faut tout d'abord se placer dans un endroit dans lequel nous générerons les patchs. Une de ces zones sera ouverte par le serveur Apache pour servir par le web les clients.

Nous allons nous placer dans le répertoire patch_service dans notre répertoire home :

~/$ mkdir ~/patch_service
~/$ cd ~/patch_service

Puis installer tout ce dont nous avons besoin pour le serveur de patchs :

~/patch_service$ patch_gen createNewProduct patch_game/ryzom.xml

Cela va mettre en place fichiers et dossiers essentiels :

  • patch_service/
    • bnp/
    • patch/
    • ref/
    • ryzom.xml

Nous allons ensuite copier nos fichiers bnp dans le répertoire qui leur est assigné (dont on imagine qu'ils sont stockés dans un répertoire ~/bnp :

~/patch_service$ cp ~/bnp/*.bnp patch_game/bnp/

Pour notre exemple, il n'y aura qu'un fichier indiqué par la suite, appelé patch_lirria.bnp

Il faut ensuite créer un fichier vide, qui servira à l'indexation des patchs. Il est formé du nom du shard (nous prendrons Lirria comme exemple ici, vu que c'est le nom du shard de développement de Khaganat), suivi de .version, et sera placé dans le répertoire patch_game :

~/patch_service$ touch patch_game/Lirria.version

Configuration du serveur de patchs

Il faut ensuite éditer le fichier patch_service/ryzom.xml :

~/patch_service$ nano patch_game/ryzom.xml

Des explications détaillées sur la syntaxe de ce fichier sont données dans un autre article (La syntaxe du fichier xml du serveur de patch), et nous nous contenterons de créer ici la mise en place du seul patch_lirria.bnp, prévu pour copier dans le sous-répertoire du client /user des données pour faire des tests.

Notre fichier de configuration ressemblera donc à ça :

ryzom.xml
<xml>
	<_Categories>
		<_Category>
			<_Name type="STRING" value="khanat_lirria"/>
			<_IsOptional type="SINT32" value="0"/>
			<_UnpackTo type="STRING" value="./user/"/>
			<_IsIncremental type="SINT32" value="1"/>
			<_Files type="STRING" value="patch_lirria.bnp"/>
		</_Category>
	</_Categories>
	<_IndexFileName type="STRING" value="ryzom.hist"/>
	<_PatchDirectory type="STRING" value="patch_game/patch/"/>
	<_BnpDirectory type="STRING" value="patch_game/bnp/"/>
	<_RefDirectory type="STRING" value="patch_game/ref/"/>
	<_NextVersionFile type="STRING" value="patch_game/Lirria.version"/>
	<_ClientIndexFileName type="STRING" value="ryzom"/>
</xml>

Les paramètres indiqués permettront d'incrémenter peu à peu le contenu de notre .bnp, en y ajoutant de nouveaux fichiers, et le fichier bnp, après avoir été téléchargé par le client, sera dépaqueté dans /user pour y être pris en compte en dernier (pour écraser d'anciennes versions de fichiers par exemple, bien pratique pour faire des tests).

Activation du serveur de patch au niveau de la base de données

Le système se basant sur une base de données, il faut lui faire savoir que nous activons le serveur de patch. Pour cela, nous allons utiliser des commandes dans MySQL.

Nous partons du principe que le numéro de votre domaine est 12, dans le cas contraire, changez la valeur. D'abord activer le serveur de patch (en mettant la valeur de patch_version à 1 au lieu de 0, par défaut)

USE nel;
UPDATE DOMAIN SET patch_version=1 WHERE domain_id=12;

Puis indiquer l'adresse du serveur dans le champs patch_urls:

USE nel;
UPDATE DOMAIN SET patch_urls='http://lirria.khaganat.net/patch' WHERE domain_id=12;

Création du premier patch

Il nous faut désormais créer le premier patch, qui fournira le bnp dans son état originel au client.Nous réutilisons la même commande, mais avec une instruction différente cette fois :

~/patch_service$ patch_gen updateProduct patch_game/ryzom.xml

Il est possible que vous ayez un warning durant cette opération, mais cela semble sans gravité.

WRN a8ded740 patch_gen_common.cpp 59 GeneratePatch <Unknown> : 'xdelta delta patch_game/empty patch_game/bnp/patch_lirria.bnp patch_game/patch/00001/patch_v1_00001.patch' failed with error code 256

L'essentiel est d'arriver au bout : Generating client index: patch_game/patch/00001/ryzom.idx…

Création de la Release Note

On peut créer un fichier à la racine de patch qui servira à diffuser des informations sur les données patchées. Ce peut-être un fichier php, qui peut recevoir de la part du client plusieurs informations :

  • version : la version du patch ;
  • lang : la langue du client ;
  • ca : le Shard de connexion
  • startPage : à définir

Imaginons que nous créons un fichier html tout simple.

~/patch_service$ nano patch_game/patch/index.php
index.php
<html><head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
  <h1>De nouvelles données de test</h1>
  <p>Nous installons de nouvelles données de test dans le répertoire /user de votre client de jeu. Merci de nous aider à tester le déploiement d'un serveur de MMORPG libre</p>
</body>
</html>

Le contenu est désormais prêt à être diffusé, reste à le faire savoir aux clients.

Configuration du serveur Apache

Nous partons de l'hypothèse que vous possédez déjà un serveur Apache fonctionnel, et qu'il s'agit juste de créer un nouveau VirtualHost. Si le répertoire home de l'utilisateur qui gère le serveur est nommé gameserver, il devra avoir ces paramètres (sinon adaptez selon vos paramètres) :

Notre souhait est d'avoir une adresse simple, sans port pour le serveur de patch, qui sera donc de la forme http://lirria.khaganat.net/patch (notre serveur de jeu étant installé à http://lirria.khaganat.net).

Il nous faut donc d'abord installer certains modules pour Apache (si ce n'est déjà fait par avance) :

~/patch_service$ sudo a2enmod proxy
~/patch_service$ sudo a2enmod proxy_http

Nous ajoutons ensuite dans le VirtualHost qui écoute le port 80 la ligne :

ProxyPass       /patch/ http://lirria.khaganat.net:43435/

Puis nous définissons notre Virtual host dédié ainsi :

<VirtualHost *:43435>
ServerName lirria.khaganat.net
DocumentRoot /home/gameserver/patch_service/patch_game/patch/
 
  <Directory "/home/gameserver/patch_service/patch_game/patch">
     Options -Indexes 
     AllowOverride All
     Require all granted
  </Directory>   
 
</VirtualHost>

L'Option -Indexes bloque l'affichage des répertoires par défaut par souci de sécurité.

Ouvrir le port 43435 dans Apache

~/ sudo nano /etc/apache2/ports.conf

Y ajouter la ligne suivante :

Listen 43435

Une fois tout cela terminé, on relance le service Apache :

~/patch_service$ sudo service apache2 restart

AU cas où les droits sur les fichiers ne seraient pas bon et bloqueraient Apache, vous pouvez les réattribuer correctement : ~/patch_service$

~/cd ~/patch_service && sudo chown -R compil:www-data patch_service | chmod g+w -R patch_service

Annoncer la mise à disposition du patch

Il faut ensuite avertir les clients que ce patch numéro 1 est prêt à être distribué, on le fera à l'aide d'un nouveau fichier Lirria.version (il y en aura donc deux avec celui précédemment créé) situé dans le répertoire patch servi par Apache :

~/patch_service$ nano patch_game/patch/Lirria.version

Il suffit d'y indiquer juste (1 - espace 1 - retour chariot):

1 1

, pour dire que le patch numéro 1 est prêt. À l'avenir, il suffira de mettre 2 pour servir le patch 2 etc.

Le second chiffre est celui qui est passé à la page php pour version, on le change en même temps donc.

Configuration du client

Pour que le client puisse accéder aux patchs, il existe deux cas.

Client DEV

Il est mieux de lui indiquer les paramètres dans son client_default.cfg. On veillera donc à la présence des ces lignes :

PatchWanted          = 1;
PatchUrl = "http://lirria.khaganat.net/patch";
RingReleaseNotePath = "http://lirria.khaganat.net/patch/index.php";

Il s'agit bien désormais de PatchUrl et non plus PatchServer, qui est obsolète.

La dernière renvoie vers le fichier que nous avons créé pour les Release Notes.

Client FV

Le client FV doit être compilé avec l'option WITH_RYZOM_PATCH pour avoir accès au serveur de patch. Sans aucune autre option indiquée, il se connectera automatiquement sur le serveur de patch indiqué par le serveur (noté ci-dessus dans la base MySQL).

Il ira chercher les releases notes aux adresses hardcodées suivantes :

RingReleaseNotePath = "http://" + WebIgMainDomain + "/releasenotes_ring/index.php";
ReleaseNotePath = "http://" + WebIgMainDomain + "/releasenotes/index.php";

Il faudra donc bien veiller à ce que l'adresse WebIgMainDomain soit correctement renseignée dans le client_defaut.cfg

SI le client FV a reçu aussi l'option WITH_RYZOM_CUSTOM_PATCH_SERVER, il se comportera comme le client DEV et devra se voir dôté des lignes nécessaires dans son client_default.cfg :

PatchWanted          = 1;
PatchUrl = "http://lirria.khaganat.net/patch";
RingReleaseNotePath = "http://lirria.khaganat.net/patch/index.php";

Enjoy !

Avec cette configuration, veillez bien à ce que votre répertoire unpack soit vide de tout fichier .version ou .idx pour ce premier patch. Par la suite, le système conservera trace des patchs reçus dans ce répertoire, veillez donc bien à conserver ces fichiers (sous peine de devoir repatcher votre client de 0). Avec notre exemple, les nouveaux éléments seront automatiquement décompressés dans votre user lors du redémarrage du client après le téléchargement.

Il ne vous reste plus qu'à lancer votre client de jeu et le voir se patcher !

Si vous travaillez à partir de dépôts comme nous pour les mises à jour des données du serveur et du client, vous pouvez aller voir comment créer rapidement les patchs lors de la mise à disposition de nouvelles données : Mises à jour des données de jeu pour le serveur Lirria

fr/installation_d_un_serveur_de_patchs.txt · Dernière modification: 2018/08/06 14:18 par zatalyz