IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 3 August 2015 (all times are UTC)
| 00:24 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 252 seconds) | |
| 04:18 | AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-jehrgizlwidrqtld, Quit: Connection closed for inactivity) | |
| 05:08 | ricotz has joined IRC (ricotz!~rico@p5B2A91AC.dip0.t-ipconnect.de) | |
| 05:08 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 06:17 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 06:18 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 06:46 | gehidore is now known as man | |
| 06:46 | man is now known as gehidore | |
| 06:58 | TatankaT has joined IRC (TatankaT!~tim@193.190.253.114) | |
| 07:22 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 08:58 | Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net) | |
| 10:24 | danau11 has joined IRC (danau11!~durban@12.197.179.122) | |
| 10:29 | danau11 has left IRC (danau11!~durban@12.197.179.122) | |
| 10:35 | uXus has left IRC (uXus!~uXus@217.77.222.72, Remote host closed the connection) | |
| 10:49 | uXus has joined IRC (uXus!~uXus@217.77.222.72) | |
| 11:10 | mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk) | |
| 11:18 | uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek) | |
| 11:21 | uXus has joined IRC (uXus!~uXus@217.77.222.72) | |
| 11:34 | Faith has joined IRC (Faith!~paty@unaffiliated/faith) | |
| 11:38 | work_alkisg has left IRC (work_alkisg!~alkisg@srv1-dide.ioa.sch.gr, Quit: Leaving.) | |
| 12:18 | adrianorg has left IRC (adrianorg!~adrianorg@189.114.156.121, Ping timeout: 250 seconds) | |
| 12:20 | adrianorg has joined IRC (adrianorg!~adrianorg@177.156.224.158) | |
| 12:26 | work_alkisg has joined IRC (work_alkisg!~alkisg@srv1-dide.ioa.sch.gr) | |
| 12:29 | Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave) | |
| 12:34 | sanctuary has joined IRC (sanctuary!1f4de25d@gateway/web/freenode/ip.31.77.226.93) | |
| 12:37 | sanctuary-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:37 | sanctuary has left IRC (sanctuary!1f4de25d@gateway/web/freenode/ip.31.77.226.93, Client Quit) | |
| 12:38 | sanctuary-it has left IRC (sanctuary-it!~sanctuary@31.77.226.93, Client Quit) | |
| 12:38 | sanctuary-it has joined IRC (sanctuary-it!~sanctuary@31.77.226.93) | |
| 12:38 | sanctuary-it_ has joined IRC (sanctuary-it_!~sanctuary@31.77.226.93) | |
| 12:39 | <sanctuary-it_> hi guys
| |
| 12:43 | sanctuary-it__ has joined IRC (sanctuary-it__!~sanctuary@31.77.226.93) | |
| 12:43 | sanctuary-it_ has left IRC (sanctuary-it_!~sanctuary@31.77.226.93, Read error: Connection reset by peer) | |
| 12:43 | sanctuary-it__ has left IRC (sanctuary-it__!~sanctuary@31.77.226.93, Client Quit) | |
| 12:54 | work_alkisg is now known as alkisg | |
| 13:00 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 13:10 | Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net) | |
| 13:16 | uXus has left IRC (uXus!~uXus@217.77.222.72, Remote host closed the connection) | |
| 13:25 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 13:38 | uXus has joined IRC (uXus!~uXus@217.77.222.72) | |
| 13:56 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 15:11 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 15:17 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 15:18 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 15:19 | danau11 has joined IRC (danau11!~durban@12.197.179.122) | |
| 15:20 | danau11 has left IRC (danau11!~durban@12.197.179.122) | |
| 16:40 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 17:22 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 17:34 | Grembler 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:49 | vmlintu 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:11 | alkisg 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:13 | vagrantc 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:15 | vagrantc 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:49 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 21:14 | Faith has left IRC (Faith!~paty@unaffiliated/faith, Quit: Saindo) | |
| 21:22 | AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-eijtfifgodvmfocu) | |
| 21:28 | vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi, Ping timeout: 265 seconds) | |
| 21:59 | ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat) | |
| 22:36 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 22:38 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 23:05 | dtcrshr has left IRC (dtcrshr!~datacrush@unaffiliated/datacrusher, Quit: Saindo) | |
| 23:22 | dtcrshr has joined IRC (dtcrshr!~datacrush@unaffiliated/datacrusher) | |
| 23:26 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 23:54 | dtcrshr has left IRC (dtcrshr!~datacrush@unaffiliated/datacrusher, Remote host closed the connection) | |