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


Channel log from 9 March 2023   (all times are UTC)

00:11jgee1186922534 has left IRC (jgee1186922534!~jgee@186.80.73.50, Quit: The Lounge - https://thelounge.chat)
00:12jgee11869225345 has joined IRC (jgee11869225345!~jgee@186.80.73.50)
00:30Vercas has left IRC (Vercas!~Vercas@gateway/tor-sasl/vercas, Remote host closed the connection)
00:30Vercas has joined IRC (Vercas!~Vercas@gateway/tor-sasl/vercas)
00:39sugarbeet is now away: [tmux detached]
01:13sugarbeet is back
01:15sugarbeet is now away: [tmux detached]
01:28jason has joined IRC (jason!~jason@98.97.58.39)
03:41jason has left IRC (jason!~jason@98.97.58.39, Quit: Leaving)
05:45vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:40, Quit: leaving)
06:06eu^10618115189ch has joined IRC (eu^10618115189ch!~eu^106181@89.151.181.106)
06:10eu^10618115189ch has left IRC (eu^10618115189ch!~eu^106181@89.151.181.106, Client Quit)
06:11pretorianecx90[m has joined IRC (pretorianecx90[m!~pretorian@2001:470:69fc:105::3:29bc)
06:37wyre is back
06:46ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:02
<Tuxifan[m]>
I see
07:02
Is there a way to additionally provide RDP access to the server?
07:02
* Is there an intended way to additionally provide RDP access to the server?
07:06wyre is now away: Auto away at Thu Mar 9 07:05:50 2023 UTC
07:10
<vsuojanen[m]>
do you mean what tool or package is favored? not really. there's xfreerdp client referenced on some ltsp github wiki pages
07:11
<alkisg>
Yeah that part isn't specific to LTSP, but installing xrdp is a nice approach. Another one is x2go.
07:33wyre is back
07:57
<Tuxifan[m]>
Yup! Just installed xrdp, and it's working nicely 🙂
07:57
Had to change sssd configuration a bit tho
07:57
Is there a way to stop clients from starting the xrdp server too?
08:35
<vsuojanen[m]>
are you setting up rdp connection from netboot clients back to to the ltsp server?
08:35
<alkisg>
Tuxifan: sure, DISABLE_SYSTEM_SERVICES="xrdp" (or whatever the service name is), in ltsp.conf, and then run ltsp initrd
08:37
<vsuojanen[m]>
ah sorry i thought xrdp would omitted by default
08:47
<Tuxifan[m]>
<alkisg> "Tuxifan: sure, DISABLE_SYSTEM_SE..." <- Pefect! Thanks 🙂
08:49
For some reason the home sshfs doesn't seem on any PXE client, for domain users at least
08:50
* doesn't seem to mount on any
08:51
<vsuojanen[m]>
both server and clients should be domain joined i think is enough
08:52
<Tuxifan[m]>
How would I join the clients to the domain? I thought joining the server is enough because the server does authentication?
08:55woernie has joined IRC (woernie!~werner@93.222.197.140)
08:55
<vsuojanen[m]>
When you use AD authentication it uses different pam auth (sssd) and it's independent from ltsp server
08:56
The home needs/If desired to Be mount tough from The ltsp server.
08:58
<Tuxifan[m]>
vsuojanen[m]: Hmm, can I configure the client to use the server to authenticate instead?
08:58
So it goes over the server
08:59
<alkisg>
The problem isn't authentication, it's user enumeration, i.e. nss, i.e. getent passwd
08:59
In normal mode, /etc/passwd is copied from the server to the clients as a file
08:59
So when you add new users on the server, you need to run ltsp initrd and reboot the clients to see them
08:59
<Tuxifan[m]>
Yeah
08:59
<alkisg>
In LDAP/AD/Whatever mode, you need an NSS service running on the clients
09:00
That is the service that will list the users
09:00
So, the clients need to join LDAP/AD etc too
09:01
<Tuxifan[m]>
But, like, the login on the clients works just fine, it's just the SSHFS...
09:01
<alkisg>
Then pam isn't properly configured
09:02
If you run ssh user@server on a client, can you properly authenticate using ldap/ad credentials?
09:02
<Tuxifan[m]>
Let me give that a try...
09:04
alkisg: That works
09:05
So sshfs should work too... right?
09:05
I can do id username@domain on the clients too, so they are definitely joined
09:07
<alkisg>
OK, now press Ctrl+Alt+F5 and try to login there; see if there are any error messages regarding sshfs etc
09:08
Also try: grep -r . /etc/pam.d/common* | nc termbin.com 9999
09:12
<Tuxifan[m]>
I just noticed something:
09:12
`sshfs user@domain:/home/user@domain/ /home/user@domain/` gets stuck forever while
09:12
`sshfs user@domain:/home/user@domain/ ./test` doesn't
09:18
<alkisg> "OK, now press Ctrl+Alt+F5 and..." <- sshfs seems to mount there just fine
09:19
<alkisg>
Which desktop environment / DM are you using? Eg. ubuntu 22.04 gnome with gdm3?
09:19
<Tuxifan[m]>
Debian Testing with KDE Plasma
09:21
<alkisg> "Also try: grep -r . /etc/pam.d/..." <- https://termbin.com/ylucm
09:26ddimakis[m] has joined IRC (ddimakis[m]!~ddimakism@2001:470:69fc:105::f3b5)
09:26
<ddimakis[m]>
Kαλησπέρα
09:28
Είχα έναν υπολογιστή που κλάπηκε. Ήταν δηλωμένος στο ltsp.conf ως va06. Στην θέση του έβαλα αυτόν που είχα δηλώσει ως va04 και άλλαξα την διεύθυνση στο αρχείο. Από την στιγμή που το έκανα αυτό ο τέως va04 χάθηκε από τον επόπτη ενώ φορτώνει το λειτουργικό
09:28
<alkisg>
!greek
09:28
<ltspbot>
greek: Στο παρόν κανάλι μιλάνε μόνο Αγγλικά, για υποστήριξη στα Ελληνικά από την υπηρεσία Τεχνικής Στήριξης ΣΕΠΕΗΥ διαβάστε το http://ts.sch.gr/wiki/IRC και στη συνέχεια πληκτρολογήστε /j #ts.sch.gr
09:28
<alkisg>
ddimakis: είσαι στο αγγλικό κανάλι, έλα στο ελληνικό ^
09:29
<ddimakis[m]>
ok
09:29
<Tuxifan[m]>
Are there any logs to check for sshfs? Like syslog?
09:30
<alkisg>
Tuxifan: give it another go to try to login via sddm now; unfortunately I'm multitasking too much currently to keep up with this thread
09:30
There's /var/ltsp/debug.log or something like that, and there's pam log, reachable via journalctl
09:30
<Tuxifan[m]>
alkisg: Sorry, don't mean to overload you 😅
09:31ddimakis[m] has left IRC (ddimakis[m]!~ddimakism@2001:470:69fc:105::f3b5)
09:37
<Tuxifan[m]>
Btw, is it enough to just run ltsp image ; ltsp image to update everything? Or do I need to run anything else?
09:38
<alkisg>
Two times ltsp image? What for?
09:38
If you update the software on your server, then yes ltsp image / is enough to update the client image
09:43
<Tuxifan[m]>
<alkisg> "Two times ltsp image? What for?" <- Second one was meant to be initrd 😄
09:44
<alkisg> "If you update the software on..." <- Alright!
09:44
<alkisg> "There's /var/ltsp/debug.log or..." <- I just noticed I can't log in locally on the client
09:44
Just says authentication failure.
09:44
Therefore, I can't read the log
09:46
Something seems very mixed up here
09:54
<alkisg>
I just noticed I can't log in locally on the client ==> I thought you said you already logged in on ctrl+alt+f5 and sshfs was working fine there
09:57
<Tuxifan[m]>
alkisg: Oh, I meant I can't log in using local accounts
09:57
like, non-domain accounts
09:57
<alkisg>
!hash
09:57
<ltspbot>
I do not know about 'hash', but I do know about these similar topics: 'LDM_PASSWORD_HASH', 'ROOT_PASSWORD_HASH'
09:57
<Tuxifan[m]>
s/in/into/, s/using//
09:57
<alkisg>
!ROOT_PASSWORD_HASH
09:57
<ltspbot>
ROOT_PASSWORD_HASH: To be able to login as root in vt1, read the last example in https://ltsp.org/man/ltsp.conf/
09:58
<Tuxifan[m]>
Hmm, I am trying to log into my UID 1000 user
09:58
That worked before
09:58
But I guess trying root can't hurt
09:58
<alkisg>
I've never used realmd, I don't know what pam changes it makes
09:59
That ^ root method bypasses ltsp pam and ad pam, so it should work
09:59
<Tuxifan[m]>
alkisg: It all works just fine on the server, interestingly
09:59
alkisg: So I am going to use that for debugging 🙂
10:00
Thanks
10:00
<alkisg>
Well, if it manually changes /etc/pam.d, without respecting pam-auth-update, then pam-auth-update WILL break it; nothing interesting about that though :D
10:00
(ltsp runs pam-auth-update on boot, to add its own pam hooks)
10:00
(which is the proper thing to do, but may break other bad implementations)
10:01
<Tuxifan[m]>
Hmmm, mind if I just send you the entire PAM config folder in PM? Maybe you can get something out of it. I wish I understood PAM configs lol
10:02
<alkisg>
PAM issues require a lot of time, and unfortunately this month I'm overwhelmed :/
10:02
(or maybe this decade, not sure yet :D)
10:03
<Tuxifan[m]>
I see 😄
10:03
I guess I am going to have to wrap my head around it myself then
10:03
<alkisg>
👍️
10:05
<Tuxifan[m]>
So, I am going to start the client, log in as domain user, and use su to read some logs
10:05
<alkisg>
Or directly login as root on vt1/2/3
10:06
<Tuxifan[m]>
Yeah. I noticed the SSSD service appearently failing to start
10:09
Uhm. Root doesn't work either
10:12
Ahhh, epoptes to the rescue
10:12
<alkisg>
Did you run ltsp initrd after adding the ltsp.conf line for root hash?
10:12
But yeah epoptes is great :0
10:13
<Tuxifan[m]>
alkisg: Ohhhhhhhhh, hahaha, oops, thanks for that hint 🙂
10:13
I never really ran ltsp initrd
10:13
Wasn't ever sure if it's actually needed and decided it probably isn't
10:15
Oh wow, xterm is really bad with journalctl
10:16
User not known to the underlying authentication module
10:16
That's what I am getting
10:19
<alkisg>
Sounds like bad pam/nss settings all right
10:22
<Tuxifan[m]>
Huh... I don't get why it's working on the server but not on the clients
10:22
It must actually be some conflict with the way ltsp sets up its own authentication as you mentioned
10:23
<alkisg>
80% of the internet tutorials suggest manually modifying /etc/pam.d. 80% of them are wrong and they should be using pam-auth-update instead :)
10:26
<Tuxifan[m]>
I am using realmd, which does all of that automatically, and it's made (or at least documented) by Red Hat, so it must be good, right?
10:27
https://access.redhat.com/documentation/de-de/red_hat_enterprise_linux/7/html/windows_integration_guide/ch-configuring_authentication#realmd-supported-domains-clients
10:27
<alkisg>
No, because Redhat isn't using the debian ways of managing pam
10:27
<Tuxifan[m]>
Oh, huh
10:27
<alkisg>
Many years ago they got pam-auth-update from debian; then they developed their own fork or solution, not sure
10:28
<Tuxifan[m]>
Can you link a good tutorial on how to do this correctly on Debian?
10:28
<alkisg>
Unfortunately no, pam lacks good documentation and tutorials
10:28
<Tuxifan[m]>
Ah...
10:28
<alkisg>
The key points are pam-auth-update and /usr/share/pam-configs/
10:30
<Tuxifan[m]>
https://ubuntu.com/server/docs/service-sssd-ad
10:30
Ubuntu.com must've got that right
10:33
Nvm, they use realmd too...
10:33
<alkisg>
If realmd is properly packaged for debian, it means it was probably modified to respect pam-auth-update
10:33
In any case, it needs troubleshooting :D
10:35
<Tuxifan[m]>
Yeahh... should I open an issue on the ltsp repository so maybe someone more experienced than can take a look at it?
10:35
<alkisg>
Eh, sure, but that'd be just me, so ... :)
10:36
<Tuxifan[m]>
Oh, well
10:36
Waiiit. there is this module required to automatically create a home dir... In the ubuntu docs they tell me to use the pam-auth-update command to add it, but I added it manually... Could that be causing any issues?
10:37
<alkisg>
You should be able to login in vt2 even without a home directory
10:41
<Tuxifan[m]>
Hmm... I might've messed up something else there. Not sure. I restored everything back to how it was and am going to retry the whole thiing
10:41
s/thiing/thing/
10:43fiesh has left IRC (fiesh!~fiesh@2003:fb:1018::21, Ping timeout: 265 seconds)
10:48jgee118692253454 has joined IRC (jgee118692253454!~jgee@186.80.73.50)
10:50jgee11869225345 has left IRC (jgee11869225345!~jgee@186.80.73.50, Ping timeout: 276 seconds)
10:50jgee118692253454 is now known as jgee11869225345
11:23fiesh has joined IRC (fiesh!~fiesh@2003:fb:1018::21)
11:31
<Tuxifan[m]>
Okay, I rejoined the domain using realmd... Now am I creating a new image and initrd, so I can check if login to local accounts is broken again
11:31
And if the same sshfs error is back
11:43
Does ltsp include files only readable by root in the image?
11:44
seems like sssd.conf is strictly root-only-readable
11:44
s/-/ /
12:06
<alkisg>
Ltsp just keeps the original permissions
12:54eu^D9649C0Astati has joined IRC (eu^D9649C0Astati!~eu^D9649C@D9649C0A.static.ziggozakelijk.nl)
12:54eu^D9649C0Astati has left IRC (eu^D9649C0Astati!~eu^D9649C@D9649C0A.static.ziggozakelijk.nl, Client Quit)
14:06
<Tuxifan[m]>
Awesome 🙂
15:59wyre is now away: Auto away at Thu Mar 9 15:58:24 2023 UTC
16:37jason has joined IRC (jason!~jason@98.97.58.39)
16:47tuxifan is back
16:54
<vsuojanen[m]>
Tuxifan did you continue with the sshfs issue? If I read the above discussions right did you get the getent work on clients and server?
16:56
<tuxifan>
vsuojanen[m] alkisg: By reinstalling the realm with instructions from ubuntu.com, I got sshfs to work. Users other than domain users are still unable to log in (including root), but that's fine if I think about it.
16:57
I noticed that if I could root, I could just trigger a root shell from epoptes
16:57
<vsuojanen[m]>
yeah remote root
16:58
<alkisg>
Great. Regarding "other users", it's tricky to get pamltsp to work both in "primary" and "additional" pam sections, so yeah leave it at that
16:58
Root should be able to login using the ltsp.conf trick
16:58
But if you have epoptes, you don't need that
16:58
<tuxifan>
Yeah. And no, root still can't log in :-)
16:58
<alkisg>
If you do have an epoptes shell, I could take a quick look
16:58
Or just check yourself:
16:59
grep root /etc/shadow
16:59
Do you see that big hash there, and is it the same as the one you specified?
16:59
<tuxifan>
Going to check that tomorrow, I already left the building and I'm back home.
16:59
<alkisg>
And then, from root epoptes shell, type passwd root, set a new one, and try to login in vt2 with that password
17:00
<tuxifan>
But thanks for attempting to help, I am going to come back to you tomorrow
17:00
<alkisg>
If you can login that way, it just means the hash is wrong
17:00
<tuxifan>
Is vt2 special, unlike other vts?
17:01
<vsuojanen[m]>
Nice work Tuxifan
17:01
<tuxifan>
Thanks
17:44
<alkisg>
No, any vt will do
17:52MarcoRomagnoli[m has joined IRC (MarcoRomagnoli[m!~marco-rom@2001:470:69fc:105::3:2a2a)
18:11
<MarcoRomagnoli[m>
Hi. I 'm working fine in my Computer Science Laboratory (High School) with 30 PCs with Debian 8 and LTSP from many years. I decided finally to (try to) upgrade to last Debian (version 12 with non -free firmware) and LTSP. I struggled many hours and finally I had LTSP working on my laptop (a quite new HP Elitebook with 16 GB RAM), but the clients at the end are booting with 640x480 resolution on their (Full HD) Monitor. Tried long with
18:11
change on ltsp.conf, but nothing... Searching here I find out this suggestion (on the same issues?) : Alkisg: "....OK now try adding vga=ask in KERNEL_PARAMETERS (and run ltsp ipxe) . When prompted, select a 1024x768 something mode". Is it a possible solution? I did add this line to ltsp.conf : KERNEL_PARAMETERS="vga=ask" in the [client] section. Is it OK? What to do next? I see no prompt to select something. Thanks
18:12
<alkisg>
Marco Romagnoli: install debian locally in one of these pcs and see if graphics work
18:12
When you do fix graphics there, possibly with the help of the #debian irc channel, then do the same things in the ltsp installation and graphics will work there too
18:12
In short, graphics issues are not at all related to ltsp
18:13
If you happen to have epoptes installed and working, I could take a quick look with remote-support
18:17
<MarcoRomagnoli[m>
yes, epoptes is working fine. Everything is working fine, if I just leave for others years on Server Debian 8 and old LTSP. I just would like to upgrade to something more updated and attractive for my students.
18:17
<alkisg>
!vnc-edide
18:17
<ltspbot>
vnc-edide: To share your screen with me, open Epoptes → Help menu → Remote support → Host: srv1-dide.ioa.sch.gr, and click the Connect button
18:17
<alkisg>
Marco Romagnoli: follow the bot instructions to share the server screen with me ^
18:19
<MarcoRomagnoli[m>
It is OK. I can do it tomorrow , or next week (according to your time preference) when I'll be at School (need to adjust with Time difference, as I live in Italy).
18:21
<alkisg>
I'll be in Italy from 21 to 27 of March, we can do it locally there :P
18:21
Joking; ping me when you can, we'll see if I'm available then
18:22
But in general, follow the "install debian locally and troubleshooting with the help of the #debian folks" advice
18:25
<MarcoRomagnoli[m>
I understand (install debian locally and troubleshooting with the help of the #debian folks). I didn't expect so fast reply and suggestion. Thank You soo much.
18:27
But now I'm curious to know more about the Event in Italy ? Where it will be? Is there a Conference or something related with Computer Science or something different?
18:28
In case is related with Open Source Software, than I'd like to know it
18:33
<alkisg>
Marco Romagnoli: no, just some teacher education in Foligno
18:33
Completely unrelated to open source
18:39
<MarcoRomagnoli[m>
Even more interesting! I'm a Teacher! It seems there is something in common. Very nice to know. Changing subject: Last info on previous request. A colleague of mine (another C.S. Theacher who uses LTSP) also had difficulties on upgrading Debian and LTSP. He suggest me to switch to Linux mint , in his case he solved his issues.
18:40
<alkisg>
Debian is a bit more difficult to set up, sometimes help from #debian is needed, e.g. for firmware
18:40
I think bookworm will include non-free firmware though, so I guess it'll be easier
18:42
<MarcoRomagnoli[m>
Yes I understand. I did install today last Debian release : bookworm, and still the problem is there. OK. Thank you again.
18:44
<alkisg>
OK, see you, cheers!
19:10vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:40)
19:34wyre is back
19:48tuxifan is now away: All Quassel clients vanished from the face of the earth...
19:49tuxifan is back
20:34woernie has left IRC (woernie!~werner@93.222.197.140, Remote host closed the connection)
21:05tuxifan is now away: All Quassel clients vanished from the face of the earth...
21:06tuxifan is back
21:13wyre is now away: Auto away at Thu Mar 9 21:13:11 2023 UTC
22:08ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
23:15
<tuxifan>
MarcoRomagnoli[m: grep for `firmware` in the kernel log, does that yield anything?
23:16
Just adding the non-free repo isn't enough to have the required firmware, there are the firmware* packages containing the actual firmware
23:17
You could also clone the whole linux firmware repo as /usr/lib/firmware, but make sure to uninstall all these firmware* packages first. That's just a last resort tho, if nothing else works
23:28tuxifan is now away: All Quassel clients vanished from the face of the earth...
23:43
<jason>
Bookworm will come with the non-free-firmware repo active but none of it will likely be installed. In my case I still have to install firmware-linux-nonfree. After my stuff works fine. You will likely have the same issue.