-
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
-
@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
-
@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?
-
This post is deleted! -
@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.
-
@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?
-
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.
-
@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.
<link to the FQDN for Xen Orchestra managing the pool>"
-
Yes, that would be possible I think
-
@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.
-
Just upgraded my home network to 8.3.0 and I must say, it went flawlessly. Also my first time taking a look at XO-Lite. Also fantastic! Kudo's to the whole vates dev and testing team. This is a huge milestone.
The only real feature for me that is missing from XO-Lite is the ability to shutdown/restart the host itself from the menu (I'm assuming this is still being added).
Currently, I cant see a way to restart the host from XO-Lite. My XCPNG host runs headless, so when I needed to restart the host, I loaded XCPNG Center and shutdown the XOA VM, and then rebooted the host (only needed when applying host patches). This method wont work now with 8.3. I was forced to use the "force reboot" from XOA to complete the final patch/reboot steps.
Without the control to restart/shutdown the host itself, the only other option is to enable SSH (when the host is headless). I would think that XO-Lite would "in theory" be more secure then leaving SSH open only for this scenario.
Separately, I also run XCPNG/XOA at work (licensed), and currently we are waiting for XOSTOR to come out of beta before we upgrade/test it in our environment. Any ETA on XOSTOR going full version in 8.3 ?
Looking forward to the future of this version and product.
-
No ETA but it's actively worked. More features are coming to XO Lite this month
(end of the month) -
@TheNorthernLight said in XO Lite: building an embedded UI in XCP-ng:
Just upgraded my home network to 8.3.0 and I must say, it went flawlessly. Also my first time taking a look at XO-Lite. Also fantastic! Kudo's to the whole vates dev and testing team. This is a huge milestone.
The only real feature for me that is missing from XO-Lite is the ability to shutdown/restart the host itself from the menu (I'm assuming this is still being added).
Currently, I cant see a way to restart the host from XO-Lite. My XCPNG host runs headless, so when I needed to restart the host, I loaded XCPNG Center and shutdown the XOA VM, and then rebooted the host (only needed when applying host patches). This method wont work now with 8.3. I was forced to use the "force reboot" from XOA to complete the final patch/reboot steps.
Without the control to restart/shutdown the host itself, the only other option is to enable SSH (when the host is headless). I would think that XO-Lite would "in theory" be more secure then leaving SSH open only for this scenario.
Separately, I also run XCPNG/XOA at work (licensed), and currently we are waiting for XOSTOR to come out of beta before we upgrade/test it in our environment. Any ETA on XOSTOR going full version in 8.3 ?
Looking forward to the future of this version and product.
Leaving SSH open won't work as eventually its port will be found, then exploited (used maliciously to gain access to host). Also it would bypass the lock down feature, modelled after VMware ESXi lockdown.
Anyway there's RPU & RPR both of which are available in the appropriate edition of XOA (Xen Orchestra Appliance) and also Xen Orchestra from Sources. The RPU will reboot each host in the pool after updating them. The RPR will reboot each host in the pool in sequence, before moving onto the next.
-
@john-c - Yes, except pool updates have never worked for us, as some of our VMs cannot be live migrated. So, we have to do it manually. Also, The XO-Lite feature I was talking about, is intended for single host scenarios (which is most common in home setups, where migration isnt possible).
-
FYI, next versions will have a way to shutdown a host, it's in the pipes
