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


Channel log from 11 January 2021   (all times are UTC)

00:53RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Quit: Please remember your own message. It'll be read as soon as possible.)
00:58RaphGro has joined IRC (RaphGro!~raphgro@fedora/raphgro)
01:36RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Quit: Please remember your own message. It'll be read as soon as possible.)
02:09RaphGro has joined IRC (RaphGro!~raphgro@fedora/raphgro)
02:54RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Quit: Please remember your own message. It'll be read as soon as possible.)
03:23GodFather has left IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net, Ping timeout: 246 seconds)
06:26RaphGro has joined IRC (RaphGro!~raphgro@fedora/raphgro)
06:26RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Client Quit)
07:19ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
08:13woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de)
09:18Aison has joined IRC (Aison!~Asion0@2a02:168:200f:110:69c6:120a:877c:5a19)
12:09mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 240 seconds)
12:24nikoh77 has joined IRC (nikoh77!~nikoh77@151.69.165.97)
13:04nikoh77 has left IRC (nikoh77!~nikoh77@151.69.165.97, )
13:13mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
13:30nikoh77 has joined IRC (nikoh77!~nikoh77@151.69.165.97)
14:22markit has joined IRC (markit!~marco@mail.ammdomus.it)
14:25
<markit>
hi alkisg, I don't remember the command I have to use to provide ssh/screen assistance for Epoptes client, I have "xterm -e socat tcp-listen:5500,keepalive=1 stdio,raw,echo=0" but if I use it in the termina (konsole), I've the prompt and not xterm open... am I doning somethign wrong or Kubuntu 20.10 has somethign different?
14:25
ehm, now works, sorry for the noise :(
14:26
maybe I tried it in a remote ssh connectino by mistake, shame on me lol
14:30
<alkisg>
markit: there's also /usr/share/epoptes-client/receive-terminals etc for console-based
14:32
And /usr/share/epoptes-client/share-terminal for the clients
15:24GodFather has joined IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net)
15:30mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 264 seconds)
15:34markit has left IRC (markit!~marco@mail.ammdomus.it, )
15:52lucas_ has left IRC (lucas_!~lucascast@177-185-133-174.dynamic.isotelco.net.br, Remote host closed the connection)
15:56nikoh77 has left IRC (nikoh77!~nikoh77@151.69.165.97, Quit: Leaving)
15:57woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Remote host closed the connection)
16:06lucascastro has joined IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br)
16:06mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
16:31lucascastro has left IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br, Read error: Connection reset by peer)
16:47woernie has joined IRC (woernie!~werner@pd9e8bc11.dip0.t-ipconnect.de)
18:06
<onixx>
alkisg: thanks: how do I check if the older older image is removed ?
18:07
<alkisg>
man ltsp image, see about --backup
18:07
<onixx>
alkisg: thanks
18:08
<alkisg>
ltsp image moves the older image to .old and deletes the previous .old
18:08
so if some clients are still using the old .old image, they'll hang
18:09
so if you want more than 2 images to exist without getting the .old one deleted, you'd need to version them with $date etc
18:09
this ability (for more than 2 images) isn't integrated to ltsp, but it could be easily scripted
18:10
<onixx>
alkisg: thanks and is there a way to find out if any client use the .old currently ?
18:10
lsof ?
18:11
<alkisg>
If it was actually used, then deletion wouldn't be a problem, as it would be kept around hidden until the clients stopped using it,
18:11
the problem is that the Debian initramfs, only supports nfsv3 with no locks,
18:12
and that absense of locks, makes the clients not keep persistent connections to the image; they only use it when they need it, not all the time
18:13
So... another easy way around the problem, would be for the ltsp clients to mount /srv/ltsp one more time after boot, and keep a persistent connection to the image, which would then solve all the deletion problems
18:14
I imagine that an FSTAB_SRV_LTSP="... mount /srv/ltsp ..." line, and a POST_SERVICE_LOCK="flock /srv/ltsp/x86_64.img", should do it, but I don't have time right now to give the exact syntax
18:42lucascastro has joined IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br)
19:35lucas_ has joined IRC (lucas_!~lucascast@189.90.44.253.jupiter.com.br)
19:38lucascastro has left IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br, Ping timeout: 246 seconds)
19:41lucas_ has left IRC (lucas_!~lucascast@189.90.44.253.jupiter.com.br, Ping timeout: 260 seconds)
19:50lucascastro has joined IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br)
19:59RaphGro has joined IRC (RaphGro!~raphgro@fedora/raphgro)
20:02vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
20:21
<vagrantc>
hrm. debhelper seems to be adding code for handling init scripts for epoptes, despite the lack of any init scripts
20:21lucascastro has left IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br, Remote host closed the connection)
20:22
<vagrantc>
my ltsp test environment is unsurprisingly a little over 6 months out of date ... e.g. the time of the last LTSP release :)
20:22lucascastro has joined IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br)
20:22lucascastro has left IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br, Remote host closed the connection)
20:24lucascastro has joined IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br)
20:48
<vagrantc>
hah. i don't know which display manager my clients are running :)
20:52
must have been experimenting with all of them ... think it was running sddm
21:13
alkisg: any special software needed for the network benchmarking to work?
21:14
alkisg: for epoptyes
21:14
s,y,,g
21:15RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Quit: Please remember your own message. It'll be read as soon as possible.)
21:15
<vagrantc>
otherwise, everything seems to be working nicely
21:15
<alkisg>
vagrantc: I think iperf2... is that removed?
21:16
<vagrantc>
alkisg: there's iperf and iperf3 available in bullseye
21:16
alkisg: neither installed on my system ...
21:17
correction ... iperf is installed
21:17
<alkisg>
And benchmarking doesn't work?
21:17
<vagrantc>
might be a quirk of the virtual networking
21:18
but yeah, epoptes benchmarking just runs for the default 10 seconds, then two seconds more, and then quits with no results
21:18
<alkisg>
firewall?
21:18
<vagrantc>
none on the server
21:18* vagrantc checks more thoroughly
21:18
<alkisg>
Or try the iperf commands manually...
21:19
<vagrantc>
should a daemon be running on the server and/or clients for iperf?
21:20
<alkisg>
No
21:20
iperf -s is the server, iperf -c the client
21:20
Two processes spawned by epoptes
21:20
<vagrantc>
hmm... # iperf2 doesn't work behind NAT and has several issues, for example:
21:21
this is a natted network ... but no NAT between the server and clients ... i think
21:22
both run from the server side?
21:23
alkisg: on server: sudo iperf -s , on client as root: iperf -c server ... worked, as far as i can see
21:26
alkisg: and as far as versioning the debian upload ... i was planning on including a the systemd-resolv patch ... do you want me to keep the version at 21.01-1 ... or ?
21:27
alkisg: in the bug you mentioned me doing a -2 ?
21:28
alkisg: i was thinking i would just upload it to debian as -1 and merge the changelog entry and tag it debian/21.01-1 (since the upstream tag is still v21.01)
21:29
alkisg: but do the debian "fork" in a debian/bullseye branch
21:31
alkisg: similar questions regarding epoptes version, although no need to add any patches; only changes in debian are needed so far
21:42
<alkisg>
Back, checking...
21:43
vagrantc: git tags have the upstream version number, which is 21.01, while debian/changelog has the debian number, which is 21.01-1
21:43
Are you saying to tag the debian version in git?
21:44* alkisg re-reads... :D
21:44
<alkisg>
Re: iperf, it would help if you ran epoptes and epoptes-client from the command line, and check the terminal output for errors
21:44
The client part also needs a -r, for reverse, iperf -c server -r
21:45
...that part sometimes chokes e.g. behind nat or firewalls
21:45GodFather has left IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net, Ping timeout: 240 seconds)
21:45
<alkisg>
What change in debian is needed in epoptes?
21:46
For the debian/bullseye branch, or debian/21.01-1 tag, whatever you like, no problem from me
21:47
<vagrantc>
alkisg: need to add an override_dh_installinit in debian/rules to make it a no-op to avoid adding code to update init scripts which aren't present for epoptes*
21:47
<alkisg>
There's also this PR that could be applied: https://github.com/ltsp/ltsp/pull/370
21:48
Both epoptes and ltsp ship services, but copy them from rules, right?
21:48
<vagrantc>
alkisg: well, you don't want anything in debian/patches on the master branch that don't apply cleanly to upstream
21:48
<alkisg>
Ah true I really don't like debian/patches at all :)
21:49
I would love it if they were just a list of git commits to cherry pick
21:49
<vagrantc>
alkisg: ok, so for ltsp, i'll make a debian/bullseye branch and then cherry-pick the changelog changes back upstream
21:49
<alkisg>
Great, thanks for that
21:49
Please have a look at that PR 370 too, it looked OK to me but you're more experienced with debian/rules
21:49
<vagrantc>
alkisg: it's just the one patch sitting there for the resolved stuff or whatever
21:50
yeah, that patch makes sense to me. not hugely important
21:50
<alkisg>
It might encourage him to send more :D
21:50
<vagrantc>
true, true :)
21:51
<alkisg>
vagrantc: I also don't mind if you want to rewrite the top of history some time. Some times it's really cleaner :)
21:52
E.g. noone would care if you git reset HEAD^ in epoptes, and you fix it properly and force push it with your name
21:52
<vagrantc>
i hate rewriting history ... i work on too many machines and seeing the history out of sync makes me cringe
21:53
so you'll never see me doing that intentionally :)
21:53
<alkisg>
:)
21:53
<vagrantc>
i'd rather deal with a messy history that's properly tracked
21:53
that said, i rebase locally all the time :)
21:54
<alkisg>
In personal projects, I use git commit --amend / force push a lot; it allows me to have clean history and not care too much about local HD disaster
21:54
But I only do that for the top of the tree
21:55
<vagrantc>
so, it's been a long time since i've debugged epoptes manually ... how exactly do i do this again? :)
21:55
<alkisg>
Run epoptes from a terminal on the server, then run epoptes-client on the client, both as root and as the user, in different terminals
21:56
That way you'll be seeing all 3 relevant outputs/errors
21:56
And just invoke the benchmark tool
21:56
(the new epoptes-client processes will replace the old ones from the services)
21:57
<vagrantc>
do i have to stop the ones from running first?
21:57
<alkisg>
No
21:57
Plain `epoptes-client`, no parameters, nothing
21:58
<vagrantc>
hah. i don't give my epoptes administrator root access normally ... heh.
21:58
<alkisg>
Are you using ltsp in that setup?
21:58
<vagrantc>
so three commands to run?
21:59
yes, using ltsp
21:59
<alkisg>
Are there 2 epoptes-client processes currently on the client?
21:59
One as root, one as user?
22:00
You can run `passwd` via epoptes>open root terminal, and set a root password on the client, and `su -` to it and run epoptes-client from there (to avoid giving admin access)
22:00
Three commands to run, yes. One on the server (epoptes), and two epoptes-client on the client
22:00
<vagrantc>
or just open a root shell on the client from epoptes ... or ... er...
22:01
<alkisg>
:)
22:01
But if the root epoptes-client process was missing, we already know the issue
22:01
<vagrantc>
i was able to send messages before the user logged in, if that matters
22:01
using epoptes
22:01
<alkisg>
Ah ok then
22:02
It's not that then
22:02
Which display manager are you using?
22:02
<vagrantc>
lightdm now (i did test sddm earlier)
22:03
<alkisg>
OK, then yeah the root epoptes-client should be running, it's not the issue we're looking for
22:03
<vagrantc>
and looks like i have a few others installed, just to make life interesting :)
22:03
i could give the epoptes admin user root, too
22:03
<alkisg>
There are some known and unsolvable issues with gdm, e.g. inability to broadcast over the login screen with gdm3
22:03
<vagrantc>
this is just a VM that i could delete if i wanted
22:04
<alkisg>
It's 12:00 here but I'll wait for a bit to see if I can help with this
22:04
<vagrantc>
my guess is it's the weird networking setup ... there *shouldn't* be any firewalling between the server and clients ... but it is virt-manager's NAT setup
22:05
<alkisg>
iperf -r doesn't work over nat
22:05
So OK no need to look into it more :)
22:05
<vagrantc>
well, there should be no NAT between the clients and the server ... they're both on the same NATed network
22:05
<alkisg>
-r = reverse = server tries to contact client 5000 port directly
22:05
Ah
22:06
OK, that should work
22:06
<vagrantc>
but *maybe* there's some trickery there
22:06
<alkisg>
I think the commands are: iperf -s -xS, and iperf -c server -r
22:06
If these work, then epoptes should work too
22:07
<vagrantc>
alkisg: how does epoptes call iperf? does it assume the user has root or sudo or something?
22:08
no, epoptes itself is running as root
22:08
ah, i don't need to run epoptes from the GUI ... i can run it from my user...
22:08
oh, nope.
22:09
<alkisg>
iperf doesn't need root, it uses port > 1024
22:09
epoptes on the server runs iperf as the user. Then it tells the root epoptes-clients to run iperf too
22:12
So, as epoptes-user on the server, run: iperf -s -xS -yC
22:12
And as root on the client, run: iperf -c server -r
22:12
If these work, then epoptes should work too...
22:17
<vagrantc>
ok, they both produce some output
22:17
$ iperf -s -xS -yC
22:17
19691231160000,192.168.122.65,42114,192.168.122.59,5001,4,0.0-10.0,8412332092,6727555431
22:18
<alkisg>
20210112001812,127.0.0.1,5001,127.0.0.1,58856,4,0.0-10.0,46369472536,37027632323
22:18
20210112001822,127.0.0.1,58860,127.0.0.1,5001,4,0.0-10.0,49117659136,39294033003
22:18
One for send, one for receive
22:19
<vagrantc>
ah, only one line on the part run as the client
22:20
the root-part responds with:
22:20
[ 5] local 192.168.122.65 port 42114 connected with 192.168.122.59 port 5001
22:20
[ ID] Interval Transfer Bandwidth
22:20
[ 5] 0.0000-10.0001 sec 7.83 GBytes 6.73 Gbits/sec
22:20
<alkisg>
Hmm actually I get 3 lines on the server, not two (for one client run)
22:20* alkisg tests properly without using "localhost"...
22:20
<vagrantc>
wow, i feel like all those people coming into #ltsp and getting confused by X11 display terminology now :)
22:21
i wonder if i ever tested this feature before
22:21
i thought i did
22:21
<alkisg>
OK, so the server is supposed to show 2 lines:
22:21
20210112002126,10.161.254.11,5001,10.161.254.10,36420,4,0.0-10.0,1178992664,940124062
22:21
20210112002136,10.161.254.11,57732,10.161.254.10,5001,4,0.0-10.0,958791680,766980422
22:22
While the client is supposed to show many lines, but essentially these 2:
22:22
[ 5] 0.0-10.0 sec 1.10 GBytes 942 Mbits/sec
22:22
[ 4] 0.0-10.0 sec 914 MBytes 765 Mbits/sec
22:22
One for send, one for receive
22:22
If it doesn't, it's supposed to show why, e.g. "bind: port already in use"
22:25
<vagrantc>
uploading LTSP in the meantime...
22:25
<alkisg>
Thanks! :)
22:26
<vagrantc>
honestly, also tempted to just upload epoptes, and debug the iperf thing later
22:29
testing the mksquashfs with zstd compression ... i think it's slower to compress, but allegedly faster to decompress
22:30
<alkisg>
Sounds good to me, I didn't have any problems with it in years and the related code hasn't changed
22:30
It's half past pampkin time though.... gn vagrantc!
22:30
<vagrantc>
alkisg: thanks and rest up!
22:43ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
23:20woernie has left IRC (woernie!~werner@pd9e8bc11.dip0.t-ipconnect.de, Remote host closed the connection)