Quote:
You'd have to recompile half the distro and you'd break the other half in the process. |
It doesn't matter to me either way, I have pam, cracklib and krb5 installed only to fulfill dependency requirements for Cinnamon DE so it would just mean 3 less things that I have to build. I have nothing different to do as far as logging in nor have I had any other issues, but again I am only fulfilling dependency requirements.
Can someone show where recently things have been broken or issues have arisen from having pam/krb5? I don't want to hear about 10yo problems. I am not trying to infuriate anyone, I just want to know/see some real world issues. |
Quote:
|
I do have to admit that it's probably time to stop fighting this one, though. A simple, Patrick Volkerding style PAM configuration probably won't be so bad anyway. I can work with it, I just don't prefer it.
I'm also of a mind that fewer dependencies are better, especially on a packaging system that doesn't do dependency tracking (also an endearing feature of Slackware for me). |
Quote:
Quote:
Quote:
|
Quote:
|
Quote:
Code:
root:::::::: I guess also, if single user mode is configured to log in with no password, it would also be a non issue. |
Quote:
|
Quote:
Cheers, Niki |
Yes, that's what you'd have to do. Boot up with install media, manually chroot (not boot with e.g. "root=/dev/sd?? noinitrd" as then that would use the system's login) and run passwd.
My method would not work with PAM policies in place, you'd have to edit that configuration too. It was just an example off the top of my head. I'm generally in favour of keeping things as simple as possible. Let's say something happened to delete those files, it's pretty easy to recreate /etc/passwd and shadow based on distro default files, with blank hashes then use passwd to fix user logins. But whatever, I'll manage with whatever Slackware does with this. |
Quote:
|
Basically, but also someone that might run afoul of PAM policies that isn't used to them. Again, we don't know how it's going to be configured yet so we don't know, but for another example PAM policies prevent users starting X as root on some distros. PAM policies can prevent things like blank or weak passwords too.
|
I've used PAM based systems for many years. I seldom pay much mind other than to disable a module here and there, such as motd. In a PAM based system /etc/shadow is still used. Recovering a PAM based system is no different than recovering a Slackware.
PAM in Slackware will be a nice step toward acceptance in the enterprise. Some home users might not care but many users will. Besides, this is Pat's distro. He'll do as he pleases. We're simply along for the ride. ;) |
Quote:
With your posts, I think you've cemented the fact that Pat should be able to include PAM with the changes likely going unnoticed by anyone not reading the changelog. Yes, if someone manages to enable some of the modules or jacks up their login info, it might be a slightly different process to fix it, but how rarely do people screw up their ability to log in? I don't know if I've ever done it in my 15+ years of using Linux (and I was a huge n00b when I first started), but it's probably happened at least a few times. But considering the potential fix might be easier than when people forget to run lilo (since they'll have to bind mount several directories), it seems like the fix is still relatively simple. |
Well, my main point is simply that this is not a change to be taken lightly (and I do trust that it isn't being taken lightly). It's a major change to Slackware. Sure, I have to agree that people that don't change anything probably won't notice if there are no policies that change existing system behaviour.
Dinosaur, here :hattip: I am sorry if some of my discussion posts are inappropriate in their respective threads. I just realized I've been doing that here. This thread was started by people who are enquiring about the change, and are eager to test it. |
All times are GMT -5. The time now is 04:29 PM. |