00:07 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 240 seconds) | |
00:09 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
00:37 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 268 seconds) | |
00:39 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
01:07 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 265 seconds) | |
01:09 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
01:38 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 268 seconds) | |
01:39 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
02:07 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 240 seconds) | |
02:09 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
02:37 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 240 seconds) | |
02:39 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
03:08 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 240 seconds) | |
03:10 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
03:37 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 240 seconds) | |
03:39 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
04:08 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 240 seconds) | |
04:10 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
04:38 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 268 seconds) | |
04:40 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
05:01 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 276 seconds) | |
05:08 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 268 seconds) | |
05:10 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
05:39 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 264 seconds) | |
05:40 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
06:09 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 268 seconds) | |
06:11 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
06:38 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 265 seconds) | |
06:40 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
07:09 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 265 seconds) | |
07:10 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
07:39 | vsuojanen 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:41 | vsuojanen 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:09 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 268 seconds) | |
08:10 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
08:30 | woernie has joined IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de) | |
08:39 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 265 seconds) | |
08:41 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
08:52 | Da-Geek has joined IRC (Da-Geek!~Da-Geek@5.154.189.38) | |
08:53 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
09:09 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 276 seconds) | |
09:10 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
09:24 | statler_ has joined IRC (statler_!~Georg@gwrz.lohn24.de) | |
09:31 | statler has left IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de, Remote host closed the connection) | |
09:31 | <vsuojanen> alkisg: ok
| |
09:32 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Quit: leaving) | |
10:04 | <woernie> poweroff
| |
10:06 | woernie_ has joined IRC (woernie_!~werner@p50867A20.dip0.t-ipconnect.de) | |
10:08 | woernie has left IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de, Remote host closed the connection) | |
10:09 | woernie has joined IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de) | |
10:17 | woernie has left IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de, Remote host closed the connection) | |
10:18 | woernie 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:38 | kjackal 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:16 | dsjii has joined IRC (dsjii!~david@047-134-241-234.res.spectrum.com) | |
11:46 | <woernie> @alksig thanks, clients shutting down now
| |
11:49 | GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net) | |
12:06 | meo 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:07 | douglas_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:27 | Da-Geek has left IRC (Da-Geek!~Da-Geek@5.154.189.38, Remote host closed the connection) | |
13:28 | Da-Geek has joined IRC (Da-Geek!~Da-Geek@5.154.189.38) | |
13:35 | eu^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:29 | spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Remote host closed the connection) | |
14:30 | spaced0ut 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:21 | GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 268 seconds) | |
15:27 | woernie has left IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de, Remote host closed the connection) | |
15:47 | eu^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:48 | Da-Geek has left IRC (Da-Geek!~Da-Geek@5.154.189.38, Remote host closed the connection) | |
15:48 | Da-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:40 | Da-Geek has left IRC (Da-Geek!~Da-Geek@5.154.189.38, Remote host closed the connection) | |
16:41 | Da-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:56 | woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de) | |
16:57 | Da-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:13 | vagrantc 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:14 | statler_ 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:42 | R4F4EL has joined IRC (R4F4EL!b1149819@177.20.152.25) | |
19:42 | R4F4EL has left IRC (R4F4EL!b1149819@177.20.152.25) | |
19:43 | R4F4EL has joined IRC (R4F4EL!b1149819@177.20.152.25) | |
19:46 | GodFather has joined IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com) | |
19:50 | douglas_br has left IRC (douglas_br!bb5f6554@187.95.101.84, Remote host closed the connection) | |
19:57 | kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:4d22:8ef4:685e:7764, Remote host closed the connection) | |
20:07 | kjackal 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:22 | ricotz 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:50 | statler 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:11 | statler 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:13 | woernie 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:16 | robert45 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:33 | kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:4854:7acc:13a8:95cb, Ping timeout: 246 seconds) | |