Hi @kagbasi-ngc,

To try and figure out what's happening, you can add this to your xo-server config:

[logs]
filter = 'xo:auth-ldap

Then run the plugin test again and see if xo-server's logs give more information.

Thanks for the feedback @fred974 We're aware of this and we're going to add a way to deploy another XOA when one is already deployed and also a way to choose which XOA the button redirects to when there are multiple ones deployed.

Hi @bnerickson, thanks for the detailed feedback!

XO Lite is still in its early development phase, which means that most of your suggestions are actually already planned, including VBD management, editing MAC addresses, creating/deleting VMs and snapshots, and more generally everything that can be done through XAPI calls.

Regarding your other suggestions, keep in mind that XO Lite is running without a server behind. This means that the persistency is only in the browser. For instance, I'm not sure how an LDAP login would work, since the credentials you're entering in XO Lite are your host's credentials, and XO Lite needs that to communicate with XAPI.

Regarding XOA's FQDN, you can already do that by configuring the field publicUrl in your XOA's config:

[http]
# Public URL to connect to this XO
#
# This optional entry is used to communicate to external entities (e.g. XO Lite)
# how to connect to this XO.
#
# It SHOULD be defined in case the IP address of the current machine is not
# good enough (e.g. a domain name must be used or there is a reverse proxy).
publicUrl = 'https://xoa.company.lan'

In any case, I took note of your feedback and we'll have to discuss some of your other interesting suggestions, both for XO Lite and XO 6, like showing more of the host's logs, failed services, etc.
Thanks!

Thanks for the feedback, we'll take care of that.

@Tristis-Oris Thanks for the report, it should be fixed on master. Could you pull and try again?

Hi @Houbsi, good question. This is how it works:

• any XO instance that is connected to a pool will add some information about itself to the pool's metadata
• XO Lite reads that information to know the URL of XO's UI

In xo-server's config, you can force XO to report a custom URL instead of raw network information:

[http]
publicUrl = 'http://example.com'

However, at the moment, XO Lite doesn't support it, but it's coming soon: https://github.com/vatesfr/xen-orchestra/pull/7849

And @olivierlambert, yes, for now, any XO instance, whether it's an XOA or not, reports itself on the pool and we simply pick the latest one. But we can definitely implement something smarter in the future if necessary.

pdonias opened this pull request in vatesfr/xen-orchestra

closed feat(lite/XoaButton): support `xo-server`'s setting `http.publicUrl` #7849

Indeed, it's not possible at the moment, only admins can edit ACLs. Taking note of the request, though

@mbriet Yes, you can. The user just needs to login once with their LDAP credentials to create the corresponding XO user and then you can manage that user pretty much like a local user, including adding them to groups you created yourself.

@mbriet Yes, exactly. You can import all the groups at once but if you want to set ACLs for a specific user, they have to login at least once first so that the user gets created within XO.

@olivierlambert It doesn't look like we did. It's documented in the config file but we can add it to the RPU doc too if necessary.

@olivierlambert By default, it's 20 minutes. And it's already configurable through xo-server's config by adding:

[xapiOptions]
restartHostTimeout = '40 minutes'

@frank-s No, it's not possible. Could you describe your use case for this compared to sending a normal email?

@Tomcatter Great!

Hi @Tomcatter, it looks like the search result for LDAP groups is reaching the size limit configured in your Active Directory. Make sure that the group filter is correct and wouldn't return more objects than you'd want to.

If you're still getting the error and you're confident about the amount of groups that you're going to import to XO, you can increase the MaxPageSize value of your AD's LDAP policy: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/view-set-ldap-policy-using-ntdsutil

If the content is only white spaces, indeed it's impossible to edit. We'll fix that, thanks for the report!

https://github.com/vatesfr/xen-orchestra/pull/7411

pdonias opened this pull request in vatesfr/xen-orchestra

closed fix(xo-web/Text): replace spaces with nbsp so that the text is always clickable #7411

Hi @mestafin, are you up-to-date with the master branch? You should see a "Click to edit" text on the individual VM page and a "Long click to edit" text on the Home page.

What browser are you using? Could you try in incognito mode without any browser extensions enabled?

Thank you @john-c! We need to make a few changes first, we'll take care of your PR right after that

@DustinB @olivierlambert I confirm it's not possible at the moment.

@maverick This is for the URL https://fw-dea12.domain.tld/api/extras/custom-fields/1/, right? What about https://fw-dea12.domain.tld/api/extras/custom-fields/?

If that works too, could you run this from the machine that hosts your XO?
Replace <TOKEN> with the token that you put in the Netbox plugin configuration:

curl -skv -H "Content-Type: application/json" -H "Authorization: Token <TOKEN>" "https://fw-dea12.domain.tld/api/extras/custom-fields/"

@maverick Please make sure that you're logged in by going to https://fw-dea12.domain.tld:8143/ first.