LTSP 5 is in minimal maintenance mode
The new LTSP is hosted at https://ltsp.github.io

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


Channel log from 21 March 2019   (all times are UTC)

00:00adrianorg has left IRC (adrianorg!~adrianorg@189.114.158.245, Ping timeout: 246 seconds)
06:03kjackal has joined IRC (kjackal!~quassel@2a02:587:3119:ef00:d972:2fda:fe23:da3e)
06:08statler has joined IRC (statler!~Georg@p5489790B.dip0.t-ipconnect.de)
06:23vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
06:28kjackal has left IRC (kjackal!~quassel@2a02:587:3119:ef00:d972:2fda:fe23:da3e, Ping timeout: 252 seconds)
06:31woernie has joined IRC (woernie!~werner@pD9E8B7B2.dip0.t-ipconnect.de)
06:59kjackal has joined IRC (kjackal!~quassel@2a02:587:3119:ef00:d972:2fda:fe23:da3e)
07:34ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:58kjackal has left IRC (kjackal!~quassel@2a02:587:3119:ef00:d972:2fda:fe23:da3e, Ping timeout: 258 seconds)
08:33kjackal has joined IRC (kjackal!~quassel@oy6r0e.static.otenet.gr)
08:58statler has left IRC (statler!~Georg@p5489790B.dip0.t-ipconnect.de, Remote host closed the connection)
09:14woernie has left IRC (woernie!~werner@pD9E8B7B2.dip0.t-ipconnect.de, Ping timeout: 272 seconds)
09:14woernie has joined IRC (woernie!~werner@pD9E8B7B2.dip0.t-ipconnect.de)
09:50statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
11:48Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:05kjackal has left IRC (kjackal!~quassel@oy6r0e.static.otenet.gr, Ping timeout: 272 seconds)
12:27kjackal has joined IRC (kjackal!~quassel@2a02:587:3119:ef00:d972:2fda:fe23:da3e)
14:41statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection)
16:31
<uumas>
Is it possible to disable some apps from some clients, but still have them on others (maybe in lts.conf)?
16:32vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:35
<||cw>
uumas: only via normal linux means. if you can find a script for it, you can add that to run in lts.conf, but probably you just want to edit the user menus, or create group based exec permissions or something
16:37
<uumas>
Ok, I guess I'll make a script that just moves some .desktop files to /usr/share/applications/ from some dir like /usr/share/disabled-apps. That would work right?
16:40
<mwalters>
ghttps://askubuntu.com/questions/8149/how-can-i-restrict-program-access-to-other-users
16:40
https://askubuntu.com/questions/8149/how-can-i-restrict-program-access-to-other-users
16:40
this is a blacklisting approach, but probably the best way to handle it
16:41
the idea is the restrict "anyone" access to none, then use the group exec permission to allow certain group to execute
16:41
<uumas>
Yeah, that's a good way. Thanks!
16:42
<mwalters>
for clarity, if you use fatclients/chroot, you need to modify the permissions in the chroot
16:42
for thinclients or chrootless, then just on the server
16:42
server root*
16:47
<vagrantc>
and you'll need to update the permissions every time you do a package upgrade...
16:48
<mwalters>
reply to the answer says that you shouldn't
16:48
I'm not certain either way
16:49
<vagrantc>
well, if a package installs a new file, i don't see how your old permissions would magically migrate, for example
16:50
unless it's using dpkg hooks
16:50
<mwalters>
I have no idea
16:52
<vagrantc>
the suggestion to use apparmor would be considerably less hacky
16:52
<||cw>
wtf nbd... "Error: Negotiation failed: Success"
16:53
<mwalters>
lololol
16:53
<vagrantc>
yeah, i've seen that before, can't remember when
16:53
<mwalters>
reminds me of my developer days dealing with vendor APIs
16:53
HTTP 200, body: { status: "failed" }
16:53
<||cw>
so what's the "right" way to tell a client which server to connect to?
16:53
I'm using nbdroot=10.212.0.85:10809
16:54
<vagrantc>
so it successfully tried to fail to negotiate
16:54
<mwalters>
or did it successfully fail to negotiate
16:54
<vagrantc>
well, since it was an error...
16:54
<||cw>
do I need more info on that append param?
16:55
<vagrantc>
i don't think you need to specify the port
16:55
<||cw>
maybe nbdroot=10.212.0.85:10809/opt/ltsp/images/i386.img ?
16:55
<vagrantc>
nbdroot=ip:/image/name/space/foo.img
16:55
<||cw>
it fails to connect at all if I don't specify the port, errors with soemthing about missing port
16:56
<vagrantc>
do you have multiple clients booting to different servers?
16:56
normally, you'd just pass next-server via dhcp
16:56
<||cw>
yes
16:56
<vagrantc>
and leave the ip address out
16:56
it's been a while since i messed with this, though
16:57
<||cw>
AD is my main dhcp server, I have one ltsp with proxydhcp, and that one doles clients out to other server. for my old 10.04 server just the ip:port works
16:57
<vagrantc>
yes, that's a very old server
16:57
the nbd protocol entirely changed since then
16:58
<||cw>
so I should be able to do ip/path/img ?
16:59
<vagrantc>
strictly speaking, it's not a path, it's actually a nbd configuration name
17:00
we just configured it to look like a path in ltsp so that you can use the same value for nfs
17:00
<||cw>
well, ip/path I get nbd_server[4379]: Negotiation failed: Success
17:00
<vagrantc>
do you have it configured in /etc/nbd*/conf.d/*.conf ?
17:00
<||cw>
so i should just put /opt/ltsp/i386 since that's the name in /etc/nbd-server/conf.d/ltsp_i386.conf ?
17:01
<vagrantc>
yes
17:01
<||cw>
also, update-kernels isn't honoring IPAPPEND
17:01
<vagrantc>
alternately, you should be able to set root-path in dhcp
17:02
update-kernels, or ltsp-update-kernels?
17:02
<||cw>
ltsp-update-kernels
17:02
<vagrantc>
ltsp-update-kernels just copies what was already generated
17:02
this is in a chroot?
17:02
<||cw>
no
17:03
<vagrantc>
sudo /usr/share/ltsp/update-kernels && sudo ltsp-update-kernels ... if i'mrememberingcorrectly
17:03
oh... i made a mess of that years ago.
17:03
<uumas>
I don't know if this helps in any way but this is how I have configured dhcp for multiple ltsp servers: https://pastebin.com/79anD2MU
17:03
<vagrantc>
there are so many ways this can go wrong
17:04
<||cw>
heh
17:04
the nore in the default file says to edit in the conf, so i do. it overwrites and still uses 3 when i want 2
17:04
nbdroot=10.212.0.85/opt/ltsp/i386 also says Error: Negotiation failed: Success
17:05
root=/dev/nbd0 should remain, right?
17:06
<vagrantc>
you still would need a colon
17:06
nbdroot=ip:name
17:06
ltsp-update-kernels is probably pulling it from the image
17:07
sudo /usr/share/ltsp/update-kernels && sudo ltsp-update-image --cleanup / && sudo ltsp-update-kernels
17:07
*maybe* that will work...
17:07
<||cw>
well that looks different...
17:08
<vagrantc>
alkisg and i worked out a bad compromise for this years ago, and it would have probably gone better to just use alkisg's suggestion in the first place rather than mixing the two methods
17:09
<||cw>
hm, I seem to have nbd now, but it's stopped at just "Negotiation:" then a crng and urandom dmesg type messages
17:09
<vagrantc>
really, ltsp just needs some time and energy and sustained maintenance :/
17:10
<||cw>
so say we all
17:10
<vagrantc>
it's been lacking a few years...
17:11
<||cw>
I was hoping to move some 16.04 to 18.04, is that worth it at this point? I don't actually need the newer software yet
17:13
<vagrantc>
isn't 16.04 out of support come ... next month?
17:14
oh, no, it's got some more years left in it
17:15
<mwalters>
it's 14.04 that goes out of support
17:16
<vagrantc>
yeah, i was comparing the wrong part of the version :)
17:22* alkisg waves
17:22
<alkisg>
||cw: in Greek schools, I tell them "I don't support 16.04 anymore, use either 12.04 or 18.04"
17:22
So 18.04 actually has had more testing
17:23
12.04 is for ancient clients that won't boot with 16.04 or 18.04...
17:24
<||cw>
maybe the issue I'm at now is that I'm running a client in qemu-kvm?
17:24
I guess I can grab a real system to test
17:24
<alkisg>
uumas: INIT_COMMAND_RM_APPS="cd /usr/share/applications; rm -f app1.desktop app2.desktop etc"
17:25
(06:53:56 PM) ||cw: I'm using nbdroot=10.212.0.85:10809 ==> nbdroot=1.2.3.4:/opt/ltsp/amd64
17:25
<||cw>
yeah, I got past nbd. still isn't completing a boot
17:25
<alkisg>
What's the message now?
17:25
The logs are too long to catch up :)
17:26
<||cw>
just stops at "Negotiation:" then a crng and urandom dmesg type messages
17:26
doens't say what's it's negotiating
17:26
<alkisg>
Do you get an initramfs prompt?
17:26
<||cw>
no, just freezes there
17:26
<alkisg>
Try: break=premount in pxelinux.cfg/default
17:26
You should get a shell, from where you could try:
17:26
!nbd-client
17:26
<ltsp>
nbd-client: To try mounting the NBD image from the client initramfs: nbd-client 192.168.67.1 -N /opt/ltsp/i386 /dev/nbd0
17:27
<alkisg>
And, you could also `cat /proc/cmdline` and paste it here, to verify that everything is in order
17:27
<||cw>
ffs it booted this time lol
17:27
<alkisg>
Hehe
17:27
This is 16.04?
17:28
<||cw>
18.04
17:28
now I have squashfs errors
17:28
<alkisg>
And that's a kvm client running on the ltsp server?
17:29
<||cw>
on another host
17:29
<alkisg>
Is the nbd server from 18.04 as well?
17:29
<||cw>
e1000 nic, qxl video
17:29
yes
17:30
<alkisg>
Are you using nbdroot= ?
17:30
<||cw>
nbd server is on the ltsp host, all 18.04. client is a kvm guest on my 18.04 workstation
17:30
<alkisg>
So no nbdroot there, right?
17:30
<||cw>
I'm using ndbroot, yes, because the PXE server is on another system
17:30
<alkisg>
OK
17:31
<||cw>
so whatever the default behaviour is, it connects to the wrong place
17:31
<alkisg>
Are you using both IPAPPEND 3 and nbdroot=?
17:31
<||cw>
IPAPPEND 2
17:31
<alkisg>
GReat
17:31
Do you have a shell on the client now?
17:31
E.g. cat /proc/cmdline | nc termbin.com 9999
17:31
...would help
17:31
<||cw>
no
17:32
rebooting it, lets see what i can get
17:32
<alkisg>
The nbd errors you say
17:32
are they from nbd9?
17:33
<uumas>
alkisg: so that goes in lts.conf?
17:33
<||cw>
gets ot "stared daily cleanup..." then block nbd0: connection timeout
17:34
<alkisg>
uumas: right
17:34
||cw: sounds like networking issues, but I can't imagine why
17:34
<||cw>
on server I have nbd_server[1172]: Starting to serve, but nothing after
17:34
virtio nic should work too, right?
17:35
<uumas>
I also get squashfs errors when trying to use a kvm client, but physical computers work, do didn't bother to debug it
17:35
<alkisg>
I don't get issues with virtualbox clients
17:35
...with or without virto
17:40
<||cw>
it works connecting to my 16.04 server
17:41
it's just getting to a random point and stops for a while, then nbd timeout.
17:42
tried rtl nic too, same thing
17:42
gotta get lunch and setup some real hardware :/
17:42
<alkisg>
You mean the 18.04 connecting to the 16.04 server?
17:42
Or the 16.04 image connecting to the 16.04 server?
17:45
<uumas>
I think they meant the kvm client connecting to 16.04
17:46
<alkisg>
Yes, but booting from which image?
17:46
The 16.04 one, or the 18.04, and then using nbdroot to connect to 16.04...
17:48
<uumas>
Ah, I'd assume 16.04. I had this exact same problem. Old 18.04 server with 16.04 chroot (Yes, I know. That's why I made a new one!) works, but new 18.04 one fails on kvm client
17:48vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 252 seconds)
17:49
<alkisg>
That sounds like an issue with kvm in 18.04 then...
17:49
(or the virtio drivers, etc etc)
17:50
<uumas>
Yeah, could be many things. Not worth debugging at least for me
17:53
<mwalters>
I have 4 servers on 18.04, and kvm client works on all of them
18:06
<||cw>
yes, kvm client to 16.04 server/image
18:08
mwalters: booting 32bit or 64?
18:08statler has joined IRC (statler!~Georg@p5489790B.dip0.t-ipconnect.de)
18:12
<||cw>
nope, doing the same thing on a laptop
18:13
gonna try rebiulding the image
18:24
lol now ipaddend is working but CMDLINE_NBD= didn't
18:42
nope. still errors. i5 laptop, atom/ndidia-ion nettop, kvm on desktop, kvm on same server the ltsp server is on, all get nbd timeouts
18:49
<mwalters>
||cw: all 64bit
18:51
<||cw>
i'm all 32, still trying to support some older thin clients. maybe that's my whole issue?
18:51
<mwalters>
not sure, sorry!
18:54
<alkisg>
||cw: 32bit works fine here
18:54
<||cw>
in vbox tho, right?
18:54
<alkisg>
Are you saying that nbd has issues even on read hardware?
18:54
In vbox and in hundreds of schools
18:54
with read servers/clients
18:55
I boot a couple of different clients per day in my office as well, for testing purposes, that schools send
18:55
No issues whatsoever
18:55
*real, not read
18:56
<||cw>
yes
18:56
<alkisg>
Test nbd-client without booting from it
18:56
!nbd-client
18:56
<ltsp>
nbd-client: To try mounting the NBD image from the client initramfs: nbd-client 192.168.67.1 -N /opt/ltsp/i386 /dev/nbd0
18:56
<alkisg>
Just run that command after the client boots, with any means
18:56
Eg. initramfs, local disk, live cd...
18:57
Then hdparm -t /dev/nbd0, or dd if=/dev/nbd0 of=/dev/null bs=1M status=progress, things like that
18:57
If it's not stable, there's something very wrong, maybe with your server nic/drivers/nbd-server/other software?
18:58
and make sure that both nbd-client and nbd-server are the latest versions offered by 18.04
18:59
<||cw>
it's on a commercial vm cluster with 30 other VMs, including 3 other ltsp servers, that all work fine
19:00
<alkisg>
Are you sure that the nic driver for 18.04 works fine with large load?
19:01
<||cw>
I have 18.04 VMs for a samba server for 80 clients and a email server for 50 clients, so yeah, seems fine
19:01
<alkisg>
So what do you think is the problem?
19:01
<||cw>
no idea
19:02
<alkisg>
Did you try that dd thing? Does it fail?
19:02
<||cw>
maybe I can get a tcpdump
19:03
Timing buffered disk reads: 226 MB in 3.01 seconds = 75.07 MB/sec
19:03
<alkisg>
Try to minimize the test case that fails, before you start tcpdump
19:04
<||cw>
1.5GB in 20 seconds
19:05
<alkisg>
So it doesn't fail?
19:05
<||cw>
lol now my PC's cache has it, (1.5 GB, 1.4 GiB) copied, 0.182834 s, 8.4 GB/s
19:05
<alkisg>
Are you using the greek schools ppa?
19:05
<||cw>
yes
19:05
<alkisg>
Chroot or chrootless?
19:06
<||cw>
less
19:06
<alkisg>
Hrm...
19:06
So dd works fine, i.e. nbd works fine, yet later on it fails?
19:06
I wonder if the network disconnects for some reason
19:07
E.g. without the greek schools ppa, network manager ifdown'ed the nic
19:07
...which then appeared as nbd issues, but it was no networking
19:08
When that happens, can you ping the client from the server?
19:11
<||cw>
that was an 64 client, let me try a x32
19:16woernie has left IRC (woernie!~werner@pD9E8B7B2.dip0.t-ipconnect.de, Quit: No Ping reply in 180 seconds.)
19:16
<||cw>
dd worked on 32bit. ping from server does stop at the point it freezes
19:17
so it does seem to be a network issue
19:17woernie has joined IRC (woernie!~werner@pD9E8B7B2.dip0.t-ipconnect.de)
19:18
<||cw>
same for the laptop
19:20
hm. I installed the server from the ubuntu-mate i386 iso that's linked from http://wiki.ltsp.org/wiki/Installation/Ubuntu
19:20
<alkisg>
||cw: did you install anything related to networking after the installation?
19:20
E.g. netplan, firewalls...
19:20
<||cw>
apt install vim aptitude bikeshed molly-guard pv iftop sysstat ethtool samba acl winbind libnss-winbind libpam-winbind ssmtp
19:21
config's samba for AD auth integrate to allow domain accounts to login
19:21
removed snapd
19:22
that's it.
19:22
I'm not opposed to a clean reinstall. I did manage to install when ubuntu was having keyserv issues so that was a struggle
19:23
<alkisg>
INIT_COMMAND_RM_IFDOWN="rm -f /sbin/ifdown"
19:23
Does that work around the issue?
19:23
(in lts.conf)
19:23
<||cw>
in lts.conf?
19:24
anywhere in [default] right?
19:25
<alkisg>
yup
19:25
<||cw>
no change
19:26
<alkisg>
Try this in pxelinux.cfg/default: ltsp.break=50-fstab
19:26
This should give you a shell when the client has booted
19:26
There, type: cat /etc/network/interfaces | nc termbin.com 9999
19:26
<||cw>
under ipappend?
19:27
or in the append line?
19:27
<alkisg>
there
19:27
In the append line
19:29
<||cw>
just lo
19:30
but it should be using network manager, right? or should I disable that?
19:30
<alkisg>
Sorry that was too soon
19:30
ltsp.break=50-swap
19:30
reboot, check again
19:31
<||cw>
ens3 is set got manual
19:32
that seems wrong?
19:32
<alkisg>
It's correct
19:32
<||cw>
shouldn't it either not be there or be dhcp?
19:32
<alkisg>
It prohibits network manager from breaking it
19:32
can you pastebin the results though?
19:33
E.g. I want to see if there are other nics or other things that could break it
19:33
<||cw>
no, this system doens't have internet permission
19:33
just lo and that one
19:33
<alkisg>
ip a
19:33
this just shows one nic?
19:33
<||cw>
and lo, yes
19:33
the laptop would have a wifi card too probably
19:34
<alkisg>
Eh, anyway go for a clean reinstall
19:34
Then try before you add more programs
19:34
If it works, and breaks after you install the additional software, it's something there that ifdowns the nic
19:34
<||cw>
yeah, that's my new plan. make it work clean
19:35
<alkisg>
Or if you ever get internet access, i could have a look with vnc
19:35
(try the reinstall first, to save time :))
19:35
<||cw>
heh, it never gets that far
20:14
well, that booted. now to see what made it fail.
20:49
got it all config'd back where I was 2 hours ago and it's all working fine. must have had something to do with the initial install issues I had
20:49woernie has left IRC (woernie!~werner@pD9E8B7B2.dip0.t-ipconnect.de, Remote host closed the connection)
20:49
<||cw>
I'm even able to login to a client as a domain user :)
20:57Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
21:03
<||cw>
is there no longer a xfreerdp screen.d?
21:04
do i need to copy it from /usr/share/ltsp/screen.d to /usr/lib/ltsp/screen.d ?
21:16
!sudo
21:16
<ltsp>
I do not know about 'sudo', but I do know about these similar topics: 'sudoers', 'fat-sudo'
21:16
<||cw>
!fat-sudo
21:16
<ltsp>
fat-sudo: to allow members of the sudo group to execute "sudo" in fat clients without a password prompt, put this in lts.conf: RCFILE_01="echo '%sudo ALL=NOPASSWD: ALL' >> /etc/sudoers"
21:21
<||cw>
I take that back, xinit is running, xfreerdp is not
21:23
oh gdi, it's defaulting the servername
21:35kjackal has left IRC (kjackal!~quassel@2a02:587:3119:ef00:d972:2fda:fe23:da3e, Ping timeout: 252 seconds)
22:02statler has left IRC (statler!~Georg@p5489790B.dip0.t-ipconnect.de, Remote host closed the connection)
23:03ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)