Si vous souhaitez déployez un site similaire à Khaganat, la page Faire un site web comme Khaganat, qui détaille d'une façon plus “tutoriel”.

Cette page est destiné à tous ceux qui souhaiteraient nous aider à améliorer notre ensemble de sites web.

La charte graphique est sur une autre page.

Nous sommes un projet bénévole. Cela veut dire que nous dépendons des bonnes volontés, du temps et des compétences de chacun pour fonctionner.

Dans ce cadre, nous avons quelques principes à respecter, énoncés ci-dessous.

Il est possible que quelqu'un maîtrisant “tout” le site web parte du jour au lendemain. C'est normal : on est libre, et on en maîtrise pas non plus les aléas de la vie qui peuvent nous éloigner.

Mais dans ce cas, que deviens le travail de celui qui part ? Pour que les suivants puissent continuer ce qu'il a fait, il faut que tout soit facile à maintenir.

Cela veut dire :

• Documentez, encore et encore, à chaque test et nouveauté. C'est parfois difficile, c'est souvent brouillon et plein de fautes, mais mieux vaut une doc médiocre que pas de doc du tout, donc notez sur le wiki lorsque vous faites des choses ! Pour le site web, certaines données sont sur le wiki des admins (privés) mais nous tentons de transférer ici toutes les informations qui ne sont pas sensibles.
• Préférez un outil simple et facile à prendre en main à un outil complet mais complexe. Imaginez que quelqu'un n'ayant aucune notion de html soit chargé de gérer le site. Est-ce qu'il peut accomplir la maintenance et la réinstallation avec ces outils et la doc ?
• Limitez la nécessité de bidouiller et pensez aux backups. Si le serveur ou le site subit un aléa, en combien de temps un noob complet peut-il tout remettre en place, de la même façon ?

Nous utilisons Teampass pour partager les mots de passe. Si une application est en place, utilisée, pensez à mettre les mots de passe à jour pour ce qui concerne la partie admin, par exemple le nom de la base de donnée et son mot de passe. Nous pouvons facilement faire des groupes pour que les mots de passes ne soient partagés qu'avec certaines personnes (par exemple, entre sysadmin).

Lorsque les applications le permettent, donnez les droits d'administration à une des autres personnes considéré comme étant de confiance.

C'est un des choix délicats à propos de la sécurité. Partager le pouvoir et utiliser Teampass augmente un peu les risques, mais permet aussi de ne pas trop perdre de choses lorsque un admin disparaît.

Je me répète, mais c'est vraiment vital pour reprendre derrière…

Note pour ceux que le mot “documentation” effraie : le principal est de savoir ce que vous avez fait et comment. Indiquer les liens vers les tutoriels que vous avez suivi est très bien et suffit ; précisez si vous les avez suivi à la lettre ou si l'architecture de Khaganat vous a demandé d'adapter certains points, c'est tout.

Vous avez le droit d'utiliser ce que vous voulez pour naviguer, créer, jouer… Par contre, les outils que promeut Khaganat doivent être libres et hébergeables. Nous voulons garder le “contrôle” sur nos données et laisser chacun libre de réutiliser notre travail. Nous acceptons de relayer nos infos sur les plate-formes propriétaires (youtube, dailymotion, facebook, github), mais nous n'en faisons pas la promotion pour autant et nous vous invitons, autant que possible, à venir “à la source”¹⁾.

Donc si vous voulez nous proposer un outil, une fonctionnalité, veillez à sa licence. Nous ne travaillerons pas sous Slack et Asana.

Nous n'hébergeons pas forcément tous nos outils, mais nous essayons de le faire aussi souvent que possible. Nous utilisons le réseau IRC de Freenode, par exemple, et les services de Lut.im régulièrement, mais ces services sont libres et nous pourrions aussi les mettre sur le serveur… simplement le service offert par ces organismes et leur philosophie nous conviennent²⁾.

Actuellement, nous avons des éléments web répartis sur plusieurs serveurs :

• Une VPS hébergeant la majorité des services web
• Un serveur kimsufi sur lequel on trouve Gitlab et Owncloud
• Un serveur de jeu, qui héberge aussi les comptes des joueurs et donc l'application pour créer leurs comptes.

Nous avons prévu de tout rassembler sur un seul serveur plus puissant, séparé en VM, mais à l'heure où cet article est écrit, ce n'est pas encore fait.

Nous avons aussi deux espaces de test : un qui est la réplique de la vps web, un autre qui est le “crashtest” du serveur de jeu.

Au 14 juin 2016, nous avons les CMS suivants qui sont installés (voir plus bas pour le détail) :

• Dokuwiki, sous forme de “ferme”
• Simple Machine Forum
• Stikked
• Etherpad-Lite
• Photoshow-gallery
• Gitlab (sur le serveur kimsufi)
• Owncloud (sur le serveur kimsufi)
• AMS (sur le serveur de jeu)
• Limnoria
• Piwik
• Fusion-directory
• Phpldapadmin
• Teampass

