IRC chat logs for #ltsp on irc.libera.chat (webchat)

Request log from specific day:

Channel log from 22 June 2023 (all times are UTC)

01:26	ltspbot has left IRC (ltspbot!~supybot@devs.ts.sch.gr, Server closed connection)
01:26	ltspbot has joined IRC (ltspbot!~supybot@devs.ts.sch.gr)
05:09	ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
05:39	<bcg_[m]> alkis: capscience is my colleague. RHEL/Fedora port is still in my todo list but I've been too busy to do it. So now it's caps's turn to give it a try.
05:40	<alkisg> bcg_: nice, I too am too busy but I'll try to chime in a bit wherever I can
05:42	capscience: see also this thread: https://github.com/ltsp/ltsp/discussions/197#discussioncomment-435950
05:44	capscience: apart from IRC, we could also discuss your progress in the related issue: https://github.com/ltsp/ltsp/issues/155 - that way other RHEL/Fedora users might also be able to help
07:36	<bcg_[m]> Some background: Our client is still using ltsp5 on rhel7. Now rhel7 is nearing EOL so we must upgrade to rhel9. Some years ago I already did preliminary port to rhel8, but I never finished it.
07:55	<alkisg> bcg_: fat clients, not thin, right?
07:57	<bcg_[m]> fat
07:58	<alkisg> OK, yeh only dracut and pam will be a challenge then
08:42	wyre is back
08:55	<Hyperbyte> Hi alkisg. I migrated user accounts from our old (Ubuntu 18) to new (Ubuntu 22) LTSP server. I did this by copying the respective entries from /etc/passwd and /etc/shadow. Apparently nobody can login. Do you have any idea where I messed up? :-)
08:56	wyre is now away: Auto away at Thu Jun 22 08:54:31 2023 UTC
09:00	luffy[m] has left IRC (luffy[m]!~luffychat@2001:470:69fc:105::3:5644, Remote host closed the connection)
09:08	<alkisg> Hyperbyte: ltsp initrd, and client reboot?
09:14	<Hyperbyte> Nope, doesn´t work
09:14	I checked auth log on the server, it says auth succesful and then immediately client disconnected
09:23	<alkisg> Hyperbyte: using chroot or chrootless? Is sshfs in the image?
09:24	<Hyperbyte> chrootless, the default. sshfs is in the image, but homes are mounted via nfs.
09:26	auth.log says session opened by user, immediately followed by received disconnect
09:27	I presume something prevents the clients from starting a graphical session, but I don't understand why
09:32	<alkisg> Use an xterm session. Or check the client side logs
09:32	Or the homes ownership
09:37	<Hyperbyte> You're right. I think I forgot -R while setting home dir permissions.
10:26	wyre is back
11:05	* Hyperbyte taps alkisg on the shoulder and bows
11:05	<Hyperbyte> Oh great LTSP oracle. May I partake in your wisdom again?
11:07	Does printing still work out of the box on Ubuntu 22? I read that cups client.conf is being deprecated
11:09	<alkisg> From phone. man ltsp.conf, see print. Cups still woks fine
11:56	<capscience[m]> <alkisg> "When you're sending ltsp.img..." <- Is dnsmasq supposed to tell everything necessary to the client, without any additional config on the external dhcp server? I have a debian test system for reference, and that seems to work without having anything on the external dhcp server. The rhel server does not send anything to the client unless I set next-server and filename to the external dhcp server, so perhaps the dnsmasq config is
11:56	wrong?
11:58	The debian system also seemed to only get ltsp.img when using next-server config on the external dhcp server
11:59	<alkisg> Proxydhcp means no config on external server is necessary
11:59	Realdhcp means no external server exists at all
11:59	Dnsmasq and ltsp support both modes
12:00	<capscience[m]> Ok. So the current problem definetly is that the client does not receive everything it needs to boot
12:00	<alkisg> http://ltsp.org/man/ltsp-dnsmasq/
12:02	<capscience[m]> I configured both systems just using ltsp dnsmasq, so in theory they should be the same config, but now I know where to look next
12:41	Well, that was an easy problem to fix. "Someone" forgot to disable the firewall, that might have blocked the proxy dhcp... Onto the next problem :)
12:42	<alkisg> capscience: btw, do you have any experience with developing dracut plugins?
12:42	<capscience[m]> No, I do not
12:44	This is the first time I work with anything dracut related :)
12:47	<alkisg> Ouch. That'll take a long while then, be very patient! :)
12:47	See the thread I mentioned, I tried it in the past, reached a few bugs in dracut, files them, I was ignored, and I gave up
12:47	*filed
12:48	<capscience[m]> Yeah, that thread was the first thing bcg told me to read
12:49	Might take a while, but at least I'll probably learn something
12:49	<alkisg> It's also possible to boot the clients in ltsp mode without bothering with dracut; in that case, you'd leave the dracut task as the last one
12:49	I've also described that method there in that thread. Then you'll have PAM as the first problem to resolve, which I imagine will be more straightforward
12:50	I think I would recommend that you do that that way, it will be easier on you, and more fruitful
12:51	<capscience[m]> Allright, thanks!
12:51	sunweaver is back
12:54	wyre is now away: Auto away at Thu Jun 22 12:53:12 2023 UTC
12:56	wyre is back
15:08	wyre is now away: Auto away at Thu Jun 22 15:06:40 2023 UTC
15:09	wyre is back
15:19	wyre is now away: Auto away at Thu Jun 22 15:17:16 2023 UTC
15:29	wyre is back
15:31	sunweaver is now away: not here ...
15:31	sunweaver is back
15:39	wyre is now away: Auto away at Thu Jun 22 15:38:13 2023 UTC
15:53	<err404[m]> hello all, on ltsp.conf I see that we can overide fstab by adding something like FSTAB_x="server:/home /home nfs defaults,nolock 0 0"
15:54	but I want use sshfs
15:54	and I want use pam like ltsp is working
15:54	in fact, I want use another ssh server for /home 😛
15:55	<alkisg> 𝔼𝕣𝕣𝟜𝟘𝟜: the users are going to login on server1, and use home from server2?
15:55	<err404[m]> not the ltsp server for /home
15:55	<alkisg> Why don't they login on server2?
15:56	<err404[m]> because all their /home is stored on the server2 (big hard drive)
15:56	<alkisg> Understood, but why don't you put the user accounts on server2 then
15:56	You don't need them on server1 at all
15:56	<err404[m]> I have server1 on a virtual machine, and it is the ltsp server
15:57	but I want use the server2 for /home storage
15:57	<alkisg> What's the host OS, outside the VM?
15:58	<err404[m]> all server run linux and I already used sshfs when I need, but I apreciate the ltsp way (mounting the /home/userxxx by sshfs and using pam)
15:58	<alkisg> OK but you're not answering any of my questions... are you seeing what I'm typing?
15:59	<err404[m]> it is an IRC channel?
15:59	<alkisg> It's both IRC and Matrix
15:59	<err404[m]> yes but sometime the bridge irc/matrix eat some messages
15:59	<alkisg> Yes that's why I'm asking
16:00	So let's try again, what's the host OS, outside the VM, is it Ubuntu 22.04 for example?
16:00	<err404[m]> all is proxmox (debian based)
16:01	<alkisg> OK. And the server2 that will host /home, can the users sshto it?
16:01	<err404[m]> yes, sshfs is working
16:01	<alkisg> So the user accounts are on both the VM and on server2? How do you do that, with LDAP? Or do you copy passwd around?
16:02	<err404[m]> yes, I can copy password if necessary in all servers
16:02	<alkisg> Let's call them proxmox, vm-server, and home-server
16:03	OK then the first step of the solution is to set SERVER=ip-of-home-server in ltsp.conf
16:03	You don't need anything else
16:03	After you do that part, ping me to tell you a better solution where you don't need vm-server running at all
16:05	Essentially, you can use proxmox for serving vm-server.squashfs over NFS, and home-server for SSHFS. You don't need vm-server to be running at all. Your users don't do anything there, it's only used to generate the ltsp image
16:05	<err404[m]> ltsp on a VM is easy to move to another proxmox server, so, I want keep the ltspVM small, and I dont want user data comming with the ltspVM when I copy the ltspVM to another place
16:06	<alkisg> Yes, I understood the use case
16:06	Your ltsp server isn't an ltsp server. It's an ltsp template VM that is only used to generate the ltsp image
16:06	<err404[m]> ok
16:07	understand more and more 😛
16:07	thanks
16:07	<alkisg> Do the SERVER=ip-of-home-server in ltsp.conf first. See that it works that way. Then come back and read the rest that I wrote once more, it'll make more sense then :)
16:16	sunweaver is now away: not here ...
16:17	<err404[m]> I added SERVER=ip-of-home-server to ltsp.conf, and I runned ltsp initrd, and after start the diskless client, it was not working as expected, but because the /home on the server2 is a symlink instead of a directory, I will change this last point later and retry
16:17	<alkisg> You will also need to either have the same ssh keys, or add the home-server ssh keys to the image
16:17	<err404[m]> can I use SERVER=ip-of-home-server/data/home ?
16:18	<alkisg> No. But it doesn't matter that it's a symlink. As long as sudo sshfs user@ip-of-home-server: /mnt mounts the user home directory, it'll work
16:18	Note that I didn't put anything after ":", no path; that means "the user home dir"
16:20	<err404[m]> sudo sshfs user@ip-of-home-server: /mnt <-- it work
16:20	<alkisg> Great, do the ssh host keys now
16:22	<err404[m]> ssh host keys is not the ssh id stored in /home/user/.ssh/ ?
16:22	s/ssh/ssh_id/, s/id//
16:26	vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:50)
16:28	<alkisg> In /etc/ssh/*key
16:29	The easiest way is to copy the ltsp server keys to the home server /etc/ssh dir
16:32	<err404[m]> ok, so it is different from the ssh users keys
16:33	I will made anothers tests in few hours, thanks for you patience and thanks for ltsp 😛
20:46	ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
23:53	vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:50, Quit: leaving)