remark; I wrote this before I saw the reply from Olivier. Redacted my reply to skip a few things I was wondering about but Oliver already solved. Main part that is left from my original thoughts is that you need to expose scopes on the Surf side before XO can actually use it, based on the information I extracted from my Authentik setup

=====

@carloum70 Strange indeed. Sadly, I do not know that much about the process.

I am a homelab user and use Authentik for authentication. In there I have to create an application and provider for XO.
The application part is nothing special, just some information about the name and the slug that will be userd later in the authentication url .
The provider part is what exposes the authentication endpoint for an application and here the properties are defined, like the authorization flow, Client ID and secret, redirect URIs, and the scopes that can be used by the client.

So I must add them to the provider first, and then the client can request them.

If I tell XO to use email for the username field and the scope email, it does not work if I did not expose the email scopemapping first in the Authentik provider.

(https://integrations.goauthentik.io/hypervisors-orchestrators/xen-orchestra/)

@carloum70 are the scopes email and uid provided by the source (are they delivered to xo by surfnet)?

By default only the openid scope is provided, without email or uid

https://servicedesk.surf.nl/wiki/spaces/IAM/pages/74226151/Connect+using+OpenID+Connect

Are the users from the oidc provider unique and not already present as local users? I ran into this issue because my already existing local user was the same as the oidc provided user

Hi all,

I saw in this announcement for Xen Orchestra 5.113 that it is now possible to map OIDC groups to roles.

• Is it possible this way to create an user of the type (XO) Admin when logging in with OIDC?

By default if I log in for the first time it creates an user of the type "User".
I do receive the groups from OIDC (e.g. the Admin group).

I tried to set up an ACL that maps the Admin group to the Admin role (other possibilities are Operator and Viewer). This however does not create an user of the type Admin, but an user of the type User with several admin options but not the same as an user of the type Admin.

When I manually change the type of the user to Admin, it is of course a full XO admin that I want it to be. But I rather would have that it created an user of the type Admin directly when you log in the first time with that user.

Also still interested ️

@AtaxyaNetwork Was looking to get OME installed in my homelab and came across the post on your site, which led me to this topic here.

Can you also share the link with me?

PS Nice to see you are using Bookstacj as well. I really like that tool for my online notes and howto writeups

@laurentm

The update of Xen Orchestra from sources (not the same as XOA) is running completely inside the VM and independent of xcp-ng.
If the proces is complaining about missing certificates I would rather suspect the OS of the VM rather than the hypervisor.

If you migrate the vm from 8.2 to 8.3 does it also show that error when updating (or use a snapshot)?

@saneece

Wget options say
-o logfile,
--output-file=logfile
Log all messages to logfile. The messages are normally reported to standard error.

-O file, --output-document=file
The documents are not written to the appropriate files, but all are concatenated together and written to file.

So the output of your first wget download was indeed redirected to the xolite.html file you saw in your browser in stead of downloading the file.

The location where you were when you typed the command will have the index.html file that is downloaded as seen in the 'log' file you created

@saneece said in XO Lite: building an embedded UI in XCP-ng:

I've tried to put get this working on both of my hosts but I get the same output when I go to it in Edge and Chrome

Microsoft Edge
Version 121.0.2277.106 (Official build) (64-bit)

Google Chrome
Version 121.0.6167.185 (Official Build) (64-bit)

Both hosts are on XCP-NG 8.2

Output is of the wget command that should be executed from a shell on the host, but you are talking about edge and chrome.
You did do the wget command in a shell (should save a xolite.html file and not an index.html file) and then with a browser open the xo-lite url on the host it was downloaded on?

Otherwise it looks like a typo in the command that made you redirect the screen output of the wget command to a file called xolite.html

@sluflyer06 if you use it like i do(*), just put a static ip and subnetmask on the storage network adapter and no gateway.

Only put a gateway in the internet connected adapters' network settings

(*) i have a separate vlan for storage with only static ip adresses assigned for that vlan on my hosts and nas, no internet connection, not even dns there.

@techjeff said in self signed certificate in certificate chain:

@stormi @olivierlambert Please see my submitted PR and please provide feedback.

I followed the guides on the site to install my custom certificates (self signed) to my new xcp-ng servers (homelab) and installed the CA cert in XO (from sources).

Came across this post when having issues with deploying self signed certificates and subsequent rrd update errors, and saw there is additional info mentioned in the PR for the Guide section on the website.

Is it correct the PR is not published yet to the website, or am I looking into the wrong places?

@cookie-eater2000 make sure your Xen Orchestra also has a connection on the 10GB network (IP address on the xo vm)

@mathiashedberg try, with xo/xoa, toggeling autostart off and then on again for 1 of the vm on the new host so xo will also activate the autostart option at the (new) server if it was not already enabled

@Danp said in XO Remote mount.nfs: access denied by server while mounting:

@daninmanchester said in XO Remote mount.nfs: access denied by server while mounting:

"stderr": "mount.nfs: access denied by server while mounting 192.168.11.60:/Backups",

Would appear to be a rights issue to me.

@tjkreidl verified they can be seen :

Export list for 192.168.11.60:
/export/Backups 192.168.11.0/24
/export/Everyone 192.168.11.0/24
/export 192.168.11.0/24

do you need to add "/export" (/export/Backups ) to be able to find the right path?

@MichaelCropper autostart in xen center is not a bug but a feature

In Xen Center, apart from enabling autostart of a vm you also need to manually (cli) enable the autostart-option on the server.

Xen Orchestra does enable this automatically when not yet enabled on the server when setting autostart for a vm.

I have two truenas servers, main server only as a Nas running core and the second server as backup target for main servers' continous replication, cloud backup sync and a little testing and playing around running scale

they work well, and also work fine together.
both are stable and doing their job without issue.
For now the advantage of scale is the slightly better gui display (no more unused nics displayed in dashboard) and maybe more drivers available for more recent or uncommon components.
Core has the advantage of proven functionality and loads of knowledge all over internet

updated and all fine

@stormi
now realise I had the same behaviour after applying the latest 8.2.0 security updates a few weeks ago.
At that time thought it was because I patched the master manually already (test repo release) and updated the entire pool only after the official release 2 days later (roling pool update).

So it is not (only) related to the 8.2.1 release

@stormi

Installation now went well, no issues noted after the reboot.
Will keep an eye on my system and report back if anything unusual is happening

@stormi

I get an error on the xcp-ng-testing repository

[14:14 xcp-ng-01 ~]# yum clean metadata --enablerepo=xcp-ng-testing
Loaded plugins: fastestmirror
Cleaning repos: dell-system-update_dependent dell-system-update_independent xcp-ng-base xcp-ng-testing xcp-ng-updates
10 metadata files removed
11 sqlite files removed
0 metadata files removed
[14:16 xcp-ng-01 ~]# yum update microcode_ctl xen-dom0-libs xen-dom0-tools xen-hypervisor xen-libs xen-tools --enablerepo=xcp-ng-testing
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Excluding mirror: updates.xcp-ng.org
 * xcp-ng-base: mirrors.xcp-ng.org
Excluding mirror: updates.xcp-ng.org
 * xcp-ng-testing: mirrors.xcp-ng.org
Excluding mirror: updates.xcp-ng.org
 * xcp-ng-updates: mirrors.xcp-ng.org
dell-system-update_dependent                                                                                                                                           | 2.3 kB  00:00:00
dell-system-update_independent                                                                                                                                         | 2.3 kB  00:00:00
xcp-ng-testing/signature                                                                                                                                               |  473 B  00:00:00
xcp-ng-testing/signature                                                                                                                                               | 3.0 kB  00:00:00 !!!
xcp-ng-testing/primary_db      FAILED
http://mirrors.xcp-ng.org/8/8.2/testing/x86_64/repodata/0359c514489ed1674f98d30cf8b500598cae60b2bdc7fb7971b005aae0c691b6-primary.sqlite.bz2: [Errno 14] HTTP Error 404 - Not Found-:--:-- ETA
Trying other mirror.
To address this issue please refer to the below wiki article

https://wiki.centos.org/yum-errors

If above article doesn't help to resolve this issue please use https://bugs.centos.org/.

(1/3): dell-system-update_dependent/7/x86_64/primary_db                                                                                                                |  25 kB  00:00:00
(2/3): dell-system-update_independent/primary_db                                                                                                                       | 132 kB  00:00:01
xcp-ng-testing/primary_db      FAILED
http://mirrors.xcp-ng.org/8/8.2/testing/x86_64/repodata/0359c514489ed1674f98d30cf8b500598cae60b2bdc7fb7971b005aae0c691b6-primary.sqlite.bz2: [Errno 14] HTTP Error 404 - Not Found-:--:-- ETA
Trying other mirror.
http://mirrors.xcp-ng.org/8/8.2/testing/x86_64/repodata/0359c514489ed1674f98d30cf8b500598cae60b2bdc7fb7971b005aae0c691b6-primary.sqlite.bz2: [Errno 14] HTTP Error 404 - Not Found
Trying other mirror.


 One of the configured repositories failed (XCP-ng Testing Repository),
 and yum doesn't have enough cached data to continue. At this point the only
 safe thing yum can do is fail. There are a few ways to work "fix" this:

     1. Contact the upstream for the repository and get them to fix the problem.

     2. Reconfigure the baseurl/etc. for the repository, to point to a working
        upstream. This is most often useful if you are using a newer
        distribution release than is supported by the repository (and the
        packages for the previous distribution release still work).

     3. Run the command with the repository temporarily disabled
            yum --disablerepo=xcp-ng-testing ...

     4. Disable the repository permanently, so yum won't use it by default. Yum
        will then just ignore the repository until you permanently enable it
        again or use --enablerepo for temporary usage:

            yum-config-manager --disable xcp-ng-testing
        or
            subscription-manager repos --disable=xcp-ng-testing

     5. Configure the failing repository to be skipped, if it is unavailable.
        Note that yum will try to contact the repo. when it runs most commands,
        so will have to try and fail each time (and thus. yum will be be much
        slower). If it is a very temporary problem though, this is often a nice
        compromise:

            yum-config-manager --save --setopt=xcp-ng-testing.skip_if_unavailable=true

failure: repodata/0359c514489ed1674f98d30cf8b500598cae60b2bdc7fb7971b005aae0c691b6-primary.sqlite.bz2 from xcp-ng-testing: [Errno 256] No more mirrors to try.
http://mirrors.xcp-ng.org/8/8.2/testing/x86_64/repodata/0359c514489ed1674f98d30cf8b500598cae60b2bdc7fb7971b005aae0c691b6-primary.sqlite.bz2: [Errno 14] HTTP Error 404 - Not Found