More system administration than dev proper, but does anyone have any advice on how to set up an OpenLDAP server for an LTSP fat client setup? In kinda having enough of the contradictory, incomprehensible, and outdated documentation I've been finding so far... 😅

nextcloud is opensource and you can host it instantly via docker container.

https://nextcloud.com/groupware/

edit: sorry i don't know what a LTSP fat client is

OpenLDAP is ... . Now one could tell me even something remotely positively yet, but after you get it to work, it will continue working.

About the documentation: Many sites refer to the old-style file based config even it is not active anymore by default - it is still possible to activate the config file (but once you get used to the new style, it is superior; it has a higher learning curve).

It set one OpenLDAP server up once so I may be able to help, would you mind being a bit more specific?

@sbiewald I feel you on OpenLDAP's quality from what I saw, but hey 😅😅. Well, as I said, it's in the rather specific context of getting network accounts to work on a fat client LTSP setup... Essentially, I thought LTSP would handle it on its own, but it likes to log me in on a client as root of the client despite me having used server user credentials... And considering I have to guess half the time due to bad documentation, it seems that I might need to configure an OpenLDAP server for accounts to work as expected (I have server users with which I can log in on the clients and retain settings, times, etc.). I am doing this sysadmin project pretty much as a voluntary school project and therefore am not very experienced with it, so please do excuse me if I make any blunders 😅

If I get you correctly, you want to have fat clients (which LTSP provide images for) and you want to login into the images as a network user, so a person logs into LTSP and have the same (unique network wide) account after login.

As an LDAP sever you have chosen (as it is one of the most described one online) OpenLDAP (more precisely slapd), which is not set up / installed yet. [You could possibly use alternatives, e.g. Microsoft Active Directory in mixed environments, FreeIPA, 398, ApacheDS etc. but every server has its own quirks; If you already have one, use it].

(Sorry for the long conclusion, but I want to understand everything correctly).

To ease up OpenLDAP setup (assuming Debian): Install the `slapd` package and `ldap-utils`. Set domain name (should be you network domain name, but can be chosen arbitrary), admin passwords and DB type (remember what you have chosen, but the choice itself is not relevant). If you are not prompted, use `dpkg-reconfigure slapd`. Somewhere the admin username shall be printed (e.g. cn=admin,dc=your,dc=domain,dc=org). Debian uses the new style config (another LDAP db as configuration storage).

To do user management either do over command-line or graphical tools (I can recommend Apache Studio). Create user accounts and structures (an LDAP directory is tree based). What is the correct object class for a user? Not sure here. In doubt, inetPerson (or so) and Unix Account (I would try that one) or choose both. That should be the basic setup.

The LDAP server must be reachable by LTSP. Now LTSP has to be configured to use LDAP. For file access an NFS server might be required, too.

And this might help you, too (didn't try): https://help.ubuntu.com/community/...

@sbiewald I will have to wait until this Friday (no, not today, at least for me) to test some of what you said out... Might also need some help for NFS if that isn't working out of the box 😅😅 But thanks for the help, indeed I went with slapd on Debian (well BunsenLabs but whatever it's Debian), and I was kinda shocked how abstract OpenLDAP seems...

@sbiewald Thanks a lot for your help, my friend and I made *some* progress... Marginally. Essentially, we in the end settled on using JExplorer (since it was kinda the only one that seemed to work and be understandable to us) as a front-end, since we already bashed our heads against the command-line LDAP and slapd commands up until now... And mind you we're both very command-line-oriented people usually, but here I guess might be easier to visualize for OpenLDAP noobs like us :P
Anyway, it turns out that for whatever reason, even though we did dpkg-reconfigure slapd after installing it since it didn't really give us anything on install where we set the dc, it still actually put it as dc=domain... Now as I'm writing this I just realized that it just might be an initial configuration issue since the first time config program just might have bailed on us early... Maybe; to check next week 😅

@sbiewald We also noticed that the only available class that vaguely resembled the ones you recommended that (we hope) are to create a new user in the tree are inetOrgPerson, nothing nearly similar to Unix Account... I do apologize if we are missing anything obvious, this is our first time dealing with this 😅

@chilledfrogs You are welcome.

About the objectClass for users: I have posixAccount and posixGroup (I haven't tested them).
They have all the required properties: uidNumber, gidNumber, homeDirectory, loginShell, authPassword, gecos, shadow*, uid, etc.). It may be possible your frontend does not offer this class, but should be available.

@sbiewald I feel incredibly stupid... Indeed it was due to the config program exiting earlier that the dc wasn't set correctly... So we got that fixed now; and indeed we do have those object classes for users :D

@sbiewald It's me again... Well, we managed to create a user, etc., that's all nice and fine, but I'm realizing now that we might have a slight problem: is it possible, on Debian, if you know, to have OpenLDAP client *and* server software on the same machine? Reason being is that in our LTSP setup, we did it the easy way and made it so that the client image automatically mirrors the server filesystem (at least in some ways, for an example in software... Makes it a bit easier to manage for those who will be dealing with this system in the future I guess :P), so we would need to make the server somehow able to connect to its own OpenLDAP server, as well as the clients (whose images are mirroring the server ones)... Is this possible? Or would we need a second, separate OpenLDAP (and maybe NFS? idk which server would be better if we really need a 2nd separate one) server? Thanks a lot in advance

I guess it should work to run the client on the same machine.

@sbiewald I thought so, but it seems some packages required for the server and client are conflicting... So I wanted to check with you if you knew anything about which packages are actually required on Debian etc.

Hm. Which packages are conflicting on your server?

