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


Channel log from 4 November 2019   (all times are UTC)

00:07vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 240 seconds)
00:09vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
00:37vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 268 seconds)
00:39vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
01:07vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 265 seconds)
01:09vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
01:38vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 268 seconds)
01:39vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
02:07vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 240 seconds)
02:09vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
02:37vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 240 seconds)
02:39vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
03:08vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 240 seconds)
03:10vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
03:37vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 240 seconds)
03:39vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
04:08vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 240 seconds)
04:10vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
04:38vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 268 seconds)
04:40vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
05:01vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 276 seconds)
05:08vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 268 seconds)
05:10vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
05:39vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 264 seconds)
05:40vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
06:09vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 268 seconds)
06:11vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
06:38vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 265 seconds)
06:40vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
07:09vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 265 seconds)
07:10vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
07:39vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 246 seconds)
07:40
<alkisg>
vsuojanen: ping! too much spam! :)
07:41vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
07:43
<alkisg>
(09:40:40 AM) alkisg: vsuojanen: ping! too much spam! :)
08:09vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 268 seconds)
08:10vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
08:30woernie has joined IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de)
08:39vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 265 seconds)
08:41vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
08:52Da-Geek has joined IRC (Da-Geek!~Da-Geek@5.154.189.38)
08:53ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
09:09vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 276 seconds)
09:10vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
09:24statler_ has joined IRC (statler_!~Georg@gwrz.lohn24.de)
09:31statler has left IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de, Remote host closed the connection)
09:31
<vsuojanen>
alkisg: ok
09:32vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Quit: leaving)
10:04
<woernie>
poweroff
10:06woernie_ has joined IRC (woernie_!~werner@p50867A20.dip0.t-ipconnect.de)
10:08woernie has left IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de, Remote host closed the connection)
10:09woernie has joined IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de)
10:17woernie has left IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de, Remote host closed the connection)
10:18woernie has joined IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de)
10:20
<woernie>
my clients don't shutdown/poweroff they just display the login-screen. How can I poweroff my clients proberly?
10:21
<alkisg>
woernie: try this, as root: poweroff -f
10:21
If this works, then it's caused by systemd or something; if it doesn't work, it's probably due to acpi
10:33
<woernie>
poweroff -f works
10:35
<alkisg>
woernie: output of sudo ltsp-info?
10:35
sudo ltsp-info | nc termbin.com 9999
10:38kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:4d22:8ef4:685e:7764)
10:42
<woernie>
https.//dpaste.de/Ayex
10:42
https://dpaste.de/Ayex
10:43
how I can call my termbin request?
10:46
<alkisg>
It should show a URL there
10:47
OK so I think you need to run apt update, apt full-upgrade etc
10:47
Since you're still in 18.04.2
11:16dsjii has joined IRC (dsjii!~david@047-134-241-234.res.spectrum.com)
11:46
<woernie>
@alksig thanks, clients shutting down now
11:49GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net)
12:06meo has joined IRC (meo!~systemdju@unaffiliated/mikeseth)
12:06
<meo>
do I understand it correctly that snapd support was fixed in a recent ltsp19 update?
12:07douglas_br has joined IRC (douglas_br!bb5f6554@187.95.101.84)
12:10
<douglas_br>
Hello all! Please! Is there mode to put systemctl restart ltsp as boot command or autostart file?
12:29
<alkisg>
meo: yes
12:29
douglas_br: why? it restarts at boot anyway
12:29
Are you talking about NAT?
12:35
<douglas_br>
yes about NAT
12:35
<alkisg>
Set just NAT=1 in ltsp.conf
12:36
<douglas_br>
this fix for 2 Nics yeah?
12:36
<alkisg>
Yes
12:37
<douglas_br>
do not need some Teacher do the command after set nat?
12:39
<meo>
alkisg: yeah found the commit
12:39
I'll go upgrade
12:40
<alkisg>
douglas_br: no commands are needed, if you set NAT=1 in ltsp.conf, every time the server is rebooted, it will forward the internet for the clients
12:42
<douglas_br>
right alkisg thank you so much
12:42
<alkisg>
np
12:46
<douglas_br>
next wednesday we will do first lab ltsp at one school here. :] (y)
12:49
<alkisg>
:)
13:12
<douglas_br>
enable NAT=1 in ltsp.conf not fix client connection, still need do the command systemctl restart ltsp
13:27Da-Geek has left IRC (Da-Geek!~Da-Geek@5.154.189.38, Remote host closed the connection)
13:28Da-Geek has joined IRC (Da-Geek!~Da-Geek@5.154.189.38)
13:35eu^mudmzpr01-ext has joined IRC (eu^mudmzpr01-ext!86bfdc4b@134.191.220.75)
13:49
<douglas_br>
alkisg enable NAT=1 in ltsp.conf not fix client connection, still need do the command systemctl restart ltsp
14:16
<alkisg>
douglas_br: can you vnc to me?
14:16
!vnc-edide
14:16
<ltsp>
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
14:17
<alkisg>
douglas_br: did you put NAT=1 under [server] ?
14:20
<douglas_br>
can you vnc to me?
14:20
yes
14:25
<alkisg>
douglas_br: ah you just haven't updated
14:26
<douglas_br>
the system?
14:26
<alkisg>
Yes,apt update to give you the new ltsp
14:26
OK try restarting the server now
14:27
journalctl | grep masque
14:27
This will tell you if internet has been enabled
14:27
If it says 11:30 there..
14:27
after reboot
14:29spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Remote host closed the connection)
14:30spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)
14:33
<douglas_br>
yes it tell that has been enabled
14:34
<alkisg>
douglas_br: ok then that was it, you just haven't updated
14:39
<douglas_br>
right alkis, sorry but, the client show user and no logon automatic, need still other command to come back logon automatic
14:40
<alkisg>
douglas_br: vnc to me again, but wait 4 minutes I need to finish something
14:50
douglas_br: so autologin works fine *except* for the first time?
14:51
I restarted lightdm and it worked...
14:51
logout/login => it worked again
14:52
<douglas_br>
so autologin works fine *except* for the first time?
14:52
before update works
14:52
<alkisg>
OK let me see...
14:52
I sent an update that put timeout=1, so that relogin works too
14:53
Maybe it's causing you issues
14:54
<douglas_br>
the client up but show user, you should seeing yeah
14:56
<alkisg>
It sounds like a lightdm bug, maybe related to lightdm-gtk-greeter
14:59
douglas_br: I put it back like it was before the update, because lightdm-gtk-greeter seems broken
14:59
so for you, AUTOLOGIN works, but RELOGIN doesn't
14:59
It can only *either* login the first time, or *all the other times* :/
15:00
You need to file a bug in lightdm-gtk-greeter for this to get fixed
15:01
See that line there, in /etc/lightdm/lightdm.conf: autologin-user-timeout=0
15:01
<douglas_br>
right
15:01
<alkisg>
If you put that =1, then it's supposed to login after 1 second
15:01
But in your case, it works only after the first time, which is a bug
15:01
This isn't related to ltsp, it's a bug in lightdm
15:02
I reported a similar issue in https://github.com/canonical/lightdm/issues/97
15:02
But yours is a bit different
15:03
<douglas_br>
right
15:06
<alkisg>
Haha for you it works with timeout=5
15:06
Let's see, maybe we'll put it =2
15:12
douglas_br: go there: https://github.com/ltsp/ltsp/issues/58 and comment this: "I'm using Voyager, which is Ubuntu with XFCE and lightdm-gtk-greeter, and for me autologin-user-timeout=1 doesn't work and I need to set RELOGIN_TIMEOUT=2 in ltsp.conf to make it work"
15:21GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 268 seconds)
15:27woernie has left IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de, Remote host closed the connection)
15:47eu^37-247-30-164 has joined IRC (eu^37-247-30-164!25f71ea4@37-247-30-164.customers.ownit.se)
15:47
<eu^37-247-30-164>
hi
15:48
I have issues with this: https://github.com/ltsp/ltsp/issues/62
15:48Da-Geek has left IRC (Da-Geek!~Da-Geek@5.154.189.38, Remote host closed the connection)
15:48Da-Geek has joined IRC (Da-Geek!~Da-Geek@5.154.189.38)
15:49
<eu^37-247-30-164>
I just wonder if it's a bug or if 16.04 isn't supported? The docs say it is...
15:49
<meo>
err is that 32bit
15:50
<eu^37-247-30-164>
yes, it won't work?
15:50
<meo>
stock amd64 ubuntu doesnt have 32 bit libs and kernel
15:50
<eu^37-247-30-164>
It's on Lubuntu
15:51
Trying to get a HP t5745 up to date
15:51
https://support.hp.com/us-en/document/c01926343
15:51
<meo>
lubuntu 32 or 64? you probably wont be able to generate 32 bit images on a 64 bit version w/o compatibility packages and extra kernels
15:52
<eu^37-247-30-164>
lubuntu 32, I don't know where you get x64 from, everything is i386
15:53
Distributor ID: UbuntuDescription: Ubuntu 16.04.6 LTSRelease: 16.04Codename: xenial
15:54
So the new LTSP 2019 won't work on i386?
15:56
Please enlighten me
16:01
<||cw>
you're using these instructions? https://ltsp.github.io/docs/installation/
16:01
<eu^37-247-30-164>
||cw yes
16:02
I tested on UBuntu 18.04 a few days ago and there where no issues, can't recall if that was on a x64 OS though
16:02
<||cw>
error implies a kernel issue, what kernel packages are installed?
16:03
<eu^37-247-30-164>
it's a clean lubuntu install, so I guess the kernels that comes with it
16:04
4.10 if that makes any sense?
16:04
<alkisg>
eu^37-247-30-164: 16.04 is supported, let me read
16:05
<eu^37-247-30-164>
alkisg thanks!
16:05
I'm reinstalling the OS as we speak
16:05
<alkisg>
eu^37-247-30-164: read this: https://github.com/ltsp/ltsp/issues/43
16:05
eu^37-247-30-164: ah then just *don't* make a separate boot partition
16:06
16.04 is supported, 32bit is supported, separate boot partition has this #43 issue,
16:06
which can be worked-around with a few commands, and I'll solve it properly later on
16:06
<eu^37-247-30-164>
alkisg thanks alot! I will try this
16:06
<alkisg>
np
16:06
<eu^37-247-30-164>
you may have saved my day!
16:12
<alkisg>
eu^37-247-30-164: btw, if you're doing a clean reinstall, why aren't you using 18.04, which is the last one to support 32bit anyway?
16:12
<eu^37-247-30-164>
I tested that and the T5745 wouldn't boot
16:13
it only boots with 4.10 kernels it seems, which is strange
16:13
<alkisg>
Weird, which one did you try, 18.04.1 or 18.04.3?
16:13
.1 is kernel 4.15, while .3 is kernel 5.0
16:14
<eu^37-247-30-164>
hmm, can't recall, but it wouldn't boot with 4.15 either
16:14
on 16.04
16:14
been at this for a week now
16:14
<douglas_br>
alkisg go there: https://github.com/ltsp/ltsp/issues/58 and comment this: "I'm using Voyager, which is Ubuntu with XFCE and lightdm-gtk-greeter, and for me autologin-user-timeout=1 doesn't work and I need to set RELOGIN_TIMEOUT=2 in ltsp.conf to make it work"
16:14
do it
16:14
<alkisg>
douglas_br: thanks, I replied already
16:15
<douglas_br>
thanks your attention
16:15
<alkisg>
eu^37-247-30-164: what are the symptoms, e.g. black screen or hang?
16:16
<eu^37-247-30-164>
it loads the kernel, then the screen blinks for 1 second and then it hangs
16:16
on kernel 4.15 that it
16:16
on 4.10 it continues
16:16
I tried the debug mode and it just says that it's loading, then nothing more
16:17
<alkisg>
You could ask in #ubuntu-kernel some time if you have time :)
16:17
But anyway, sure, ltsp will work there
16:18
<eu^37-247-30-164>
I've tried everything it seems. Tried the old ltsp as well, and there I got some other issues
16:18
It booted up fine, but hanged at mounting the root file system
16:18
https://askubuntu.com/questions/955687/mate-16-04-3-lts-xenial-client-boot-issue-boots-on-busy-box
16:18
this issue
16:19
but doing as posted didn't help
16:19
wow! your workaround worked!
16:19
<alkisg>
!netplan
16:19
<ltsp>
netplan: To work around https://bugs.launchpad.net/netplan/+bug/1763608/comments/47, either update to a new LTSP version, or put this in lts.conf: INIT_COMMAND_RM_NETPLAN="rm -rf /lib/systemd/system-generators/netplan /run/netplan"
16:19
<alkisg>
This is the usual booting problem in 16.04 ^
16:19
<eu^37-247-30-164>
aah
16:20
thanks for that as well
16:20
<alkisg>
But ltsp5 isn't really maintained anymore, so go for ltsp19
16:20
<eu^37-247-30-164>
will try to boot soon
16:20
*crossing fingers*
16:21
<alkisg>
Hmm I wonder if I can get notifications from askubuntu whenever someone asks about ltsp there...
16:22
<eu^37-247-30-164>
alkisg I'm booting via next-server in pfsense, what's the proper values to put there?
16:23
right now I have ltsp/ltsp.ipxe
16:23
it works sometimes and sometimes now
16:23
not*
16:23
also dnsmasq makes DNS unreachable so to get ipxe I need to install dnsmasq afterwards
16:25
<alkisg>
Disable all boot filenames and root-path in pfsense, and use proxydhcp
16:25
pfsense=dhcp server, ltsp=proxydhcp server
16:25
pfsense doesn't support "IFs" in the dhcp configuration, which is needed for ipxe
16:26
Coffee time, be back in a couple of hours :)
16:40Da-Geek has left IRC (Da-Geek!~Da-Geek@5.154.189.38, Remote host closed the connection)
16:41Da-Geek has joined IRC (Da-Geek!~Da-Geek@5.154.189.38)
16:45
<eu^37-247-30-164>
alkisg thanks alot! it's finally booting as it should!
16:46
I should have come here in the first place
16:56woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de)
16:57Da-Geek has left IRC (Da-Geek!~Da-Geek@5.154.189.38, Quit: Leaving)
17:58
<alkisg>
eu^37-247-30-164: great :) Or, use ltsp community issues on github
18:01
<eu^37-247-30-164>
btw, confirmed that kernel 4.15 doesn't work on t5745
18:01
<alkisg>
!community-issues
18:01
<ltsp>
community-issues: In https://github.com/ltsp/community/issues you may ask (or answer) LTSP19+ related questions. Use that instead of mailing lists/forums/stackexchange/launchpad questions; LTSP developers also participate in community issues
18:01
<alkisg>
eu^37-247-30-164: ask in #ubuntu-kernel about the kernel
18:01
They may give you command line options that might workaround the issue
18:02
<eu^37-247-30-164>
nvm, I'm happy as long as it's something newer than kernel 2.2 :D
18:02
<alkisg>
:D
18:02
<eu^37-247-30-164>
which was the case before
18:03
now we can run Windows Server 2019 through remmina, that was impossible before this
18:03
only thing I'm worried about is the network
18:03
we will connect around 100 users
18:03
Switch is Gigabit, but yeah, I don't know
18:05
<uumas>
100 users to a single Windows server?
18:07
<eu^37-247-30-164>
no, serveral different TS
18:09
<uumas>
Gigabit should be enough then, but you'll need to verify that in your environment.
18:09
<eu^37-247-30-164>
yeah, we'll go live with this as soon as I've tested everything
18:09
btw, the LTSP enviroment is READONLY right?
18:09
<alkisg>
eu^37-247-30-164: did you end up using ltsp19 or ltsp5?
18:10
<eu^37-247-30-164>
ltsp19 (y)
18:10
<alkisg>
The server image is readonly, but with a temporary overlay on the client that makes it writeble in ram only, yet the client /home is mapped from the server via sshfs so it's normally writable
18:11
<eu^37-247-30-164>
hmm
18:11
so it would be possible to make changes to their user?
18:11
we intend to use one singel user for everyone
18:11
sinlge*
18:11
<alkisg>
If you only care about remote desktop, you might want to check this one: https://github.com/ltsp/community/issues/47#issuecomment-549017534
18:12
There, I describe how to make a single user for all terminals, with customized settings etc
18:12
<eu^37-247-30-164>
perfect!
18:12
<alkisg>
Although I only give the basic facts, and I invite the users to write a wiki page with them :D
18:13vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
18:14
<alkisg>
vagrantc: I was wondering, maybe it would be better to just create a binary package in our ppa and let apt take care of security?
18:14statler_ has left IRC (statler_!~Georg@gwrz.lohn24.de, Remote host closed the connection)
18:15
<alkisg>
It would be a "temporary" package, until we manage to get the files shipped in other packages
18:16
<vagrantc>
alkisg: what package are you referring to?
18:16
<alkisg>
ltsp-binaries, that would have ipxe etc
18:16
Instead of manually using gpg to verify downloads
18:17
<vagrantc>
then it would require a third-party repository, but sure
18:17
<alkisg>
It would go e.g. to /usr/share/ltsp/binaries/* and we'd just copy them from `ltsp ipxe`
18:17
<vagrantc>
certainly worth using to proof-of-concept it
18:18
well...
18:19
we could use apt and specify the keyring(s) and sources.list from the commandline ... and either install the packages or download them and extract the binaries from them
18:19
hmmmm.
18:20
<alkisg>
A normal repository would allow us to send updates too
18:20
<vagrantc>
right
18:21
still seems a bit messy to propegate to debian testing/stable ... but i guess technically no worse than implementing a signed-checksum verification system from scratch (and arguably better)
18:22
of course, the best thing would be to get the packages fixed in the distros that support it...
18:26
<alkisg>
The down side is that it's not cross-distro anymore, but I guess RHEL can also provide such a temporary package
18:27
<vagrantc>
yeah
18:27
not 100% sure how widespread gpgv is either...
18:32
<alkisg>
Can binary packages go to debian contrib/non-free/whatever? Or would `ltsp ipxe` add the ppa in the user sources? :/
18:32
*I mean, packages with binary contents...
18:34
<vagrantc>
if it's possible to build from source, it should be built from source and go in main
18:35
<alkisg>
The source is already in main, but it doesn't build the targets we want ;)
18:35
<vagrantc>
sounds like we need some bugs filed in the debian bug tracker against the ipxe and possible other packages?
18:35
i don't know the exact issues of what's missing from the debian packages, though i'd be happy to be in a conversation about it
18:36
<alkisg>
ipxe is the show-stopper
18:36
We don't mind very much about memtest etc
18:36
<vagrantc>
memtest86+ is the other?
18:36
right
18:36
<alkisg>
yes; I also had the idea to put sshfs online for people that want to netboot live cds, but that's not in the code, they can download it manually
18:37
<vagrantc>
the code could even "apt update && apt install sshfs"
18:37
using more memory and all, but ...
18:38
<alkisg>
Sometimes it needs "universe" in the sources etc, or even archives.ubuntu.com, it's more complicated
18:39
I do have code to check for it in /etc/ltsp/sshfs-$(uname -m), so that's where people are supposed to put it
18:39
(it goes to ltsp.img initrd then)
18:39
<vagrantc>
ah, true
18:40
all the dependencies tend to be available?
18:40
<alkisg>
Yes. I even managed to do just `debootstrap; chroot install linux-generic initramfs-tools`, and netboot the result with ltsp, without *any* more packages than that
18:41
<vagrantc>
wow
18:42
surprised that fuse is included by default now
18:46
alkisg: so, the idea of "ltsp ipxe" adding a sources.list entry and a keyring entry out-of-the-box would be surprising to me as a sysadmin
18:47
<alkisg>
I was using nfs home for the plain deboostrap
18:47
<vagrantc>
alkisg: slightly mitigated if the keyring wasn't globally installed, but only for that repository
18:48
<alkisg>
Yeah I don't like it either; for the people installing from the ppa it's not a problem as they already have it in their sources, but I'm not sure how would people installing from experimental would get it
18:48
<vagrantc>
i think there's something like deb [signed-by=/path/to/keyring] http://...
18:48
but that still allows arbitrary packages installed with root privledges
18:49
e.g. anything in that repository could take over a package from the Debian repositories
18:49
<alkisg>
Sure, but it would need to be signed by us...
18:49
<vagrantc>
of course
18:49
<alkisg>
Not just a man in the middle attack etc
18:50
<vagrantc>
it's still giving global trust to that keyring
18:50
whereas if the sources.list entry wasn't in the default path, then it would only come into play when they're running "ltsp ipxe" and not typical security updates
18:50
<alkisg>
Maybe we could add a section in the installation page, "even if you're in experimental, add that ppa... temporarily... etc"
18:51
<uumas>
signed by us != signed by a trusted party for many people...
18:51
<vagrantc>
uumas: right
18:51
and if it's in the PPA, it's basically under the control of launchpad, no?
18:52
alkisg: do you have control of the secret keys used to sign the launchpad PPAs?
18:53
<alkisg>
No
18:53
<vagrantc>
right, so essentially, it's putting trust in launchpad
18:54
<alkisg>
We can host the repository in github if it makes any difference, but personally I'm ok with launchpad
18:54
<vagrantc>
well, if the signing keys are also hosted on github, then it wouldn't make any difference, other than if you trust github more than launchpad
18:55
<alkisg>
No, I would have them then
18:55
It would just be a web server not a signing server
18:57
<vagrantc>
so, going with the "just use apt" idea ... i see basically two options ... both include the same signed repository ...
18:58
in case A, you just install the sources.list entry in /etc/apt/sources.list.d/ltsp-extra.list with a signed-by=/path/to/keyring
18:58
and then you just use apt to install the desired packages
18:59
in case B, "ltsp ipxe" calls "apt -o=/path/to/config" which adds /etc/ltsp/sources.list.d/ltsp-extra.list (which also has the same signed-by line) when it needs to install the extra binaries
19:00
and of course, case C, get ipxe in Debian with a package supporting our needs
19:00
<uumas>
Doesn't it kinda lose the point of having ltsp in the debian repos if you still need a third party repo for ipxe?
19:01
<vagrantc>
uumas: that's definitely a downside
19:01
uumas: hence the preference for case C
19:02
<uumas>
yes
19:02
<vagrantc>
in the end, i'm hoping we can get there, but sometimes you need incremental progress
19:42R4F4EL has joined IRC (R4F4EL!b1149819@177.20.152.25)
19:42R4F4EL has left IRC (R4F4EL!b1149819@177.20.152.25)
19:43R4F4EL has joined IRC (R4F4EL!b1149819@177.20.152.25)
19:46GodFather has joined IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com)
19:50douglas_br has left IRC (douglas_br!bb5f6554@187.95.101.84, Remote host closed the connection)
19:57kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:4d22:8ef4:685e:7764, Remote host closed the connection)
20:07kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:4854:7acc:13a8:95cb)
20:17
<R4F4EL>
Hello everyone, could anyone tell me why the ltsp-client-core_5.5.7-1_i386.deb package no longer includes the / usr / bin / getltscfg-cluster script? (https://launchpadlibrarian.net/250043945/buildlog_ubuntu-xenial-i386.ltsp_5.5.7-1_BUILDING.txt.gz)
20:17
This script has been added until the ltsp-client-core_5.5.1-1ubuntu2_i386.deb version of the ltsp-client-core package (https://launchpadlibrarian.net/172795287/buildlog_ubuntu-trusty-i386.ltsp_5.5.1-1ubuntu2_UPLOADING.txt. gz)
20:22ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
20:22
<vagrantc>
R4F4EL: that's so many years ago ... this is the first i think anyone's mentioned it missing
20:23
ltsp-cluster was abandoned upstream quite some years ago (e.g. it was never actually part of ltsp, per se)
20:24
even oldoldstable in Debian doesn't have it...
20:29
but it appears to be gone in ltsp 5.5.4, at least.
20:45
<R4F4EL>
vagrantc: thanks for the reply. I have been using LTSP-Cluster since 2010 to help set up about 200 thinclients (hp t5545). Guidance is to stop using LTSP-Cluster?
20:50statler has joined IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de)
21:00
<alkisg>
R4F4EL: how many servers, and is this just about linux or do you use remote windows desktop too?
21:09
With just 512 MB RAM on the clients, I guess the best would be to use xfreerdp with a small script for load balancing
21:10
cephfs on the servers would also help for shared home
21:10
<R4F4EL>
I have 1 boot server, 1 control center server, 4 application servers, all virtualized in OpenVZ on a Dell R710 80GB RAM hardware node. In addition, I have a Microsoft Remote Desktop Services farm with about 20 physical machines each with a dedicated graphics card (nvidia Quadro 600).
21:10
<alkisg>
Why 4 application servers instead of 1? Different applications?
21:11statler has left IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de, Remote host closed the connection)
21:11
<alkisg>
Since it's on the same hardware, it's not really balancing the load...
21:12
<R4F4EL>
I can handle 6 computer labs with this solution, totaling about 200 thinclients (hp t5545, t610 and t5740).
21:12
<alkisg>
Sure, but why separate the same hardware into 4 same vms...
21:12
I'd use one installation only instead of 6 there
21:13woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Read error: Connection reset by peer)
21:13
<alkisg>
It would also cache things and use RAM and CPUs a lot better
21:14
<R4F4EL>
The reason is to separate the workload from computer labs, for example by allowing different firewall rules to be applied to each server, depending on the type of academic activity going on.
21:14
<alkisg>
In general though, for future setups, don't invest on thin clients; buy clients that are good enough to run the OS locally, with just remote disk, not remote desktop (ltsp fat clients instead of thin)
21:15
Sure, if it's not about separation and not load balancing, it's well designed
21:15
*about separation
21:16
!cheap-client
21:16
<ltsp>
cheap-client: https://www.gearbest.com/tv-box-c_11262/?attr=2081-1279
21:17
<alkisg>
E.g. for schools we're buying i3's here, but if you want low cost ones, these ^ will do
21:18
<R4F4EL>
All hardware used in the described solution was purchased between 2010 and 2012. The new acquisitions will take into account the ability of the terminals to operate in fatclient mode.
21:18
<alkisg>
Xorg started deprecating thin clients around... 2005 or so :(
21:19
Unfortunately for a while it won't be a good model. In the future, with hardware hdmi encoding etc, it might work again
21:19
e.g. see google stadia
21:21
<uumas>
And steam link is able to gamestream really playably using a raspi and less than 50mbit of bandwith
21:21
It's not impossible, we just don't have a great solution atm.
21:21
<alkisg>
The major missing part is common server-side hardware
21:22
E.g. graphics cards that would be able to encode 10 compressed hdmi streams to be sent over the network
21:22
Nvidia sells such cards, but at impossible prices, and with dedicated software
21:25
<uumas>
Oh. I had an impression that wouldn't be too gpu-heavy
21:26
But I you've probably looked into this much more than I have :-)
21:27
<alkisg>
Yeah at a time someone wanted to implement remote gaming from linux servers to be sent to android devices so I had a look at what was available
21:27
It's server-class equipment, for youtube servers, stadia servers, steam link servers etc, not for small setups..
21:46
<R4F4EL>
thanks for the help.
21:46
<alkisg>
np
22:16robert45 has joined IRC (robert45!~robert45@r179-24-26-9.dialup.adsl.anteldata.net.uy)
22:19
<robert45>
alkisg any idea why a ltsp thin client would show a desktop screen with black and white instead of colours?
22:33kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:4854:7acc:13a8:95cb, Ping timeout: 246 seconds)