IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 18 June 2019 (all times are UTC)
| 02:22 | ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Ping timeout: 258 seconds) | |
| 05:05 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 272 seconds) | |
| 05:10 | kjackal has left IRC (kjackal!~quassel@athedsl-135895.home.otenet.gr, Ping timeout: 272 seconds) | |
| 05:12 | adrianor1 has left IRC (adrianor1!~adrianorg@179.177.212.52.dynamic.adsl.gvt.net.br, Ping timeout: 245 seconds) | |
| 05:31 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 05:45 | adrianorg has joined IRC (adrianorg!~adrianorg@177.18.177.26) | |
| 06:37 | stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166) | |
| 07:01 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 07:45 | kjackal has joined IRC (kjackal!~quassel@2a02:587:311b:3d00:1020:c4a3:e998:75ee) | |
| 08:16 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 09:59 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 10:26 | lee_ has joined IRC (lee_!~lee@loathe.ms) | |
| 10:34 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 10:34 | ogra has joined IRC (ogra!~ogra_@ubuntu/member/ogra) | |
| 10:54 | statler has joined IRC (statler!~Georg@gwrz.lohn24.de) | |
| 11:11 | GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net) | |
| 11:56 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:08 | stellasolitaria has left IRC (stellasolitaria!~jhonny5@159.213.93.166, Ping timeout: 248 seconds) | |
| 12:14 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 12:39 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 245 seconds) | |
| 12:39 | ||cw has left IRC (||cw!~chrisw@unaffiliated/cw/x-1182934, Ping timeout: 245 seconds) | |
| 12:44 | ||cw has joined IRC (||cw!~chrisw@97-87-137-194.dhcp.stls.mo.charter.com) | |
| 12:55 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 13:16 | stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166) | |
| 13:35 | kjackal has left IRC (kjackal!~quassel@2a02:587:311b:3d00:1020:c4a3:e998:75ee, Ping timeout: 252 seconds) | |
| 13:35 | kjackal has joined IRC (kjackal!~quassel@athedsl-135895.home.otenet.gr) | |
| 13:55 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 13:58 | GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 246 seconds) | |
| 14:24 | GodFather has joined IRC (GodFather!~rcc@2600:1007:b114:e55f:25e0:f6df:490f:3642) | |
| 14:47 | GodFather has left IRC (GodFather!~rcc@2600:1007:b114:e55f:25e0:f6df:490f:3642, Ping timeout: 252 seconds) | |
| 15:03 | Sleaker has left IRC (Sleaker!quasselcor@2604:880:a:7::e1b, Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) | |
| 15:07 | ||cw has left IRC (||cw!~chrisw@97-87-137-194.dhcp.stls.mo.charter.com, Changing host) | |
| 15:07 | ||cw has joined IRC (||cw!~chrisw@unaffiliated/cw/x-1182934) | |
| 15:12 | Sleaker has joined IRC (Sleaker!quasselcor@2604:880:a:7::e1b) | |
| 15:21 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 15:38 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Read error: Connection reset by peer) | |
| 15:39 | Faith has joined IRC (Faith!~Paty_@2001:12d0:2080::231:49) | |
| 15:39 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 15:42 | ZAJDAN has left IRC (ZAJDAN!~zdenek@77.48.149.75, Quit: Konversation terminated!) | |
| 15:43 | ZAJDAN has joined IRC (ZAJDAN!~zdenek@77.48.149.75) | |
| 15:44 | <||cw> just saw ubuntu is considering going x64 only for 20.04
| |
| 15:55 | GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net) | |
| 15:55 | <alkisg> ||cw: you mean the archive too, or just the .isos?
| |
| 15:56 | Btw where did you see that?
| |
| 15:58 | <||cw> https://lists.ubuntu.com/archives/ubuntu-announce/2019-June/000245.html
| |
| 15:58 | ISOs, including "we will not provide 32-bit builds of new upstream versions of libraries"
| |
| 16:00 | <alkisg> Hrm, ok, I guess I can ship a debian VM for schools that need a "32 bit chroot"
| |
| 16:04 | GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 248 seconds) | |
| 16:10 | stellasolitaria has left IRC (stellasolitaria!~jhonny5@159.213.93.166, Ping timeout: 245 seconds) | |
| 16:18 | <alkisg> vagrantc: there are no services around similar to Ubuntu PPAs that would do 32bit builds for Debian, right? What about https://build.opensuse.org/, does that build .deb packages?
| |
| 16:47 | <vagrantc> alkisg: i think you can use open build service to build .deb packages; haven't tried it myself
| |
| 16:48 | <alkisg> Ah not repositories, just debs...
| |
| 16:49 | <vagrantc> maybe full repositories too, don't know
| |
| 16:54 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 248 seconds) | |
| 16:54 | zerkalo has joined IRC (zerkalo!myricae@ny1.hashbang.sh) | |
| 16:55 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 17:29 | inaki has joined IRC (inaki!5282c6ee@gateway/web/freenode/ip.82.130.198.238) | |
| 17:30 | <inaki> how to connect wacom stu-530 sign tablet to client?
| |
| 17:30 | <quinox> I would use the wire provided with it
| |
| 17:32 | <vagrantc> inaki: what have you tried so far?
| |
| 17:40 | <inaki> i have connected to usb on the client and it's ok, lsusb show wacom driver on the terminal , but xsession doesn't show and lsusb shows server devices
| |
| 17:41 | <vagrantc> sounds like you're running on a thin client ... any reason not to use an LTSP fat client?
| |
| 17:42 | <inaki> pc's is too old
| |
| 17:53 | <vagrantc> inaki: so ... what's not working? if you're running a thin client, the user interface is effectively running on the server, so that's working as expected
| |
| 17:53 | not familiar with the specific hardware you're talking about, so you're going to have to get more verbose about what isn't working
| |
| 17:59 | <inaki> thanks, I'm going to try some configurations ...
| |
| 18:05 | <alkisg> inaki: ltsp doesn't support usb forwarding; only file system forwarding
| |
| 18:06 | You'd need usbip to use that like you imagine
| |
| 18:06 | In general, thin clients are going away though...
| |
| 18:07 | https://developer.ridgerun.com/wiki/index.php?title=How_to_setup_and_use_USB/IP
| |
| 18:08 | * alkisg wonders if that would work better than jetpipe for printers... | |
| 18:38 | inaki has left IRC (inaki!5282c6ee@gateway/web/freenode/ip.82.130.198.238, Ping timeout: 256 seconds) | |
| 18:51 | statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection) | |
| 19:17 | <fiesh> we used to use usbip for a while
| |
| 19:17 | can't say it worked super rock solidly though...
| |
| 19:17 | but it wasn't awful either
| |
| 19:19 | kjackal has left IRC (kjackal!~quassel@athedsl-135895.home.otenet.gr, Ping timeout: 244 seconds) | |
| 19:40 | kjackal has joined IRC (kjackal!~quassel@2a02:587:311b:3d00:1020:c4a3:e998:75ee) | |
| 20:27 | kjackal has left IRC (kjackal!~quassel@2a02:587:311b:3d00:1020:c4a3:e998:75ee, Ping timeout: 258 seconds) | |
| 20:36 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 245 seconds) | |
| 20:50 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:01 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 21:12 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 21:14 | <vagrantc> alkisg: haven't looked at it recently, but libnss-extrausers seems to handle a lot of what we want here...
| |
| 21:14 | not sure if it has major drawbacks
| |
| 21:18 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:18 | <vagrantc> libnss-systemd also sounds interesting...
| |
| 21:19 | <alkisg> vagrantc: it's not preinstalled in some live cds, so it would limit our use cases; and we don't need it anyway as I finished with pwmerge
| |
| 21:20 | * alkisg checks libnss-systemd... | |
| 21:21 | <alkisg> also, libnss-extrausers wouldn't authenticate against ssh; so we'd have to write the code anyway to look up the users elsewhere etc
| |
| 21:22 | Btw I thought I'd rename the scripts to pamltsp, for authentication, and pwmerge, for the python merge tool
| |
| 21:22 | <vagrantc> ah, yeah, ssh authentication...
| |
| 21:23 | <alkisg> Heh, this looks rather interesting: https://www.freedesktop.org/software/systemd/man/sysusers.d.html#
| |
| 21:23 | Let's hope systemd spreads and replaces passwd too! :D
| |
| 21:25 | <vagrantc> hmmm..
| |
| 21:26 | <alkisg> I'm pondering where to store the additional information needed by pamltsp
| |
| 21:27 | E.g. the server or even the special user for synching might go to the pam.d/common-auth line
| |
| 21:27 | And the pamltsp users might get marked with hash=pamssh in shadow
| |
| 21:27 | ...or a separate file may be used instead; which is hard to keep in sync
| |
| 21:31 | I think maybe I should also put a common-account pam_exec line, that would disable passwd changing for pamltsp users
| |
| 21:31 | *local passwd changing
| |
| 21:33 | I thought about creating a special pamltsp group, and the members of that group would be the ones to authenticate remotely, but I'm worried that it might not work for too many users
| |
| 21:33 | (due to other libraries limitations)
| |
| 21:33 | And since the shadow man page states that "invalid hashes mean the user cannot login with password locally" - seem like a valid usage to me
| |
| 21:36 | <vagrantc> well, it doesn't say "arbitrary stuff can be stuffed in there and used" either ... but yeah.
| |
| 21:38 | <alkisg> ... This tagging helps pamltsp know when to try SSH authentication or not, and when to display errors via PAM. For example, with a "roaming laptop",
| |
| 21:38 | a teacher at home shouldn't try to authenticate against the school SSH server, while a student at school should see appropriate messages like "server: connection refused".
| |
| 21:39 | I think it's best to tag the users; between (1) a pamltsp group, (2) the shadow hash, or (3) a separate file that we can't really sync if local changes occur, you'd go for 3?
| |
| 21:39 | We do need to invalidate the hash anyway, for pam_unix to fail before us
| |
| 21:39 | <vagrantc> what were your concerns about the pamltsp group?
| |
| 21:42 | does it basically check for the user being in group "pamltsp" and only try ssh authentication if so?
| |
| 21:42 | <alkisg> Yes
| |
| 21:42 | Well, suppose one has 1000 or 10000 users, how long that line will be?
| |
| 21:42 | Redhat says it's split into multiple lines after some line length
| |
| 21:42 | With the group gid being repeated
| |
| 21:43 | I'm not sure if all the libraries involved can handle that
| |
| 21:43 | <vagrantc> interesting
| |
| 21:43 | <alkisg> While I'm pretty sure they'd properly handle invalid hashes
| |
| 21:43 | And it's the part that we do want to write to anyway, as we're in charge of invalidating the local hash
| |
| 21:43 | <vagrantc> and the separate file would simply be a dump of pam-sshable usernames?
| |
| 21:43 | <alkisg> Right
| |
| 21:43 | Maybe with some additional things if we want to, like the server
| |
| 21:45 | <vagrantc> i see why you're leaning towards using the invalidated shadow hash ... but i still get nervous about designing an interface around the inverse of the intended purpose of the field
| |
| 21:46 | while it should be fine to stuff anything in there, relying on specific things getting stuffed in there has risks
| |
| 21:46 | <alkisg> "x" means "look up in shadow". "!" means "locked password". "invalid hash" means "cannot login"
| |
| 21:46 | It's already having multiple usages there, by design
| |
| 21:46 | <vagrantc> yes, and those are three defined behaviors ... but you're appending an arbitrary number of use-cases into the "invalid hash" part
| |
| 21:47 | <alkisg> It's just "pamltsp invalid hash"; and I'm the only one that looks up the word "pamltsp"; I don't see any clashes with the definition
| |
| 21:47 | <vagrantc> the purpose of the "invalid hash" is to prevent authentication, not as an arbitrary data store
| |
| 21:48 | <alkisg> I'm not storing any data except for a single bit; that we're the ones that are in charge of this field
| |
| 21:48 | If someone e.g. does `sudo passwd user`, he's no longer a pamltsp user
| |
| 21:48 | <vagrantc> you're storing something above and beyond "this is an invalid password"
| |
| 21:48 | <alkisg> Right. "this is OUR invalid password"
| |
| 21:49 | <vagrantc> yes, i get that
| |
| 21:49 | <alkisg> So you prefer the separate file better?
| |
| 21:49 | Or the group thing; and check if the limitations are good enough for most cases nowadays?
| |
| 21:50 | <vagrantc> i guess so ... the group idea sounded less hackish to me, but if it won't scale at all ...
| |
| 21:50 | a separate file allows for arbitrary flexibility in the future ... at a cost of maintaining that.
| |
| 21:51 | <alkisg> So if the sysadmin removes a pamltsp user, and adds a local user, then we'll still continue to authenticate him as a pamltsp user
| |
| 21:51 | The problem isn't our part of maintaining it; it's that it doesn't integrate with accounts anymore
| |
| 21:51 | It's a separate entity that we cannot possibly sync
| |
| 21:51 | and adds a local user ==> with the same name
| |
| 21:52 | <vagrantc> shouldn't it remove the user from the group then?
| |
| 21:52 | <alkisg> "oh I don't want user alkisg to be pamltsp anymore, I want him local; I'll delete and recreate him; oh wth why he's still logging in with ssh..."
| |
| 21:52 | I thought we were talking about the separate file?
| |
| 21:52 | <vagrantc> ok
| |
| 21:53 | ok, i see what you're saying with the separate file ...
| |
| 21:53 | <alkisg> When the sysadmin goes to gnome-users and plays with users, he doesn't update our separate file
| |
| 21:53 | <vagrantc> all of the sudden we'll need to maintain frontends to user management tools, which ... we don't want.
| |
| 21:53 | yup, that seems undesirable.
| |
| 21:54 | ina has joined IRC (ina!53d54098@gateway/web/freenode/ip.83.213.64.152) | |
| 21:57 | <alkisg> vagrantc: well, if you feel better, we may store the encrypted value of "pamltsp" there :)
| |
| 21:57 | <vagrantc> alkisg: are there any other pam modules in the wild using the "invalid hash" field to store specific content?
| |
| 21:57 | <alkisg> And mark it as disabled
| |
| 21:57 | Dunno
| |
| 21:58 | <vagrantc> alkisg: huh. using the disabled password to behave differently ... at first pass, that sounds ugly, but maybe a little less crazy.
| |
| 21:59 | it's obviously not human-readable ... so hrm.
| |
| 21:59 | <alkisg> I think that's a lot more problematic though; e.g. maybe DMs will not even show the user
| |
| 21:59 | <vagrantc> it's still a big hack :)
| |
| 22:00 | <alkisg> About playing with the fields, when libc needed to add the salt, it introduced the $ in that field
| |
| 22:00 | To separate method/salt/pass
| |
| 22:00 | We're not glibc, but we do need something similar
| |
| 22:00 | <vagrantc> yeah, you might be on to the best way ... though i still feel like the group thing is not relying on any embedded easter-egg like features
| |
| 22:01 | if it's unrealistic scale-wise, hrm.
| |
| 22:01 | <alkisg> I have up to 300 users; I'm ok with that; but I'm fearing that it'll have issues in bigger installations
| |
| 22:02 | * vagrantc wonders what the practical limit for passwd/group numbers are | |
| 22:02 | <vagrantc> most large installations i would imagine use ldap or some other database backend
| |
| 22:02 | <alkisg> What does ldap do? It tries to authenticate for all users?
| |
| 22:03 | Or it uses different id space, with big id numbers?
| |
| 22:04 | We may also just do this: "if it's a non-system user with an invalid hash, try to authenticate him against the server",
| |
| 22:04 | so instead of "pamltsp" in the hash, we'd use the standard "*" or "!",
| |
| 22:04 | <vagrantc> that's certainly the simplest approach
| |
| 22:04 | <alkisg> at the expense of trying even for users that are actually not meant to login
| |
| 22:04 | <vagrantc> the downside being local users would get timeouts on invalid passwords and such
| |
| 22:05 | <alkisg> Which I find disturbing
| |
| 22:06 | <vagrantc> how about the inverse ... a group of users who do not log in via pamssh?
| |
| 22:06 | <alkisg> It has the same limits
| |
| 22:07 | <vagrantc> but are you going to have a handful of users log in with pamssh and thousands of thousands of users log in locally?
| |
| 22:07 | it seems like the remote login users are likely to be the bulk of them ...
| |
| 22:07 | <alkisg> I don't know; they might just want to give pamltsp a shot, before migrating to ssh auth
| |
| 22:07 | <vagrantc> could also have it support any of the above methods ...
| |
| 22:08 | <alkisg> In that case, they'd only switch a handful of users
| |
| 22:08 | No, I want the "keep it simple" approach in ltsp19
| |
| 22:08 | <vagrantc> sure
| |
| 22:08 | <alkisg> No more overengineering, it make code rot
| |
| 22:09 | <vagrantc> right, this is the default method; if they want something else, they can use LDAP or whatever
| |
| 22:09 | <alkisg> Ah of course
| |
| 22:09 | We won't force things
| |
| 22:09 | I was also thinking if we wanted to propose a homedir seperation to nfs3 users
| |
| 22:09 | <vagrantc> default *simple* method :)
| |
| 22:10 | <alkisg> E.g. /home for normal users, and /nfshome or /home/nfshome for the others,
| |
| 22:10 | so e.g. the teachers homes would be more safe, while the student ones that would use nfs/sshauth, ...unsafe but noone cares about what they draw or write there :P
| |
| 22:11 | <vagrantc> alkisg: you obviously haven't worked in schools in lawsuit-happy countries
| |
| 22:11 | <alkisg> I did a quick poll, all the teachers said "nfs; we don't care about security, we want it to be stable and fast"
| |
| 22:12 | If they have enough money for laysuits, they won't use ltsp :D
| |
| 22:12 | <vagrantc> people only ever care about security after the fact
| |
| 22:12 | <alkisg> I'm not talking about the default; it'll be sshfs anyway,
| |
| 22:12 | <vagrantc> sure
| |
| 22:12 | <alkisg> which we know has problems like stability and speed and lots of server cpu etc
| |
| 22:13 | so many users will opt for nfs3
| |
| 22:13 | So proposing homedir separation protects them a bit
| |
| 22:13 | Dunno if it's worth the trouble, or if we should just tell them "you opted for no security; live with that"
| |
| 22:14 | <vagrantc> gets back to the keeping it simple angle
| |
| 22:14 | <alkisg> Unfortunately /etc/exports can't express "export /home but not /home/administrator"
| |
| 22:14 | Yeah; I can't think of a simple enough way to manage two different home dirs
| |
| 22:15 | <vagrantc> well, you keep the "secure" accounts in a different homedir ... i.e. /secure/home/administratorN
| |
| 22:15 | <alkisg> Yes that's what I was proposing, but it's hard to do this without being familiar with cmdline
| |
| 22:16 | Or one would need to edit addusers.conf, add the unsafe users, then edit it again, add the safe users... etc
| |
| 22:16 | <vagrantc> i was just talking about how to resolve that with /etc/exports
| |
| 22:17 | how to actually configure other homedirs for the user-management frontends is another story
| |
| 22:17 | <alkisg> Yes, it's the reason I proposed it, because /etc/exports doesn't support anything else
| |
| 22:17 | But... on the plus side, if we actually proposed that... we could separate the remote users by that additional path
| |
| 22:18 | So, if the user home matches some specific path => he's a pamltsp user
| |
| 22:19 | /home => local user, /home/nfs => remote user, mounted via nfs, authenticated via ssh, /home/sshfs => remote user, authenticated/mounted via sshfs
| |
| 22:19 | I didn't like it much, but it was an idea
| |
| 22:20 | <vagrantc> it has it's appeal ... but also it's warts
| |
| 22:20 | <alkisg> The worst part is if one user is moved from local to remote, the stored paths break in gsettings and elsewhere
| |
| 22:21 | <vagrantc> yeah.
| |
| 22:21 | <alkisg> Anyways... sleep time
| |
| 22:21 | Bye vagrant!
| |
| 22:21 | * vagrantc waves | |
| 23:39 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |