SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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.
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.