IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 15 December 2021 (all times are UTC)
| 02:35 | vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:21:21:0:100e) | |
| 04:38 | vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:21:21:0:100e, Quit: leaving) | |
| 05:46 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585682-65.dhcp.inet.fi) | |
| 07:22 | NecTal has joined IRC (NecTal!~NecTal@194.126.106.149) | |
| 07:25 | <NecTal> Hello. I have a small problem with autologin. I added mac separated lines in ltsp.conf and added there hostname, autologin and passwords_hostname lines but for some reason it does not log this client in automatically.
| |
| 07:25 | <alkisg> NecTal: did you run `ltsp initrd` after modifying ltsp.conf?
| |
| 07:26 | <NecTal> Yes.
| |
| 07:26 | <alkisg> NecTal: do you have epoptes installed? Do you mind if I see over remote-assistance, to resolve this sooner?
| |
| 07:26 | !vnc-edide
| |
| 07:26 | <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
| |
| 07:30 | <NecTal> Unfortunately i don't have epoptes installed.
| |
| 07:30 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 07:30 | <NecTal> But does the password have to be base 64 encoded in ltsp.conf?
| |
| 07:30 | <alkisg> Yes
| |
| 07:31 | It's to prohibit "over-the-shoulder" looking
| |
| 07:31 | Can you pastebin your ltsp.conf? But put "xxx" where the passwords are, to hide them
| |
| 07:35 | <NecTal> https://pastebin.com/E99tv8jE
| |
| 07:37 | <alkisg> NecTal: if you login to the client, do you see the correct hostname that you set, or is it like ltsp123?
| |
| 07:39 | <NecTal> I do but i don't know if it takes it from dnsmasq or ltsp.conf.
| |
| 07:40 | <alkisg> Try to set it to something else in ltsp.conf, e.g. HOSTNAME=test123
| |
| 07:40 | Run ltsp initrd, reboot, then if you see test123 it means your ltsp.conf works and the problem is in the base64 encoding
| |
| 07:44 | <NecTal> ltsp.conf works. Client got the hostname from it after login.
| |
| 07:45 | <alkisg> OK then the problem is in the password. Try this: press ctrl+alt+f2 to switch to vt2, type "tooreg" and "enter" for a password, it's supposed to be automatically filled by ltsp
| |
| 07:45 | Does it show some error message there?
| |
| 07:50 | <NecTal> In a new login screen after i typed in username and pressed enter on password prompt it says "Sorry that didn't work. Try again.". And in tty3 console it says login incorrect.
| |
| 07:51 | <alkisg> Go to the server, run `journalctl -b -f`, then try again to login on the client
| |
| 07:52 | Does the server say "auth: wrong password" or something like that?
| |
| 08:48 | woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Ping timeout: 265 seconds) | |
| 08:48 | woernie_ has joined IRC (woernie_!~werner@p5b296789.dip0.t-ipconnect.de) | |
| 10:21 | <NecTal> Sorry for the delay. Had a meeting. But journalctl only shows this without manually logging in.
| |
| 10:21 | https://pastebin.com/DK55rnme
| |
| 10:21 | Even tried different user.
| |
| 10:25 | <alkisg> OK, you'll need to install epoptes for more help, as it's probably a user error somewhere
| |
| 10:25 | I.e. it'll take 2 hours over IRC, or 2 minutes over VNC... :)
| |
| 10:41 | <NecTal> Just one question. Should the user account be local account in ltsp server for autologin to work? Because i'm getting users from our fileserver.
| |
| 10:42 | <alkisg> The username/password should be appropriate for ssh'ing to the SSH_SERVER, which by default is the ltsp server
| |
| 10:42 | If you want your users to authenticate to your fileserver, and get their homes from there, you can set SSH_SERVER in ltsp.conf
| |
| 10:47 | <NecTal> Okay. Does it matter which display manager i'm using? Right now I'm using gdm3 display manager where user accounts are hidden so that user has to enter username and password manually?
| |
| 11:03 | <alkisg> No, you can login using any method, a display manager, the console, ssh, whatever
| |
| 11:03 | It's a PAM hook so it's universal
| |
| 11:04 | !bench
| |
| 11:04 | <ltspbot> I do not know about 'bench', but I do know about these similar topics: 'cpubenchmark', 'lan-benchmark'
| |
| 11:04 | <alkisg> !lan-benchmark
| |
| 11:04 | <ltspbot> lan-benchmark: If you have a mixed-speed network (gigabit server<=>switch connection, and 100 Mbits/sec clients<=>switch connections), then you might suffer from the !flow-control issue. To benchmark your LAN with epoptes, see http://www.epoptes.org/documentation/lan-benchmark
| |
| 11:05 | <alkisg> Strange, that page was there in the distant past, then it got removed, I don't know how. I just rewrote it though, and I strongly recommend that LTSP sysadmins follow it at least once, to test their computer lab speed
| |
| 14:01 | NecTal has left IRC (NecTal!~NecTal@194.126.106.149, Quit: Client closed) | |
| 16:03 | fdfgdfgdfgdfgd has joined IRC (fdfgdfgdfgdfgd!~fdfgdfgdf@159.146.10.78) | |
| 16:03 | <fdfgdfgdfgdfgd> 123123
| |
| 16:03 | 21321
| |
| 16:03 | fdfgdfgdfgdfgd has left IRC (fdfgdfgdfgdfgd!~fdfgdfgdf@159.146.10.78, Client Quit) | |
| 16:23 | <ogra_> damn, someone leaked this weeks lottery numbers !
| |
| 16:35 | lucascastro has left IRC (lucascastro!~lucascast@192-140-51-187.static.oncabo.net.br, Ping timeout: 256 seconds) | |
| 17:28 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585682-65.dhcp.inet.fi, Ping timeout: 250 seconds) | |
| 17:29 | zetaE has joined IRC (zetaE!~neon@139.47.114.154) | |
| 17:29 | <zetaE> hei
| |
| 17:29 | anybody around?
| |
| 17:30 | what's the trick to ssh client to client?
| |
| 17:30 | that is terminal to terminal?
| |
| 17:30 | <quinox> sshd is disabled by default
| |
| 17:30 | <zetaE> oohh!!
| |
| 17:30 | <quinox> since you don't have unique private server keys
| |
| 17:30 | you can enable it if you want to
| |
| 17:30 | let me find the documentation, sec...
| |
| 17:31 | <zetaE> quinox: what about ssh jumping via the server? terminal1 --> server --> terminal2
| |
| 17:31 | <quinox> https://ltsp.org/man/ltsp.conf/ see KEEP_SYSTEM_SERVICES
| |
| 17:31 | <zetaE> as matter fact ssh is one way only, even from the server I can.t ssh into terminals
| |
| 17:32 | <quinox> For management there's https://epoptes.org/ - it allows controlling all clients from a nice GUI
| |
| 17:32 | including VNC and shell access
| |
| 17:33 | <zetaE> quinox: I see, I was trying to do old fashion way
| |
| 17:34 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585682-65.dhcp.inet.fi) | |
| 17:34 | <zetaE> quinox: can you enlighten me on some issue? Terminals are able to "su" into anyother user, and ssh as well.
| |
| 17:36 | <quinox> with the password of the other user?
| |
| 17:36 | or without password
| |
| 17:36 | <zetaE> "su"ing from terminal only shows the users logged in /home/{terminal,su "other user"} , such as the terminal and when su.
| |
| 17:37 | yet when ssh'ing into any other user with server.s ip it shows all the users in /home
| |
| 17:37 | a bit confusing behavior
| |
| 17:37 | <quinox> ah
| |
| 17:37 | <zetaE> can epoptes be run as user in terminals?
| |
| 17:38 | <quinox> a booted LTSP client has an empty /home/ - when you log in LTSP will mount the appropriate /home/<user>/ using SSHFS
| |
| 17:38 | when you do 'su' you bypass that, and then you'll not have /home/<su-user>/
| |
| 17:38 | SSHFS is the default setup, it works out of the box
| |
| 17:39 | you can also mount /home/ directly from the server before the login happens, then you'll see all users in /home/
| |
| 17:39 | <zetaE> I see, it mounts per user directory
| |
| 17:39 | <quinox> by default, yes
| |
| 17:40 | https://ltsp.org/man/ltsp-nfs/ see fe. for mounting the entire /home/ folder
| |
| 17:40 | <zetaE> the epoptes thingy, can any terminal use it ?
| |
| 17:40 | <quinox> I have never used it myself, I'm fairly confident you need to be root on the server to use it
| |
| 17:40 | <zetaE> basically, I need the admin user be able to shutdown reboot any terminal
| |
| 17:41 | that's why I wanted to use ssh
| |
| 17:41 | <quinox> Epoptes should be able to do that
| |
| 17:41 | either right-click and pick "shutdown" or run the command "shutdown -h" on the remot eclient
| |
| 17:42 | epoptes is used in school environments to control all LTSP clients
| |
| 17:43 | so things like remote shutdown, sending messages, taking a look at screen, taking over remotely
| |
| 17:43 | <zetaE> thanks
| |
| 17:44 | quinox: one more question, how to integrate a separate hard disk for shared media?
| |
| 17:44 | currently is set up with samba, which in my opinion is assbackwards in this case
| |
| 17:44 | <alkisg> !sshd
| |
| 17:44 | <ltspbot> sshd: Exposing sshd host keys over NFS is unsafe, so it's disabled by default and !epoptes is recommended instead. If you insist on running sshd in LTSP clients, read https://github.com/ltsp/ltsp/discussions/310#discussioncomment-101549
| |
| 17:45 | <quinox> shared between different users on the same hardware, or between different users on different computers?
| |
| 17:45 | that would be however you want to do it with standard Linux
| |
| 17:45 | SMB is a decent option
| |
| 17:45 | <alkisg> https://epoptes.org/documentation/run-fat/
| |
| 17:46 | <zetaE> quinox: the server has both ltsp harddrive and the second hard disk
| |
| 17:46 | * alkisg can only paste links, typing from phone... ;) | |
| 17:47 | <zetaE> quinox: samba doesn't integrate with lxqt remote places and requires logging which makes no sense as the material should be always available and not per user basis
| |
| 17:48 | cramming the entire m$$$ protocol for a always-available media seems an overkill
| |
| 17:48 | <quinox> I have a normal SMB mount entry in /etc/fstab that mounts my network share as /mnt/media
| |
| 17:48 | <zetaE> alkisg: thanks
| |
| 17:48 | <quinox> if happens on boot, so users don't have to know how to log in on SMB themselves
| |
| 17:48 | <zetaE> quinox: do you need to logging each time you boot into the clients?
| |
| 17:49 | I mean, click on "network places" then the m$$$ logging thingy
| |
| 17:49 | <quinox> nope, it happens on startup
| |
| 17:49 | without user interaction
| |
| 17:49 | let me find my command...
| |
| 17:50 | <zetaE> quinox: so the server is mounting the media before the clients in your case?
| |
| 17:51 | <quinox> Inside my `lts.conf` I have this line in the [Default] block:
| |
| 17:51 | RCFILE_22="mkdir -p /mnt/archive && /sbin/mount.cifs //2a01:1b0:5256:1337:10:50:0:12/ARCHIEF /mnt/archive -o guest,noserverino,gid=2000,forcegid,file_mode=0660,dir_mode=0770 || echo 'Failed to mount /mnt/archive'"
| |
| 17:51 | <zetaE> so it's transparent to clients
| |
| 17:51 | <quinox> correct
| |
| 17:52 | <zetaE> in this case is the client doing the "network search" which makes absolutely no sense on top of being slow as hell
| |
| 17:52 | <quinox> it doesn't do a search: it has the IP address of the server hardcoded, so it works right away
| |
| 17:53 | <zetaE> users get confuse a copy the entire mounted disk into a "public" folder in Desktop rather than being a shortcut
| |
| 17:53 | <quinox> that I do not know, I don't use a desktop myself
| |
| 17:53 | if you know another Linux way of mounting the drive you're free to use that
| |
| 17:54 | <zetaE> quinox: thank's for the snippet
| |
| 17:54 | <quinox> you can use the RCFILE_xx to run commands on startup
| |
| 17:55 | <zetaE> great
| |
| 17:57 | nowadays with terminals being quite powerful hardware wise, does ltsp make sense?
| |
| 17:59 | <quinox> LTSP has dropped support for thin clients, that idea indeed doesn't make any sense anymore
| |
| 17:59 | <zetaE> mm.. why not share /home with nfs as in /etc/exports example?
| |
| 17:59 | <quinox> I like it myself quite a bit for managing all the computers at my office
| |
| 17:59 | <zetaE> what does the ssh part do in the whole thing?
| |
| 18:00 | <quinox> I can roll out a new Ubuntu version without having to tell the users how to upgrade their machines
| |
| 18:00 | I can buy an empty computer and boot it to get a fully working computer
| |
| 18:01 | by default LTSP verfies the user credentials over SSH, and then mounts the /home/<user> over SSHFS
| |
| 18:01 | that last part work out of the box but isn't too great for performance
| |
| 18:01 | <zetaE> that's what I thought about the extra performance penalty of sshfs
| |
| 18:02 | <quinox> you probably want to mount /home/ over something else like NFS
| |
| 18:02 | <zetaE> can.t be the same be done with nfs?
| |
| 18:02 | <quinox> yes, but not securely
| |
| 18:02 | SSHFS is perfectly secure, just not too great performance wise
| |
| 18:02 | NFS is great performance wise, just less secure
| |
| 18:04 | or use whatever you want: LTSP is normal Linux, you can do anything you like
| |
| 18:04 | <zetaE> lol
| |
| 18:06 | <quinox> I outfitted my machines with SSD drives and use RCFILE_xx to mount them on startup + apply some magic to make Docker + MySQL + Postgres run from these SSDs
| |
| 18:07 | <zetaE> quinox: you're already behind, now it's NVME
| |
| 18:13 | <quinox> it's SSD over E.2 right?
| |
| 18:14 | yeah, NVME is amazing
| |
| 18:15 | my shop calls them "NVMe M.2 SSD"
| |
| 18:17 | The three jumps in technology that made me excited : going from single-core to multi-core CPUs, going from spinning platter to SSD, and now going from SATA to NVMe
| |
| 18:22 | (my shop -> the shop I buy my hardware from)
| |
| 18:49 | vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:21:21:0:100e) | |
| 20:22 | lucascastro has joined IRC (lucascastro!~lucascast@192-140-51-187.static.oncabo.net.br) | |
| 20:27 | Vercas has left IRC (Vercas!~Vercas@gateway/tor-sasl/vercas, Quit: Ping timeout (120 seconds)) | |
| 20:29 | Vercas has joined IRC (Vercas!~Vercas@gateway/tor-sasl/vercas) | |
| 22:03 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |