LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 07-17-2014, 03:31 PM   #31
Arkerless
Member
 
Registered: Mar 2006
Distribution: Give me Slack or give me death.
Posts: 81

Rep: Reputation: 60

Quote:
Originally Posted by Slax-Dude View Post
In the IT world 4 years is a long time and PAM has been around for 14 years (and is still active)... so I expect that most of its major problems have been dealt with.
I would humbly suggest your expectations sound unrealistic. The major problems were mostly design issues at heart. The design has not been changed. No matter how long you polish the driftwood, no matter how shiny you get the frequently touched parts, it's still always going to be driftwood, and will never transmute to ivory.
 
Old 07-17-2014, 03:42 PM   #32
NeoMetal
Member
 
Registered: Aug 2004
Location: MD
Distribution: Slackware
Posts: 112

Rep: Reputation: 24
Quote:
Originally Posted by Woodsman View Post
While I suspect the statement was tongue-in-cheek with respect to the requirement to build "half" of Slackware, I get the point about the additional overhead to include PAM in Slackware. I am curious how much change is required to include PAM in Slackware. PAM is a de facto standard package in almost all other distros. I have no opinion on that inclusion but I doubt there are serious usability problems with PAM or distro maintainers would have not included PAM as a de facto standard package. And that several Slackware users in the enterprise do PAM-ify their Slackware systems is revealing to some degree and that the exclusion of PAM requires a Slackware enthusiast active in the enterprise to choose a different distro also is revealing.


Perhaps then this thread could change focus to provide the details necessary to add PAM to Slackware? Perhaps that kind of approach would help the development team with experimenting and testing?

Also, if PAM was added to Slackware, could the defaults be to have PAM disabled such that only those who need PAM need to take active steps to enable? That is, can PAM be installed but not be used or required? Or is including PAM all-or-nothing?
I tried to outline what was needed and where I found some of the info in my post here: http://www.linuxquestions.org/questi...ml#post5108904

(It was kind of a rushed stream of consciousness thing but hopefully it conveys the overall process, I can try to clean it up and walk through it again to see if it makes sens to even me several months on. Maybe Ser Olmy or V Batts might be able to clarify some things better than I could as that was my first time really delving into it :O )
 
1 members found this post helpful.
Old 07-17-2014, 04:19 PM   #33
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: FreeBSD 11.0-Current Slackware64-Current
Posts: 4,961
Blog Entries: 15

Rep: Reputation: 1471Reputation: 1471Reputation: 1471Reputation: 1471Reputation: 1471Reputation: 1471Reputation: 1471Reputation: 1471Reputation: 1471Reputation: 1471
PAM is fairly much all-or-nothing as if added, it becomes a hard dependency for programs unless the PAM argument is turned off at compile-time. Some programs have this, and some do not.

The best argument I could give to find out how many packages would require PAMification, would be to thoroughly read through BLFS as a kind of guidebook, and see which packages they have that utilize PAM, that way you have an idea of what requires PAM if added, maybe in Slackware.

There is another option I'm surprised NOBODY failed to mention/ask about.

/extra

Just as AlienBOB has his multilib directory, though it's not in Slackware officially, any and all packages that require PAM could effectively be given a /extra/pam-packages directory either on disk or on the Slackware FTPs, and just maintained that way either with packages or ready-to-use SlackBuild scripts.
 
1 members found this post helpful.
Old 07-17-2014, 04:38 PM   #34
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: Slackware, CentOS
Posts: 2,412

Rep: Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298
Quote:
Originally Posted by ReaperX7 View Post
There is another option I'm surprised NOBODY failed to mention/ask about.

/extra
This has been discussed, though a bit under the radar on IRC. AlienBob suggested exactly this, an extra repo similar to his multilib repo. Only problem is you'd have to find someone to maintain it.
 
Old 07-17-2014, 04:56 PM   #35
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: Slackware, CentOS
Posts: 2,412