@sbiewald Little update: never mind, I finally found an article that works (it's unfortunately bookmarked locally on the server machine so I can't give it to you now) concerning that, it all works fine, I even *gasp* understand somewhat how LDIF files work... But despite us being able to log on the client with the test user credentials, it still shows that we're logged in as root but on the client hostname, which is why we went through the entire ordeal of OpenLDAP in the first place... Any ideas?

@chilledfrogs Sadly not. Do you sign in to a graphical or a command line session?

One thing might be possible: Is your test user's uid 0, by a chance?

@sbiewald On the clients it is a graphical session, and concerning the second thing, I'm almost sure it isn't

On Unix like systems, every user has a (hopefully) unique number. This is the "real" identification, Linux itself does not even know (or cares) about the name. root has the uid 0. So if a user has the uid 0, he is root, no matter what his username might be. The first few 100 ids are for service accounts.

At 1000 (or 500, depending on the system) the regular uids for normal users start.

For LDAP users I usually choose 10000 or higher so it won't collide with local users.

@sbiewald I'm not sure if I took one in the 1000s or 10000s, I might as well try to change that next time...
Do group IDs make a difference BTW?

Usually not. The user gid is usually the same because many users are in the group of the same name.

Anyway, a uid != 0 should be root.

@sbiewald On the server or the client?

@chilledfrogs What do you mean? Uid != 0 means not root? Everywhere.

@sbiewald you said "a UID != 0 should be root" previously, so was thinking whether that was an error or not...

Right. My fault.

uid == 0 => root
uid != 0 => not root

@sbiewald I'm preparing more and more for the possibility of having to ditch LTSP in favour of a more traditional setup with the OS installed on the client as well... But I have a slight issue concerning that: keeping programs up-to-date. Do you have any suggestions to avoid a huge bloody mess concerning keeping client programs in sync with server programs and libraries?

@chilledfrogs For normal system updates (assuming Debian/Ubuntu): Unattended-upgrades.

For new software: Good question. SSH on them and install the software? Maybe with saltstack to reach all machines. But must say, I lack experience here.

Generally: Install the clients from prepared images (with all applications and configuration).

@sbiewald Yeah, of course there would be a cloned image, the point would be in keeping them up-to-date ;) I'll take a look at the stuff you sent me, thanks a ton

@sbiewald Ok, slight breakthrough here: turns out LDM (LTSP's default display manager) was the culprit, since literally by accident I tried to log in through a VT and it worked perfectly fine, X session and everything included... But there is a slight issue that I'm running into and running out of ideas: we tried to just swap it out for good old LightDM, so we set the appropriate executable in the appropriate file... Well, the executable is there, but for whatever idiotic reason, the client image just doesn't get the service file copied, so it reverts back to terminal login... I checked the only client exclude file I could find and it didn't seem to exclude that pattern, but get this: it's copied in /rofs/[...], which I have really no clue what it could be or why it is there instead of the usual path... Would you happen to know any possible reasons for why this could be, and/or maybe suggest some solution for making LDM itself work? The web doesn't seem to have anything on the topic...

Well, managed to fix the display manager issue, was a simple line to add in lts.conf... Now just need to get NFS working as well as some ricing hehe

@chilledfrogs Great news!
I assume with NFS you mean the network file system (is there even another acronym NFS?).

NFS is funny.
You might be surprised how insecure it is, depending on your setup.

My idea would be to export the whole /home folder to all clients and mount it on client startup before login
As you use LDAP for your users, the uid if each user should be set up on every client and user can not read others home directories.

Downside is, when someone gains (local) root, he might read all data of all users. Additionally if an attacker fakes an IP address on his device he can simply mount it itself.
This might be already okayish.

The alternative would be Kerberos authentication and only allow Kerberos authenticated users to access their home directories. This is the secure, but harder way.
Haven't seen this setup anywhere yet, but I'm certainly missing experience here.

@sbiewald Yeah, I already thought of at least for now to keep it simple export /home/ on the server to /home/ on the clients... Keep in mind that this is a school network; I will ask a couple people around to report any security flaws once we get something kinda working 😅 but hey

@sbiewald I indeed heard about Kerberos but it was hard enough for us to get LDAP somewhat working so for now I think we're just gonna try to get the permissions straight enough to at least get a first initial setup 😅

@chilledfrogs Temporary solutions are the ones living longest :)

If you ever redo the network, instead of OpenLDAP I would now recommend something like Active Directory (Windows Server), Samba AD (open source implementation of an Active Durectory) or Univention corporate server (better packaged Samba AD with web interface).

All of those have an LDAP server and have setup Kerberos domains already. You can later join the domain on the clients with either Samba/Winbind or better SSSD.
This will ease up Kerberos setup massively and will allow Windows clients.

@sbiewald The entire point is to get rid of Windows :P

@sbiewald And to be quite blunt, when I looked at how to administer AD I nearly had to grab eye and brain bleach...

@chilledfrogs That's the reason for Samba and Univention, both run on Linux.

I currently have to work with AD - I know it's not great, but it still has advantages.

I don't like Windows in general, it unfortunately has the nice property "it just works", especially with the AD. It's the easy approach.

Getting rid of Windows is a good idea, and I wish more would dom

@sbiewald In my experience it's more "it kinda works some of the time, and if it doesn't, all you can do is sit and cry" but hey 😅 I'll look into the other 2 indeed, even though I've heard that Samba is full of security holes...

@chilledfrogs The "sit and cry" is worse with Exchange.

@sbiewald Ouch... Somehow I'm not surprised 😅
Welp, we'll be working on NFS tonight, hope we can finish it...

@sbiewald Well, it seems to almost work... We're getting some RPC errors on boot, but we couldn't stay forever so we couldn't fix it, but I think it's just a missing service file which can be fixed by KEEP_SYSTEM_SERVICES in lts.conf, at least I hope