Derniers messages
#1
Programmation / SpacetimeDB
Cliquez pour afficher le message
Bonjour,
Comme vous le savez, faire un MMORPG capable de supporter du monde est difficile, très difficile. Récemment je suis sur un projet qui pourrait simplifier l'affaire et qui, malgré ses défauts, vaut sans doute le coup qu'on le regarde d'un peu plus prêt : SpacetimeDB.
Il s'agit d'une projet un peu spécial qui se présente comme une base de données sur-boostée spécialisée dans les MMORPG et autres applications multi-utilisatrices à haute performance, mais qu'à titre personnel je vois plus comme un serveur générique paramétrable qui intègre une base de données. Le principe est assez simple : on écrit des sortes d'extensions pour SpacetimeDB et ça en fait un serveur de jeu complet avec d'excellentes performances et qui est fait pour « scaller » de manière très simple. Il est prévu de pouvoir écrire ces extensions dans plusieurs langages, dont Python, mais à l'heure actuelle seul Rust est supporté pour le serveur.
Bien entendu, afin de communiquer avec le serveur il faut que le client soit compatible. Il y a des des bibliothèques disponibles dans différents langages. À l'heure actuelle, seuls Rust, C# et Typescript sont supportés, mais il est prévu d'ajouter Python, C++ et Lua.
Enfin, il y a un soucis avec la licence. Dans la mesure où la société derrière SpacetimeDB commercialise une offre d'hébergement en infonuagique, elle n'a pas super envie que d'autres entreprises utilisent la liberté du logiciel pour leur faire directement concurrence. De base, SpacetimeDB est donc sous une licence privatrice qui ressemble cependant à une licence libre mais ajoute 2 restrictions : la possibilité de n'avoir qu'une seule instance en production et l'interdiction de s'en servir pour faire une offre en infonuagique. Il est important de noter que la licence change automatiquement 4 ans après la release afin de devenir l'AGPL.
À titre personnel je ne suis pas fan des licences privatrices, mais je peux comprendre le mouvement ici car sur d'autres logiciels libre il y a eu des abus qui ont fait que la société fournissant tout le travail perdait des parts de marchés face à des concurrents peu scrupuleux qui revendaient leur solution moins cher et sans les financer ni contribuer en retour. Ici je trouve que la bascule automatique vers l'AGPL est très appréciable.
Pour en apprendre plus, voici un certain nombre de ressources en anglais :
Comme vous le savez, faire un MMORPG capable de supporter du monde est difficile, très difficile. Récemment je suis sur un projet qui pourrait simplifier l'affaire et qui, malgré ses défauts, vaut sans doute le coup qu'on le regarde d'un peu plus prêt : SpacetimeDB.
Il s'agit d'une projet un peu spécial qui se présente comme une base de données sur-boostée spécialisée dans les MMORPG et autres applications multi-utilisatrices à haute performance, mais qu'à titre personnel je vois plus comme un serveur générique paramétrable qui intègre une base de données. Le principe est assez simple : on écrit des sortes d'extensions pour SpacetimeDB et ça en fait un serveur de jeu complet avec d'excellentes performances et qui est fait pour « scaller » de manière très simple. Il est prévu de pouvoir écrire ces extensions dans plusieurs langages, dont Python, mais à l'heure actuelle seul Rust est supporté pour le serveur.
Bien entendu, afin de communiquer avec le serveur il faut que le client soit compatible. Il y a des des bibliothèques disponibles dans différents langages. À l'heure actuelle, seuls Rust, C# et Typescript sont supportés, mais il est prévu d'ajouter Python, C++ et Lua.
Enfin, il y a un soucis avec la licence. Dans la mesure où la société derrière SpacetimeDB commercialise une offre d'hébergement en infonuagique, elle n'a pas super envie que d'autres entreprises utilisent la liberté du logiciel pour leur faire directement concurrence. De base, SpacetimeDB est donc sous une licence privatrice qui ressemble cependant à une licence libre mais ajoute 2 restrictions : la possibilité de n'avoir qu'une seule instance en production et l'interdiction de s'en servir pour faire une offre en infonuagique. Il est important de noter que la licence change automatiquement 4 ans après la release afin de devenir l'AGPL.
À titre personnel je ne suis pas fan des licences privatrices, mais je peux comprendre le mouvement ici car sur d'autres logiciels libre il y a eu des abus qui ont fait que la société fournissant tout le travail perdait des parts de marchés face à des concurrents peu scrupuleux qui revendaient leur solution moins cher et sans les financer ni contribuer en retour. Ici je trouve que la bascule automatique vers l'AGPL est très appréciable.
Pour en apprendre plus, voici un certain nombre de ressources en anglais :
Dernier message par Zatalyz - 11 Décembre 2024 à 12:42:36
Cliquez pour afficher le message
C'est corrigé !!!! Alleluiaa !!!!
Dernier message par Zatalyz - 10 Décembre 2024 à 21:09:02
Cliquez pour afficher le message
Comme vous avez pu le constater depuis la dernière mise à jour, les numérotations des titres sur le wiki sont des plus fantaisistes. Cela n'arrive que si on est connectée. J'ai mis du temps à identifier le problème, car tout marche tant qu'on n'est pas co ; mais une fois co, une balise "div" est ajouté autour de chaque titre, ce qui amène des erreurs dans la façon dont le css est interprété. Car ces numéros sont ajoutés via le css...
J'ai cherché longuement d'où venait cette div en trop et la réponse est : c'est une modification dans le code même de dokuwiki. La réponse est ici :https://github.com/dokuwiki/dokuwiki/pull/3957.
Je ne comprends pas trop le détail du "pourquoi", par contre ça me pose souci pour le css, parce qu'il faut que je prévois la version "pas connectée" et la version "connectée". Et ce n'est vraiment pas trivial, mais le css permet des choses fabuleuses à présent. Et maintenant que je sais que cette div n'est pas un bug ou un souci quelconque, je vais trouver comment faire avec. Ou arrêter d'essayer de numéroter les titres. On va voir
J'ai cherché longuement d'où venait cette div en trop et la réponse est : c'est une modification dans le code même de dokuwiki. La réponse est ici :https://github.com/dokuwiki/dokuwiki/pull/3957.
Je ne comprends pas trop le détail du "pourquoi", par contre ça me pose souci pour le css, parce qu'il faut que je prévois la version "pas connectée" et la version "connectée". Et ce n'est vraiment pas trivial, mais le css permet des choses fabuleuses à présent. Et maintenant que je sais que cette div n'est pas un bug ou un souci quelconque, je vais trouver comment faire avec. Ou arrêter d'essayer de numéroter les titres. On va voir
Dernier message par YannK - 05 Décembre 2024 à 21:39:50
Cliquez pour afficher le message
Personnellement je serais pour:
- les infos minimum nécessaires pour mettre en place les outils (donc ce que tu as listé comme obligatoire). Si jamais le reste s'avérait utile à l'avenir, ça pourra être ajouté. Pas la peine de s'ouvrir une porte inutile et d'ajouter du taf genre RGPD en plus si ce n'est pas utile.
- pour les groupes au sein de khaganat, je verrais assez bien de décliner en fonction des accès aux outils, par exemple :
- membre du collège associatif
- membre de l'association
- contributrice simple : accès sans privilèges à tous les outils (ou les plus bas accordés à chaque fois)
- contributrice développeuse : accès avec privilèges DEV sur la forge
- contributrice mainteneuse : accès avec privilèges Maintainer sur la forge
- contributrice éditrice : accès avec privilèges avancés sur les wikis
- contributrice adminsys : accès avec privilèges avancés sur les wikis adminsys
- contributrice modératrice : accès avec privilèges avancés sur le forum
Dernier message par Zatalyz - 05 Décembre 2024 à 21:16:52
Cliquez pour afficher le message
CitationEn y réfléchissant, et après visionnage de la vidéo que tu as liée, je me demande si OAuth est vraiment adapté à ce schéma.
Tu as raison, il faut peut-être que je veille à ça. Après, Oauth, OpenID, SAML... ça se vaut (même si ça ne demande pas les mêmes choses). Et malheureusement je ne saurais quel système est "bon" qu'une fois que j'aurais testé... Je sens que je vais m'amuser.
Après, attention, y'a une différence entre le backend, où je suis pour le moment (avec très peu de choix, quand on élimine certaines techno...) et le frontend. LemonLDAP, FreeIPA, Kadnim etc c'est du frontend et à ce stade "je m'en fous", je ne suis que sur LDAP brut... Et vu les limitations de LLDAP et ce que Shepeng pointe, je vais devoir retourner à OpenLDAP. Et bon c'était pas pour partir dans une discussion de tech, je demandais juste des trucs basiques comme "vous voulez quoi comme groupes et arborescence" et autre "et mettre votre bio dans le profil ?"
CitationEst-ce que le périmètre s'applique uniquement au services web ou aussi au machines (container LXC, machines virtuelles, Hyperviseurs) ?
C'est du LDAP. Donc, ça s'interface avec ce qu'on veut, pour peu que le truc en question supporte le protocole LDAP. Et si ça ne supporte pas LDAP mais qu'on veut l'interfacer, ben on fera le lien avec une autre techno. Le gros intérêt de LDAP c'est que c'est un truc assez primaire qui sert facilement de liant à "plein de trucs". Mais je n'ai pas prévu qu'on se connecte en tant que sysadmin aux serveurs avec ça, là je préfère séparer un peu, et ssh me va très bien. Proxmox... on verra.
Maintenant concernant les besoins, ils sont déjà décrit dans le wikhan, et à mon niveau si j'arrive à avoir le forum et les wikis avec un seul coin pour les identifiants, je serais déjà contente. L'objectif c'est de mettre en place le système, puis d'y connecter petit à petit le maximum de chose. Sachant que certains services web demanderont peut-être du développement.
Dernier message par shepeng - 05 Décembre 2024 à 13:59:59
Cliquez pour afficher le message
En y réfléchissant, et après visionnage de la vidéo que tu as liée, je me demande si OAuth est vraiment adapté à ce schéma.
D'ailleurs sur la doc de lemonLDAP OAuth n'est pas cité.
Du coup : regarder plutôt SAML ou OpenID Connect.
D'ailleurs sur la doc de lemonLDAP OAuth n'est pas cité.
Du coup : regarder plutôt SAML ou OpenID Connect.
Dernier message par Rollniak - 03 Décembre 2024 à 10:24:53
Cliquez pour afficher le message
Bonjour tout le monde 
@Shepeng me fait penser que l'on doit bien définir nos besoins pour choisir par la suite le bon outil.
Est-ce que le périmètre s'applique uniquement au services web ou aussi au machines (container LXC, machines virtuelles, Hyperviseurs) ?
Il est question de multi-domaine, donc ça exclut FreeIPA que je connais le mieux pour l'avoir utilisé (Non administré) en entreprise.
Concernant les profiles, j'imagine que les informations suivantes sont importantes :
Pour le mail, je pense que ça dépends, la seul utilité que je voie c'est pour des applications qui ne supporte que l'authentification avec un é-mails ou si un serveur é-mail utilise LDAP pour l'authentification et obtenir la liste des é-mails valides.
Pour les groupes on pourrais réfléchir au accès en suivant le principe de de moindre privilège. Les admins on certains accès, les devs on des accès plus restreint suivant leurs besoins est ainsi de suite.
Je pense que 0auth peut être vue plus tard une fois que la configuration LDAP est terminé.
@Shepeng me fait penser que l'on doit bien définir nos besoins pour choisir par la suite le bon outil.
Est-ce que le périmètre s'applique uniquement au services web ou aussi au machines (container LXC, machines virtuelles, Hyperviseurs) ?
Il est question de multi-domaine, donc ça exclut FreeIPA que je connais le mieux pour l'avoir utilisé (Non administré) en entreprise.
Concernant les profiles, j'imagine que les informations suivantes sont importantes :
- Nom Affiché
- mot de passe
- identifiant
- uid (Je crois que la valeurs de départ doit être haute pour pas empiéter sur des comptes existant dans le cas ou le LDAP est utilisé pour s'authentifier sur des machines)
- L'avatar est un plus optionnel
- Les préférences dépendes du support des applications utilisé par nos services, ça peut être vue au cas par cas.
Pour le mail, je pense que ça dépends, la seul utilité que je voie c'est pour des applications qui ne supporte que l'authentification avec un é-mails ou si un serveur é-mail utilise LDAP pour l'authentification et obtenir la liste des é-mails valides.
Pour les groupes on pourrais réfléchir au accès en suivant le principe de de moindre privilège. Les admins on certains accès, les devs on des accès plus restreint suivant leurs besoins est ainsi de suite.
Je pense que 0auth peut être vue plus tard une fois que la configuration LDAP est terminé.
Dernier message par shepeng - 03 Décembre 2024 à 09:24:52
Cliquez pour afficher le message
Mes premières idées en vrac.
Est-ce que LLDAP permet de faire plusieurs arborescences, d'avoir plusieurs racines ?
Si oui, ton problème de sous groupes est réglé. Si non, et si tu veux vraiment séparer les entités, il faut passer à autre chose, pour avoir une racine par entité.
Ce qui donne les fonctionnalités à LDAP, ce sont les schémas que l'on ajoute. Il faut à mon avis déjà penser à l'implémentation 0Auth ou autre mécanisme de connexion internet et voir quels schémas sobnt nécessaires.
Si tu veux intégrer les avatars, il faudra également trouver un schéma le contenant. Le schéma posix contient une éventuelle photo, mais ce n'est pas vraiment le même chose.
Est-ce que LLDAP permet de faire plusieurs arborescences, d'avoir plusieurs racines ?
Si oui, ton problème de sous groupes est réglé. Si non, et si tu veux vraiment séparer les entités, il faut passer à autre chose, pour avoir une racine par entité.
Ce qui donne les fonctionnalités à LDAP, ce sont les schémas que l'on ajoute. Il faut à mon avis déjà penser à l'implémentation 0Auth ou autre mécanisme de connexion internet et voir quels schémas sobnt nécessaires.
Si tu veux intégrer les avatars, il faudra également trouver un schéma le contenant. Le schéma posix contient une éventuelle photo, mais ce n'est pas vraiment le même chose.
Dernier message par Zatalyz - 03 Décembre 2024 à 08:52:47
Cliquez pour afficher le message
Pendant que j'y suis (et que je suis plus réveillée), je me questionne un peu sur le logiciel que j'utilise, LLDAP, qui est hyper basique, peut-être trop. En gros il n'y a que les utilisatrices, et les groupes, sans possibilité de faire des sous-groupes. Et je me dis que quand j'aurais 10 asso/organisations ça va être lourd de ne pas pouvoir juste cibler les groupes d'une asso. Mais ce n'est peut-être pas si grave, suffit que je préfixe par le nom de l'asso. L'autre solution est de passer à OpenLDAP, qui est assez effrayant mais plus complet.
Votre avis ?
Votre avis ?
Dernier message par Zatalyz - 02 Décembre 2024 à 22:50:56
Cliquez pour afficher le message
J'ai oublié de poser clairement ma demande...
Donc :
- donnez votre avis sur ce que vous voulez voir dans "profil" (et si ça doit être vu juste par vous et les personnes avec assez de droits, ou si tous les membres connectés peuvent le voir)
- listez-moi les divers groupes qui vous semblent utiles.
- et pour les groupes, listez aussi si au delà du nom et de la description, vous voyez d'autres infos utiles à afficher.
Donc :
- donnez votre avis sur ce que vous voulez voir dans "profil" (et si ça doit être vu juste par vous et les personnes avec assez de droits, ou si tous les membres connectés peuvent le voir)
- listez-moi les divers groupes qui vous semblent utiles.
- et pour les groupes, listez aussi si au delà du nom et de la description, vous voyez d'autres infos utiles à afficher.