Rep: Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298
Quote:
Originally Posted by Woodsman View Post
And that several Slackware users in the enterprise do PAM-ify their Slackware systems is revealing to some degree and that the exclusion of PAM requires a Slackware enthusiast active in the enterprise to choose a different distro also is revealing.
This will be a bit off-topic, but there's more to it than that. The absence of PAM is only one factor in my migration, but there are some others where Slackware is not necessarily at fault. A significant part of my job is teaching, and the last three requests I had from businesses were all specific for Ubuntu Server, which seems to be extremely popular, at least here in France. So I try to meet the client's expectations, and I'm an eat-your-own-dog-food type of admin/teacher. Besides that, there's an unexpected problem using Slackware in France for teaching, it's that most of the folks in France are really bad at understanding even the most basic english. During the last class I taught, there were some vocal protests why we weren't using a translated version of Linux. An entirely different factor, and this is completely unexpected, I've discovered Elementary OS' Pantheon desktop, which is nothing less than the perfect Linux desktop environment I've always been looking for. Right now it's only available for *buntu, Arch and Gentoo, but maybe one day someone will port it to Slackware. Last but not least, I find myself more busy and with less time on my hands these last months, so it's in effect much easier and less time-consuming to setup half a dozen of PPA's on Elementary in order to have a full-fledged workstation with applications galore. For the time being, I had to put my MLED project to sleep, and I don't know when I can pick it up again.

That being said, Slackware will always have a warm place in my heart.

Niki

Last edited by kikinovak; 07-17-2014 at 04:58 PM.
 
2 members found this post helpful.
Old 07-17-2014, 05:40 PM   #36
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 540Reputation: 540Reputation: 540Reputation: 540Reputation: 540Reputation: 540
Quote:
This will be a bit off-topic, but there's more to it than that.
Thanks for sharing. I am in a similar predicament, as you already know from other threads.

Quote:
PAM is fairly much all-or-nothing as if added
Could the defaults be configured to be as transparent as possible, almost to the point that those who do not need PAM would almost not notice?

Quote:
This has been discussed, though a bit under the radar on IRC. AlienBob suggested exactly this, an extra repo similar to his multilib repo.
Is the idea that all of the /extra packages would be direct drop-in replacements? Just use upgradepkg?
 
Old 07-17-2014, 06:51 PM   #37
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: FreeBSD 11.0-Current Slackware64-Current
Posts: 4,961
Blog Entries: 15

Rep: Reputation: 1471Reputation: 1471Reputation: 1471Reputation: 1471Reputation: 1471Reputation: 1471Reputation: 1471Reputation: 1471Reputation: 1471Reputation: 1471
The idea is yes, they would be drop-in replacements... such as:

OpenSSH-x-x86_64-1.txz would be replaced with OpenSSH-x-x86_64-1-pam.txz

This way, PAM is not just optional on the system as a whole, but so are the packages, their configuration scripts, etc.

Last edited by ReaperX7; 07-17-2014 at 06:52 PM.
 
Old 07-18-2014, 02:00 AM   #38
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad W520
Posts: 5,492

Rep: Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526
Quote:
Originally Posted by ReaperX7 View Post
The idea is yes, they would be drop-in replacements... such as:

OpenSSH-x-x86_64-1.txz would be replaced with OpenSSH-x-x86_64-1-pam.txz

This way, PAM is not just optional on the system as a whole, but so are the packages, their configuration scripts, etc.
That would mean more maintenance. I'm not sure that the Slackware crew can afford that.
 
Old 07-18-2014, 02:43 AM   #39
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 2,057

Rep: Reputation: 1063Reputation: 1063Reputation: 1063Reputation: 1063Reputation: 1063Reputation: 1063Reputation: 1063Reputation: 1063
Quote:
Originally Posted by ReaperX7 View Post
OpenSSH-x-x86_64-1.txz would be replaced with OpenSSH-x-x86_64-1-pam.txz
Just a minor nitpick but that suggested name does not follow Slackware package naming conventions. Issuing "echo [full package name] | rev | cut -f4- -d- | rev" should result in the short package name (without the version number, architecture, build tag and extension). Your suggested naming breaks this.

More likely it would be openssh-pam-version-architecture-buildtag.txz (I also lower cased OpenSSH, since this is how the package is named in the official Slackware packages).
 
Old 07-18-2014, 02:58 AM   #40
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 2,057

