Categories

  • All news regarding Xen and XCP-ng ecosystem

    142 Topics
    4k Posts
    A
    @gduperrey Installed on home lab via rolling pool update and both host updated no issues and vms migrated back to 2nd host as expected this time. fingers crossed work servers have the same luck. I do have open support ticket from last round of updates for work servers. Waiting for response before installing patches.

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    kruessK
    Good moaning... The solution was pretty simple: a toolstack restart on the master (xcp83) did get all back on track and it now allows me to move the systems with a simple shutdown/start.

  • All Xen Orchestra related questions/reports

    3k Topics
    28k Posts
    olivierlambertO
    Hi, I think I've identified the issue. The OIDC plugin assumes the identity provider will always return the requested profile fields, but it doesn't handle the case where they're missing. Error 1 (Expected 'undefined' to be 'string' with usernameField: uid): passport-openidconnect only maps standard OIDC fields (displayName, username, emails) onto the profile object. Custom fields like uid are only available in the raw claims (profile._json), but the plugin doesn't look there. Error 2 (Cannot read properties of undefined (reading '0') with usernameField: email): The plugin tries to access profile.emails[0].value without checking that profile.emails exists first. If your provider doesn't return the email claim (which SURF/SRAM doesn't by default — only openid is provided), it crashes. I've opened a draft PR that fixes both issues by falling back to raw OIDC claims and giving a clear error message when the field is genuinely missing: https://github.com/vatesfr/xen-orchestra/pull/9648 Could you test it? You'd need to build from that branch. If the fix works, you should either get a successful login (if the field exists in the raw claims) or a clear error message telling you exactly which field is missing — instead of the current cryptic crashes. Also, it would help to confirm what your provider actually returns. You can check by temporarily adding this line in packages/xo-server-auth-oidc/index.js at line 136 (before the registerUser2 call): console.log('OIDC profile:', JSON.stringify(profile, null, 2)) Then check the xo-server logs after a login attempt. olivierlambert opened this pull request in vatesfr/xen-orchestra draft fix(xo-server-auth-oidc): handle missing profile fields in username resolution #9648

  • Our hyperconverged storage solution

    43 Topics
    729 Posts
    SuperDuckGuyS
    @alcoralcor Thanks for the info. I thought maybe I was using too many disks, so I've tried creating disk groups of 3-4 drives with the same issue.

  • Non-English speakers

    34 Topics
    100 Posts
    AtaxyaNetworkA
    @bvivi57 Hello ! Déjà bravo pour le travail d'écriture, faire plusieurs articles aussi long, avec screenshot et commandes CLI intégré, c'est un boulot de fou ! J'ai rapidement parcouru tous tes articles, je prendrais le temps de tout relire pour te faire un feedback complet avec quelques tips, si tu le souhaites ! Sur le dernier article, j'ai vu que tu as redémarré xo-serveur parce que tu n'arrivais pas à te reconnecter au master: tu peux (dans XO5, pas encore XO6) juste aller dans setting server, et cliquer sur le bouton "disconnect" et "reconnect". Ça va forcer une reconnexion à la XAPI, et si elle est disponible, ça va reconnecter ton pool instantanément à ton XO. Redémarrer un XO, surtout si tu as plusieurs pools, peut avoir certaines conséquences : Si tu as des backups en cours, ça va les kill instantanément, pareil pour les migrations entre deux pools différents. Il faut y aller doucement avec un systemctl restart xo-server En tout cas merci pour ces articles, je suis heureuse de voir que la communauté francophone s'intéresse de plus en plus à l'écosystème XCP-ng/XO (et je dit ça en tant qu'"early" qui utilise la solution depuis... longtemps ! )