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


Channel log from 31 October 2018   (all times are UTC)

00:49zama has left IRC (zama!~zama@unaffiliated/stryx/x-3871776, Ping timeout: 252 seconds)
00:58zama has joined IRC (zama!~zama@unaffiliated/stryx/x-3871776)
01:16josefig has left IRC (josefig!~josefig@unaffiliated/josefig, Ping timeout: 250 seconds)
02:19adrianor1 has joined IRC (adrianor1!~adrianorg@177.18.49.220)
02:20adrianorg has left IRC (adrianorg!~adrianorg@179.187.25.94.dynamic.adsl.gvt.net.br, Ping timeout: 245 seconds)
02:43adrianor1 has left IRC (adrianor1!~adrianorg@177.18.49.220, Ping timeout: 244 seconds)
02:49adrianorg has joined IRC (adrianorg!~adrianorg@186.215.21.64)
03:12adrianorg has left IRC (adrianorg!~adrianorg@186.215.21.64, Ping timeout: 268 seconds)
03:19adrianorg has joined IRC (adrianorg!~adrianorg@177.18.173.141)
06:55
<cemc>
quinox, alkisg: thanks, it is working now
06:55
<alkisg>
np
09:13enaut[m] has left IRC (enaut[m]!enautmatri@gateway/shell/matrix.org/x-tylptccdomvnrmtf, Read error: Connection reset by peer)
09:23enaut[m] has joined IRC (enaut[m]!enautmatri@gateway/shell/matrix.org/x-rytdoqkgudkpdosx)
10:01kjackal has joined IRC (kjackal!~quassel@2a02:587:3101:400:8c1b:8441:9019:ed7a)
10:05Natureshadow has left IRC (Natureshadow!45d1515d22@commu.teckids.org, Read error: Connection reset by peer)
10:25ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
11:16GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net)
11:47Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
14:50GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 245 seconds)
15:06GodFather has joined IRC (GodFather!~rcc@2600:1007:b12b:f6ac:7d36:a71a:fdad:eaec)
15:07rubberduck77 has joined IRC (rubberduck77!~rubberduc@gk8.condor-edv.de)
15:10
<rubberduck77>
Hello LTSP! First of all, I would like to say thanks to the really impressive work on this project. I have installed the LTSP, now beeing impressed but already have some questions to maybe unsupported features. Someone out there who might have some deep insights?
15:12
<||cw>
just ask. several are in and out this time of day
15:13
but do keep in mind that LTSP is glue for several normal linux tools, so quite often the answer is simple "how would you do that on any multiuser linux system"
15:13
<rubberduck77>
Thnx...
15:14
...the "question" is... how (and when) does the ldm process add the getent <user> to the "local" passwd/shadow?
15:16
I have a problem from that, since the mate-desktop wont unlock the screensaveer with my installation... but I already hacked the LTSP quite a bit, to be able to run from a "local" img file. So I would like to understand, how authorisation is implemented.
15:17
Hacked might be wrong wording.. simply using a local disk; not only for the kernel and initrd but also the root.img looped to the kernel. Required only two small parameters for the cmdline, and now the "thinclient" is much faster on a remote network.
15:23
<mwalters>
rubberduck77: can't answer the technical aspects, but adding the following line to lts.conf will resolve the screensaver issue: LDM_PASSWORD_HASH=True
15:23
(for fat clients)
15:26
<rubberduck77>
Thnx... that seems to disable the screensaver, right?
15:33
<mwalters>
no... trying to think of how to word it correclty
15:34
end result is a properly functioning screen lock... creates a shadow entry for the logged in user?
15:34
(locally)
15:35
"Will create a proper shadow entry on the client, allowing for screen locking, and other things which require authentication to work"
15:35
<rubberduck77>
Ah, Ok. That seems to be what I would need. I will give it a try. Side-Effect would be, that on a local vty a user also would be able to logon, right
15:36
<mwalters>
from lts.conf manpage
15:36
probably, let me test
15:36
yes, logging into vty works
15:36
(I'm on a fat client right now ;) )
15:36
<rubberduck77>
sound good
15:37
<mwalters>
also to note from man: This lets users change their password locally, but does not change it on the server... you'd want to use like, `ltsp-remoteapps passwd` for it to be persistent
15:38lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-186.isotelco.net.br)
15:41GodFather has left IRC (GodFather!~rcc@2600:1007:b12b:f6ac:7d36:a71a:fdad:eaec, Ping timeout: 260 seconds)
15:41lucascastro has left IRC (lucascastro!~lucascast@177-185-139-186.isotelco.net.br, Remote host closed the connection)
15:50lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-186.isotelco.net.br)
15:57GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net)
16:12Natureshadow has joined IRC (Natureshadow!45d1515d22@commu.teckids.org)
16:14josefig has joined IRC (josefig!~josefig@unaffiliated/josefig)
16:43GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 260 seconds)
17:24vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
18:16kjackal has left IRC (kjackal!~quassel@2a02:587:3101:400:8c1b:8441:9019:ed7a, Ping timeout: 252 seconds)
19:14josefig has left IRC (josefig!~josefig@unaffiliated/josefig, Ping timeout: 244 seconds)
19:29lucascastro has left IRC (lucascastro!~lucascast@177-185-139-186.isotelco.net.br, Read error: Connection reset by peer)
19:30lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-186.isotelco.net.br)
19:32GodFather has joined IRC (GodFather!~rcc@174-081-217-069.dhcp.chtrptr.net)
19:43
<rubberduck77>
@mwalters: thanks... testet and works like a charm
19:44
<mwalters>
:D
19:45
<rubberduck77>
Is there anyout else, who prefers using a local cache disk instead of nbd'ing everything always over the net?
19:45
<vagrantc>
i would get tired of updating the disk
19:46
but i guess if the caching was transparent in the background...
19:46
<rubberduck77>
@vagrantc: your rght, but maybe one can sctipt the needed updates
19:46
<mwalters>
dunno other people's workloads, but generally I open chrome and leave it open all day ;)
19:46
<vagrantc>
i haven't seen a public example, but yes, it's theoretically possible
19:46
<mwalters>
same with mate-terminal
19:47
<rubberduck77>
Currently my grub can choose to boot from net or local disk... I now would need to implement the cache update "script". So thats the reason for my question... maybe someone else already did this.
19:48
you're right... the terminals wont need to load that much stuff if they get up and running. But until loaded over a "small" uplink to the server, the local cache saves a lot of time
19:49
<vagrantc>
and what are you doing to cache locally?
19:49
just dd to the disk?
19:51
<rubberduck77>
I currently use the amd64.img, place it on a separate partition and use kernel looping
19:52
<alkisg>
!local-boot
19:52
<ltsp>
local-boot: If you want LTSP fat clients on a low-speed network, you can put i386.img on e.g. C:\Boot\LTSP\i386.img and use this command line in pxelinux.cfg: APPEND ro initrd=ltsp/i386/initrd.img init=/sbin/init-ltsp root=/dev/sda1 rootflags=ro loop=/Boot/LTSP/i386.img; IPAPPEND 3
19:52
<alkisg>
mwalters: ^
19:52
ah, sorry, rubberduck77 ^
19:53
<rubberduck77>
I use something similar:
19:53
<alkisg>
I used it in a couple of schools, and gave a command to the teacher to use via epoptes
19:53
Like, dd if=/dev/nbd0 of=/path/to/amd64.img
19:54
So he typed it once in the epoptes dialog, and all clients updated, and auto-shutdown after they were done
19:54
<vagrantc>
the killer feature would be something that just did that dynamically when you boot to the network
19:54
<alkisg>
That would be a good task for a caching file system, with dmcache possibly
19:54
<vagrantc>
right
19:55
<alkisg>
And it would be even greater if all nbd traffic was broadcasted and automatically cached by all clients
19:55
<rubberduck77>
menuentry "LTSP local image" {
19:55
loopback loop "(hd0,1)/amd64.img"
19:55
set root='(loop)'
19:55
linux /boot/vmlinuz ro quiet splash init=/sbin/init-ltsp forcepae root=/dev/sda1 nbdroot=DHCP ltsp.SERVER=192.168.198.15 loop="amd64.img"
19:55
initrd /boot/initrd.img
19:55
loopback -d loop
19:55
}
19:55
<vagrantc>
especially if it could be opportunistic and just sync in the background
19:55
<alkisg>
rubberduck77: eh, no need to keep the kernel locally, it's just a few mb...
19:55
<vagrantc>
alkisg: but it's already in the image
19:56
<alkisg>
Yeah, but it requires grub on the client
19:56
<vagrantc>
ah
19:56
<alkisg>
While in my case i didn't want to "upset" the local windows installations
19:56
And, netbooting allows to get the newest kernel each time, not the one from the image, which might have issues
19:56
<vagrantc>
so if the network was down, the client wouldn't function... though without a homedir i guess it doesn't matter
19:56
<alkisg>
Right
19:57
!epoptes
19:57
<ltsp>
epoptes: Epoptes is a computer lab administration and monitoring tool. It works on Ubuntu and Debian based labs with LTSP or non-LTSP servers, thin and fat clients, standalone workstations, NX clients etc. More info: http://www.epoptes.org
19:57
<alkisg>
rubberduck77: in case you don't know it, it's handy for running tasks in all clients easily ^
19:57
<rubberduck77>
@alkisg: already installed this handy tool
19:57
<alkisg>
nice
19:58* alkisg waves, 'night all...
19:58
<rubberduck77>
I already said it a couple of hours ago... really impressed of all the LTSP-Stuff around!
19:58
<vagrantc>
for the right niche, it's pretty amazing :)
19:59
<rubberduck77>
Works easily and covers many tasks already... never the less... I do not understand, why here in germany it a (at least seems) to be not that heaviliy used...
20:00
...we were evalutating for quite some time now some solutions to upgrade some "old" SunRay installations...
20:00
...come accross some "cheap" and also some "expensive" commercial solutionss...
20:01
...but only the "free" solution "LTSP" seems to cover all of our needs!
20:01
<vagrantc>
glad to hear it's working for you!
20:02
there are (were?) a number of deployments of LTSP in germany using the Debian-Edu project; not sure if they're still in use or not
20:02
<rubberduck77>
We are still evalutiation... but it is on a good way... we need it for a hospital e.g. with around 500 thinclients and citrix on top
20:02
<vagrantc>
heh. with citrix on top, just about anything could be underneathe
20:05
<rubberduck77>
well... not quite eveything... the openthinclient project (also in germany maintained) uses debian wheezy... so our "brand new" IntelNUCs are not supported... and also wont be in the early next release the told be. At least for mutli monitor solution or with 4K resoltuion.
20:07
and ubuntu 18... latest xorg with latest intel... works without any problems from scratch
20:10
I would also prefer to drop citrix .. but the customer insists on that, cause the manager has been familar with it at a former workplace. so... I need to provide a solution for 4K, multi-monitor with "cheap" thin-client hardware.
20:10
Is there anything on how we can support the project?
20:17
<quinox>
$$$
20:17
;)
20:23
<vagrantc>
LTSP has been stalled for some years on some new feature development ... it's largely been in maintenace mode, and could use some updates
20:23
or at the very least, cleaning out some cruft ...
20:24
but it really needs some model that can sustain development over time
20:25
there's a bit of drive-by interest now and then, but it's been a while since there's been an active developer community
20:25
<rubberduck77>
I already saw something about "clustering" the server... dont know if we already need it for our planned installatioones... but seems to outdated?? Or already not really needed any longer?
20:25
<||cw>
rubberduck77: they're using citrix for linux desktops?
20:25
<vagrantc>
the ltsp-cluster stuff is a perfect example of things that are no longer maintained or suported, that still have bits of code all over the place
20:26
<rubberduck77>
@vagrantc ... sorry... quite new here... is there a list "public" visible of the people which one would call a ltsp developer?
20:27
@cw no--- citrix to access windows-terminal-servers over some small uplinks from several locations.
20:27
<||cw>
will their apps work on linux?
20:27
<vagrantc>
rubberduck77: you can look at the commit history
20:27
<rubberduck77>
@cw: no...
20:27
<vagrantc>
rubberduck77: mostly alkisg these days with the occasional contribution from myself or someone else
20:28
in fact, i really should make sure it works ok with the upcoming Debian freeze...
20:28
<||cw>
ltsp is linux terminal server. it's not really comparable to citrix.
20:28
<rubberduck77>
@cw we only need a "platfrom" to laucnh the citrix receiver
20:29
<||cw>
however, you can use ltsp in a bare bones way to run xfreedrp to connect to windows terminal servers or virtual machines (VDI style)
20:29Natureshadow has left IRC (Natureshadow!45d1515d22@commu.teckids.org, Read error: Connection reset by peer)
20:29
<||cw>
so does that work on linux with 4K multi display?
20:30
in that use, ltsp is just a nice way to make the clients diskless.
20:30
<rubberduck77>
we have testet with ubu18... and with our intel nuc it works without any problems from scratch
20:30
<alkisg>
How much ram do the clients have?
20:30
<rubberduck77>
8G
20:31
<alkisg>
Eh, didn't you also say you had some old clients?
20:31
Or ltsp is just for the nucs?
20:31
<rubberduck77>
the old clients we are going to replace are sunray2... but they will be replaced completly
20:31
ltsp is the "operation system" for the new nucs
20:31
<vagrantc>
there was an attempt to port ltsp to sunray at one point... but too locked down
20:32
<alkisg>
So you want ltsp just to netboot the nucs and run citrix on top? The users won't work on linux at all?
20:32
<vagrantc>
i'm guessing citrix won't use much of that 8GB of ram
20:32
honestly, if that's all you're doing ... just load the NBD image into RAM
20:33
<rubberduck77>
@alkisg: at least for the hospital installation that is right. on some other nstallations where we need to "upgrade" the old thinclient hardware, there are also local-browers that have to be sused.
20:33
@vagrantc we already thought of only using 4G
20:33
<vagrantc>
how much ram does citrix eat?
20:33
<rubberduck77>
then the complete nuc would cost aroung 145@
20:33
<alkisg>
And I'm guessing you won't need linux-authentication either (users etc), since the users will authenticate against citrix?
20:33
<rubberduck77>
@alkisg: right
20:34
<alkisg>
OK, then yeah you can have a kiosk-like session that only offers citrix
20:34
<rubberduck77>
@vagrantc: i haven't measured until now
20:34
<alkisg>
The kiosk plugin in ltsp could use a rewrite, but it should be easily implementable
20:34
<rubberduck77>
@alkisg... that would suffer the hospital needs, riught
20:35Natureshadow has joined IRC (Natureshadow!45d1515d22@commu.teckids.org)
20:49
<rubberduck77>
Another question (not tested until now): do you know, if hospital keyboards like "eHealth-BCS Tastatur G87-1504" will work?
20:50
Not the keybord itself in question, but the card readers contained in?
20:51
<alkisg>
If they work on linux, they work on ltsp too
20:52
<rubberduck77>
Ok; I'll give it a try
20:53
So to focus on e.g. citrix-kiosk mode... what would be needed?
20:53
<vagrantc>
look at the various scripts in /usr/share/ltsp/screen.d/
20:54
xfreerdp/rdesktop might be the most similar use-case
20:54
or the kiosk script, but i suspect that is overkill
20:54
not very familiar with citrix, so maybe there's more to it than i realize
20:56* alkisg has used citrix in 2006, right before jumping on the ltsp wagon in 2007
20:56
<alkisg>
...ltsp was a looooooooot faster/efficient :)
20:57
At some point we tried to combine them, ltsp + citrix on top, but then we realized noone wanted citrix after working with ltsp :)
20:57Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
20:57
<vagrantc>
:)
20:59
<rubberduck77>
do you know working installations over slow uplinks??
21:01
<alkisg>
I think at that point we had adsl with 256 download / 64 upload or so, I don't remember. It was working for a couple of clients, but not for the whole classroom of 8+1 clients
21:01
<vagrantc>
there's NX and that other project that's forked and updated it
21:02
the name slips my mind
21:02
<alkisg>
x2go
21:02
<vagrantc>
x2go
21:02
hah
21:02
<alkisg>
!x2go
21:02
<ltsp>
x2go: x2go is an NX-based suite of applications that allow logging in to a remote X server from any OS. It's much more efficient than VNC over slow network. More info: http://www.x2go.org/
21:03
<vagrantc>
i should really experiment with it sometime
21:04
<alkisg>
It very frequently has issues because of stale sessions
21:04
<rubberduck77>
@vagrantc the screen kiosk... what parameters will be $1 $2??
21:04
<alkisg>
So me and others that have tried it, switched to plain ssh + reverse vnc...
21:11
<vagrantc>
alkisg: i've let the ltsp-docs package pretty much fall through the cracks assuming it won't be in debian buster ... but now i'm realizing that's the source of the lts.conf manpage
21:12
the documentation is out of date enough ... i figured it was worth letting it go
21:12
but now i'm not so sure
21:12
<alkisg>
vagrantc: it's still useful,I think we shouldn't make any big changes there and let it be until ltsp6 comes along where we replace it
21:13
E.g. I'm frequently saying "read about LDM_HASH_PASSWORD" in `man lts.conf`; I don't think we document things like that elsewhere
21:13
<vagrantc>
i think there are a handful of patches for it floating around in the debian bug tracker and/or launchpad ... should apply those then and get it back into buster
21:13
alkisg: yeah, waiting for ltsp6 has been part of my hesitance to spend any significant energy on updating it
21:14
but that's turning out to be a long wait :/
21:14* alkisg hopes we'll find funding for that some day :)
21:14
<alkisg>
Maybe in a future gsoc...
21:22
<rubberduck77>
Is there a roadmap available for ltsp6?
21:23
<alkisg>
Hyperbyte: wth? http://wiki.ltsp.org/wiki/6_Solutions_To_Increase_Penis_Size
21:23
spam bots?
21:24
rubberduck77: there are some dev: pages in the wiki, e.g. http://wiki.ltsp.org/wiki/Dev:GSoC
21:24
But nothing concrete
21:24
<||cw>
yeah you need captcha on any wiki these days
21:24
<alkisg>
This page was last modified on 15 October 2018, at 22:32.
21:27ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:29
<rubberduck77>
@alkisg: sound like a "complete" reimplementaiton...!?!
21:34
<vagrantc>
rubberduck77: pretty much
21:34
<rubberduck77>
do you have a time schedule on that?
21:35
and development resources?
21:35
<vagrantc>
a lot of the current LTSP codebase is generating an ltsp chroot, which has been discouraged for years in favor of the chrootless model
21:35
it would greatly simplify a lot of things
21:36
rubberduck77: no schedule and not really any resources beyond a few volunteers here and there
21:44josefig has joined IRC (josefig!~josefig@unaffiliated/josefig)
21:46
<vagrantc>
there have been a few GSoC and Outreachy projects, but they are limited in duration, so don't sustain long-term maintenance
21:49
the good news is it morely works despite all that! :)
21:50
<quinox>
it works great
21:50
<vagrantc>
er, more-or-les
21:50
s
21:50
<quinox>
I have been using it for 8 years now, really happy with it
21:50
<vagrantc>
or mostly .. hah.
21:51
<rubberduck77>
The other listed developers no longer involved in further development plans, or all busy ?
21:52
<vagrantc>
several busy with other things, or changed companies, etc.
21:53
the ltsp-cluster stuff mentioned earlier was largely the work of a few of the ltsp developers at a specific company, that eventually changed it's business model and no longer used ltsp, for example
21:53
<rubberduck77>
with ltsp6 is seems, that cluster-stuff in the old manor is no longer needed, right?
21:54
<vagrantc>
right
21:54
a lot of stuff isn't needed
22:02kjackal has joined IRC (kjackal!~quassel@2a02:587:3101:400:8c1b:8441:9019:ed7a)
22:07
<rubberduck77>
dnsmasq and tftp is needed to support out-of-the-box configurations, right?
22:13
as I saw in another thinclient implementation; they are using LDAP to send/recv configuration etc.
22:30
<vagrantc>
dnsmasq can server both tftp and dhcp and most interestingly, proxy dhcp where it can inject additional information needed to network boot
22:31
tftp is kind of the lowest common denominator for a download protocol for network boot... it's widely supported
23:10Natureshadow has left IRC (Natureshadow!45d1515d22@commu.teckids.org, Read error: Connection reset by peer)
23:30josefig has left IRC (josefig!~josefig@unaffiliated/josefig, Ping timeout: 272 seconds)
23:31kjackal has left IRC (kjackal!~quassel@2a02:587:3101:400:8c1b:8441:9019:ed7a, Remote host closed the connection)
23:31kjackal has joined IRC (kjackal!~quassel@2a02:587:3101:400:8c1b:8441:9019:ed7a)
23:39kjackal has left IRC (kjackal!~quassel@2a02:587:3101:400:8c1b:8441:9019:ed7a, Ping timeout: 252 seconds)
23:44josefig has joined IRC (josefig!~josefig@unaffiliated/josefig)