Aller au menu du forum Aller au contenu du forum Aller à la recherche dans le forum
Logo Khaganat
Menu principal

Derniers messages

Dernier message par neodarz - 09 Août 2018 à 13:53:00
Cliquez pour afficher le message
Salut,

Techniquement searx intègre déjà un crawler maison (de ce qu'ai je compris à l'arrache lors de la création de mes crawlers perso pour le searx de khaganat) afin d'aller chercher les infos des moteurs de recherches.

Je vais voir comment fonctionne scrapy mais il y a des chances que searx intègre scrapy dans son crawler maison, il faut que je me renseigne à ce sujet.

Dans l'idée il faudrait un soft qui permet de crawler + indexer les résultats. J'ai testé YACY (https://yacy.net/fr/) qui fait ce genre sur deux/trois des sites de khaganat et ça marchait plutot bien mais j'ai pas trop réussi à le faire fonctionner comme je souhaitais...

Pourquoi indexer ? On va éviter de crawler tous les sites à chaque recherche non ?  :smiley2:

Ah et YACY c'est fait en JAVA donc je suis pas trop pour, j'ai pas envie de jouer avec du JAVA...
Dernier message par Zatalyz - 24 Juillet 2018 à 16:37:11
Cliquez pour afficher le message
Neodarz nous avait préparé une installation de searx pour faire de la recherche globale sur plusieurs sites autour de Khaganat, Ryzom, Ryzom core (trouver la doc !) : https://git.khaganat.net/neodarz/ryzomcore_searx

Le besoin d'un méta-moteur continue de se poser. Certaines parties de notre site ne sont pas bien indexées par les moteurs traditionnels, et si vous cherchez "site:khaganat.net brumes" sur votre moteur préféré, vous ne verrez rien venir du forum par exemple (alors que la recherche interne du forum ne marche pas trop mal). Si vous chercher un nom d'utilisateur sur le gitlab... vous n'allez pas avoir son profil, la liste de ses projets, ses contributions, ses issues... ou alors un peu, si vous avez de la chance. Le moteur de recherche interne de gitlab est pourri et c'est une volonté : le "bon" moteur est dans la version payante.

Searx répond au besoin d'agglomérer les résultats des divers moteurs internes, mais il n'a pas de crawler interne (ou araignée, c'est plus joli). Donc ça ne résous pas le souci de gitlab. Il faudrait donc ajouter un crawler, que Searx peut ensuite interroger ; ou faire un crawler qui récupère tous les sites.

J'ai commencé à regarder un peu https://scrapy.org/ , qui est en python. Je vous avoue que j'ai mis de côté les crawlers en java, peut-être à tort.

Je ne peux pas tester beaucoup plus avant, j'ai cassé Nuxru pour le moment et ma vm de test était dessus. De votre côté, si vous avez déjà croisé des trucs de ce genre, si vous connaissez des solutions à cette problématique, laissez vos infos ici :)
Dernier message par Zatalyz - 22 Juillet 2018 à 11:59:45
Cliquez pour afficher le message
Je suis en train de chercher une solution automatique pour les gens qui vont débarquer sur IRC après notre passage à XMPP (car il y en aura).

Ce que j'ai pu trouver d'utile :
http://web.archive.org/web/20080305043840/http://supybot.sourceforge.net:80/docs/plugins/Utilities.html
http://web.archive.org/web/20080227013210/http://supybot.sourceforge.net:80/docs/plugins/Note.html
http://web.archive.org/web/20090204171755/http://supybot.sourceforge.net:80/docs/plugins/Scheduler.html
et
https://github.com/ProgVal/Supybot-plugins/tree/master/Trigger

L'idéal serait que si quelqu'un se connecte ET parle, son premier message donne lieu à une réponse de pendorid, lui expliquant qu'on est sur XMPP. mais uniquement un message par jour par personne, sinon bonjour le flood. Ça élimine le trigger "si quelqu'un se connecte" car il y a des gens qui co/déco régulièrement (réseau instable). Faire aussi une whitelist avec les gens déjà prévenus et sur XMPP serait un plus, j'ai pas envie de me faire spammer si je débarque pour aider une perdue ;)
Dernier message par Zatalyz - 29 Juin 2018 à 22:15:02
Cliquez pour afficher le message
Artefact = artifact en anglais, ça aide pour les recherches.

Mon hypothèse actuelle est qu'il y a un ou des timeouts à régler dans /etc/gitlab/gitlab.rb. Mais je vais avoir besoin de plus de détails pour savoir ce qui est en cause. Typiquement : minuter et me dire quand ça plante, si c'est 30s, 1mn ou 1heure ça donne de sacrés indices. Les messages d'erreur complet, l'heure et la date si possible.

Comme je ne serais pas là jeudi, mieux vaut me laisser les infos ici, je verrais dès que je peux... Si Shepeng est là ce jour là et a envie de regarder, par rapport à la doc de gitlab, notre installation est celle baptisée "omnibus" :)

Log du soir à propos du souci.
Spoiler for Hiden:
<aleajactaest> petite question concernant le serveur gitlab.
<aleajactaest> est-il possible d'avoir plus de disque
<aleajactaest> quand j'envoie un artefact de 3.1 Go, il plante
<aleajactaest> cela passe à 2.9 Go, mais on doit etre limite
<aleajactaest> bref on a besoin de disque pour permettre d'avoir une image docker disponible (une image docker ~3Go)
<Zatalyz> je ne suis pas sûre qu'il s'agise de l'espace sur le disque, il doit y avoir un paramètre qui bloque, plutôt
<Zatalyz> parce qu'on a 485Go sur ce disque et il n'est plein qu'à 11%
<Zatalyz> Ok, je pense qu'il te le met en mémoire probablement sur le disque de l'OS et non dans les dépôts
<aleajactaest> ok, donc, je me suis trompé sur cette analyse
<aleajactaest> peux-etre un timeout pendant le transfert d'un artefact
<Zatalyz> et le disque de l'os n'est pas aussi gros, ça correspondrait au niveau des chiffres
<Zatalyz> je vais regarder 1) si y'a pas de la place à faire sur ce disque (c'est quasi sûr) et 2) s'il ne peux pas calculer ça ailleurs
<Zatalyz> étant donné que je ne sais pas trop ce qu'est les artefacts... c'est vraiment juste une archive avec un nom qui se la pète ?
<aleajactaest> ok
<Zatalyz> ha mais non ça correspond pas ^^ bon c'est pas grave, y'a de la place en plus
<Zatalyz> (y'avait 17Go de libre sur le disque de l'os, maintenant y'en a 20)
<Deed> ca doit etre dans les option gitlab
<Deed> voir peut etre une limite technique interne
<Zatalyz> ouais, je trouve des trucs sur où ils sont stockés, mais pas une limite de taille... je vais plonger plus loin dans la doc
<Zatalyz> Un doute me viens... vous savez comment on peut vérifier en quel format le disque est ? genre je l'aurais mis en fat32 ? non, bon, je n'y crois pas trop mais...
<Zatalyz> https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#maximum-artifacts-size
<Zatalyz> Ok, actuellement c'est réglé à 5000MB
<aleajactaest> un artefact est en réalité un fichier zip
<aleajactaest> il s'agit du résultat de la compilation
<Zatalyz> ça devrait passer pourtant :s
<merlin8282> Zatalyz: la commande mount
<merlin8282> sans aucun paramètre
<merlin8282> ça t'affiche tous les systèmes de fichiers montés ainsi que leur type
<Zatalyz> merci. C'est de l'ext3 sur l'OS, et de l'ext4 sur les dépôts. Et me demande pas pourquoi ^^
<Zatalyz> l'ext3 n'a pas de limites de taille comme le fat ?
<Zatalyz> enfin pas à 4Go
<Zatalyz> Je suis désolé, je ne comprends pas pourquoi ça bloque... je peux (et vais) mettre ça sur l'autre disque, mais ptet pas ce soir parce que je suis en mode faire des bêtises
<Zatalyz> cependant, ce n'est pas la place qui manque vu les tailles que tu me dit
<merlin8282> non, pas vraiment de limite sur ext3
<merlin8282> enfin pas aussi basses
<merlin8282> c'est de l'ordre du To pour un fichier, je crois
<aleajactaest> pour info, je ne suis pas chez moi, donc tu as le temps pour trouver d'ou provient l'erreur
<merlin8282> (si déjà sur du fat32 c'est 2 Gio la limite, faut pas déconner hein)
<aleajactaest> je pourais faire un test jeudi soir
<Zatalyz> Si je résume : gitlab autorisait des artefacts de 4,88GB, je suis passé ce soir à 9,77GB
<Zatalyz> Il y avait minimum 17Go d'espace disque
<merlin8282> Zatalyz: en ext3 la taille max d'un fichier c'est au moins 16 Gio : https://fr.wikipedia.org/wiki/Ext3
<merlin8282> regarde le tableau de droite
<Zatalyz> et ton image faisait 3.1Go
<Zatalyz> Je ne vois pas ce qui a pu coincer :s
<Zatalyz> si vous avez des idées, je teste
<Zatalyz> peut-être la compilation, le serveur moulinait trop, trop longuement, et il a décidé de couper le bazar ?
<aleajactaest> je ferai un test jeudi prochain pour retrouver le message d'erreur
<merlin8282> je savais même pas que gitlab permettait ça... Je suppose que ça fait partie de la partie CI/CD ?
<merlin8282> mmm, c'est peut-être aussi un manque de RAM / swap ?
<aleajactaest> oui, il s'agit de la partie CI/CD
<aleajactaest> il plante pendant le transfert du fichier
<aleajactaest> l autre idée était le timeout de la connexion
<Zatalyz> Hum pourquoi pas... je ne sais pas où ça se règle, ça
<Zatalyz> (y'a du bordel dans les logs de gitlab, je vous raconte pas...)
<aleajactaest> j'ai trouvé le message
<aleajactaest> WARNING: Uploading artifacts to coordinator... failed  id=1309 responseStatus=502 Proxy Error status=502 Proxy Error token=DxnVa2sT
<Zatalyz> je ne trouve rien avec un 'grep -nri "DxnVa2sT" /var/log/gitlab/* '
<Zatalyz> Après, proxy... ça peut être avant
<aleajactaest> bon je ferai un test jeudi soir, on regardera en live
<aleajactaest> bonne nuit
<Zatalyz> ok
<Zatalyz> bonne nuit alea !
<Zatalyz> sauf que jeudi je serais sur la route, je viens de percuter... ^^"
<Zatalyz> sauf s'il fait ça avant 10h :D
<Zatalyz> Je vois plusieurs trucs pour gérer les timeouts dans la config... Mais il va me falloir des infos plus précises
Dernier message par Zatalyz - 27 Avril 2018 à 12:05:24
Cliquez pour afficher le message
Bonjour les Mages !

Ce sujet fait écho à cet aspect du cahier des charges : https://khaganat.net/wikhan/fr:gamedesign:khanat:start#gestion_de_compte

Pour les aspects web, ça se réglera au fur et à mesure, ce n'est pas vraiment le problème ; le travail de Tycho Brahe sur Django est un pas dans la bonne voie.

Mais il y a l'aspect client de jeu. En effet, il faudrait qu'on puisse lancer le jeu, se connecter avec son compte "joueuse", et de là choisir son perso en cassant la limite actuelle de "5 perso max par compte ; si un compte est connecté, impossible de connecter un des autres perso".

La solution propre et longue demanderais de réécrire le client. Pourquoi pas, un jour.

Mais j'ai l'idée d'un hack beaucoup plus simple, qui pourrait rapidement être mis en place.

L'idée est de faire une surcouche. C'est à dire de créer un lanceur (dans le langage de vos rêves, ou de reprendre ce que Ryzom a fait si c'est utile ?), indépendant du client. Ce lanceur permet de connecter son compte Khaganat (compte joueuse, donc), puis d'afficher la liste des personnages liés à ce compte, qu'on devrait pouvoir récupérer de la BDD, ainsi que de proposer la création d'un personnage.

Au moment où on choisit un personnage/on créé un personnage, alors le lanceur lance un client de jeu. Ce client-là reçoit automatiquement des infos de connexion (rien à entrer) et sélectionne le premier personnage. Ce qui veut dire que chaque sous-compte n'aura qu'un seul personnage, en fait.

Un petit schéma pour tenter d'expliquer...

https://liev.re/cloud/s/7m9ngh6MQlCGZoZ

Cela veut dire plusieurs choses :

Primo, il n'y a pas besoin de trop toucher aux clients de jeu actuel. Il faut juste trouver
- comment lancer automatiquement le slot 0
- comment créer automatiquement un compte dans la BDD. Il faut absolument enlever l'obligation du mail.
- comment lancer directement le créateur de personnage.
- quel appel envoyer pour supprimer un compte.
Et c'est tout côté client actuel, oui oui.

Secundo, côté lanceur maison, il faut construire un truc de zéro mais c'est assez basique et ne demandera pas un dev expert. Le plus compliqué sera l'habillage graphique mais y'a des bibliothèques pour ça. La gestion du compte devra se faire via la BDD de django.
Cela veut dire :
- une base de donnée qui sait que le compte général a accès aux comptes de jeu "clients X, Y , Z", et qui enverra ces infos au client de jeu (notez bien : l'association "compte général-comptes de jeu se fait côté maison, pas côté client de jeu, ce qui permettra de gérer la sécurité des comptes en amont de façon moderne avec django), qui peut aussi récupérer le nom des persos pour l'afficher.
- la possibilité, en cliquant sur "jouer" et "créer un perso", de lancer le client avec l'option correspondante. Dans le cas de "supprimer", c'est juste un envoi à la BDD pour vider l'info en question.
- les options "créer un compte", "mot de passe perdu", "Aide" renvoient toutes à la gestion générale des comptes, via Django.
- l'option "paramètres" doit permettre de gérer a priori la configuration graphique du client, afin de pouvoir le lancer en mode "minimum" si besoin. C'est secondaire pour le moment. Notez qu'il s'agit en principe juste de changer le fichier "client.cfg".
- Pour le moment, pas de prévisualisation 3d des persos, on se contentera d'afficher leur nom. Dans un second temps, je pense qu'on peut facilement associer un portrait à chaque nom, et dans un 3e temps ce sera possible de remettre la version 3d si vraiment on y tiens mais... ça ne me semble vraiment pas vital.

Cela veut aussi dire que via le lanceur de base, on peut lancer plusieurs clients en même temps et donc jouer avec plusieurs persos sous le même compte. Cela enlève la restriction de "5 perso max par compte" ainsi que "impossible de jouer 2 persos d'un même compte" : en réalité ces restrictions existent toujours dans le client, mais en tant que joueuse on ne les voit plus.

Il ne me reste que deux soucis.
D'abord, la gestion des patchs. On peut se dire que ça patche lors de la sélection du perso, et comme tout utilise le même dossier, si c'est patché pour un perso, c'est ok ; mais lors des patch il y a redémarrage des clients et dans ce cas précis ça va ptet mettre le bazar. Il faut voir avec nos experts du patch. Peut-être que le lanceur devra lancer un test en amont.

Ensuite, des détails lorsqu'on joue plusieurs perso en même temps (cas où on lance 2 ou 3 fois le client en parallèle sur son ordi. Déjà, ça prend plus de ressource qu'un seul client, donc quand je faisais ça, je mettais tous les paramètres au minimum. Là, est-ce qu'on pourra gérer ça proprement, switcher facilement entre "tout à fond parce que j'ai un seul client" et "tout au minimum parce que j'en lance 3" ?
De plus, gérer plus d'un personnage à la fois c'est prendre le risque de s'emmêler les pinceaux... personnellement je m'aidais un peu en mettant un fond de couleur différent pour mes fenêtres en jeu suivant le compte lancé. Or, pour que ça marche, j'utilisais plusieurs dossiers pour chacun de mes clients car il fallait modifier des fichiers locaux. Là, pourrait-on arriver à quelque chose de similaire sans dupliquer les dossier ?

Les détails à propos du multi-perso ne me semblent pas important pour le moment, mais si vous voyez comment gérer ça proprement, partagez vos idées.
Dernier message par Zatalyz - 07 Mars 2018 à 14:51:44
Cliquez pour afficher le message
J'en suis à une interrogation de design... Et aussi la certitude que je devrais faire de cette fonctionnalité d'onglets un plugin et pas mettre ça dans le code. Mais bon avant que je fasse un plugin faudrait que je lise plus de doc, et comment dire...  :sleep:

Bref, toujours est-il qu'il faut décider de certains comportements.

Option numéro 1 : on ne change presque rien à ce qui existe actuellement
Ça veut dire que :
- les pages "générales" sont sous la forme de lien "fr:page"
- les autres pages sont sous la forme "fr:onglet:page" (donc fr:gameplay:page, fr:animation:page, etc)
À noter que j'ai mis les pages discussions au même niveau que les autres : fr:talk:page (et plus talk:fr:page qui est le truc actuel).

Option numéro 2 : la page générale a son onglet
Ça veut dire qu'on n'aura plus, par exemple, de fr:branaz, mais fr:general:branaz.
La première conséquence c'est que tous les liens externes à l'um1 qui pointe vers une page de l'um1 deviendront faux (faudra rajouter "general"). On peut faire une redirection automatique, par contre : si on arrive sur fr:page, ça redirige en automatique sur fr:general:page. Mais cette redirection auto empêche du coup d'utiliser fr:page pour autre chose. Est-ce bien utile de la bloquer ?
La seconde conséquence, un peu trivial, c'est que je trouve moins intuitif de créer sa page en mettant "general" dans le namespace et que ça alourdit d'autant les liens. Mais bon c'est juste une habitude à prendre.
Enfin, ça demande de déplacer toutes les pages dans l'espace de nom fr ; y'a des outils pour assister ça, mais je ne sais pas trop comment ça va se passer, je crains un peu les soucis (faut pas faire du recursif).

Option bis : les onglets ne s'affichent que dans des espaces de noms précis
Ça, ce serait clairement plus simple si j'en faisais un plugin... bref, vu le fonctionnement de l'um1, les pages encyclopédiques sont intéressantes avec les onglets (branaz, ra, blasa, etc) mais c'est moins vrai dans certains espaces de noms. Les pages sous les espaces de nom tag(génération du menu par catégorie), user (pages persos), wiki (pages d'explication de comment marche le wiki) : on s'en fout des onglets.
C'est un peu plus complexe à faire pour moi mais si c'est un idéal à atteindre, je peux le mettre sur la todoliste. À voir si on s'en fout ou pas.

Il s'agit donc surtout de trancher entre l'option 1 et 2. J'attends vos retours.
Dernier message par Zatalyz - 17 Février 2018 à 18:45:15
Cliquez pour afficher le message
J'ai pas mal avancé ; j'ai même pushé ça :
https://git.khaganat.net/zatalyz/khum1-doku

Depuis le dernier commit j'ai encore ajouté quelques trucs mais bon, flemme, tout ça. Même si ce n'est pas parfait, ça marche relativement bien. Il faut que je peaufine des détails, que je teste ça comme il faut et si c'est bon, je ferais le reste du thème façon Um1. Mon regret est qu'actuellement, vu comme c'est fait, les onglets ne sont pas dynamiques ; je vois bien comment faire pour qu'on déclare les onglets qu'on veut dans l'interface d'admin, mais pas comment les gérer dans le code, donc c'est tout en dur. Et flute. Mais qui sait, je finirais peut-être aussi par m'y attaquer... ou quelqu'un pourra refactoriser ce code qui a au moins le mérite d'être commenté et verbeux à l'extrême.

Alleluia !  :ola:
Dernier message par Zatalyz - 17 Février 2018 à 14:20:42
Cliquez pour afficher le message
Les onglets
Ha ce morceau...

Pour résumer : sur l'um1  nous avons, au dessus des articles, des onglets (général, animation, gameplay etc...). Ce qui est très bien, sauf que cela a été fait il y a plusieurs années, par quelqu'un qui ne maitrisait pas bien dokuwiki et php. Donc, le code est un assemblage de trucs piqués ici et là (dont des morceaux inutiles) et surtout : je ne peux pas remettre le thème à jour parce que cette fonction me bloque. C'est tentaculaire, tel que c'est fait, et je finis toujours par casser des trucs en nettoyant parce que c'est pas clair du tout. Il me faut un truc que je puisse ensuite coller où je veux dans mon nouveau thème. Mais c'est moins trivial que ça n'en a l'air car tous ceux à qui j'ai tenté de confier le job se sont enfuis en hurlant, visiblement rendus fous par les appels à des choses immondes dont nul ne devrait parler.

La problématique est aussi détaillé (avec le code actuel et des idées) ici : https://git.khaganat.net/khaganat/website_jukni/issues/8

Je finirais par y arriver. Si.

Un lien dans l'UM1 ressemble ensuite en gros à ceci (après https://khaganat.net/um1/ ) :
$lang:$tab:<ns>:$id
où :
- $lang est le code de langue déclaré dans le plugin translate
- $tab est le nom des onglets (chez nous, donc, "Général, Animation, Gameplay, Développement, Discussion")
- <ns> : il peut potentiellement y avoir des sous-espaces de nom, même si en théorie, non...
- $id : le nom de la page


En théorie, le lien commence toujours par "$lang:$tab:" et se termine toujours par ":$id".  Et en gros, il faut que j'arrive à générer ces variables proprement, suivant où le visiteur se situe dans l'arborescence.

L'un de mes premiers problèmes est de détecter si on est sur du wiki multilingue, et si oui, prendre l'espace de nom avec le code de lang et le traiter à part. Alors, oui : sur Khaganat le multilangue est activé partout, mais je souhaiterais partager ce thème à la communauté Dokuwiki (quelle ambition) et donc je ne dois pas supposer que forcément, il existe...

Détecter si le plugin est actif, ça se fait comme ça :

if ($translation)
echo "translate" ;
else
echo "notranslate";



Et il y a le code suivant qui me retrouve les langues configurées pour le wiki :
$tab_lang = explode(" ", $conf["plugin"]["translation"]["translations"]) ;


Seul souci, je ne sais pas comment traiter ce que je reçois avec explode. Ok, je récupère "en", "fr" et autre ; je sais que comme la condition du plugin existant est rempli, je trouve ça en début de chaine. Mais je ne vois pas trop la suite. Probable même que ça ne me serve à rien, tout ça...
Dernier message par Zatalyz - 17 Février 2018 à 11:54:25
Cliquez pour afficher le message
Ce sujet est là pour discuter des diverses particularités de Dokuwiki. Comme tout le monde doit le savoir ici, je porte un amour immodéré à ce logiciel, qui n'a que des qualités (ou presque). Bon, malgré tout, je patine un peu sur certains aspects où de l'aide est toujours bienvenue... donc ce sujet permettra de discuter de ce genre de choses. IRC ne se prête pas trop à ces informations qui ont besoin de structure et de pérennité.

TychoBrahe travaille actuellement sur Django, qui va nous fournir la barre de navigation générale. Cette barre est multilingue (alleluia !). Pour l'intégration dans Django, il suffit de l'exporter en php, puis de l'inclure dans le thème Dokuwiki.

Premier aspect : l'internationalisation.
Dokuwiki détecte la langue de l'utilisateur selon plusieurs paramètres. Par défaut il donne au visiteur le wiki dans la langue pour laquelle son navigateur est configuré, ou l'anglais s'il n'a pas cette langue. Comme j'ai activé le plugin Translation, il y a une gestion multilingue du wiki et si le visiteur passe d'un article en français à sa version en anglais, l'interface passe aussi du français à l'anglais.

Les traductions du thème (ce qui sera notre cas ici) se placent dans un dossier du template. Le chemin précis est dokuwiki/lib/tpl/<template>/lang/<ISO-code>/ ; ce qui donne dans le cas de la barre de navigation pour le template "wikhan" quelque chose comme
dokuwiki/lib/tpl/wikhan/lang/fr/khanav.php et dokuwiki/lib/tpl/wikhan/lang/en/khanav.php

Pour l'interface générale, le fichier appelé doit être lang.php dans lang/<ISO-code>/ . Mais il est déjà utilisé pour d'autres choses dans le thème et ne devrait pas être écrasé si on régénère la barre de navigation. Ceci dit, c'est du php, donc il suffit d'ajouter à la fin include('khanav.php'); et ça marche.

Voici l'exemple d'un fichier lang/fr/khanav.php :
<?php 

$lang
['khanav_test']            = "Ceci est un test incroyable.";


Et voici le bout de code qui me permet de voir ce message dans dokuwiki (bout que j'ai ajouté dans le main.php du template, mais osef) :

<div><?php 
$khanav_test tpl_getLang('khanav_test');
            echo 
$khanav_test ;
?>
</div>

Note : il y a très probablement plus élégant et si vous voyez comment faire ça, proposez-moi. Mais ça, ça marche.
Dernier message par shepeng - 28 Janvier 2018 à 17:00:59
Cliquez pour afficher le message
xen-tools utilise debootstrap pour installer sa VM, il faut trouver un moyen d'installer la distribution cliente sur la partition prévue. Tu peux utiliser l'installateur prévu  de la distribution, en faisant une VM utilisant hvm et démarrant depuis une image iso du CD d'installation, ou trouver un outil capable d'installer la distribution cible dans un chroot ou sur un répertoire précis. Ça va dépendre de la distribution cible.

Personnellement je n'utilise plus xen-tools pour créer mes VM mais un playbook ansible. Ce playbook fait toutes les étapes de xen-tools, plus certaines autres (pas exemple ajout de mes clés publiques dans la config ssh), il n'y aurait qu'à remplacer la partie concernant debootstrap dans ce playbook pour l'adapter à une autre distrib.
Licences Mentions légales Accueil du site Contact