Hi! We introduced a bug in commit 59e6868 causing "Page not found"s and fixed it in commit 6e52794.

@d1rtym0nk3y Thanks for the feedback! This is actually something that we had in mind. It will probably have to wait for the next major version of XO, though.

I already opened one: https://github.com/vatesfr/xen-orchestra/issues/4882.

pdonias created this issue in vatesfr/xen-orchestra

closed [VM] Network: show IP addresses in front of their VIFs #4882

We're showing all the IP addresses reported by the VM's guest_metrics, and they're not sorted in any specific way, indeed. We could change that and show each address in front of the corresponding VIF.

I'm not seeing any. And I don't think this would be fixed by @julien-f's recent change on xo-server-xoa since it should already use the configured proxy by going through the updater.

/cc @Mohamedox

https://github.com/vatesfr/xen-orchestra/issues/4467

pdonias created this issue in vatesfr/xen-orchestra

closed Hide legacy backup menu entry #4467

@julien-f We could also completely remove the menu entry and simply keep showing the legacy backups (if there are any) in Backup NG like we already do.

@duxepu Ok, this is weird, I'm not able to reproduce that and I don't see how it's possible. Could you check a few things?

• from an admin point of view, at the bottom of the VM's advanced tab, please check that the user has Admin ACLs on the VM
• from the user's point of view, when you're on the snapshots tab, open the browser console (press F12 > Console tab) and check if there are any errors
• do you have this issue with all the users of all your Self Service groups or is it more specific?

Thanks!

Hi @duxepu, no it's not intended. A Self Service user should be able to interact with all the VM's snapshots. Even delete them for now (we'll change that in the future for snapshots they didn't create themselves).
What type of backup is it? Has the user been added to the Self Service before or after the backup was run?

@mrbaz Thanks for the detailed feedback!

If XO had a way of pulling the user's group information and only allowing those in a certain group to have authorization to XO to have their accounts automatically generated, that would work too.

That wouldn't be trivial to implement with our current plugin system. But as you said, a user that logs into XO isn't able to do anything without granting them permissions first. Also, if this is still a concern for you, you can disable user auto-generation in xo-server configuration by adding this line:

createUserOnFirstSignin = false

However, you'd then have to create the users manually before they can log in.

the issue still stands that I can't put a user into a group or assign ACLs until after they have signed in for the first time.

I agree but I'm not sure what a good solution to this would be. If we add an option to import all the users at once, it could mean importing a lot of users for some companies, even if many of those users would never actually log in later.

Hi @mrbaz, thanks for the feedback.

I'm not sure why it's an issue for you that the user account is automatically created in XO.

literally anyone who properly authenticates will be able to log in to XO

Isn't it the point? You seem to be raising a security issue here, but I'm not sure what it is. Could you clarify it?

Thanks!

@d1rtym0nk3y Thanks for the feedback! This is actually something that we had in mind. It will probably have to wait for the next major version of XO, though.

@olivierlambert It would look like it. I also tried to remove everything from blocked-operations except shutdown and I was able to xe vm-shutdown the VM. But as soon as I add clean_shutdown, xe doesn't allow the shutdown anymore.

@olivierlambert That's weird because it can be set and read with XAPI calls but not with xe and if I remove it from the blocked operations (and leave all the other operations), I'm able to stop the VM with a VM.shutdown call, which is what we're trying to avoid when the option is enabled.

@willruss1 Ok, great!

@gr85z said in auth-ldap (v0.6.4) - LDAP authentication plugin for XO-Server:

So I followed guide documentation which pull from git.

Ok, so if you install it from the sources, don't install the plugins from NPM, use the source code from the repository instead. (we just marked them as deprecated on NPM since it could be confusing). All the plugins are in the packages folder. You can use Yarn's link feature to easily link xo-server-auth-ldap to xo-server.

Hi,

@willruss1, we made quite a lot of changes on the LDAP plugin, the latest version is 0.9.0. Could you update it and retry?

@gr85z 5.50.3 is the current "stable" version of XO. The latest changes of the LDAP plugin are still in the "latest" channel. You can change the channel on the right hand side of the updater page and then click on Upgrade. Then, the "current version" should say 5.51.1. You can then check your LDAP plugin configuration and retry.

Also, can you tell us about the issue you had with the deploy from https://xen-orchestra.com/#!/xoa? Did you get an error message?

Thanks!