mwalters has joined IRC (mwalters!~ubox@c-73-152-61-86.hsd1.va.comcast.net)

18:29

<mwalters>

whoops, home server lost connection

18:29

I'm not doing ldap, trying to avoid it

18:31

Last time I tried ldap w/ linux was like 2009... we had a factory in Israel, and we needed to stand up a RHEL server to put our financial software on because of local laws... connected samba to active directory... it was a mess D:

18:31

I was the only person in the entire company with any real linux experience, so I got stuck with it :D

or probably more accurately, the date the user logged into the fat client

18:48

<alkisg>

mwalters: how are you planning to do this/

18:48

You can allow the users to change password graphically, with remoteapps

18:49

<mwalters>

so, I have age checking working w/ a bash script right now

18:49

ltsp-remoteapps mate-terminal -- /my/script.sh

18:50

the script uses passwd -S to check age, if the age is greater than some specified value... call passwd

18:50

at least that's what I have roughed out right now

18:51

<alkisg>

mate-about-me allows the users to change the password graphically

18:51

<mwalters>

sprinkle in some user friendly echo messages and things, use read -s to get old/new passwd

18:51

are ideas

18:51

<alkisg>

You can do the check with a remoteapps script that calls that, to avoid showing a terminal to the users

18:51

<mwalters>

I need to "force" them to complete the process

18:51

<alkisg>

Terminals can be scary to new linux users...

18:51

<mwalters>

as part of our agency policies

18:51

no doubt

18:51

communication will be key

18:51

<alkisg>

You can pop graphical programs as many times as you like, until they do change the password

18:52

<mwalters>

lol

18:52

<alkisg>

And even show zenity dialogs, if needed

18:52

<mwalters>

yeah, I have a few scripts that use zenity already, I'm just kinda proof of concepting as well

18:52

we also have 4 different LTSP boxes... ideally I want the password to be synced between all of them

18:52

<alkisg>

Btw, all that because ldm doesn't allow to change aged passwords?

18:52

<mwalters>

basically

18:53

<alkisg>

Eh, it'd be much more convenient to fix that then

18:53

<mwalters>

Probably :)

18:53

On my end, this is driven by licensing requirements/federal law

18:54

we need to put forth at least a basic effort

18:54

due to the nature of what we do

18:54

(I'm assuming you have various privacy laws in Greece/EU regarding student privacy... similar to that)

18:55

<alkisg>

I mean, if you enforced "passwords are aged after 1 month" normally on the server, and solved the "update password at login" issue, shouldn't it be the best solution?

18:55

<mwalters>

yes, it would

18:55

However, I know nothing about ldm... and can muddle through some bash scripts ;)

18:56

<alkisg>

ok

18:56

<mwalters>

to be honest, my development experience is in webapps and things like that

18:57

(and bash scripting to support deployment/automation of that type of stuff)

18:58

so, what I'm saying is... I can get this running "good enough", nowish... versus putting an unknown quantity of time and effort into getting LDM to do what I want ;)

18:59

even in the case of LDM honoring password aging and supporting changes... I'd still need to develop the scripts to update the shadow hashes across 4 servers

19:00

<alkisg>

But you wouldn't need that if you used ldap, right?

19:00

Is ldap really that hard? I was wondering if it could be the "secure default" for the next ltsp...

19:00

<mwalters>

yes, but I'm a department of one... it's upfront cost, vs maintenance

19:00

another server, another OS, another thing to keep updated

19:00

<alkisg>

Like `ltsp-config ldap` and it would configure everything in a sensible way

19:01

<mwalters>

replace server with vm/container/whatever

19:01

<vagrantc>

we've done a lot to try and avoid ldap ... maybe we should explore what it takes to use it :)

19:01

<mwalters>

lol

19:02

A lot of it is not wanting YAVM ;)

19:02

<vagrantc>

well, many people have explored it ... but it's been a while

19:02

<mwalters>

or YAC

19:02

<alkisg>