Rep: Reputation: 1063Reputation: 1063Reputation: 1063Reputation: 1063Reputation: 1063Reputation: 1063Reputation: 1063Reputation: 1063
If I had a vote (which obviously I don't), I would suggest Slackware adopts PAM. After several years maturation it has obviously got to the stage where it is workable (given pretty much every major distro has a adopted it). Additionally I think it makes life far more difficult not having it, for those that need it in production environments.

P.S. Four years back volkerdi had already hinted at the possibility of Slackware with PAM one day.

Quote:
Originally Posted by volkerdi View Post
That was true perhaps a decade ago, around the time I made the now infamous comment about "PAM == SCAM". Back then, many applications either had to be patched to add PAM support, or if they had PAM support it probably needed additional patches to work right. These days, the opposite is just as likely to be true. Especially with things such as ConsoleKit and polkit (which we pretty much have to include in order to provide a functional desktop), we are finding that the non-PAM code is not as well tested, and that we've had to patch things in order to work with the traditional shadow based authentication. Eventually these developments are likely to force our hand with regard to PAM (but not in the immediate future).
I wonder if we are any closer now or not?
 
Old 07-18-2014, 03:43 AM   #41
a4z
Member
 
Registered: Feb 2009
Posts: 881

Rep: Reputation: 330Reputation: 330Reputation: 330Reputation: 330
Quote:
Originally Posted by ReaperX7 View Post
The idea is yes, they would be drop-in replacements... such as:

OpenSSH-x-x86_64-1.txz would be replaced with OpenSSH-x-x86_64-1-pam.txz

This way, PAM is not just optional on the system as a whole, but so are the packages, their configuration scripts, etc.
and then we re-write all packaging tools to respect the new namings and deal with them.

--
sometimes it have the feeling that some opinions are more based on fundamentalism than on facts.
 
1 members found this post helpful.
Old 07-18-2014, 04:35 AM   #42
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 2,057

Rep: Reputation: 1063Reputation: 1063Reputation: 1063Reputation: 1063Reputation: 1063Reputation: 1063Reputation: 1063Reputation: 1063
Quote:
Originally Posted by a4z View Post
and then we re-write all packaging tools to respect the new namings and deal with them.
The idea would work assuming there was someone to maintain them. He just got the naming wrong but that part is fixable.

Doesn't have to be in extra though, any interested party with enough time on their hands could do this.

Last edited by ruario; 07-18-2014 at 04:37 AM.
 
Old 07-18-2014, 07:56 AM   #43
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: Slackware, CentOS
Posts: 2,412

Rep: Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298Reputation: 1298
Quote:
Originally Posted by ruario View Post
If I had a vote (which obviously I don't), I would suggest Slackware adopts PAM.
+1.
 
Old 07-18-2014, 01:34 PM   #44
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 540Reputation: 540Reputation: 540Reputation: 540Reputation: 540Reputation: 540
Quote:
That would mean more maintenance. I'm not sure that the Slackware crew can afford that.
I am guessing Pat and the team have many script wrappers to automate Slackware maintenance, so perhaps not that much additional maintenance. I suspect the biggest hurdle is introducing PAM into Current so Current users can start kicking tires and revving engines.

Quote:
Just a minor nitpick but that suggested name does not follow Slackware package naming conventions.
Yeah, but we all got the point. Perhaps just replace "SBo" with "PAM" to make the drop-in packages.

Quote:
Doesn't have to be in extra though, any interested party with enough time on their hands could do this.
Perhaps SBo for 14.2 and after that trial run pull into 15.0?

Quote:
If I had a vote (which obviously I don't), I would suggest Slackware adopts PAM.
Yeah, +1 here too. Not saying PAM is a Good Thing or the Right Stuff, but as Pat shared four years ago, the infamous PAM = SCAM days are long gone. I have no personal need for PAM, but adding PAM is one less item to use against Slackware when people choose a distro. Sometimes swimming against the tide forces uncomfortable decisions and adding PAM probably is a reasonable decision nowadays.
 
Old 07-22-2014, 10:54 AM   #45
abesirovic1
LQ Newbie
 
Registered: Sep 2005
Location: Germany
Distribution: Slackware
Posts: 29
Blog Entries: 1

Rep: Reputation: 6
For educational purposes, why is PAM bad (I'm not trolling, I'm just curious)?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
PAM and Slackware 10.2 darkarcon2015 Slackware 15 10-20-2007 02:32 PM
PAM Available For Slackware 10.0 eric.r.turner Slackware 14 09-22-2006 12:08 PM
PAM for my Slackware rmg Linux - Newbie 3 04-06-2006 01:10 PM
does slackware 10 support PAM? joroxx Slackware - Installation 2 11-16-2004 12:06 AM
pam mount in slackware 10 qwijibow Linux - Software 1 08-06-2004 08:37 AM


All times are GMT -5. The time now is 07:15 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration