XO Lite: building an embedded UI in XCP-ng

pdonias

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!

buldamoosh

This post is deleted!

john.c

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

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!

The LDAP authentication could be implemented by having PAM use LDAP client authenticate against an LDAP backend. The necessary configuration and/or could be preserved or converted (as required) across each upgrade from ISO media.

Alternatively an OpenID client and server could be used for authentication on XCP-ng to handle federated authentication services for XCP-ng.

Also the XO Lite can be using LDAP if authentication, performed for XCP-ng is based on OpenID or PAM.

olivierlambert

It's a big no. We don't want cram the Dom0 with more components, if you want LDAP or external auth, you should use XO

bnerickson

@pdonias Thanks for the feedback and fix for the XOA FQDN thing! I figured most of my suggestions were pretty standard and already on the docket.

Regarding LDAP: I think @john-c put it best. XO-Lite would probably need to be integrated w/PAM in the backend for LDAP support. It sounds like the serverless (?) architecture of XO Lite runs counter to the request and said design may hinder future feature requests that ask for tighter host visibility. Regardless, XO Lite in its current form will definitely be invaluable as more and more of the items currently on the docket are implemented

john.c

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

It's a big no. We don't want cram the Dom0 with more components, if you want LDAP or external auth, you should use XO

My suggestion during development of XCP-ng 8.3 of implementing the ability to lock down XCP-ng (thus XO Lite) so you can only login through XOA would, in this case be a good compromise, to handle the business deployments (especially large ones).

Especially if implementing LDAP support is a big no!

@bnerickson Would what I suggested above be a good compromise, to having LDAP on XCP-ng?

john.c

This post is deleted!

bnerickson

@john-c It sounds like you're suggesting that XO Lite should only allow login if XoA is unavailable. Otherwise, if XoA is available (and able to communicate via xapi with the host in question) then login to XO Lite on that host is blocked.

In theory as an optional feature for security-conscious organizations, maybe? I'm not sure how feasible the implementation would be though.

john.c

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

@john-c It sounds like you're suggesting that XO Lite should only allow login if XoA is unavailable. Otherwise, if XoA is available (and able to communicate via xapi with the host in question) then login to XO Lite on that host is blocked.

In theory as an optional feature for security-conscious organizations, maybe? I'm not sure how feasible the implementation would be though.

The suggestion was inspired by the lock down feature of VMware ESXi. It was first discussed when people were talking about alternative to VMware NSX to be used with Vates VMS.

To get the background checkout this link https://xcp-ng.org/forum/topic/8605/similar-product-to-vmware-nsx/.

@olivierlambert Would you care to comment on the feasibility of implementing my suggestion if LDAP is a no go?

olivierlambert

Lockdown is a possibility, in any case I would consider direct mgmt network access a no go. The role of XOA is to make that secure bridge to outside, without exposing mgmt.

I think you can already disable XO Lite UI if you want. Anyway, that's not a top priority now, there's 1000 things to do first.

john.c

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

Lockdown is a possibility, in any case I would consider direct mgmt network access a no go. The role of XOA is to make that secure bridge to outside, without exposing mgmt.

I think you can already disable XO Lite UI if you want. Anyway, that's not a top priority now, there's 1000 things to do first.

With lockdown I mean having it disable XO Lite by disabling, not showing the login form and doing so while showing a message instead. Also the lockdown feature would disable SSH (as well as inhibit enabling it) as this would by pass Xen Orchestra on the XCP-ng host. For instance a message such as:-

"Logging into XO Lite is unavailable due to restrictions to only be able to login via Xen Orchestra. Please login to the Xen Orchestra instance managing this pool.

olivierlambert

Yes, that would be possible I think

john.c

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

Yes, that would be possible I think

The disabling, not showing the login form while displaying the message would occur before even attempting the login. Don't forget the SSH and/or console would need disabling and/or inhibiting login to prevent by pass of Xen Orchestra as well as part of the lockdown.