(while the unsecure default could be nfsv3+copying passwd/shadow to the clients; only after reaaaly notifying the sysadmin about the security implications)

19:02

<vagrantc>

and many horror stories...

19:02

<mwalters>

I don't use NSF

19:02

eer nfs

19:03

<alkisg>

It's just that the ssh/sshfs thing is ltsp specific, it's not widely used

19:04

while things like "oh password aging doesn't work with lightdm" as solved rather fast

19:04

<mwalters>

sure... I mean... ldap is probably the "right" solution for my problem when it comes right down to it... I'm struggling with scale... standing up a whole new service for 4 other servers just seems silly to me

19:04

<alkisg>

*with lightdm and ldap

19:04

<mwalters>

if I had 10 ltsp servers, I'd probably be doing it

19:04

but honestly, we'll be down to 3 in the next year I think

19:12

<alkisg>

vagrantc: do you think we could rename the old source package to ltsp5, and keep it around for a few years, while the new source package that would be named ltsp, would only produce one binary package named ltsp, which would conflict with ltsp-client-core, ltsp-server, ltspfs, ldm etc etc?

19:13

So that people could still use ltsp5 for a few years, until the newer ltsp gets all the bells and whistles needed for production

19:14

<vagrantc>

conceptually possible, devil in the details :)

19:14

<alkisg>

Hehe, always :D

19:15

<vagrantc>

should only need to conflict with ltsp-client-core and ltsp-server

19:15

though maybe we'd want it to block other things ...

19:15

having ldm and ltspfs installed should be harmless, hopefully

19:16

since they don't enable any services by default...

19:16

<alkisg>

Possibly, but why not get rid of them anyway...

19:16

E.g. in the initial release we might say "it defaults to nfs3 and passwd/shadow copying which very insecure; use nfsv4/kerberos/ldap for proper security"; but that would be hard for our users, until ltsp-config is able to automatically configure all these

19:16

<vagrantc>

ugh.

19:16

not real fond of this copyring around shadow.

19:17

nfs3 for homedirs?

19:17

<alkisg>

Indeed; but if we're going for proper pam, it might be the quick workaround until that proper pam thing is implemented

19:18

Or, we could keep it in experimental for some time, until those things are implemented

19:18

I was reading a bit about nis; it's not much safer than just copying shadow

19:19

<vagrantc>

yeah, no reason to try nis

19:19

<alkisg>

So of the existing pam modules, I think ldap would work; but of course we wouldn't have sshfs then; so... nfsv4; and to protect that => kerberos

19:20

So it's getting complicated, and it needs a lot of experience in that field to define good defaults for ltsp-config

19:20

<vagrantc>

right

19:20

although we should still be able to do sshfs with ldap ?

19:20

<mwalters>

getting freeipa to work correctly and fully is... odd... I have mucked about with openldap in a while, though

19:21

(work correctly and fully on ubuntu)

19:21

(haven't mucked about with openldap)

19:21

<alkisg>

vagrantc: we'd need a pam hook to get the ldap password and then do an ssh connection, to be able to have the sshfs home

19:21

<vagrantc>

i seem to recall using samba's ldap implementation a few years back, but i wasn't the primary person working on it

19:21

<mwalters>

generally ldap won't disclose the password, only if the authentication request succeeded

19:22

<vagrantc>

hence libpam-sshauth ... but that's got it's own complications...

19:22

<mwalters>

e.g., client makes a request to the server, the server turns it around and asks the ldap server to verify the request

19:22

<alkisg>

sshfs by itself has a lot of issues (e.g. no ~/.dmrc); libpam-sshauth has a lot more

19:22

mwalters: one can get the password that the user typed to the DM, from a pam hook, without involving ldap

19:23

<vagrantc>

i didn't even think ~/.dmrc was used anymore, or certainly not consistantly

19:23

<alkisg>

vagrantc: there's also /var/lib/accountservice etc; but we don't have those dirs on the clients either; while ldap supposedly has solutions for such things