Hey Willy, here's one of the lesser-known distinctions of the Debian/Ubuntu world. Upgrade system and eventually install new dependencies:

Update system without installing new dependencies:

That being said, Ubuntu Server LTS has a feature freeze like the other distros. I'm running a handful of Ubuntu servers both locally and public, and I haven't noticed any mysterious dependency tsunami. On the contrary, the installations are quite lightweight.

Cheers,

Niki

Brian Q Public here. As I've explained in my LQ blog, I was a late starter as far as interest in and use of computers is concerned. I'm interested in just about anything that can be done with Linux, and a full install of Slackware (+ a few more bits and pieces) gives me the software to do it. OOTB, without apt-getting or yuming for hours on end. So, to me, it's not bloated. If some Slackers need PAM, let 'em have it. I don't know how, or where, I'll leave that to Pat & the Team.
:twocents:

Yeah, and there's no need for you to be rude either. I do plenty with my system, including a lot of R&D for a project I work at with diligence. Sorry, if I'm just one more "stupid American" you act like you can look down on.

Yeah, bro, I see how it is... just because I'm not a system or network admin, you look down on me? Go read every post I've ever made! Quote something from each and every single one where I didn't do least something. Put your money where your mouth is or pipe down and be silent!

It would be nice to have a little update and/or statement from the BDFL himself about the subject.

My prediction: this will happen in a timely manner.

The other way round, it wouldn't be bad to increase a bit the signal/noise ratio of this thread.

Talking about minimalism & bloat, here's something for the minimalophiles:

http://minimal.linux-bg.org/

Only 8 MiB!!! Oh, WOW!!!
:)
P.S.
There you are, a bit of noise. ;)

As most of you know me by a dropline gnome dev. and from the systemd slackbuilds.
I am using PAM for a long time.

My opinions on this matter.

1. Does Slackware need PAM
A. NO
2. Would PAM be nice to have, and what would be minimal to be rebuild ?
A. Yes, shadow only.

Personally it would be handy to have PAM, but it is not to much hassle to build and install PAM, and rebuild shadow in order to have PAM functionality for the software you need.

The only reason why I would like to see PAM in Slackware is to make my life easier.

Are you sure about that? Vincent Batts has an experimental PAMified package repo, and on the latest count, it contains no less than 22 (twenty-two) rebuilt packages.

http://www.hashbangbash.com/downloads/pam/pkgs/i486/

let me give a few examples:

proftp <-- doesnt need to be rebuild, only if you want to use pam for it (works without)
openssh <--- see proftpd

etc. etc.

Well, what can a poor boy say? Thank you very much for that clarification! That's great news!

Yeah it really depends what you want to accomplish. I would say rebuild su, sudo, and ssh as well as shadow though so that all the normal login methods work as expected.

I think this points out one of the subtle problems that tends to make problems for threads of this nature.

You ask the same question and two people can still understand it in different ways.

PAM? Heck no! says person 1 who interprets the question as 'rebuild everything to rely on PAM and look just like CoreBuntu.
PAM? Why not? says person 2 who interprets the question as 'build one package that provides PAM exclusively other packages which require it.'

They could both actually be in total agreement if you gave them more specific, detailed proposals rather than the more general question, we just dont know.

At any rate despite some painful-to-read moments of heat I think some interesting arguments have been posted and I feel like I am learning something.

@bartgymnast - can you expand a little particularly in regards to how you use PAM, if you do in fact use it?

My specific need being LDAP authentication working on a Slackware server with mixed clients (Slackware, Ubuntu, Elementary OS).

I am using PAM for GDM and now for the logind of systemd.

before using systemd, it was just for GDM.

My problem is getting openldap up and running with the correct security constraints (SASL and TLS). I haven't gotten to the libnss_ldap portion yet.

This part of configuring openldap correctly has nothing to do with PAM.

If you want SASL to use ldap for authentication information, you'll have to rebuild cyrus-sasl as well as modify /etc/rc.d/rc.saslauthd to use the ldap authentication mechanism.

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 :-).

I say roll it into SBo and let people take responsibility into their own hands. At least let we'd have a package and enough stuff to let those in need of it, use it.

I would only recommend it for stable systems though as -Current would be far too volatile.

SBo tries really hard not to replace or clash with any Slackware packages, for very good reasons that are on public display every time someone has messed their system up through poor working practices and thinks something in SBo is broken.

If only one -- just one -- of the people who want PAM would step up and maintain a repo with source Slackbuilds on Github and binary packages somewhere compatible with slackpkg+, that would be more constructive than discussing here the best strategy for maneuvering that work onto Mr Volkerding. Just start with ivandi's stuff when 14.2 comes out, and interact with the community until everyone is happy. Problem solved, until 15.0 comes out, or until another security scare (like the recent openSSH thing), whichever happens first ;-)

Folks, please don't witter how much hard work that would be. Don't fanny around. Use grown up tools like git and github, slackrepo or virtual machines for clean building, and slackpkg+. This kind of project is exactly what those tools were created for.

I'd say start fresh with 14.2 and slowly replace stuff, but above all else a complete list of packages that would be in need of rebuild and modifications would be even better, but yes, it should only be done towards a stable release.

The lack of pam is one of my favorite things in Slackware, it just over complicates the system like everything redhat has their hands into. If pam exists in slackware it should be an entirely optional third party package. Maybe you should add it to your slackworks repo along with all the packages that would need to be rebuilt.

I could pending time, but to get started I would need, at minimum, a full list of packages that have PAM as a dependency. I have OpenPAM in /extras but that's just for testing only and special interest, nothing actually concrete.