Nous avons quelques pages “faites maison” :

• La partie IRC
• La barre de navigation générale, qui se retrouve sur presque toutes les pages du site
• Le convertisseur Dokuwiki vers Mediawiki

Dokuwiki est un excellent moteur de wiki.

Il est organisé sous forme de ferme. Cela veut dire qu'il y a un wiki “maitre”, où le moteur est installé, et des wiki “animaux” qui contiennent uniquement les datas et quelques particularités (genre certains thèmes ou plugins). Tous ces animaux utilisent la même base d'utilisateur.

Voici la liste des animaux :

• bienvenue qui héberge la page d'accueil, les mentions légales et la page de contribution. Bien que ce soit techniquement un wiki, sa modification est réservée aux membres du Collège de l'association et sa présentation imite un site statique.
• wikhan : c'est le wiki sur lequel vous vous trouvez. Il héberge la documentation généraliste.
• blog : le blog, avec certains plugins qui permettent d'avoir des fonctions de blog. Cela permet à tous les inscrits de poster un article de blog.
• mediateki : Ce wiki est destinée à recevoir des histoires sur le monde de Khanat.
• um1 : c'est l'encyclopédie du monde de Khanat. Les onglets animation, dev et gameplay hébergent aussi des informations concernant le serveur de jeu (comme les quêtes).
• un wiki spécial administrateurs, avec des infos sensibles donc pas accessible au public !
• des vieux tests qu'il faudrait que j'archive et nettoie un jour et qui sont sans importance dans le cas présent…

Dokuwiki utilise actuellement LDAP pour la connexion des membres : un même identifiant et un même mot de passe sur chaque partie.

Pour plus d'informations techniques, voyez Dokuwiki, ferme de wiki

• Nous aurions besoin de refaire les templates des wiki. Nous sommes basés sur une vieille version qui ne prends pas en compte de nouvelles fonctionnalités du moteur (qui lui, est à jour) et ça a été modifié à la R.A.C.H.E. De plus, ça ne passe absolument pas sur mobile… Bref, si vous maîtrisez le css, le html et un chouïa de php, ça devrait bien se passer !
• Certains plugins qui nous étaient utiles ne sont plus maintenus et ont été cassés lors de mises à jour. Si vous avez envie de les reprendre, toute la communauté Dokuwiki en profiteras. Cela demande de bonnes connaissances en PHP et l'envie de bien comprendre comment fonctionne Dokuwiki.

Notre forum.

Notre choix en matière de forum se base sur deux choses :

• Un certain attrait pour le visuel “phpbb2”. Non, je n'aime pas ces trucs à la mode sans catégorie et avec l'avatar qui n'est pas à gauche du texte.
• La nécessité de pouvoir lier un compte principal à plusieurs sous-comptes. À terme, l'idée est de se connecter avec son compte utilisateur (le même que pour les wikis, le jeu, etc) mais de pouvoir intervenir sur le forum soit sous ce pseudo, soit avec le pseudo de ses personnages en jeu, afin d'aider le roleplay. SMF propose un plugin gérant les sous-comptes, qui n'est pas vraiment à jour mais qui fonctionne tout de même.

En dehors de ça, nous sommes ouverts aux suggestions. SMF est sympa, mais pleins de fonctionnalités dont nous n'avons pas vraiment l'usage, finalement… Et dans l'absolu, nous aimerions un forum offrant d'autres fonctionnalités aux joueurs, comme le fait d'héberger son sous-forum de guilde directement, lié aux persos, avec la possibilité de mettre des parties publiques et d'autres privées. Le Forum-CMS de nos rêve est un vague projet, qui demanderait un vrai programmeur.

La seule chose qui nous manque réellement sur le forum, actuellement, c'est de pouvoir lier ça à une connexion unique. Voir plus bas.

Stikked est une forme de pastebin. Rien de particulier à dire dessus, il fait son travail ; il est remplaçable aussi. Le pastebin nous sert régulièrement au sein du projet.

Le seule souci, c'est le captcha, qui est illisible et laisse passer les bots par moment. Mais bon… C'est assez secondaire, on finit par arriver à le passer.

Une installation d'Etherpad, avec quelques plugins, dont “Mypads”. Il est lourd, il prend de la mémoire et dernièrement il finissait par faire planter le serveur donc on l'a désactivé en attendant de migrer sur une machine plus puissante. Les pads nous servent souvent, cet outil est donc vraiment utile pour nous.

Pouvoir le lier à l'authentification unique serait pratique, mais ça marche sans aussi, donc…

Ce CMS sert à héberger nos images. Il nous a rendu service, mais à présent il correspond de moins en moins à nos besoins. Je ne lui ai pas trouvé de remplaçant.

J'apprécie le fait qu'il fonctionne sans base de donnée. Mais sinon :

