|00:39||markit has left IRC (email@example.com, )|
|01:48||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)|
|02:00||vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)|
|06:57||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)|
|07:42||ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)|
|08:22||kjackal has joined IRC (firstname.lastname@example.org)|
|11:34||kjackal has left IRC (email@example.com, Ping timeout: 250 seconds)|
|11:34||kjackal has joined IRC (firstname.lastname@example.org)|
|13:39||spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)|
aside from some (non-ltsp related) hiccups. All my 14.04 servers are gone, and I now have 4 18.04 ltsp servers. The LTSP part of all this went very smooth. Thanks for all your hardwork into this project everyone.
|14:45||GodFather has joined IRC (GodFather!~rcc@2600:1011:b123:50d6:95d3:6e04:4912:c01f)|
You're welcome :)
|15:55||mmarconm has joined IRC (mmarconm!~mmarconm@unaffiliated/mmarconm)|
|16:48||mmarconm has left IRC (mmarconm!~mmarconm@unaffiliated/mmarconm, Quit: Konversation terminated!)|
Can I adjust the fstab file in my chroot to mount extra stuff from the ltsp server?
e.g., I have a /public dir that has some scripts that "everyone" might use
I guess I could just move them to the chroot
/thinking out loud ;)
|17:31||GodFather has left IRC (GodFather!~rcc@2600:1011:b123:50d6:95d3:6e04:4912:c01f, Ping timeout: 252 seconds)|
|17:45||vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)|
mwalters: FSTAB_xxx="line" in lts.conf
Don't forget to also exclude /public in /etc/ltsp/ltsp-update-images.excludes
nice, thanks! I've also had a couple fat clients hard-freeze today (can't move mouse or anything)... Any common issues there?
e.g., "Oh, that's usually ____" ?
"Oh, that's usually __network or graphics drivers__"
First through was network issue with one of them... old buildings, questionable cabling... but then had an issue with a client in another building (same server, fiber backhaul)
Or out of ram, if they have little ram
yeah, that's what I thought... time to go down the rabbit hole
p sure both of the frozen clients have 4gb
4 GB is fine for casual use; but it can still cause OOM if you have firefox + thunderbird + libreoffice + gimp open...
So just run `top` when they're in the middle of their work
most clients are basically just chrome
...which is probably the equiv to all of those things ;)
Chrome with 30 tabs can do that too :)
maybe I can set up a script to grab vmstat output every so often if it becomes a consistent thing
|18:26||spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Ping timeout: 252 seconds)|
|18:26||spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)|
|18:31||spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Remote host closed the connection)|
mwalters: if you can, file a bug against ltsp, so that it sets LDM to be killed first on OOM. This will at ensure no hangs; just xorg crashes, which can at least notify the sysadmin about OOM issues.
ltsp-bug: To file a bug report for upstream LTSP, go to https://bugs.launchpad.net/ltsp
That'd be helpful, I'll do that!
|18:35||mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Quit: Leaving)|
In your local installation, you could run chrome with the highest oom score, so that it's killed first, and xorg / session survive
|18:38||spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)|
I suspected that's what was happening on our old thin client set up, but nothing ever made it to syslog
on the client or the server (we were using ltsp-localapps w/ chrome)
it really seemed to happen at random, though... sometimes you could go days, othertimes you couldn't even log into gapps with a single tab
To see things in server syslog, you'd need to set up remote syslogging in lts.conf
"The Ethernet Alliance’s new roadmap traces Ethernet’s path from 10 Mb/s through present-day speeds of 1 to 400 gigabit Ethernet (GbE), and looks ahead to future speeds achieving up to 1.6 terabits (TbE) and beyond."
1 tbps would make thin clients feasible again :P
|20:04||kjackal has left IRC (email@example.com, Ping timeout: 258 seconds)|
alksig: didn't the old thin client setup use NBD swap?
mwalters: all ltsp clients should use nbd swap by default for the last 10 years or so...
But at some point it defaulted to just 64mb, which was too low
Just checked the manual, looks like it's off for fat clients w/ more than 800MB
I increased it to 512, but I don't remember well
if boolean_is_true "$LTSP_FATCLIENT"; then NBD_SWAP_THRESHOLD=2100
else NBD_SWAP_THRESHOLD=800 fi
Fat clients with more than 2100 don't get swap
And thin clients with more than 80
Is there any server side config if I were to explicitly enable it?
(other than modifying lts.conf)
The size can be configured in /etc/ltsp/nbdswapd.conf
Otherwise, it's on by default, with 512 mb swaps
To force all clients to use swap, NBD_SWAP=True in lts.conf
specify SWAPDIR and SIZE (in megabytes?) in nbdswapd.conf?
(I decided to disable swap-over-network entirely and buy more RAM when clients crash)
Just SIZE, no reason to set SWAPDIR
That would be ideal, for sure ;)
but I feel like I'm playing whack-a-mole right now ;)
But if you're doing all this to avoid client crashes without investigating first... you're following a bad approach
Yeah, I get what you're saying there
also, since encrypted nbd swap is broken, there was at least a window of time where i had NBD swap disabled in Debian ...
What you're saying is that any client could potentially peer into swap used by another client?
anyone on the network who can spoof the ip address of a client
or anyone on the server able to read the swap files
They're owned by nbd though, right? So only root could read them on the server
or, at least, shoudl be
Actually, they're deleted upon creation, so nah, they're not even accessible by root, unless he does very fancy things
And the "fake ip" nbd-client wouldn't be able to set up a new nbd connection, as the file isn't there
It would need to fake the "previous client" as well; I don't know if that's possible; it depends on the nbd internal state
ah right, we finally managed to remove the file, so yeah ... it's a lot harder
for some years the files just sat there and re-used connections from old ip addresses
er, reused files from old ip addresses
Yeah I think I changed that 3-4 years ago
Server space was the initial problem; but the deletion had good side effects :)
|21:21||* alkisg => pumpkin|
|22:14||ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)|
thanks for thinking all that through for me ;)