IMO, the larger danger of bloat is not so much the extra time it takes Slackware users to troubleshoot problems, but rather the extra time it takes the Slackware development team to troubleshoot problems.

Testing and reverting/upgrading individual packages takes time only proportional to the number of packages, but testing them together and resolving integration issues takes time and effort proportional to the square of the number of packages (proportional to, but less than, as it's actually the number of interactions which count).

Thus, increasing the complexity of the system dramatically increases the dev team's QA burden, which means either releases happen less often, or releases that happen have more uncaught problems, or some of both.

I'd rather see Slackware remain a rock-solid basis for building purpose-specific systems. Problems are easier to solve if I can be reasonably certain that those problems were caused by my changes, and not by Slackware itself.

Now, that having been said, I can see a justification for adding PAM by looking around my workplace, where all the servers use PAM-based authentication (mostly just for ssh). If there were a desire to use Slackware here, its lack of PAM would pose an obstacle to doing so. On one hand that's hypothetical, but on the other hand it makes me think incorporating PAM would increase Slackware's appeal to businesses.

The talk of a server-specific Slackware fork touches a chord in my own heart. I've been wanting to build up a "superpackage" for turning a Slackware install into "Datacenter Slackware" since 2000'ish, but it's a daunting task (especially the QA effort it would require), and I've never been able to justify making it a priority. It's hard enough finding the time to work on my GlusterFS SlackBuild.

The language you have used is not warranted.
I strongly suggest you do to not exceed the limits netiquette and the LQ Rules set again and in such a way.

My 2 cents...
 

Greetings folks. Some of you might know me from the irc... I'm an oldie - my first install of Linux was back around 1993 or 1994 and was SLS, and my second install was Slackware. I've been a Slackware user at heart, even though I've had to support other distros over the years. The two things that I like about Slackware are:

1. Even with a full install, you still have a relatively lean yet functional system available. I can then go ahead and build my own add-on packages and deploy them to my systems as I feel without being required to fight dependency tracking. (Optional dependency tracking systems are just that - optional.)
2. Resistance to changes that occur in the general Linux community. I mean this from a pragmatic standpoint: resistance to a package just because it's "new" or "different" is not what I'm talking about, and that can actually be counter productive. However, I'm glad that some things like PulseAudio and systemd have not yet been adopted yet just because other distros did it. It is the weighing of the benefits versus the costs attitude that I do respect in this community.

With regards to Linux-PAM, I will admit that I've been in the anti-Linux-PAM group for all time until this past week. This was mostly due to my desire to keep things as simple as possible. In the past when I was working as a sysadmin I always wanted to get Slackware into the infrastructure at my clients' offices (most had either windows-only environments or mixed environments), and I was only ever able to get some computers designated for interns at one client's office in the whole of the 10+ years I worked as a sysadmin consultant. Only now that I've been pondering my specific needs at home (due in part to having a child who just assisted me to assemble his own computer and also in part due to the number of computers I have at home and the vm's that I also use), that I can actually see that perhaps my viewpoint has been wrong all along (after some early bad bugs were worked out of Linux-PAM that is), and had the support for multiple authentatication schemes been available, I would have had a much stronger leg to stand upon in convincing my clients to accept Slackware in their infrastructure. The cost for adopting Linux-PAM into the vanilla Slackware installation as default seems to be in the initial development of the installation packages and base configuration files for Linux-PAM. Despite the fact that it's one more component in the machine to break, we in North America at least have accepted power locks and power windows in our cars as defacto components even though they are technically more prone to failure than hand crank windows and non-power locks are. In theory, from a software standpoint, it might cause overall a few extra JMP's in code, a few more things tossed up on the stack, maybe a little more consumption of the heap, but it seems to open up so many more possibilities for deployment of Slackware.

I'm more or less in the same position as Niki here - I too wish to set up a centralized single-sign-on server using MIT kerberos and OpenLDAP (or another LDAP engine), and I am finding the documentation to do this on a system that is not already Linux-PAM'ized to be rather lacking in general. So what are my options? Sure, I could fork Slackware and have Slackpamware, but between my day job, kids, and my involvement in the FreeSWITCH project, I have little spare time that I can dedicate to such an endeavor (and I'm not sure I'd be able to do as good of a job as PV and team have done with Slackware itself). And if I would jump through the hoops to get my system Linux-PAM'ized, I'd want to share my knowledge and/or efforts back to the public... but again is that problem of time.

I do realize that it's not only my time that is valuable, but most everybody who is involved considers their time to be valuable as well. I guess the question is where do we go with Slackware now? Maybe we now stand at those crossroads that PV talked about 4 years ago? Will we alienate any of our core community if we were to adopt Linux-PAM? Even if we do alientate some (you can never please everybody all of the time) by adopting, are we alienating more by not adopting? Do we as a community (and PV as our BDFL) care about that? I know on a personal level, I'd like to see Slackware continue to thrive and grow... I'd have to consult the chart again, but Slack might be the oldest distro still in existence...

Slackware has been where I cut my teeth on unix-like systems. It's also been where I cut my teeth for C, C++, PHP, Java, etc., development. (I did actually do x86 ASM once upon a time with Borland TASM back in the DOS 5 days, but who uses ASM for anything besides SIMD operations these days? :-) ). The inclusion of Linux-PAM could also open up the door to the imagination to develop and implement all sorts of whacky auth schemes... I find that Slackers are very prone to developing new things because of our roots as hobbyists... and for me it's a hobby that didn't get ruined when I went pro. :-)

I did want to address the "5 minute solution" that I believe genss had posted here. Yes, that was indeed a 5 minute solution, and it's really impractical from the standpoint of any scenario that has more than 5 users and/or machines in it. :-) And yes, one can develop all sorts of application layer protocols that one wants, but in the end, it's actually a lot more difficult to come up with a system that is secure, safe, synchronized, functional, and has at least the appropriate level of ease-of-use. Just making something safe and secure is in of itself a challenge.

slackware is a tool and you are the admin. glad to see you come into the forum. Your wealth of knowledge is something we all can use.
http://slackbuilds.org/repository/14...nss-pam-ldapd/

Hi,

I'm about to start using Slackware soon. I'm not saying the no PAM thing is the major selling point, but in the distro I was starting to set up last week I hit a packaging bug involving PAM policy vs. lack of support in a package. So I can give you this one concrete example of PAM messing someone up (me last week and this guy who reported the bug a while ago): https://bugs.debian.org/cgi-bin/bugr...cgi?bug=672936 The comments in the NOTES file in lshd referred to in that report might interest some here too, though they were over my head, at least in a quick reading.

For me personally, PAM is something I don't want to know about -- it strikes me as ugly and extraneous -- but I'm just a home user and hobbiest. I can say with certainty I'll never try to use LDAP or kerberos. I can understand how people who need that stuff might feel differently.

Also this particular problem may not just be one of using PAM but also require you to think its PAM's job and not the shell init scripts to set umasks. Or at least I think that's what the comment in my bash profile is trying to lead me into. It's inaccurate and that still hasn't been fixed (perhaps the maintainer needs to think about bigger issues or discuss with others to say the right thing?), so I'm not positive what the intent is: https://bugs.debian.org/cgi-bin/bugr...cgi?bug=598730 At any rate if I uncomment the normal umask line from my profile things are fine again from what I can see.

I still don't understand how the umask ever got to be zero here, btw. Init seems to initialize it to 022. If you don't set it with bash init scripts or with pam_umask, shouldn't processes get what init set it to? It's kind of serious perhaps, cause I noticed some of my archived .debs were world writable. I can only think this happened from this issue. Hmmm, I should probably look more into this before my slackware dvd arrives and I blow away this install, just to see if there's something that should be reported. Should aptitude or whatever it calls to download and archive .debs really trust the umask of my user? It ought to set it to something safe itself I'd think.

(I don't mean to pick on debian here. It's a nice distro too in a way.)

I rebuild a lot of packages including the toolchain on my test boxes and I notice that if I would want to use newer versions of a few base/core packages, PAM will start to be needed to support all features of those base packages. Same issue concerning a more recent udev version.

hendrickxm - could you please provide some documentation about the packages that you are encountering this in? Thanks!

14.1 still uses kbd-1.15 for example. You could add vlock in kbd-2.0.2 with pam enabled.
PhantomX's slackbuilds are with pam (and also systemd). https://github.com/PhantomX/slackbui...E2%9C%93&q=pam

It would be nice if you were right. I've been trying to sort out how to do Authentication to a Samba4 AC/AD and everywhere I look it talks about using PAM (https://zachbethel.wordpress.com/201...n-with-samba4/) "The key package you will need to make this work is nss-pam-ldap. You can find it here. As stated on the website, this package provides a PAM module and daemon (nslcd) for querying and authenticating to an LDAP server."

Is this not correct? Can I really avoid using PAM?

ethoms wrote: "I think there may be another way to get ldap authentication without dirtying hands with PAM. It seems like it has a static implementation of PAM included inside it, enough to do ldap auth. It is in salckbuilds: http://slackbuilds.org/repository/14...nss-pam-ldapd/"

I tried buiding that, but it failed. building the package failed with "fatal error: asm/socket.h: No such file or directory", and attempting to run ./configure in the source directory failed with "configure: error: PAM header files are missing".

I never said I was right. I said PAM is optional to the main system as a whole. Currently, adding PAM, like other things, is up to you to add for yourself. There is no PAM package in SBo so feel free to contribute one though.

http://pastebin.com/QLajSZYX
don't know the specific of your setup but have you got a full install? I got asm/socket.h in the kernel-source package.

sorry ReaperX7 but, IMHO, PAM is not something that should go in SBo: we cannot maintain it as an optional dependency (it would be something very similar to hell on earth) and a lot of stuff in Slackware would have to be rebuilt to support it.
so, as for me (I'm not talking for the other admins), PAM on SBo is a nono.

It probably could be done, but you would have to draft up an extensive README-Slackware file to accurately explain the entire rebuild dependency layer process of adding PAM into the system accurately, and explain if PAM is ever updated along with packages using PAM, everything would have to be rebuilt yet... agai... yeah good call on the no-no. Kinda see why a certain person doesn't like to mess with it either. It's like a giant cobweb. You take the cobweb down only to find it's a load bearing cobweb.

in short, why make it complicated.
the simple solution would be: PAM should be part of Slackware, most people would not even recognize a different, and those who need it would be more than happy

Let's not start beating this horse again. The Slackware dev team is well aware of PAM and that some in the community desire it to be included with Slackware. They will make the decision if/when they feel it needs to happen. Until then, let's not get into another heated "discussion" over it.

discussion
 

While I agree there probably isn't a lot anyone can add on a technical level I don't think its bad to discuss the inclusion of PAM from time to time. Provided that it does not get personal, everyone understands the development team does not owe them a response, let alone a PAM enabled system and it all stays friendly.

Adding PAM will be a lot of work. Much less work though to do it 'in-tree' and maintain it than out of tree. Doing it out of tree creates all the challenges Multilib being out of tree does. The difference as I see it is that the need for MultiLib has a time horizon fewer and fewer people will have a need for 32-bit only stuff as time goes on. PAM on the other hand being where the "main stream" is means more and more people are likely to run up against special challenges of not having it as time goes on. We all know there are good reasons to leave it out as well. The question is really one of "when have the scales tipped".

Letting Pat and dev team have some visibility into how many people would like Slackware to move in that direction in the form of message posts on these boards they are free to read or not isn't a bad thing. Certainly e-mailing them or something about the issue at this stage really would be 'unless' perhaps you are offering to do the work :-).