Somehow this has become routine. :hattip:

If PAM gets added to Slackware it will totally not be optional, because it will require the reconfiguration and recompilation of a sizeable amount of packages to give them PAM support.

Well, after reading through the discussions i thought I would shares my opinion as well.

I use Slackware my main desktop both at home and at work (where i also maintain a small server for the use a small group).

I do not use PAM, however it is not because i do not need it or do not want . it is because it is not convenient to maintain a separate set of packages on my own and potentiality recompile them each time there is an update.

Also me using slackware is a bit sneaky. I would much prefere to be a able to log in to my desktop using centralized authentication against AD. Also single sign on and kerberos would be convenient at work.

I understand that, but I still don't see why this can't be all hosted on a third party repo? Sure it would be a lot of work for whoever maintained it, but seems preferable to me than if someone was forced to maintain a repo for getting rid of pam.

who said it can't? it actually already is and there are three different ones:
- one dedicated to PAM only, maintained by Slackware core team member Vincent Batts http://www.slackware.com/~vbatts/pam/
- one with PAM, kerberos, mate desktop and other third party stuff all together, maintained by ivandi http://www.bisdesign.ca/ivandi/slackware/SlackMATE/
- one with PAM, kerberos, systemd and gnome, maintained by bartgymnast https://github.com/Dlackware
the point, IMHO, is that people still push to have it integrated in Slackware without even have tried the above!!!

I think Vincent's is the more sane, targeting the core system leaving SBo alone as managed by the user first and foremost, plus he uses a tagging system that can be switched on and off with the blacklist feature in slackpkg/pkgtools.

OK, so PAM is not included in Slackware. Apparently I need for Samba 'Member Servers' to authenticate with the Samba4 AD/DC (and Samba4 *is* include in Slackware). Can it be built from sources (http://www.linux-pam.org/library/) and have it work?

I'm sorry but PAM simply is the type of package that goes with lots of other stuff.. And I, for one, would need to be an idiot to use it on a real public server or in a system that deals with network authentications and not care from where the security updates came from or try to remember from what repository a package is needed from so that it's build with PAM.. etc, etc... Not to mention that packages included in the distribution get more testing and quicker security updates than those in some random repo..

Luckily, I afford not to care about PAM having other stuff on my mind (like getting a job :)) ).. But if I would, spending so much time alone in "trying" something that should already be core functionality just so I can run some version of Slackware that isn't even Slackware after those changes.. Well, that would be a very big no..

I'm sorry but PAM would change almost nothing for the users that don't actually need it... Hell, most of them won't even know it's there.. Yet it means so much for those who do and I would say for the distribution itself.. It's one thing to be stable and clean, it's completely a different thing to be.. well.. debian (no offence to anyone -- I was just insinuating that Debian-stable is usually old, outdated and almost useless in practice)...

I had not seen vbatts' packages before, thanks Ponce. It looks like he has done some really nice work! Still I must sorta echo Smokey_justme feelings on the matter. Even vbatts has some TODOs and unknowns in his readme. Unless PAM is included in Slackware 'proper' I can't really see using it except for possibly a very very stripped down highly purpose built system with few packages on it. There is way to much potential for a non-pam package to allow a partial bypass or policy violation because it goes after nss and shadow directly.

For some of the very reasons cited in the past for not wanting to include PAM, I'd be very concerned about going any way other than all in, or the all out we have today. Its also true that it would be trivial to ship a default PAM setup that would have near zero impact on the usual stand alone Slackware install. Its back to that tipping point question, when do the risks and headaches of adding it become less than pains of trying to do without. I even would argue that Pat has been right about PAM historically speaking. Until pretty recently we have been better off without it; its just in 2015 the stand alone server is a declining species. The alternatives like NIS that can be implemented without PAM are obsolete and come with their own serious security issues.

Well, I hate to be pedantic. But only the second project in your list provides "out of the box" directory integration. And it can definitely be used as a base for implementing this functionality in Slackware. So far that's the main reason threads like this have been revived.

BUT only in a fantasy world called Slackware a complete and utter idiot will deploy my project "as is" in production environment and will be waiting for me to finish my glass of wine and eventually look at some important security updates.


Cheers

While I concur with you from a purely factual and technical point of view, you could have stated this in a more civil manner.

No one has addressed my issue. Is there a way for a member server to authenticate if not with PAM? Seems to me that if Slackware were usable in an AD/DC environment, then this functionality would be crucial. All web posts I've seen so far say PAM is a must for single-sign-on. How would one do this in Slackware without PAM?

Only if you want to do a lot of extra work, break things, and reconfigure a lot of stuff that will take you down a no-man's-land path. It can be done, but it's more akin to pulling teeth while performing an amputation, open heart surgery, and delicate brain surgery on the same patient at the same time without anesthesia.

If you do need PAM, just build PAM, install it, and rebuild packages to use PAM as needed. It's very cut and dry.

agree, except, it's not the fantasy world called Slackware, just some guys here that repeat 'use this use that do it your self' without having to much clue what they are talking about, and this since years. we have here a good archive that not only documents the lack of understanding of a problem but also the absolute inability to learn and adopt to facts.

I think we can debate all we want about the inclusion of PAM into Slackware it is nothing more than feedback(?) to Patrick and the core dev team. While Slackware development is not a democratic process, and wishes and request are not necessarily granted, i say it out loud:

@Volkerdi
Please consider the inclusion of PAM into Slackware.

and if you do not that will still be OK with me :)