Petition for the inclusion of PAM in the next Slackware release
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Same here. I'm running NIS as a "lesser evil" in the meantime, until Slackware decides to ship PAM.
Using NIS is almost the same as using telnet. It's a disaster waiting to happen.
Your case reminds me about a boss I had. He was convinced that a security problem that can't be solved by technical mean can be solved by administrative one. Poor guy. He couldn't believe that the intruder he intended to "arrest" could be some 10000 miles away
BTW I am using telnet daily on embedded systems but the only "network" is a 6 feet cable between the POD and a dedicated NIC in my workstation.
PAM packages "could" be built with a USE_PAM=YES/NO flag to make using PAM easier to include or exclude, or and this is daring of me to say, we could even have a flag in the installer to do this:
1. Ask the installer if they want to use PAM.
2. Install all non-PAM using packages normally.
3. Use the installation selection to enable USE_PAM=YES and have the installer build and install the PAMified SlackBuilds at installation.
This way no packages need to be built beforehand by Patrick, and if a NO flag is passed, no packages are rebuilt, but just installed only. Kind of similar to how sbotools works, but have a small repository on the DVD.
Just a thought on the table.
And also USE_KRB5=YES USE_AUDIT=YES ... Why don't we make a Slackware.SlackBuild and define all these USE flags at the beginning.
my question for those who want 'enterprise' features why not just use redhat or suse in those cases? its obvious that slackware is a different distro with different goals and philosophy. I have found it a very clean environment to do c/c++ development for cross platform unix/windows/osx development. and would be happy to see slackware maintain its emphasis on minimal dependencies.
The point of having it install time optional, is simply that. Let's keep it optional. Not everyone will want it, but if you do, there's no sense in not having a way to install PAM and packages that will have PAM as a dependency during installation.
And, no, you don't need to use Gentoo, just use your tools and your head. Looking at how SBo package are handled by sbotools got me seriously thinking about this. If a build time option exists, then why not enable it during the build and install process?
Why can't Slackware have a few source optional builds on the install disk triggered by a flag? That's not deviating from Slackware since realistically you're still installing official packages.
Besides what's even stopping you from grabbing PAM's SlackBuild and OpenLDAP's SlackBuild, making a few edits to use PAM, and then rebuilding and installing both as local maintained packages? I maintain my own repository with runit-boot, ConsoleKit2, eudev, and others.
Why can't Slackware have a few source optional builds on the install disk triggered by a flag?
I can think of two problems with that without giving it much thought.
you would have to introduce some control logic for dependency tracking for which package changes depending on which flag etc. that code is not there at the moment and could quickly eclipse the size of the whole installer in short order given its simple design.
combinatorial explosion of test cases. for a very small team I imagine just getting one solid 32/64 build out the door is a lot of work. now multiply that by the number of conditional compilations that are possible and you have more testing work then the team could deal with.
I can think of two problems with that without giving it much thought.
you would have to introduce some control logic for dependency tracking for which package changes depending on which flag etc. that code is not there at the moment and could quickly eclipse the size of the whole installer in short order given its simple design.
combinatorial explosion of test cases. for a very small team I imagine just getting one solid 32/64 build out the door is a lot of work. now multiply that by the number of conditional compilations that are possible and you have more testing work then the team could deal with.
Actually you don't need to do that. You could use a queue system to install in a preset order. Several of the SBo toolkits use a queue system to stage packages in a certain order.
As already said by someone here, if we accept PAM to take Slackware into "enterprise world" then we should accept many others things.
I would be really sorry seeing Slackware with an unspecified identity.
A middle earth between current and enterprise is useless.
And as recently expressed by someone else in another thread which I cannot find at the moment:
Every time I hear the word enterprise I hear the Star Trek theme music playing in the background.
What the *&$% is "enterprise" in this context anyway except another tired old marketing term intended to distinguish "ours" from "theirs".
The whole of my life's various enterprises, business and other, at this time are tightly coupled to Slackware and there is no good second place Linux contender! In my book that makes it "enterprise" level. I don't require anyone else to point to the list of installed apps and say that it is or isn't "enterprise" level. It is - for my enterprises.
As already said by someone here, if we accept PAM to take Slackware into "enterprise world" then we should accept many others things.
I would be really sorry seeing Slackware with an unspecified identity.
A middle earth between current and enterprise is useless.
While this may be true to some extent, PAM is the only thing that's badly missing, in my humble opinion.
AThe whole of my life's various enterprises, business and other, at this time are tightly coupled to Slackware and there is no good second place Linux contender! In my book that makes it "enterprise" level.
Then please let us know how you manage central authentication and roaming profiles for your users. I'm asking, because so far I've only had three different answers to that question in similar threads:
"I don't use central authentication." (fine for you)
"NIS is fine." (no, it's not, it's a security nightmare)
"My wife tells her students to use USB disks." (sic, no comment)
What the *&$% is "enterprise" in this context anyway except another tired old marketing term intended to distinguish "ours" from "theirs.
this is an important question that has a clear and unambiguous answer. vertically integrated enterprise delivers cloud based solutions that lock in future growth potential. now give me your money.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.