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


Channel log from 3 August 2015   (all times are UTC)

00:24Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 252 seconds)
04:18AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-jehrgizlwidrqtld, Quit: Connection closed for inactivity)
05:08ricotz has joined IRC (ricotz!~rico@p5B2A91AC.dip0.t-ipconnect.de)
05:08ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
06:17telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
06:18telex has joined IRC (telex!teletype@freeshell.de)
06:46gehidore is now known as man
06:46man is now known as gehidore
06:58TatankaT has joined IRC (TatankaT!~tim@193.190.253.114)
07:22vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
08:58Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)
10:24danau11 has joined IRC (danau11!~durban@12.197.179.122)
10:29danau11 has left IRC (danau11!~durban@12.197.179.122)
10:35uXus has left IRC (uXus!~uXus@217.77.222.72, Remote host closed the connection)
10:49uXus has joined IRC (uXus!~uXus@217.77.222.72)
11:10mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
11:18uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek)
11:21uXus has joined IRC (uXus!~uXus@217.77.222.72)
11:34Faith has joined IRC (Faith!~paty@unaffiliated/faith)
11:38work_alkisg has left IRC (work_alkisg!~alkisg@srv1-dide.ioa.sch.gr, Quit: Leaving.)
12:18adrianorg has left IRC (adrianorg!~adrianorg@189.114.156.121, Ping timeout: 250 seconds)
12:20adrianorg has joined IRC (adrianorg!~adrianorg@177.156.224.158)
12:26work_alkisg has joined IRC (work_alkisg!~alkisg@srv1-dide.ioa.sch.gr)
12:29Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave)
12:34sanctuary has joined IRC (sanctuary!1f4de25d@gateway/web/freenode/ip.31.77.226.93)
12:37sanctuary-it has joined IRC (sanctuary-it!~sanctuary@31.77.226.93)
12:37
<sanctuary-it>
can anybody help me with a problem with a nbd server setup?
12:37sanctuary has left IRC (sanctuary!1f4de25d@gateway/web/freenode/ip.31.77.226.93, Client Quit)
12:38sanctuary-it has left IRC (sanctuary-it!~sanctuary@31.77.226.93, Client Quit)
12:38sanctuary-it has joined IRC (sanctuary-it!~sanctuary@31.77.226.93)
12:38sanctuary-it_ has joined IRC (sanctuary-it_!~sanctuary@31.77.226.93)
12:39
<sanctuary-it_>
hi guys
12:43sanctuary-it__ has joined IRC (sanctuary-it__!~sanctuary@31.77.226.93)
12:43sanctuary-it_ has left IRC (sanctuary-it_!~sanctuary@31.77.226.93, Read error: Connection reset by peer)
12:43sanctuary-it__ has left IRC (sanctuary-it__!~sanctuary@31.77.226.93, Client Quit)
12:54work_alkisg is now known as alkisg
13:00Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
13:10Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)
13:16uXus has left IRC (uXus!~uXus@217.77.222.72, Remote host closed the connection)
13:25ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
13:38uXus has joined IRC (uXus!~uXus@217.77.222.72)
13:56mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
15:11vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
15:17telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
15:18telex has joined IRC (telex!teletype@freeshell.de)
15:19danau11 has joined IRC (danau11!~durban@12.197.179.122)
15:20danau11 has left IRC (danau11!~durban@12.197.179.122)
16:40vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
17:22vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
17:34Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave)
19:17
<highvoltage>
sbalneav1, vagrantc: howdy o/ regarding debian bug #789106 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789106
19:18
package got removed from testing because of that, can I go ahead and update the package or isn't it something anyone cares about anymore?
19:38
<vagrantc>
highvoltage: i've been debating that
19:39
highvoltage: the fix is trivial, but given how long it's taking to make progress with it, maybe we should look at other alternatives
19:39
<highvoltage>
vagrantc: ah *nod*
19:39
<vagrantc>
alkisg: thoughts?
19:40* alkisg checks...
19:40
<vagrantc>
i probably should've kept libpam-sshauth out of jessie, honestly.
19:40
<alkisg>
Ah, pam-sshauth FTBS?
19:40
<vagrantc>
i mean, it was useable, but probably not something we should maintain until we're sure we're going to support it long-term
19:41
alkisg: something in the build toolchain requires more explicity definitions
19:41
alkisg: more explicit build-depends
19:41
<alkisg>
That seems easy to fix...
19:41
I don't know if/when we'll use it in ltsp
19:41
<vagrantc>
it's easy to fix, but do we want to fix it, or do we want to take a different direction?
19:41
exactly
19:41
<alkisg>
If it's working, it will make a good default
19:42
<vagrantc>
it's "working"
19:42
but plenty of rough edges
19:42
<alkisg>
Does it support listing users etc?
19:42
<vagrantc>
no, none of that
19:42
everything is post-authentication
19:43
<alkisg>
Well honestly, I would prefer to copy /etc/passwd (not shadow) from the server on boot + before login :P
19:44
<vagrantc>
i'm learning towards exploring more conventional network authentication
19:44
<alkisg>
And support all the pam* based methods
19:44
<vagrantc>
wouldn't support multiple login servers ...
19:45* vagrantc wonders how well libpam-mount works with tmpfs homedir
19:45
<alkisg>
Well if one has multiple servers, he doesn't use passwd, does he?
19:45
Or if he does, then the client cannot properly cope with multiple servers without hacks anyway...
19:45
*it
19:46
<vagrantc>
we don't have a good way forward to support multiple servers with libpam-sshauth ... short of making a session-type for each server+desktop combo
19:46
LDM supports multiple servers fine
19:46
<alkisg>
If one is using multiple servers, can't we assume that he's using ldap or AD?
19:46
Not fine
19:46
With hacks, merging groups dynamically
19:47
<vagrantc>
ah, ok, sure.
19:47
for the most part, those groups barely matter
19:47
<alkisg>
Can't we just tell people "if you want multiple servers, use something pam-based" there?
19:48
<vagrantc>
i'm not sure how the libpam-sshauth hooks will integrate with other pam modules
19:48
<alkisg>
For single server, with a bit of encryption, we can just copy passwd, and then do the ssh check and possibly update one shadow entry like LDM_PASSWD_HASH does now...
19:48
<vagrantc>
if the server and client are out of sync on the users/groups you could end up with real problems
19:49
<alkisg>
Currently we update the info on login, that's what we'll do in that case as well
19:49
We cannot do anything more than that...
19:49vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi)
19:49
<vagrantc>
so you mean something a little more sophisticated than "just copy"
19:49
<alkisg>
No, plain copy
19:49
Once on boot and once right before login
19:50
<vagrantc>
but the system will already have daemons running with old uid/gid
19:50
<alkisg>
At the auth phase
19:50
Ah, boot + login copies come from the same server
19:50
<vagrantc>
syncing it on boot would be helpful
19:50
i guess we could use an ssh key to do the copy
19:50
<alkisg>
ltspd can send signed + encrypted things...
19:50
<vagrantc>
or some other method from whatever replaces init-ltsp.d
19:50
<alkisg>
Right
19:51
So that way we can use lightdm or whatever
19:51
<vagrantc>
there still are likely to be permission clashes on files ...
19:51
i vaguely recall dbus getting allocated different uid/gid and not being able to write to /var/run/dbus or something
19:52
so i wonder if it wouldn't be better to ensure consistancy at image creation time
19:52
then you could modify the uid/gid files on the actual image
19:52
<alkisg>
I think I read in some policy that demons are supposed to take care of /dev/* uids on boot
19:52
<vagrantc>
and it would be a non-issue
19:53
<alkisg>
And /run too
19:53
<vagrantc>
but filesystem permissions may prevent them from being ale to change the permissions
19:54
i think it's silly to try and force it to use a specific set of uid/gid without fixing the filesystem permissions
19:54
it's asking for problems
19:54
they may be infrequent, or even rare, but when they come up they will be terribly difficult to diagnose
19:55
<alkisg>
I'm only suggesting that, if it's part of some policy, like I vaguely remember
19:56
<vagrantc>
there are policies in debian about daemons ensuring ownership and proper permissions at boot, but one of the appropriate responses is to fail.
19:57
and i don't think that policy accounts for swapping the set of uid/gid mappings at package install time for a different set.
19:58
<alkisg>
find /usr ! -uid 0
19:58
==> 2 entries, one for "daemon" and one for "libuuid"
19:58
So you're right, client system uids/gids should be kept
19:58
<vagrantc>
honestly, image creation/updating might be a good time to fix that stuff up.
19:59
having it be consistant would probably not affect a large number of files, and would make this issue moot.
19:59
<alkisg>
How can you fix the issue on image creation/update?
20:00
Don't the same issues apply?
20:00
<vmlintu>
What is the actual situation where this happens?
20:00
<vagrantc>
you check for all the files owned by the old uid/gid and reassign them to the new one
20:00
and update passwd/group accordingly
20:00
i guess you have to track which ones have already been changed
20:01
<alkisg>
vagrantc: there would be system uids/gids in the chroot that don't exist in the server, and vice versa,
20:01
<vagrantc>
actually, on second run there would be no discrepancies...
20:01
<alkisg>
and those reserved uids would then cause clashes with the other ones that were "syncable", preventing them from syncing...
20:01
<vagrantc>
this whole discussion is why i've been leaning towards usng some existing backend to keep this stuff in sync.
20:02
rather than reimplementing an ugly workaround...
20:02
<alkisg>
Do ldap/samba etc deal with system uids/gids?
20:02* vagrantc assumed so
20:02
<vagrantc>
maybe that's a flawed assumption
20:02
<vmlintu>
alkisg: normally you don't have system users and groups in ldap.. at least I haven't seen that
20:03
Probably some do that, though
20:04
<alkisg>
I think it makes more sense to let the chroot deal with its system uids/gids, and only merge the user uids/gids, either with some syncing hack or with ldap/samba...
20:04
So, my "copy passwd" proposal would need to become "sync passwd" on boot + on auth...
20:04
(so that we're able to use lightdm etc)
20:04
<vagrantc>
i think one of the groups that brought this to light was "fuse" which is no longer actually used
20:07
<vmlintu>
Why would you need sync on boot?
20:08
<vagrantc>
to be able to know which users are valid
20:08
alkisg: although, that could get out of sync if users are added after boot
20:08
<vmlintu>
If you construct the pam stack carefully, you can do everything thin/fat clients need during pam auth.
20:09
<alkisg>
Sorry, the boot part was when I was suggesting to sync the system uids/gids too
20:09
Now I think it suffices to do it only on auth, yup
20:10
Oh, there's accountsservice and user lists in lightdm...
20:10
Two reasons to do it on boot..
20:10
Not too important, I guess
20:10* alkisg needs to go, 'night all
20:11alkisg is now known as work_alkisg
20:11
<vmlintu>
We are actually using the nss-extrausers module so that we don't need to merge /etc/passwd
20:11
<work_alkisg>
I think libpam_sshauth also uses that?
20:11
<vmlintu>
I don't remember that anymore since we don't use libpam-sshauth
20:13
Basically it goes now: lightdm - pam-auth - kerberos auth - http request - extrausers update - pam-account - pam-session - nfs4 mount
20:13vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 240 seconds)
20:13
<vmlintu>
If you take out the kerberos auth and authenticate the http request with basic auth, everything else but nfs4 mount would work the same way
20:15vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
20:17
<vmlintu>
so instead of libpam-sshauth one could only use a http server to do pam and nss
20:18
openssh requires that nss finds the username before it starts pam auth, but lightdm doesn't require that
20:49ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
21:14Faith has left IRC (Faith!~paty@unaffiliated/faith, Quit: Saindo)
21:22AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-eijtfifgodvmfocu)
21:28vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi, Ping timeout: 265 seconds)
21:59ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)
22:36telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
22:38telex has joined IRC (telex!teletype@freeshell.de)
23:05dtcrshr has left IRC (dtcrshr!~datacrush@unaffiliated/datacrusher, Quit: Saindo)
23:22dtcrshr has joined IRC (dtcrshr!~datacrush@unaffiliated/datacrusher)
23:26vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
23:54dtcrshr has left IRC (dtcrshr!~datacrush@unaffiliated/datacrusher, Remote host closed the connection)