00:11 | jgee1186922534 has left IRC (jgee1186922534!~jgee@186.80.73.50, Quit: The Lounge - https://thelounge.chat) | |
00:12 | jgee11869225345 has joined IRC (jgee11869225345!~jgee@186.80.73.50) | |
00:30 | Vercas has left IRC (Vercas!~Vercas@gateway/tor-sasl/vercas, Remote host closed the connection) | |
00:30 | Vercas has joined IRC (Vercas!~Vercas@gateway/tor-sasl/vercas) | |
00:39 | sugarbeet is now away: [tmux detached] | |
01:13 | sugarbeet is back | |
01:15 | sugarbeet is now away: [tmux detached] | |
01:28 | jason has joined IRC (jason!~jason@98.97.58.39) | |
03:41 | jason has left IRC (jason!~jason@98.97.58.39, Quit: Leaving) | |
05:45 | vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:40, Quit: leaving) | |
06:06 | eu^10618115189ch has joined IRC (eu^10618115189ch!~eu^106181@89.151.181.106) | |
06:10 | eu^10618115189ch has left IRC (eu^10618115189ch!~eu^106181@89.151.181.106, Client Quit) | |
06:11 | pretorianecx90[m has joined IRC (pretorianecx90[m!~pretorian@2001:470:69fc:105::3:29bc) | |
06:37 | wyre is back | |
06:46 | ricotz 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:06 | wyre 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:33 | wyre 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:55 | woernie 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:26 | ddimakis[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:31 | ddimakis[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:43 | fiesh has left IRC (fiesh!~fiesh@2003:fb:1018::21, Ping timeout: 265 seconds) | |
10:48 | jgee118692253454 has joined IRC (jgee118692253454!~jgee@186.80.73.50) | |
10:50 | jgee11869225345 has left IRC (jgee11869225345!~jgee@186.80.73.50, Ping timeout: 276 seconds) | |
10:50 | jgee118692253454 is now known as jgee11869225345 | |
11:23 | fiesh 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:54 | eu^D9649C0Astati has joined IRC (eu^D9649C0Astati!~eu^D9649C@D9649C0A.static.ziggozakelijk.nl) | |
12:54 | eu^D9649C0Astati has left IRC (eu^D9649C0Astati!~eu^D9649C@D9649C0A.static.ziggozakelijk.nl, Client Quit) | |
14:06 | <Tuxifan[m]> Awesome 🙂
| |
15:59 | wyre is now away: Auto away at Thu Mar 9 15:58:24 2023 UTC | |
16:37 | jason has joined IRC (jason!~jason@98.97.58.39) | |
16:47 | tuxifan 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:52 | MarcoRomagnoli[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:10 | vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:40) | |
19:34 | wyre is back | |
19:48 | tuxifan is now away: All Quassel clients vanished from the face of the earth... | |
19:49 | tuxifan is back | |
20:34 | woernie has left IRC (woernie!~werner@93.222.197.140, Remote host closed the connection) | |
21:05 | tuxifan is now away: All Quassel clients vanished from the face of the earth... | |
21:06 | tuxifan is back | |
21:13 | wyre is now away: Auto away at Thu Mar 9 21:13:11 2023 UTC | |
22:08 | ricotz 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:28 | tuxifan 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.
| |