I’ve seen Ubuntu join scripts and there are fragments of how to do these things with Fedora/Redhat based distros.
But what about Debian itself?
Adding a member server means adding a system which is very different from your standard Debian with lots of proprietary stuff that seems aimed at mainaining this system as a base for “UCS apps”.
That can be fine, but what when you really just want to use UCS for ID and access management, which according the the Univention home page is its core functionality:
Mit unseren Open-Source-Lösungen für integriertes Identitäts- und Zugriffsmanagement haben Sie die Kontrolle. Egal, wo Sie sind oder welches Gerät Sie nutzen – unsere skalierbaren und hochverfügbaren Lösungen sorgen für eine nahtlose und sichere Nutzung ganz unterschiedlicher Softwareanwendungen. Vertrauen Sie darauf, dass Ihre IAM-Prozesse und Identitäten stets in Ihren Händen bleiben.
I am not sure if I understand completely what you want to achieve - There is no way to use UCS “on top” of a normal Debian, UCS incorporates Debian and integrates it with Nubus, the IAM stack provided by us - So UCS contains Debian, but changes and extends it in various ways to make the administration easier and reduce efforts.
My recommendation however would be to stick to UCS itself, this is what we are testing and there is no considerable overhead in comparison apart from everything needed to maintain configuration centralized.
A small remark:
Nothing in our product is proprietary stuff, everything is published and mirrored to Github and 100% Open Source.
“top” and “bottom” are a permanent issue in CS with trees growing the wrong direction…
But basically I just want to use a Debian base and have the IAM integrated via UCS. Strictly speaking it’s a delegation of authority for IAM from the local Linux to an external authority, but it’s very much like a tribe electing a leader as liege lord and then swearing an oath of fielty… that leader then leads from the top, even if in a Unix world you’d see that as a super-root, sometimes expressed as a double slash…
Yes, that’s the fully manual approach, do everything yourself and better understand fully what you’re doing, including all security risks which might come from a typo or misplaced flag… not very attractive and I’d rather have a Univention maintained join script for that or as much effort as I have with Windows clients
Which is why I first tried that latter road with a plain member server, for the ease of pre-manufactured integration.
But if you compare say what you get on /etc on a standard Debian vs. what a Univention member server puts there, you might notice that it says “maintained by UCS” pretty much everywhere.
Proprietary might have been a questionable term, but it’s your code, managed by you and changing it, likely breaks things rather badly.
And trying to add software from outside of the UCS package set very quickly gets you into trouble, too.
The gap between a UCS member server and a Linux, which delegates only its IAM to UCS is large and has potentially a lot of meaningful differentiations, but the current minimum, follow the link for DIY is too low to be useful.
Now in this case I really want to have my Proxmox/Ceph cluster servers to be managed by UCS IAM as well, and I can either use a Proxmox ISO and “join” UCS or a UCS ISO and add Proxmox. (Of course, I can also use a neutral Debian base ISO and then add Proxmox and join UCS… but let’s not complicate things further.)
Now, please spare me the knee-jerk reaction (just in case…), that “thou shallst never mix hypervisors and apps”, because that’s exactly what Univention used to do itself and what’s Univention still sells: one IAM to rule all.
Proxmox explicitly supports adding Proxmox on top of a standard Debian, so I’ve tried the latter (UCS member server) and it kind of works with quite a bit of wrangling, e.g. adding UCS registry items to open Proxmox management ports in the firewall… a rather UCS “proprietary” way of doing FW things. Not bad, but if all you know is Debian, you won’t easily find where UCS member servers configure it: you have to read the UCS manuals to get there.
(And then you’d want them inherited from the domain controller to servers in a group, instead of manageing them at the node level…)
But I’d rather stick to the Proxmox ISOs to decouple kernel life-cycles and only delegate the IAM to UCS. And there is potentially a lot of physical hosts involved in a Proxmox buildout while it also has a rich delegation model, which is eactly what you’d want to use a IAM like UCS for.
Of course, doing those Proxmox role mappings isn’t something I’d expect you to deliver (although a shared common approach from both in a partner eco-system could be a killer app for both of you…), but at least the base IAM integration at the mere Debian level should be more than the above link: a join script there isn’t too much to ask, I’d say.
BTW: I regard adding Proxmox really as a compensation for UCS giving up on managing VMs.
I understand that UCS decided to quit the race of offering a full hyperconverged infrastructure (HCI) stack akin to Nutanix/vSphere/RHV/Citrix, but that means customers need better integration.
Firstly thanks for this long and concise answer! While I fear that I cannot answer every interesting point it’s always informative to learn about your needs in depth.
Let me give you a rather broad answer: Our overall strategy is not to make things different / the Univention way and differ from common approaches - Most of these deviations are rooted in past decisions at points in time where the needs of our users led to a self-made solution, while nowadays we would do many things vastly different, mostly with the goal to use standard-mechanisms and do not intervene into our Debian base if possible.
Nonetheless UCS often provides it’s own way of doing things - With supporting a full Kubernetes deployment we already took a big step into the direction of generalizing mechanisms and sticking to industry standards, for the appliance there is still some work to do (and some things are quite hard to change due to backwards-compatibility).
With the points you mentioned I can only recommend giving Nubus for Kubernetes a look, where the goal is to only provide IAM functionality and make integrations easy without needing to run a full custom Debian.
You do know that concise and long are opposites, right?
I have no idea how Kubernetes (and/or Nubus) should help me run Proxmox, which is one of the many things I am trying to manage via UCS as as IAM.
Just as I’d like to manage the VMs (and potentially LXC containers) inside, some of which are Windows, others Linux, pfSense also (still) BSD. And they also run a Ceph cluster for storage, perhaps also ZFS with replication for standby expansions.
And then there is more workstations, plenty of laptops and gamer-PC from the kids, locally, near-by and longer distance, which use VPNs to connect to the home base or play games together. We also have phones, tablets, Raspis and OrangePis, all of which I’d like to manage via a single IAM.
That’s just the home-lab, where everything I do typically started for decades.
For some years (2016-2024) I’ve pushed UCS as a IAM onto a bunch of servers in an international research lab using an oVirt/Gluster base, mostly for ML research involving GPUs (sharing those is easier with VMs and pass-through), trying to potentially validate that as a solution that could grow from the labs into international production: plenty of vSphere and M$ I’d have loved to replace, instead of having it moved into GCS.
That didn’t work out, but with Trump poisoning US clouds, there is a bit of a (giant) come-back opportunity, which is why I harrass you.
Before that (2008-2016) I’ve led the deployment of mission critical nation scale services under PCI-DSS compliance on OpenVZ containers using a bit of stand-alone LDAP, because it only used admin and technical accounts. There the challenge was still scale-in consolidation but also highest availability managed at application level (Kubernetes would be far to slow to react, and Google was still keeping it secret at the time), because not everyone is running Facebook and needs the scale-out Kubernetes is designed for. We achieved 70:1 consolidation on entry level servers vs. 3-5:1 which VMware shops managed.
Yes, scale-out Kubernetes designs will also run consolidated (Google nested several layers for decades), but plenty of legacy runs just fine with a IaaS abstraction container while still profiting from a IAM, which should support XaaS, really.
And yes, I’ve read the complete manual set from cover to cover (and on each release), but I’d still like to have the Ubuntu join script (which isn’t only getting fave reviews) also run Debian.
Please, do not concentrate on teaching your customers how to adapt their ways if the largest achieveable horizontal IAM market is your goal. You’ll have to offer out-of-the box or one-click integration for 80% of the use cases to stand a chance.
