This should actually be a good exercise for learners like me. It's rainy season here, no outings for next month or so, so I think I can grok some basics of it. *thumbs up*

Regards.

thinking about it for 5min actually yes, in a way

i would have on my computer a list consisting of computer names paired with a root/admin password that was generated by /dev/random
when someone wanted to change their password they would have to contact me and i would start a script that would ssh into every one of those computers and change it

that way there would be no logical inconsistencies and as a bonus other things like upgrading software could be automatized yet secure
and no dependencies on a central authority that could go bonkers

ofc i would make it so it reports unexpected behavior that would require hands on investigating
and the admin passwords would be changed every month or two (time would be calculated by how long it takes for a big data center to crack a shadow file)

from what i know, and that is not much, PAM is required in the enterprise for window server things

they usually call all together when you're on holiday lying on a beach...

1 members found this post helpful.

She's causing a lot of trouble, this PAM. Wouldn't be surprised if she was related to Harry Potter...no, Lenny Potter...Poetter...whateverhisnameis.

1 members found this post helpful.

Homespun Heath Robinson solutions like that are all well and good until a random set of 300 of your 5000 hosts are either down or uncontactable at the point in time when you want to do the change. Then you're left with a "this random set of changes still need doing" problem to manage. When you get a bunch of these incomplete changes build up, each with their own random set of hosts, it gets messy keeping track of it all.

While there are products out there to allow you to robustly manage change deployment over a wide installation base (and to be honest its not that hard to write one yourself - I've never understood why people spend thousands of pounds licensing them from the likes of IBM), user authentication is probably best left to centralised systems such as NIS, kerberos, LDAP etc that were created specifically to address the issues at hand.

Beatrix?

There's really only one question:
Is there sufficient need/demand from slackware users to warrant inclusion of PAM in stock Slackware? There is clearly some, but probably not that much. Whether there is "sufficient" is a question for Pat and the Slackware team. The rest of this thread is just noise(*).


(*) WTH happened to this forum?

2 members found this post helpful.

Another one? Triplets? PAM, su, and Beatrix? "Bob" help us!

Seems to depend on what the users are using Slackware for. For me, it's a hobby, I'm sole user of my computers, so I don't believe I need it or that I'd find it useful. But if some users need it, OK. Maybe stick it in /extra? I'll let our BDFL decide.

You made my day ))))

sure, you could idk ping them every 5min or something

thinking another 5min on this, a theoretical situation

lets say workstation A can ping B but can not contact the auth server while B can
changing a password would work on B so A <-> B communicating would break

in the case of PAM it would not work either since they bout need to contact the central authority (when connecting i guess)

but in the case of normal use with the password staying the same A could contact B since it does not have to contact a server that might be across the world

and ye, from what i know it wouldn't be so hard to write your own protocol using just some encryption library and sockets

So, they would have to tell you their password, so that you could ssh into all the computers and change it...
Yes, I see that is way better and more secure.
I think you need more than 5min to think of a better solution to this problem

Sure, let's replace that dependency with you.
Humans are way more reliable and error free than computers anyway.
Congrats, you are now the single point of failure. I hope you will be all right, for the company's sake.

Since the passwords will have to be communicated to you in clear text, the time to crack would be reduced to 0.000000000001 seconds.

You urgently need to up your google skills and read more.

Most of this I completely agree with. But I have a few counterpoints.

1) Having a large number of computers that all need to be accessed with the same accounts is probably not the way that most people use slack. So for the most common use case, PAM is simply adding a superfluous abstraction level on top of the unix login system that is actually to be used. Cutting corners for convenience like that can make perfect sense in an application but not for a critical system component everything else is relying on, where an exploit OR a bug could have catastrophic implications.

2) For the case where you DO have need for a central auth scheme, my instinct would be to pick ONE and install it in the simplest and most robust configuration possible, not to add multiple systems and a whole new abstraction layer to access them through.

I think your link is borken.

wow
how about you take more then 10sec of thinking before being smart

like that that it is just a protocol
that could be done in a small binary
that could send a line like "pswdchng: username oldpass newpass newpass"
a line that would be encrypted ofc
and so on and so forth
but first you would have to use a brain to understand theory from practice

in no post on this topic have i claimed to know it all, even less to know it perfectly
so what is the cause of this looking down on a thought ?

to be a smartypants, a question; how would some one read that hypothetical clear text that was sent to me ?

Well, if Slackware were to be used in enterprise I'd assume the number of users would go up a fair bit.
So, it would probably be the way most people would use slack
But, for the present, I concede that you are correct: slackware is mostly used by hobbyists that don't need a central authentication service.
I just think that "it has always been this way" is not a valid argument for not making changes.

Do you propose that we stop using databases for critical stuff?
Are you saying that the whole server/client architecture is flawed, or just in this one use case?

I would also pick one and go with simplest and most robust.
The problem is that the best one today may not be the best one tomorrow...
Should we keep changing core packages to add support for the next_best_auth_scheme_NG every few years?
You will find that this abstraction layer is not so superfluous if you plan for further than tomorrow.

Did you try clicking on it?

http://englanders.us/~jason/howtos.php?howto=openldap appears to have written step-by-step documentation on centralized authentication using LDAP. I'm trying it on a couple of test machines.

You're going to have to explain why you think that LDAP requires NFS.

I think Niki cited NFS as an example of per-user storage (for $HOME and/or whatever else) usable by the users on the hosts on which they authenticate with LDAP.