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


Channel log from 12 October 2015   (all times are UTC)

00:00gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
01:33StolenToast has left IRC (StolenToast!~stolentoa@cnut.resist.cc, Ping timeout: 264 seconds)
01:42StolenToast has joined IRC (StolenToast!~stolentoa@cnut.resist.cc)
01:47gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection)
01:48gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
01:52gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection)
02:11gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
02:15gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 246 seconds)
03:11gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
03:16gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 255 seconds)
03:22fnurl has joined IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95)
04:13gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
04:18gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 264 seconds)
05:15gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
05:20gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 264 seconds)
05:25alkisg has left IRC (alkisg!~Thunderbi@ubuntu/member/alkisg, Remote host closed the connection)
05:27alkisg has joined IRC (alkisg!~Thunderbi@ubuntu/member/alkisg)
05:42yanu has left IRC (yanu!~yanu@178-116-58-90.access.telenet.be, Quit: leaving)
05:43yanu has joined IRC (yanu!~yanu@178-116-58-90.access.telenet.be)
06:16gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
06:21gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 256 seconds)
06:30ricotz has joined IRC (ricotz!~rico@p5B2AA972.dip0.t-ipconnect.de)
06:30ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
06:55alkisg has left IRC (alkisg!~Thunderbi@ubuntu/member/alkisg, Quit: alkisg)
06:59alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
07:22gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
07:25schlady has joined IRC (schlady!~schlady@ip1f111304.dynamic.kabel-deutschland.de)
07:26gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 268 seconds)
07:28mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
07:41maldridge1 has left IRC (maldridge1!~maldridge@cpe-76-183-148-124.tx.res.rr.com, Quit: WeeChat 1.3)
07:42maldridge has joined IRC (maldridge!~maldridge@69.13.217.92)
07:45tpe-cpp has joined IRC (tpe-cpp!c23fefeb@gateway/web/freenode/ip.194.63.239.235)
08:01maldridge has left IRC (maldridge!~maldridge@69.13.217.92, Ping timeout: 244 seconds)
08:13Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)
09:01schlady has left IRC (schlady!~schlady@ip1f111304.dynamic.kabel-deutschland.de, Remote host closed the connection)
09:01schlady has joined IRC (schlady!~schlady@ip1f111304.dynamic.kabel-deutschland.de)
09:07schlady has joined IRC (schlady!~schlady@ip1f111304.dynamic.kabel-deutschland.de)
09:09schlady has left IRC (schlady!~schlady@ip1f111304.dynamic.kabel-deutschland.de, Remote host closed the connection)
09:25larryni has joined IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com)
09:42larryni has left IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com, Ping timeout: 256 seconds)
09:55larryni has joined IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com)
10:06khildin has joined IRC (khildin!~khildin@ip-213-49-86-226.dsl.scarlet.be)
10:30schlady has joined IRC (schlady!~schlady@141-53-221-236.ip.uni-greifswald.de)
10:38schlady has left IRC (schlady!~schlady@141-53-221-236.ip.uni-greifswald.de, )
10:41schlady has joined IRC (schlady!~schlady@141.53.32.60)
10:43schlady has left IRC (schlady!~schlady@141.53.32.60, Remote host closed the connection)
10:43gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
10:46gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Read error: Connection reset by peer)
10:47gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
10:53schlady has joined IRC (schlady!~schlady@141-53-32-60.ip.uni-greifswald.de)
10:57schlady has left IRC (schlady!~schlady@141-53-32-60.ip.uni-greifswald.de, Ping timeout: 240 seconds)
10:58gdi2k has joined IRC (gdi2k!~gdi2k@49.151.0.108)
10:59schlady has joined IRC (schlady!~schlady@141-53-32-60.ip.uni-greifswald.de)
11:16gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection)
11:22larryni has left IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com, Ping timeout: 240 seconds)
11:27gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
11:31gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 246 seconds)
11:32khildin has left IRC (khildin!~khildin@ip-213-49-86-226.dsl.scarlet.be, Ping timeout: 256 seconds)
11:34larryni has joined IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com)
11:42os_a has joined IRC (os_a!c3707414@gateway/web/freenode/ip.195.112.116.20)
11:44
<os_a>
Hi!
11:45gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
11:47danau11 has joined IRC (danau11!~durban@66.251.57.114)
11:47larryni has left IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com, Quit: Leaving)
11:54schlady has left IRC (schlady!~schlady@141-53-32-60.ip.uni-greifswald.de, Ping timeout: 250 seconds)
11:58danau11 has left IRC (danau11!~durban@66.251.57.114)
12:27gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
12:32gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 260 seconds)
12:39
<highvoltage>
win 23
12:39
<alkisg>
win some, lose some...
12:48schlady has joined IRC (schlady!~schlady@141-53-221-236.ip.uni-greifswald.de)
12:56schlady has left IRC (schlady!~schlady@141-53-221-236.ip.uni-greifswald.de, Ping timeout: 265 seconds)
12:56schlady_ has joined IRC (schlady_!~schlady@141-53-221-236.ip.uni-greifswald.de)
13:19gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
13:19schlady_ has left IRC (schlady_!~schlady@141-53-221-236.ip.uni-greifswald.de, Remote host closed the connection)
13:25Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
13:57schlady has joined IRC (schlady!~schlady@141-53-221-236.ip.uni-greifswald.de)
13:59gbaman_ has joined IRC (gbaman_!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
14:03gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 240 seconds)
14:04gbaman_ has left IRC (gbaman_!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 256 seconds)
14:05os_a has left IRC (os_a!c3707414@gateway/web/freenode/ip.195.112.116.20, Ping timeout: 246 seconds)
14:24ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
14:40gdi2k has left IRC (gdi2k!~gdi2k@49.151.0.108, Quit: Ex-Chat)
15:14gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
15:37khildin has joined IRC (khildin!~khildin@ip-213-49-86-226.dsl.scarlet.be)
16:05mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
16:13gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: $HOME)
16:19
<muppis>
$HOME not set; using /
16:20
<ogra_>
your home is the whole world !
16:21
<muppis>
:D
16:31Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave)
16:51Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)
17:09schlady has left IRC (schlady!~schlady@141-53-221-236.ip.uni-greifswald.de, Remote host closed the connection)
17:13maldridge has joined IRC (maldridge!~maldridge@69.13.217.92)
17:25maldridge has left IRC (maldridge!~maldridge@69.13.217.92, Quit: kernel upgrade)
17:30maldridge has joined IRC (maldridge!~maldridge@69.13.217.92)
17:36vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
17:42
<alkisg>
vagrantc: what's your view on using a special ssh user, let's say the ltsp user, for clients to communicate with the server, to implement ltspd that way instead of using a SimpleHTTPServer?
17:42
It would have a special shell, it wouldn't allow password authentication etc etc
17:44
It could also be the other way around, the client could have sshd running and a special ltsp user and the server would connect to it
17:53
<vagrantc>
alkisg: why ssh?
17:53
<alkisg>
vagrantc: we're already using it anyway, and it's stable, offers encryption, socket forwarding, multiple connections etc
17:54
Any downsides?
17:54
<vagrantc>
having to configure ssh server-side ... and running it client-side introduces lots of problems with hostkeys
17:55
<alkisg>
Well, we'll either have `ltsp-config sshd` to configure /etc/ssh/sshd_config and put a special match stanza, or use /var/lib/ltsp/.ssh/authorized_keys, for server-side ssh,
17:56
or we can have the server's public key on the client's authorized keys for the opposite, which is easier
17:56
(the ltsp user's public key...)
17:56
<vagrantc>
but the server would essentially have to ignore host keys when connecting to the client
17:57
<alkisg>
how would any other ltspd service solve that issue?
17:57
Don't expect wonders :)
17:58
But any client offering a shell to execute commands on it... how much harm can that do?
17:58
It's just about configuration, which currently is sent unencrypted over the network
17:59
So it's 1000% more security than we have now, or than we could get with https or other technologies
18:00
secure boot is another issue, not solved at this point. When we are able to re-generate static random keys on the client, then we can tell the server to remember them and trust them only once
18:01
<vagrantc>
ok, with an https server, we can configure a certificate server-side that's known to both the server and clients...
18:02
requiring modifications to the ssh server may be prohibited by some site policies (weather misguided or otherwise, they're real-world scenarios)
18:02
<alkisg>
and if the clients know it, then another can't mimic the server?
18:02
I don't see why certificates are different from ssh keys
18:03
<vagrantc>
i'm not talking about a shared secret key, but the traditional client-server model
18:04
technically, there really is no difference with ssh keys, yes... but ssh is well established for logging into systems, and many sites have policies regarding how you are able to configure login service
18:05
<alkisg>
But we're using ssh anyway, and we don't need to modify sshd_config
18:05
We just need /var/lib/ltsp/.ssh/authorized_keys
18:05* vagrantc wonders how that could be implemented without modifying sshd_config
18:05
<alkisg>
We can enforce things there, like the forced login command etc
18:06
http://serverfault.com/questions/142997/what-options-can-be-put-into-a-ssh-authorized-keys-file
18:06
Something like taht
18:06
*that
18:06
<vagrantc>
how do you implement a customized authorized_keys file without modifying sshd_config to check that file?
18:07
<alkisg>
It checks the user's authorized-keys anyway
18:07
<quinox>
gitolite also has a completely locked down shell without any sshd modifications
18:07khildin has left IRC (khildin!~khildin@ip-213-49-86-226.dsl.scarlet.be, Ping timeout: 260 seconds)
18:07
<alkisg>
ltsp is a user, the clients would run ssh ltsp@server
18:07
and the ltsp user's $HOME is there
18:07
(in /var/lib/ltsp, like lightdm's home or other services)
18:08
<vagrantc>
alkisg: ok.
18:08* alkisg checks gitolite...
18:08* vagrantc wonders how many sites have an "ltsp" user
18:08
<quinox>
# head /home/git/.ssh/authorized_keys
18:08
# gitolite start
18:08
command="/usr/share/gitolite/gl-auth-command netrom",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB
18:08
(rest of key cut off)
18:09* vagrantc often uses the "ltsp" user for throwaway test machines :)
18:09
<vagrantc>
yeah, i'm familiar with forced ssh commands
18:10
we'll then need one key for every command ... or the command we use needs to parse arguments
18:10
<alkisg>
If in the future we're able to create random ssh-keys for the clients on boot, but have them use a seed like e.g. the output of `dmidecode` so that they're always the same, then we can easily implement the "trust phase" where the sysadmin needs to run something like `ssh-copy-id` for each client once
18:10
<vagrantc>
the latter often being a security risk
18:10
<alkisg>
stdin, not arguments
18:10
The connection would be permanent, for all the time the client is up
18:10
<vagrantc>
arguments, stdin, whatever ... validated input
18:10
<alkisg>
Yes, like we do now with ldminfod
18:11
And lts.conf parsing on the client (where we already have some issues with $vars :))
18:11
<vagrantc>
no, ldminfod responds the same no matter what you tell it.
18:11
<alkisg>
ah, what was it, ltsp-cluster then? ok...
18:12* vagrantc doen't know ltsp-cluster well enough to speak about it
18:12
<alkisg>
ltspd will need argument handling in any case
18:12
That much is certain
18:12
It will need to know the client arch, ram, mac, cpu... to make decisions
18:13
all the web has argument handling, we can't block progress because it might not be implemented correctly...
18:13
<vagrantc>
no, but we also should think about it.
18:14
<alkisg>
Sure, and peer review the implementation etc
18:14* vagrantc also wouldn't use the web as something worth emulating
18:14
<alkisg>
I'm just trying to balance the sshd vs https implementation now
18:14
<vagrantc>
sure
18:14
<alkisg>
(https == the other probable implementation for ltspd, which is also used in the web...)
18:15
<vagrantc>
as long as we're not trusting arbitrary certificate authorities, that should be fine. :)
18:15
<alkisg>
So which of those 2 would you vote for?
18:15
There's also socat+openssl like epoptes does now
18:16
But it seems too much ad-hoc to me
18:16
<vagrantc>
so you're not happy with epoptes approach?
18:16
<alkisg>
`socat unknown-server` blocks with 100% cpu in wily
18:17
Reported upstream, patch exists, but no bug tracker anywhere, communication is done with private emails
18:17
I prefer using more mainstream technologies whenever possible
18:17
sshd is very well tested
18:17
<vagrantc>
so, the main advantage of ssh is that it's an already existing service that we've historically already depended on being present
18:17
<alkisg>
https as well, although maybe not so much the python implementation that we'll use
18:17
We rely on it now as well, we can't stop using ssh, it's not only historical
18:18
And it supports a vast range of useful things, like even socket forwarding now
18:18
<vagrantc>
well, technically i thin we could move away from ssh if we did fat clients only, for example
18:18
or some other remote X protocol
18:18
<alkisg>
And use what for home, nfs?
18:19
<vagrantc>
NFS, NFSv4, cifs ...
18:19
to me, if we're going to be gutting everything, we don't *have* to assume we'll need ssh.
18:20
<alkisg>
I think that configuring those on the server correctly, with authentication, security etc, will be way more intrusive than having an ltsp ssh user with authorized_keys
18:20
Why would we Depend: https but not Depend: sshd?
18:20
<vagrantc>
i don't really see not having ssh on *my* servers ...but i'm not 100% sure LTSP needs in in the future
18:21
it may very well be the best way forward, i'm just trying to keep an open mind
18:22khildin has joined IRC (khildin!~khildin@ip-213-49-86-226.dsl.scarlet.be)
18:22
<vagrantc>
so, the main disadvantage with an https implementation are ... still have to negotiate keys/certs somehow, and more code left to implement?
18:22
<alkisg>
If we document the phases of communication, then if someone wants, he can implement that "backend" differently, e.g. with https...
18:23
The ssh connection will always be up and can be two-ways
18:23
The client can request things from the server, or the server can instruct the client to shutdown etc
18:24
The https connection will be stateless and that's more stable, but that can only do a few things
18:24
It can't forward sockets or ports or file systems
18:25
<vagrantc>
well, the restricted login shouldn't be able to do those things either...
18:26
<alkisg>
Why wouldn't it forward sockets?
18:26
E.g. suppose that you have sshd running on the client, and listening only on localhost, so that noone can login there from the local network,
18:26
and the client doing a port forward of the local 22 port to the server, so that only the server's ltsp user can login to the client
18:27
Voila, you now have a channel to run commands on the client without authentication, secure, which allows multiplexing etc
18:28
<vagrantc>
the security relies on whatever shell/forced-command we've set up that user to use
18:29
<alkisg>
If we only want port+socket forwarding, it can be /usr/sbin/nologin
18:29
If we want parameter parsing, it will need to be /usr/share/ltsp/login-script
18:30
On the client side, the ltsp user can have /bin/sh as the shell, np there, as it will only allow the server to login there
18:31
<vagrantc>
so as soon as a client boots, the server connects to it?
18:31
<alkisg>
At init-ltsp.d
18:31
<vagrantc>
and leaves a running ssh sesision?
18:31khildin has left IRC (khildin!~khildin@ip-213-49-86-226.dsl.scarlet.be, Quit: I'm gone, bye bye)
18:31
<alkisg>
Instead of 05-getltsconf or so
18:31
Yes
18:32
<vagrantc>
how does the client tell the server to connect?
18:32
<alkisg>
With a local port forward of 22 if we want the server to be able to run things on the client
18:32
Are you asking about the boot/configuration phases?
18:32
how? or when?
18:32
<vagrantc>
yes.
18:33
i.e. client boots ... how does the server know where to connect?
18:33
or when
18:33
<alkisg>
At init-ltsp.d, we'll replace 05-getltscfg with 05-connect-to-server-with-ssh
18:34
<vagrantc>
ok, so there are two ssh connections, one from the client to the server, and another from the server to the client?
18:34
<alkisg>
and at that point we'll tell the server the client ram, cpu etc, and get the configuration we need
18:34
that one connection will forward port 22 from the client to the server
18:34
The server doesn't need to connect at all, it won't use it
18:34
The sysadmin will use that via a tool when he wants, asyncrhonously
18:34
i.e. ltsp-exec pcxx command
18:35
<vagrantc>
and that will connect back to the server via ssh to the client?
18:35
<alkisg>
That `sudo ltsp-exec` tool will check the available sockets, locate pcxx, and login via ssh and run the command
18:36
E.g. if we want to say it with ports, if pc01 forwarded port 22 of the client to the server's 1234, then ltsp-exec would connect to 1234
18:36
But we would prefer sockets there, not ports, for security and clarity of filenames
18:36
<vagrantc>
yes, spinning up lots of arbitrary ports on the server seems dangerous
18:37
<alkisg>
ltsp-exec would of course use private ssh keys, and the public keys would be in the client image authorized-keys
18:37
<vagrantc>
hah.
18:38
<alkisg>
So, encryption over encryption :D
18:38
<vagrantc>
client-side, it could generate random keys, push the public host and authentication keys to the server, and then each client could have an independent set of keys...
18:38
it wouldn't need deterministic keys
18:38
<alkisg>
If the server is willing to automatically trust them, sure
18:39
<vagrantc>
well, it wouldn't have to trust them globally
18:39
<alkisg>
We can't avoid that until we can find a way to seed ssh-keygen
18:39
<vagrantc>
the server-side ssh commands can specify the known_hosts file it uses
18:41
the client image has a trust path to the server (the built-in /etc/ssh/ssh_known_hosts shipped in the booted image) ... and a way to login to the server as a specified user ... which can then push it's generated keys to the server at boot... which then uses those keys to verify it's connecting to the same host, and uses a custom login key
18:42
<alkisg>
Yes, after init-ltsp.d/05-ssh runs, the channel is secured
18:42
<vagrantc>
basically, that avoids the need for a shared private key or deterministic keys on the client
18:42
<alkisg>
Any client can get the server's ssh_known_hosts and claim that it's an ltsp client
18:42
<vagrantc>
this does feel a bit like a maze, though.
18:43
<alkisg>
So before 05-ssh, there's no complete security...
18:43
<vagrantc>
alkisg: sure, but there is information available in the ssh connection that the server can validate
18:43
such as the ip address
18:43
<alkisg>
Which can be spoofed etc etc
18:43
It's the best we can do at this point
18:44
And waaaaay better than what we have now, security-wise
18:44
<vagrantc>
it's much easier to spoof something with a deterministic private key than one that's generated every boot.
18:44
<alkisg>
You have a "join domain" step there
18:45
<vagrantc>
it burns!
18:45
<alkisg>
Where the sysadmin is called to manually accept the key
18:45
:D
18:45
Imagine the client booting, and stopping at 05-ssh, and displaying an ncurses UI, saying "Please enter a domain administrator password to have this machine join the ltsp realm" :P :D
18:45
<vagrantc>
the concept of a "secure" deterministic key is highly questionable.
18:47
<alkisg>
About https, it will be more straight forward, but it won't be able to do things like `ltsp-exec`
18:47
<vagrantc>
one of the things i've always loved about LTSP is being able to plug in an arbitrary machine and boot it and it just works ... requiring a "domain join" equivalent would be very unfortunate.
18:48
<alkisg>
Well you either need to store something on the client (boot from a usb stick or internal DOM with some keys), or reuse some state that the client has that is private and unique (like arguably the output of dmidecode)
18:48
So.... sshd or https? :)
18:48
<vagrantc>
alkisg: could do the same key-exchange over https and then the server could tell it to start up an sshd on $PORT and allow key $KEY to run $COMMAND
18:49
<alkisg>
ssh again
18:49
<vagrantc>
both.
18:49
<alkisg>
We can do the socket forwarding in the opposite side
18:49
If sshd runs on the client, the persistent connection can be from the server to the client
18:50
<vagrantc>
alkisg: you've explained it numerous times, and i still get lost in the explanation
18:50
<alkisg>
The client boots and reaches 05-ssh
18:50
<vagrantc>
alkisg: which suggests to me it's kind of complicated to explain, let alone document, and for a sysadmin to grasp
18:50
<alkisg>
Hehe
18:50
<vagrantc>
so i worry about that a bit
18:50
<alkisg>
It's brainstorming, not documentation
18:50
<vagrantc>
sure
18:51
<alkisg>
And not many people bother with socat + openssl in epoptes, it just works
18:51
<vagrantc>
i still don't see why the client needs something deterministic ... it can tell the server "hi, i'm client FOO, please use these keys to connect"
18:51
<alkisg>
sysadmins need to know about ltsp-exec, not what's behind the scenes
18:51
<vagrantc>
until something doesn't work
18:51
<alkisg>
That (determenistic) part is theoretical, let's leave it for another time
18:52
Then they file bug reports... I think ldm's plugin mechanism is much more difficult to comprehent than ssh socket forwarding
18:52
<vagrantc>
key negotiation is hard, let's go shopping!
18:52
<alkisg>
hehe
18:55
<vagrantc>
so, let's even leave ltsp-exec out of the picture, and get a solid explanation of the phases you see
18:55
and come back to that once that's clearer
18:56
<alkisg>
All of them? Many are unrelated to the technology we'll select. But ok let's go
18:57
I haven't yet made up my mind about the initramfs. If we can stick to the dhcp info, let's use that one only without contacting the server, it will keep the requirements to a minimum (like wget for https)
18:57
We only need the mount parameters there, hopefully dhcp is enough for all use cases there
18:57
So the first phase is init-ltsp.d, at 05-ssh
18:58
There the client sends some info, mac, ip, cpu, ram, graphics card etc, and asks for the equivalent of lts.conf
18:59
That config can contain commands for the client to run at the next phase, which is at ltsp-client-core.init, when services get to run. But I don't think that the client needs to contact the server again at that point.
19:00
The next point that the client will run commands is at the DM, like the ldm-script I*, X*, K* points now
19:00
Before login it will need to contact the server again, and after logout
19:01
We leave the asynchronous ltsp-exec (or ltsp-exec-a-cron-job) bits out of the picture for now...
19:01
It's very similar to what ltsp-cluster has now in the code already
19:01
It just need to be called in some generic way, fetch-config <params>, not -cluster...
19:02
<vagrantc>
currently, the configuration is only received once, but i remember ltsp-cluster allowing it to change every time it runs
19:03
<alkisg>
Right
19:03
Furthermore, it should be able to send more things, like even .xsession files
19:03
Not just key=value lines
19:04
<vagrantc>
ok, so that all seems clear enough at that level view... :)
19:05* vagrantc wonders if ltsp-client-core.init could just disappear, and be handled by configuring everything in init-ltsp.d
19:06
<alkisg>
We do need a `now it's time to run services` hook...
19:07
<vagrantc>
what services that wouldn't be handled by the usual init system?
19:07
<alkisg>
We can either install that hook at init-ltsp.d or from debian/package.systemd, np there
19:08
E.g. SCREEN_07=lightdm SCREEN_08=lightdm, we don't want that?
19:10
<vagrantc>
that's a valid question, but even if the answer is yes, we could possibly generate .service files (or other init scripts) in init-ltsp.d instead
19:10
<alkisg>
Yup, that's what I said, either install the hook (service file) from init-ltsp, or ship it
19:11* vagrantc can smell the torches and pitchforks coming out of the woodwork
19:11
<alkisg>
:)
19:12
<vagrantc>
ok, so ... what does the 05-ssh thing look like?
19:12
<alkisg>
That, or the new getltscfg tool?
19:13
05-ssh is similar to the current /usr/sbin/epoptes-client
19:13
It gathers some data from the client and send them to the server
19:13
and then gets a "personalized" configuration for the client, and stores it in /var/cache/ltsp...
19:13
<vagrantc>
ok, and it gets back the equivalent of lts.conf, with some extra possibilities?
19:13
<alkisg>
Right
19:14
<vagrantc>
that seems fairly uncontroversial
19:14
<alkisg>
If you want to go far enough, you can have the server ship all the ltsp-client code dynamically
19:14
It isn't large
19:15
We're doing something similar with epoptes, allowing the server to send code to the client
19:15
The result is that epoptes-client doesn't need to be updated frequently
19:15
<vagrantc>
one of the frustrating things with the image-based approaches is having to rebuild the image for a one-line change in a file, or adding a single file, etc.
19:15
so that sounds appealing
19:16
<alkisg>
You could e.g. have live CDs or local squashfs images, years old, and have them working with the latest ltsp because they fetch it dynamically from the server
19:16
<vagrantc>
but in the worst-case, it would basically replace lts.conf ... ok.
19:20
alkisg: so when you explain it like that, i feel like it get it ... i think i get lost when you start talking about local to remote and back-again port forwarding and sockets and such
19:21
<alkisg>
I think I get too excited with all the possibilities that I forget to focus on the base first :)
19:21
I'm still not sure where to go with the implementation though... sshd+shell or https+python...
19:24
vagrantc: are you ok with sshd running on the client, with only the server being able to connect and execute commands there by default?
19:24
And even scp files?
19:25
If yes, then we can use that for the bulk of the implementation, not only for ltsp-exec
19:25
I.e. the client would say in 05-ssh:
19:26
server, my mac is xxx, ip=yyy etc, give me my configuration
19:26
...at that point the server would ssh, patch things on the client, copy files, whatever, and then just reply with "you are ready, continue" :D
19:26
So the implementation there is shell, server-side
19:26
And we have selected the technology we want and we can start coding
19:29
<vagrantc>
that sounds a lot like ansible :)
19:32* alkisg verified that sshd can run at init-ltsp.d, it doesn't seem to have any other services as a dependency...
19:33* vagrantc really doesn't like running services from init-ltsp.d
19:33
<alkisg>
Heh, a workaround for people trying to run sshd on the clients... RCFILE_01="dpkg-reconfigure openssh-server" - should be enough...
19:33
That's a good point though, we don't have any guarantee that launching sshd from init-ltsp.d will keep working
19:34
<vagrantc>
we could actually create a second sshd configuration for the client configuration
19:34
<alkisg>
So sshd is good enough for ltsp-exec, but not while the client is still booting
19:35
Ah, sure, another port, configuration file etc
19:35
<vagrantc>
then if the user manually configures sshd, we won't step on those toes
19:36
<alkisg>
http://www.commandlinefu.com/commands/view/13289/reverse-sshfs-mount
19:36
This is not a service... it can run temporarily from init-ltsp.d and offer access to the whole client file system to the server
19:37
Very powerful, but it does sound complicated
19:38
<vagrantc>
complicated, and error-prone
19:38
it doesn't really suceed on the "least access necessary to accomplish the task"
19:38
test
19:38
could sshfs mount some scripts for the client to run...
19:39
<alkisg>
unauthenticated sshfs access to the server? even read-only?
19:39
<vagrantc>
sshfs server:/some/dir/clientXXX/setup.d/
19:40
run-parts setup.d
19:40
something like that
19:41
<alkisg>
The ltsp user could login chrooted in that setup.d dir, but wouldn't you consider that a security issue?
19:41
<vagrantc>
all of the dynamic configuration is a bit of a security issue
19:42
basically, we're giving the server root access to dynamically configure the client ... which it always has had through lts.conf, the image itself, etc.
19:42
<alkisg>
In the sshfs command above, isn't it the client that connects to the server via sshfs?
19:42
I.e. aren't we giving sftp access to the ltsp user?
19:43
<vagrantc>
but there's a simplicity in the image itself being shipped out ... "what's in the image is what we're running" ... dynamic configuration does make it considerably more complicated
19:43
alkisg: it could be a read-only sftp connection to a restricted directory ... but yes.
19:43
alternately, it could just shunt a tarball over the ssh pipe, and we unpack it and run it
19:44
<alkisg>
Well, with those tools, we could boot as an "ltsp client" any live cd, they all have ssh installed - it would only need a custom init command
19:44
<vagrantc>
right
19:45
<alkisg>
No more need for an ltsp-client package, just a small /sbin/init-ltsp command that runs `ssh to the server; and give control to the server`
19:47
<vagrantc>
something feels unsatisfying about that.
19:48
<alkisg>
We have a "do you trust this server" step there ... :)
19:49
<vagrantc>
so, the server-client interaction then relies on the server being able to reliably know all the correct configuration for the client
19:50
so the server-side needs to be multi-distro and multi-release aware ...
19:50
<alkisg>
Evolution... from ltsp-build-client patching chroots, to init-ltsp.d patching live systems, to init-ltsp-ssh handing complete control to the server :D
19:51
<vagrantc>
so, i see advantages, but it does seem rather complicated
19:52* vagrantc still hasn't uploaded ltsp 5.5.5
19:52
<alkisg>
...do we have an answer on the sshd | https? Or do we postpone it for another time?
19:53
Lots of information today though, maybe it does need some time to settle
19:56
Maybe the simpler thing to do is (1) https for config, (2) code on the client, not on the server, (3) leave ssh + ltsp-exec up to epoptes, i.e. epoptes-exec..
19:58
<vagrantc>
certainly a simpler proposal
20:00
<alkisg>
and a *lot* less flexible :)
20:00
<vagrantc>
yes
20:00
<alkisg>
Imagine a student coming in the ubuntu-based ltsp classroom with a fedora laptop
20:01
...and booting with init=init-ltsp, over wifi, in a completely customized (cow, temp) systemd, suitable for the classroom, while utilizing all the local disk speed :D
20:01
*system, not systemd.. meh I typed it a lot recently
20:01
<maldridge>
if I was a student, I don't think I'd boot my laptop over the network like that; too many things could go wrong
20:01
<alkisg>
cow, nothing written locally
20:02
If you had bank accounts there sure, it wouldn't be appropriate
20:02
<vagrantc>
"trust us"
20:02
supporting arbitrary distros on the server-side seems... optimistic
20:03
<maldridge>
the "trust us" approach doesn't sound quite right
20:03
<alkisg>
Theoretically it would just be a folder that I could download from fedora themselves
20:03
OK anyway enough dreaming... it seems to me https is more likely to be widely accepted
20:04
It will be a little tricky to send multiple files etc on one request, but it should be doable
20:04
<vagrantc>
send an archive back
20:05
with a standardized format
20:05* alkisg is thinking about multiple calls, "call me again I have more data for you"
20:05
<vagrantc>
always send all the data?
20:05
latest revision wins
20:06
if we're not configuring *everything* it shouldn't be much data overall
20:06
<alkisg>
Let's say the client asks the server about the ldminfod information
20:06
So it should reply with a few .xsession files, some locale info etc
20:06
Not all of the information is files, we can't easily use tar
20:07
We could use a shell-based output... cat >file.1 <<EOF etc
20:07
I.e. everything that the server sends is just executed client-side
20:07
It wouldn't be binary-safe, but I don't think we need that
20:08
https does need encoding though, the server side would definately be python
20:08
(or php if we wanted a conventional web server)
20:08
<vagrantc>
alkisg: if you do start to code this, please use python3
20:09
<alkisg>
ssh would be much more simple there, jsut scp + commands
20:09
<vagrantc>
no php!
20:10
<alkisg>
ltsp-cluster used php, didn't it? :P :D
20:10
(that's why it never got in debian.... :D)
20:10
<vagrantc>
and how's ltsp-cluster doing these days? :P
20:11* vagrantc thought php had finally gone legacy
20:11
<alkisg>
Don't let Hyperbyte hear you
20:11
He'll crash ltsp.org
20:13
Hmm it's getting rather late here... /me needs to go... bb guys! :)
20:13
<vagrantc>
alkisg: well, thanks for talking all that out!
20:13* vagrantc waves to alkisg
20:13
<alkisg>
Thank you too, we'll see how this goes
20:13alkisg is now known as work_alkisg
20:15* vagrantc is amazed at how much work alkisg gets done while sleeping
20:38
<Hyperbyte>
Heh... sure guys, go ahead and bash php... meanwhile, it's still running half the web. :-)
20:52
<vagrantc>
Hyperbyte: so we should migrate LTSP to a PHP webapp?
20:52
:)
20:52* vagrantc thought webapps were all javascripty nowadays
20:57
<Hyperbyte>
Javascript is client side protocol. It's useless without a server side backend.
21:16gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection)
21:32ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
21:34gbaman has joined IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk)
21:43gbaman has left IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk, Remote host closed the connection)
21:52gbaman has joined IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk)
21:55* Phantomas saw the conversation above and started working again on the ltsp config parser he was writing, which supports ".d/" style configuration (ltsp.d/10-test.conf, 20-bar.conf, 25-foo.conf etc) with DEFAULT section support and multiple inheritance (like 'LIKE') support
22:32ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)
22:42gbaman has left IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk, Remote host closed the connection)
23:02tex-rt has joined IRC (tex-rt!4ac0a1b7@gateway/web/freenode/ip.74.192.161.183)
23:05
<tex-rt>
New Ubuntu 14.04 with Shuttle acting as thin clients - display detection identifying 'default display' and an actual physical display - it acts like a dual display. We'd like to have it default to a single physical display for users.