IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 11 January 2021 (all times are UTC)
| 00:53 | RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Quit: Please remember your own message. It'll be read as soon as possible.) | |
| 00:58 | RaphGro has joined IRC (RaphGro!~raphgro@fedora/raphgro) | |
| 01:36 | RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Quit: Please remember your own message. It'll be read as soon as possible.) | |
| 02:09 | RaphGro has joined IRC (RaphGro!~raphgro@fedora/raphgro) | |
| 02:54 | RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Quit: Please remember your own message. It'll be read as soon as possible.) | |
| 03:23 | GodFather has left IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net, Ping timeout: 246 seconds) | |
| 06:26 | RaphGro has joined IRC (RaphGro!~raphgro@fedora/raphgro) | |
| 06:26 | RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Client Quit) | |
| 07:19 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 08:13 | woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de) | |
| 09:18 | Aison has joined IRC (Aison!~Asion0@2a02:168:200f:110:69c6:120a:877c:5a19) | |
| 12:09 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 240 seconds) | |
| 12:24 | nikoh77 has joined IRC (nikoh77!~nikoh77@151.69.165.97) | |
| 13:04 | nikoh77 has left IRC (nikoh77!~nikoh77@151.69.165.97, ) | |
| 13:13 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 13:30 | nikoh77 has joined IRC (nikoh77!~nikoh77@151.69.165.97) | |
| 14:22 | markit 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:24 | GodFather has joined IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net) | |
| 15:30 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 264 seconds) | |
| 15:34 | markit has left IRC (markit!~marco@mail.ammdomus.it, ) | |
| 15:52 | lucas_ has left IRC (lucas_!~lucascast@177-185-133-174.dynamic.isotelco.net.br, Remote host closed the connection) | |
| 15:56 | nikoh77 has left IRC (nikoh77!~nikoh77@151.69.165.97, Quit: Leaving) | |
| 15:57 | woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 16:06 | lucascastro has joined IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br) | |
| 16:06 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 16:31 | lucascastro has left IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br, Read error: Connection reset by peer) | |
| 16:47 | woernie 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:42 | lucascastro has joined IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br) | |
| 19:35 | lucas_ has joined IRC (lucas_!~lucascast@189.90.44.253.jupiter.com.br) | |
| 19:38 | lucascastro has left IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br, Ping timeout: 246 seconds) | |
| 19:41 | lucas_ has left IRC (lucas_!~lucascast@189.90.44.253.jupiter.com.br, Ping timeout: 260 seconds) | |
| 19:50 | lucascastro has joined IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br) | |
| 19:59 | RaphGro has joined IRC (RaphGro!~raphgro@fedora/raphgro) | |
| 20:02 | vagrantc 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:21 | lucascastro 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:22 | lucascastro has joined IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br) | |
| 20:22 | lucascastro has left IRC (lucascastro!~lucascast@177-185-133-174.dynamic.isotelco.net.br, Remote host closed the connection) | |
| 20:24 | lucascastro 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:15 | RaphGro 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:45 | GodFather 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:43 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 23:20 | woernie has left IRC (woernie!~werner@pd9e8bc11.dip0.t-ipconnect.de, Remote host closed the connection) | |