Using Slackware makes me feel like a melomaniac with a rack stuffed with vinyls.
 

Imagine you enjoy your morning coffee listening to your favorite music on the best vinyl player money can buy.
You want to continue listening while driving to work but the only way is to use a CD. And hell no. It wont be the same music.
You would like to listen to your music during your workday like everybody else. God(Bob) forbid.
How all these people could not hear the difference. This bleeding edge mp3 format cuts all the high frequencies I enjoy.
Finally you get back home and you turn on your gramophone. You know every scratch on every of your vinyls and it feels good.

I have a perfect Slackware setup. Everything I need is there.
It is solid. Not a single crash since the last time the hard disk broke several years ago.

But...

I want to use a fingerprint scanner? Oh no it needs PAM and Bob said it was evil.
A smart card then? PAM again.
Could I connect my Slackware laptop to my workplace network. Oh no. It is a nontrivial proprietary AD setup. I have to add some packages, recompile others and meet this evil PAM again.
May be if I try to connect my lappy to Linux only fully open source network it will work. Still no luck. LDAP this time. And this PAM is everywhere. And when the hell NFS moved to v4.

And I heard some rumors the init is going to be replaced. Argh no, only over my dead body.
I know every single line in my init scripts. Every single line of script contains the essence of Unix.
I am not going to give up the control over my system to some bleeding edge crap full of thousands lines of C code.

Cheers.

You should be able to use LDAP without PAM.

Pat had pointed out that it is getting to be a larger security risk to *not* use PAM than to use it, which is a switch from the early days.