• Je ne vois pas comment le lier à l'authentification unique et ça m'embête
• J'aimerais bien que ça puisse se lier aux guildes et aux comptes joueurs, qu'il y ait automatiquement la possibilité d'héberger des images privées et publiques pour ces deux types de comptes.
• Les media associés à des tags, c'est sympa aussi
• Une meilleure gestion du cache et de la prévisualisation. En l'état, c'est vite lourd à charger, surtout que la VPS rame.
• Mettre en avant des galeries, genre en page d'accueil “les meilleurs screens du moment” en diaporama.
• Pouvoir y héberger aussi nos vidéos, même avec un player très basique.

Bref il nous faudrait de quoi gérer les médias. Si vous connaissez un bon truc pour ça, parfait. J'ai testé quelques CMS, dont Piwigo (l'un des meilleurs dans le lot) sans être complètement convaincue pour autant.

Gitlab sert à gérer les dépôts. Il prend beaucoup trop de ressources, mais il est vraiment très utile aussi…

Actuellement, nous sommes dépendants de Dremor sur cette partie. Nous attendons la doc, et un serveur plus puissant afin de faire des tests sur un gitlab qui n'est pas en production…

Sinon ça marche, et c'est connecté à LDAP.

Owncloud ne nous sert qu'à échanger quelques fichiers entre membres de l'équipe, de façon temporaire. Son utilité est discutable. C'est plus pratique à utiliser pour des gens qui ne maîtrisent pas les dépôts et veulent juste partager vite fait un travail en cours. Rien n'est destiné à rester sur Owncloud, car son accès reste privé. Les fichiers utiles sont destinés à aller soit sur Gitlab, soit dans un des wikis, soit dans la galerie photo. Les fichiers temporaires sont voués à disparaître…

Ça marche, et c'est connecté à LDAP.

AMS est l'outil web de Ryzom Core qui sert, entre autre, à gérer les comptes des joueurs sur le serveur de jeu.

Il n'est pas finalisé et mal documenté… Voir plus bas “Développements futurs”.

Ce n'est pas vraiment visible sur le site mais c'est installé… C'est notre logiciel pour gérer les bots sur IRC. Un bon logiciel, riche en possibilité :)

Nous sert à avoir une vague idée de l'audience du site. Vague, car nous nous refusons à pister nos utilisateurs (nous respectons les “do not track” et nous ne lions pas ça à Google). Son utilité est très secondaire pour le moment, et il marche tout seul.

Permet de partager des mots de passe de façon relativement sécurisée. Je serais curieuse d'avoir un audit sur le code, mais nous n'avons pas les moyens de le faire… Indispensable, sinon les mots de passes se promènent en clair, et ça, ça ne se fait pas.

La barre en haut. Nous avons récupéré et customisé la Framanav, d'une façon assez “sale”. Résultat, cette barre nous pose des soucis, en faisant appel à des classes et/ou des fonctions qui sont aussi utilisées dans les CMS, ce qui met le boxon régulièrement. Sinon, on aime bien la façon dont elle fonctionne. Même si je me demande si niveau accessibilité, elle est correcte…

La refaire proprement serais un plus.

Nous souhaitons qu'un utilisateur utilise le même couple mot de passe/pseudo sur tous les éléments du site web. Cette partie là est globalement gérée par LDAP, même si c'est utiliser un marteau pour écraser une mouche. Dans cette optique, nous avons installé Fusion-directory et Phpldapadmin qui sont complémentaires pour gérer la base de façon graphique…

Nous aimerions surtout que l'utilisateur ait, dans la barre de navigation en haut, la possibilité de “se connecter/s'inscrire”, ce qui le redirigerait vers une page de connexion/inscription (ou ouvrirait une fenêtre dépliante ?) et qu'une fois son compte créé/connecté là, il soit d'office connecté sur les divers éléments du site, de dokuwiki à gitlab en passant par smf et autres.

Il semblerait que Oauth2 permette ça. Gitlab fournit justement un serveur Oauth ; dokuwiki et owncloud semblent pouvoir utiliser ce protocole aussi. D'après un webadmin qui nous a présenté cette solution, connecter un CMS qui n'a pas de plugin Oauth n'est pas très complexe ; c'est ce qu'utilisent Google, Facebook etc et donc il suffit de modifier ce genre de trucs.

Il y a un gros boulot à faire de ce côté.

Nos chantiers prioritaires sont :

• Trouver et mettre en place une autre solution d'hébergement (en cours… sans doute en juillet ?)
• Le chantier de longue haleine de l'authentification unique
• Bidouiller Django pour les API avec le serveur de jeu

Django est un framework en python. Nous avons des développeurs en python.

Les API fournis avec Ryzom Core sont un sacré bazar. Sans documentation, rarement finies, impossibles à déployer, elles sont, en l'état, inutilisable. Il est apparu que ce serait moins long et plus facile de tout reprendre à zéro, ce que certains se proposent de faire au sein de l'équipe. Il est possible que les possibilités de Django soient aussi mises en œuvre pour le forum et le gestionnaire de média ; en fait, pour faire un CMS adapté à nos besoins. À condition toutefois que la documentation et la maintenabilité soient là…