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


Channel log from 17 December 2013   (all times are UTC)

00:08staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 252 seconds)
00:25freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
01:56gdi2k has left IRC (gdi2k!~gdi2k@120.28.248.83, Ping timeout: 245 seconds)
02:09gdi2k has joined IRC (gdi2k!~gdi2k@64.69.46.199)
02:13gdi2k has left IRC (gdi2k!~gdi2k@64.69.46.199, Ping timeout: 240 seconds)
02:31gdi2k has joined IRC (gdi2k!~gdi2k@120.28.248.83)
02:40
<SeRi>
Team, I have a centos 6 setup with ltsp-server 5.4.5-22.el6 all is setup and well. I have notice that my clients hungs on shutting down. Exactly when the device is shuttingdown eth0. It will never power off or reboot. Any ideas how to get pass this small annoyance? :)
03:18alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
03:54
<alkisg>
vagrantc: hi, another idea! Instead of reimplementing ldm, how would you feel about using a local 'ltsp-connect' wrapper, which would read ldm_username and ldm_password from ldm.c (i.e. stdin), then call ssh, then create the local user (without exposing ldm_username etc in the environment), and finally would re-ssh as the user to the server?
03:54
The difference now is that only 10 shell lines know ldm_username/password from stdin and until the user owned ssh socket is created
03:55
Or, if you prefer, all that could be done inside ldm.c...
03:59* alkisg thinks the current solution for remoteapps, i.e. having a root listener, is worse, security-wise, than caching the password long enough to do a second ssh connection...
04:00
<alkisg>
...and it wastes some more RAM :D
04:13
(unrelated): $ grep -r REMOTECMD .
04:13
./server/k12linux/configs/lts.conf: LDM_REMOTECMD=/usr/bin/myloginscript
04:13
./client/getltscfg/lts.conf: LDM_REMOTECMD=/usr/bin/myloginscript
04:13
...I don't see REMOTECMD anywhere in the code....
04:26
<vagrantc>
alkisg: that seems like it would be best done in ldm itself, at this point ... but maybe that is too hard.
04:26
alkisg: ldm.c (or the ssh plugin ... the c code).
04:27
<alkisg>
vagrantc: no problem, I've written more .c code than shell code... I just feel .c is not necessary, it just adds overhead for ldm (not the greeter) :)
04:29
We still want the local user to be added by our shell script, right?
04:30
I.e. ssh.c will call that script before spawning the second ssh connection....
04:31* alkisg really doesn't like all that .c => shell => .c => shell swapping...
04:32
<alkisg>
With ldm in shell, it would be much more elegant, the greeter in .c, and all the plumbing in shell...
04:33
Mixing languages via stdin/stdout is fine, I just don't like it when .c or .py programs continuously call shell commands do to the actual work, and the .c or .py code is just a wrapper that can also be done in shell...
04:33
*to do
04:34* vagrantc nods
04:34
<vagrantc>
how badly are we doing at that, though, really?
04:34
<alkisg>
I really think ldm is a bad wrapper for shell scripts that can be done in < 100 lines of shell itself, safely
04:35
For rdesktop, it just reads the password from the greeter and puts it in the command line (!)
04:35
So the rdesktop plugin could be done in a few lines of shell with no security difference
04:36
pam.c doesn't exist, we could do it easily in shell too,
04:36
and I don't think reading LDM_PASSWORD from stdin in shell, makes it less secure than reading it from ssh.c....
04:36
....and ssh.c can also be done in e.g. 50 lines of code
04:37
I could post an ldm in shell for review, without committing anything in trunk...
04:46
I think my actual question here is, if I do it well enough (so that it e.g. also supports expired passwords and optionally hashing the password to /etc/shadow which _adds_ security for locking the screen of fat clients), and noone sees any obvious way to exploid LDM_PASSWORD... _then_ would it be OK to push it upstream?
04:50* vagrantc is more worried about non-obvious methods
04:50
<vagrantc>
i am not confident in my ability to spot some of these complicated security issues.
04:52
<alkisg>
LDM_PASSWORD will be only set between 10 lines of shell code of a single script, not in all of the login scripts...
04:53
It won't even be exported to the environment, so cat /proc/pid/environ as root won't see it
04:53
Only RAM dumping will, which is the same for any language
04:54
And of course anyone with enough rights do dump the RAM could more easily install a keylogger...
04:54
*to
04:55
The only difference that I see between shell and .c, is that in .c we can call memset to clean the password in RAM. That's very hard to do right, and we don't even try it currently, and (wrt keylogger) I don't even see a point in doing so
05:22
<vagrantc>
alkisg: so, with all the talk of passwords, how would it handle logins with ssh keys?
05:25
<alkisg>
vagrantc: how is it done now? the user types an empty password, and the sysadmin has somehow allowed him to provide the key to the local filesystem?
05:27
<vagrantc>
alkisg: i don't think it asks for a password unless one is needed
05:27
<alkisg>
OK, and where is the key?
05:27
<vagrantc>
alkisg: i think it tries the ssh connection before getting the password
05:28
when i've set it up, i use /root/.ssh/id*.pub
05:28
<alkisg>
So the user wouldn't have access to it
05:28
<vagrantc>
right
05:28
only works because ldm runs as root, currently
05:29
<alkisg>
So, ldm in shell or in c, or even with libpam_sshauth, we couldn't have user-owned ssh socket that way
05:29
...unless we copied the keys to some user-owned folder...
05:29
<vagrantc>
i vaguely recally testing it with libpam_sshauth and it worked...
05:29
since pam runs as root, and creates the user-owned socket
05:30
<alkisg>
I don't see how libpam_sshauth can do things that ssh.c or plain shell can't...
05:30
To run ssh from the client as the user, the user must exist and have a folder with the keys that he has access to
05:30* vagrantc looks at the code, it's been a couple months
05:31
<alkisg>
But anyways, back to ldm in .c vs in shell comparison, ldm in shell would do exactly what ldm in .c does now
05:31
The exact input/output, the exact file system changes etc
05:32
If libpam_sshauth can do better, then maybe we should start with making an libpam_sshauth.c ldm backend...
05:35
<vagrantc>
yeah, ssh keys can't work...
05:35
it just runs ssh as the user
05:36
<alkisg>
So we need to decide if we prefer ssh keys OR a user-owned ssh socket
05:36
We could just prefer the keys option...
05:36
<vagrantc>
for autologin, i liked keys better, as i could set up passwordless users on the server
05:37
and passwordless users can't do a lot of things, which is exactly how i wanted it
05:38
can't change their password, can't authenticate through other means, etc.
05:39
<alkisg>
OK... so let's abort the user-owned ssh socket plan... rewritting ldm in shell is still a good way to move forward in my opinion
05:40
<vagrantc>
but the user-owned socket is really realyl important!
05:40
i wany it all.
05:40
someday i'll even be able to type.
05:40
<alkisg>
The user owned ssh socket is one way to do remoteapps without an extra process binding together 2 sockets
05:41
<vagrantc>
it seems like a lot to invest in when we're looking at switching to something else
05:41
<alkisg>
It's not any more important than saving 500 Kb RAM on the client...
05:41
I'm not sure we'll even want to drop the greeter...
05:41
*ever
05:42
And I don't think it's more than a weekend's work...
05:42
<vagrantc>
i'm just worried about regression potential
05:43
<alkisg>
How about dropping ldm.c, keeping the greeter, adding libpam_sshauth, and writing a small script to interface between the greeter and libpam_sshauth?
05:45
We do have some regression potential there, but we've added libpam_sshauth, which supposedly is the way forward....
05:45
<vagrantc>
if we can sanely integrate libpam_sshauth into ldm, that sounds ideal to me.
05:46* alkisg isn't really sure that he prefers libpam_sshauth over e.g. samba, but anyways it's a starting point, having a shell script that allows the greeter to do local pam-based authentication is the key point in my opinion
05:46* vagrantc nods
05:46
<vagrantc>
ideally, we just support pam... and everything else comes from that.
05:47
<alkisg>
OK, I'll start with testing libpam_sshauth first, I haven't do so yet... bbl!
05:47
<vagrantc>
i think the ltsp-pam-examples could actually work with something other than libpam_sshautth
05:47
<alkisg>
thanks for the chat!
05:47
<vagrantc>
always!
05:47alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
06:05freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
06:26work_alkisg is now known as alkisg
06:36
<alkisg>
vagrantc: any how-to's for libpam_sshauth? In a wheezy chroot, can I just install it?
06:40alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 265 seconds)
06:47alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
06:49
<alkisg>
https://wiki.ubuntu.com/libpam-sshauth => Unresolved issues: Is Scott smart enough to write this?
06:49
Hahaha!!!
06:50* alkisg wouldn't wonder about sbalneav1 intelligence, only about if he has enough lobsters to do so...
07:15
<alkisg>
50-init-commands: env | sed -n 's/^LTSP_INIT_COMMAND_[0-9][0-9]=//p' | sh
07:15
good enough? ^
07:18* alkisg will install libpam-sshauth in his trusty box, generate a chroot via ltsp-pnp, and will try to configure libpam_sshauth from LTSP_INIT_COMMAND_xx in order to be able to log in from tty1... brb
07:19alkisg has left IRC (alkisg!~alkisg@plinet.ioa.sch.gr, Remote host closed the connection)
07:20work_alkisg has joined IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr)
07:20work_alkisg is now known as alkisg
07:26Fenuks has joined IRC (Fenuks!~Fenuks@5.128.82.13)
07:33
<alkisg>
vagrantc: you should package the example ltsp-session in libpam-sshauth's examples...
07:49
Ah and since we'll be using libpam_sshauth, there's no reason to delete the tty1 service, it's useful now
07:50
<vagrantc>
you'll have to configure it, but sure
07:51
it's got it's own package at the moment
07:51
<alkisg>
vagrantc: which file do we need to configure? /etc/pam.d/login?
07:51
<vagrantc>
yeah
07:51
<alkisg>
(09:51:13 πμ) vagrantc: it's got it's own package at the moment => /me didn't get that, are you talking about libpam-sshauth?
07:52
That's what I installed, but it didn't contain /usr/bin/ltsp-session...
07:52
Or at least /usr/share/examples/...ltsp-session
07:52
Ah, are you thinking that we should ship /usr/bin/ltsp-session from the ltsp package?
07:53
Instead of symlinking it from init-ltsp.d?
07:54
<vagrantc>
http://wiki.ltsp.org/wiki/Dev:LTSPPamNotes
07:54
ltsp-pam-examples
07:55
i just install the init-ltsp.d hook as part of ltsp-pam
07:55
<alkisg>
whoops, I didn't install libnss-extrausers... thanks for the link
07:56
<vagrantc>
well, the ltsp-pam package handles that stuff :)
07:56
in the current progress section
08:00staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
08:02
<alkisg>
vagrantc: in ltsp-pnp, we don't want to modify the server's nss/pam configuration, we want to do those dynamically from init-ltsp.d
08:02
Dunno if that affects any of the current ltsp-pam scripts...
08:02
<vagrantc>
i think the ltsp-pam package does everything from init-ltsp.d
08:02
or at least it should
08:03
<alkisg>
Cool
08:03
<vagrantc>
long-term, it should be integrated directly into ltsp.
08:07staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 240 seconds)
08:27nocturn00 has left IRC (nocturn00!~nocturn@85.234.217.236.static.edpnet.net, Ping timeout: 245 seconds)
08:32nocturn has joined IRC (nocturn!~nocturn@unaffiliated/nocturn)
08:41
<alkisg>
vagrantc: why in pam.d/lightdm, and not in common?
08:41
So that it works for tty's too?
08:41
<vagrantc>
alkisg: caution
08:41
alkisg: i.e. you might only want to selectively allow certain services
08:41
<alkisg>
ok... I copied lightdm to pam.d/login, but a tty login then got stuck in "calling /usr/share/ltsp-pam/ltsp-sesison"...
08:42
...after after 1 minute, FAILED LOGIN for guest: system error
08:42* alkisg digs more...
08:43
<vagrantc>
there are probably some parts of that code that aren't meant to be run from arbitrary pam sessions
08:44
<alkisg>
OK let me see if it works from lightdm, first
08:54vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
09:04bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 245 seconds)
09:05bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
09:09Fenuks has left IRC (Fenuks!~Fenuks@5.128.82.13, Ping timeout: 246 seconds)
10:11Fenuks has joined IRC (Fenuks!~Fenuks@5.128.82.13)
10:26workingcats has joined IRC (workingcats!~workingca@212.122.48.77)
10:28cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Read error: Connection reset by peer)
10:29cyberorg has joined IRC (cyberorg!~cyberorg@203.187.194.152)
10:29cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
10:47freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
10:47hachque has left IRC (hachque!james@2600:3c01::f03c:91ff:fe96:5060, Remote host closed the connection)
10:51hachque has joined IRC (hachque!james@2600:3c01::f03c:91ff:fe96:5060)
11:33Fenuks has left IRC (Fenuks!~Fenuks@5.128.82.13, Ping timeout: 264 seconds)
11:34GrembleBean has joined IRC (GrembleBean!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net)
12:22Yiannis_ has joined IRC (Yiannis_!c23fefeb@gateway/web/freenode/ip.194.63.239.235)
12:23
<Yiannis_>
alkisg
12:23
@alkisg
12:27Yiannis_ has left IRC (Yiannis_!c23fefeb@gateway/web/freenode/ip.194.63.239.235, Client Quit)
12:27
<elias_a>
Yiannis_: He has fallen asleep ;-)
12:28willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
12:31willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Client Quit)
13:32alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg)
13:56cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 250 seconds)
13:57cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
13:58
<alkisg1>
cyberorg: congrats about the release ;)
14:05
<cyberorg>
alkisg1, thanks :)
14:10gdi2k has left IRC (gdi2k!~gdi2k@120.28.248.83, Remote host closed the connection)
15:03mattcen has left IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au, Ping timeout: 257 seconds)
15:15mattcen has joined IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au)
15:25sbalneav1 has left IRC (sbalneav1!~sbalneav@mail.legalaid.mb.ca, Quit: WeeChat 0.3.8)
15:25freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
15:25sbalneav has joined IRC (sbalneav!~sbalneav@mail.legalaid.mb.ca)
15:35staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
15:36vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi)
15:37Fenuks has joined IRC (Fenuks!~Fenuks@212.20.39.215)
15:39
<vmlintu>
alkisg: alkisg1: I just noticed from the logs that you've been discussing guest logins. I just did a new thin client guest login implementation for our systems last weekend..
15:42
There's a inetd listener on the ltsp server that listens for connections from the thinclients. The thinclient uses nc to send the username to the ltsp server and it has to be of form guest-<hostname>.
15:42
inetd then runs a script that creates a user on the ltspserver the same way as lightdm does:
15:42
https://github.com/opinsys/puavo-ltsp/blob/thinguest/client/puavo-ltspserver-create-guest
15:43
that script is still missing a check that the hostname actually exists before creating the user
15:44
Then there's an additional ltspguestsshd running that has a PAM stack that allows users to login without password.
15:44
https://github.com/opinsys/puavo-ltsp/blob/thinguest/client/templates/etc/pam.d/ltspguestsshd
15:45
ltspserver-guest-login checks that the username is of form guest-<remote hostname> and let's the user login if it matches:
15:45
https://github.com/opinsys/puavo-ltsp/blob/thinguest/client/pam/ltspserver-guest-login
15:46
If you run ssh with option -o NumberOfPasswordPrompts=0, it logs in without a password without using keys or anything else..
15:48
The code is not in actual use yet, so there are probably some issues still..
15:49
My ltsp servers are now pxe booting themselves using the same image as the clients, so the code has some quirks for that too..
16:52
<alkisg1>
vmlintu: cool! I don't know where in the logs you saw that, but for "real" guest logins here I'm just creating a local user and using an nbd swap mount from the server, formatted as ext4, for /home/guest...
16:53
I.e. there's no ssh/sshfs to the server involved at all
16:54Fenuks|2 has joined IRC (Fenuks|2!~Fenuks@212.20.39.215)
16:57
<vmlintu>
alkisg1: that's for fatclients?
16:58
<alkisg1>
Yup, although for thin clients you'd need server-side users as you said, ok
16:59
<vmlintu>
yes, for fat clients I'm using pretty much the normal lightdm guest session like you do
17:01
Fat clients are much easier for guest logins.
17:05
On normal ltsp servers one can of course create the guest users once when setting it up
17:08
I haven't been following lately - is lightdm out of the picture now?
17:09freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
17:13
<alkisg1>
vmlintu: I think we've decided that we don't want to rip out ldm and start clean with ltsp6, but to progressively implement stuff _before_ removing ldm, so that then replacing ldm with lightdm is a much smaller task than it is now
17:15GrembleBean has left IRC (GrembleBean!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Quit: I Leave)
17:34Fenuks|2 has left IRC (Fenuks|2!~Fenuks@212.20.39.215, Ping timeout: 245 seconds)
18:05ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 264 seconds)
18:05Fenuks has left IRC (Fenuks!~Fenuks@212.20.39.215, Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/)
18:05ogra_ has joined IRC (ogra_!~ogra_@80.152.237.3)
18:10ogra_ has left IRC (ogra_!~ogra_@80.152.237.3, Max SendQ exceeded)
18:11ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
18:16vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
18:21alkisg is now known as work_alkisg
18:21alkisg1 is now known as alkisg
18:47workingcats has left IRC (workingcats!~workingca@212.122.48.77, Quit: Leaving)
18:59kev_j has joined IRC (kev_j!~Kevin@web.ta-realty.com)
19:18kev_j has left IRC (kev_j!~Kevin@web.ta-realty.com, Quit: Leaving)
19:46ChadLepto has left IRC (ChadLepto!~chadlepto@unaffiliated/chadlepto, Ping timeout: 252 seconds)
20:41monteslu has left IRC (monteslu!~monteslu@ip68-109-175-67.ph.ph.cox.net, Ping timeout: 240 seconds)
20:45monteslu has joined IRC (monteslu!~monteslu@ip68-109-175-67.ph.ph.cox.net)
21:19alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
21:4236DABZBHP <36DABZBHP!~egorij@91.210.103.30> has joined #ltsp
21:4636DABZBHP <36DABZBHP!~egorij@91.210.103.30> has quit IRC (K-Lined)
21:52shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, Remote host closed the connection)
21:57shawnp0wers has joined IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers)
22:01vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 250 seconds)
22:07brunolambert has left IRC (brunolambert!brunolambe@nat/revolutionlinux/x-dirbgtgicrovmwjn, Quit: Leaving.)
22:18
<other_other_joe>
anyone ever try something like profile-sync-daemon on a fat client setup?
22:18
I'm seeing tons of nfs writes all due to the browser profiles
22:19
I think if I can keep them local things'll be much more snappy
22:32hkfrvuwzbz has joined IRC (hkfrvuwzbz!iamparadox@c-71-206-130-134.hsd1.va.comcast.net)
22:35|Paradox| has left IRC (|Paradox|!~iamparado@c-71-206-130-134.hsd1.va.comcast.net, Ping timeout: 245 seconds)
22:36hkfrvuwzbz is now known as |Paradox|
22:49Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
23:43freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)