LTSP 5 is in minimal maintenance mode
The new LTSP is hosted at https://ltsp.github.io

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


Channel log from 18 June 2019   (all times are UTC)

02:22ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Ping timeout: 258 seconds)
05:05alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 272 seconds)
05:10kjackal has left IRC (kjackal!~quassel@athedsl-135895.home.otenet.gr, Ping timeout: 272 seconds)
05:12adrianor1 has left IRC (adrianor1!~adrianorg@179.177.212.52.dynamic.adsl.gvt.net.br, Ping timeout: 245 seconds)
05:31ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
05:45adrianorg has joined IRC (adrianorg!~adrianorg@177.18.177.26)
06:37stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166)
07:01alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
07:45kjackal has joined IRC (kjackal!~quassel@2a02:587:311b:3d00:1020:c4a3:e998:75ee)
08:16ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
09:59ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
10:26lee_ has joined IRC (lee_!~lee@loathe.ms)
10:34ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
10:34ogra has joined IRC (ogra!~ogra_@ubuntu/member/ogra)
10:54statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
11:11GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net)
11:56Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:08stellasolitaria has left IRC (stellasolitaria!~jhonny5@159.213.93.166, Ping timeout: 248 seconds)
12:14mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
12:39mgariepy 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:55mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
13:16stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166)
13:35kjackal has left IRC (kjackal!~quassel@2a02:587:311b:3d00:1020:c4a3:e998:75ee, Ping timeout: 252 seconds)
13:35kjackal has joined IRC (kjackal!~quassel@athedsl-135895.home.otenet.gr)
13:55ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
13:58GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 246 seconds)
14:24GodFather has joined IRC (GodFather!~rcc@2600:1007:b114:e55f:25e0:f6df:490f:3642)
14:47GodFather has left IRC (GodFather!~rcc@2600:1007:b114:e55f:25e0:f6df:490f:3642, Ping timeout: 252 seconds)
15:03Sleaker 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:12Sleaker has joined IRC (Sleaker!quasselcor@2604:880:a:7::e1b)
15:21vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
15:38Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Read error: Connection reset by peer)
15:39Faith has joined IRC (Faith!~Paty_@2001:12d0:2080::231:49)
15:39Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
15:42ZAJDAN has left IRC (ZAJDAN!~zdenek@77.48.149.75, Quit: Konversation terminated!)
15:43ZAJDAN has joined IRC (ZAJDAN!~zdenek@77.48.149.75)
15:44
<||cw>
just saw ubuntu is considering going x64 only for 20.04
15:55GodFather 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:04GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 248 seconds)
16:10stellasolitaria 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:54mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 248 seconds)
16:54zerkalo has joined IRC (zerkalo!myricae@ny1.hashbang.sh)
16:55mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
17:29inaki 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:38inaki has left IRC (inaki!5282c6ee@gateway/web/freenode/ip.82.130.198.238, Ping timeout: 256 seconds)
18:51statler 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:19kjackal has left IRC (kjackal!~quassel@athedsl-135895.home.otenet.gr, Ping timeout: 244 seconds)
19:40kjackal has joined IRC (kjackal!~quassel@2a02:587:311b:3d00:1020:c4a3:e998:75ee)
20:27kjackal has left IRC (kjackal!~quassel@2a02:587:311b:3d00:1020:c4a3:e998:75ee, Ping timeout: 258 seconds)
20:36mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Ping timeout: 245 seconds)
20:50ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:01Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
21:12ricotz 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:18ricotz 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:54ina 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:39vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)