Hey, when you get older the high frequency response of your ears gets rather shitty. (Unless it's tinnituses in one of your ears; then it can be the glorious high-pitched whine just like a computer case fan bearing starting to go. 24 hours a day, 7 days a week.) Maybe then you'll grow to like MP3 or FLAC for your music.

When people admit that software is a multi-billion business, then they will see that much is not about pleasing the user but about business strategy.
Systemd is not just a bit of code to replace init.
If people would put as much intelligence into strategic thinking as they do into coding they would realise that.
Failing that they could just listen to Poetering explaining the agenda at FOSS in 2012.
Systemd is the start of a project - hence the intense marketing and continuing development of systemd.
If Slackware implements systemd then Slackware will cease to exist within a decade or so - it will be superfluous.

PAM has always been optional on Slackware. The problem is nobody has been willing to submit a SlackBuild over at SlackBuilds.org that can encompass a multi-target/purpose distribution like Slackware that works out of box without impeding on any functionality.

It would be nice if we had one, but as it's been stated several times, it's an optional aftermarket layer of security that should be setup by a system administrator, not a distribution maintainer due to the complexity of the setup.

If you have one and would like to contribute, contact Robby Workman over at SlackBuilds.org about submitting it, and any other necessities for deployment. You may wish to offer several example setups as well. SlackBuilds.org is basically a sort of community repository for packages.

I don't know how you would do this without replacing several official packages.
Something like PAM isn't a good fit for slackbuilds.org IMO; it merits its own repository/tutorial/documentation elsewhere, from a trusted source.

It's possible, but you'd need to provide the extra documentation on which other packages would require a rebuild, along with edited SlackBuild scripts. You could technically label them like:

LinuxPAM
PAM-shadow
PAM-OpenSSH
PAM-OpenLDAP
etc.

All it requires is a willingness of the person who knows a lot about it.

Not to say I wouldn't use it, but a few people in the Slackware community might find it beneficial, and it still falls back under optional.

It's not we can wish and automagically it poofs into existence.

+1 for the addition of PAM to Slackware. The more so since you already did most of the work, if not all of it. We all know Pat isn't one to easily give in to the vox populi. But when several seasoned sysadmins in this forum - including AlienBob - repeatedly wish PAM was included, then maybe it's time to reconsider.

I wonder if you ever had to maintain servers that use PAM? The "complexity of the setup" is NOT something you want to leave to the system administrator. It should be properly integrated into the OS, by the distribution maintainer, so that it works out of the box and is easy to (re-)configure.
All the campaigns against the use of PAM because of its perceived complexity, dragging examples onto the table about how you can damage your PAM configuration so that the system won't boot anymore, that is mere FUD. I can change ONE character in /etc/inittab and your Slackware won't boot either.

Slackware is a complex Linux distribution which requires a lot of attention to keep it stable and usable, just like any other distro. But from the user perspective, it is easy to administer Slackware. This is not going to change if you add PAM. It's just a few easy to understand configuration files, which should be attractive to any Slacker.

Note that Pat did not keep PAM out of Slackware for its complexity but because its poor security record.
In the last few years, the situation has changed, there are more PAM implementations than just one, and the recent upheaval with openssl and bash shows that even respected software can take a deep dive.

Eric

Internally, we have a full set of PAMification work done already by Vincent Batts. That does not mean it will get implemented, it just means that there is no need to re-invent the wheel.

Eric

-1

Added into /extras maybe, but officially in the main system, no. PAM is something best setup by the system admin, not a distribution maintainer or package builder, in my opinion. There are too many configuration options to put out in a generalized package to cover multiple angles. Having separate SlackBuilds would allow for each package to have it's own special custom PAM configuration as well. PAM would also require it's own sub-packages built for it that would conflict with non-PAM packages, so /extras or SBo would be the best choice, plus not everyone likes PAM nor wants to use it. Nothing should be forced on everyone just to satisfy a small number of people. We've used Slackware without it safely for now, as optional, and leaving it to the system administrator to set up and deploy is the better choice.

I respectfully disagree but that's my POV.

How did you evaluate the "small number" of people ? Do you have a solid poll to reference ?

Well, you can say YOU not WE... I didn't give you my vote so you could embrace myself in your 'we'...

Nice you say that... at the end, you tend to have an imperative pompous way to explain your point of view, that even if I, sometimes, could agree with you, most of the time I'm ashamed the way you do it.. If you were my lawyer I'll fire you to have, a least, a chance to win the case.

Cheers

Garry.

Another possibility would be of course to include PAM, and then leave it up to ReaperX7 to setup a BLFS (Beyond Linux From Slack) project where all the core packages are built without PAM, so everybody's happy.

I often find myself having a perfect state of ambivalence facing Slackware's conservatism. On the one hand, I can only quote something which I've already stated somewhere else. Something I came across in classical philology (one of the subjects I studied). A marketing specialist living and working about 2.000 years ago - say with a nice office here in Nîmes (called "Nemausus" 2000 years ago), on the Voie Domitienne ("Via Domitia") - would have put an "OLD" sticker on every package he wanted to sell. "OLD" meant something like "proven, solid, reliable", whereas a product with a "NEW" sticker on it would have been suspicious to folks. "NEW" meant first of all "has-to-prove-its-worth".

On the other hand, this conservatism has turned out to be a problem on some occasions. Back in 2007, when I first had to install Linux desktop clients on a larger scale, Slackware was one of the rare distributions that still relied on the 2.4 kernel instead of 2.6 like all the other distributions out there. Using the 2.4 kernel meant going without HAL at the time, which meant in turn that automounting removable devices like USB sticks didn't work. This turned out to be a showstopper, and in the end, I opted for the, ahem, less conservative CentOS 5.0.

For central authentication, I still rely on the NIS/NFS couple, which is relatively easy to setup. As far as security is concerned, 1. I don't wanna know, 2. I'm waiting for a better solution. 3. I keep telling myself that since I've come across some big networks (1000+ clients) using NIS/NFS, it can't be so bad. 4. I stick my head in the sand in the meantime.

I am glad to hear it.
Hope you are not talking about http://www.slackware.com/~vbatts/pam/.
Because from what I can see at least in /source it has a long way to go.

BTW being less secret about your work will keep us from re-inventing the wheel.

Cheers

Conservatism for the sake of conservatism might be something dangerous. Sometimes, things have to change :)

We use computers to get some job or task done. In this case, conservatism is just making it harder and it is only being justified by subjective reasons ("It is complex" "Every admin should maintain it for him(her)self"). Alienbob gave a good reason tho (it was insecure).

I don't know PAM much but I wouldn't mind it, at all.