LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   slackware 15 and pam (https://www.linuxquestions.org/questions/slackware-14/slackware-15-and-pam-4175483168/)

Arkerless 07-17-2014 03:31 PM

Quote:

Originally Posted by Slax-Dude (Post 5205214)
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.

NeoMetal 07-17-2014 03:42 PM

Quote:

Originally Posted by Woodsman (Post 5205506)
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 )

ReaperX7 07-17-2014 04:19 PM

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.

kikinovak 07-17-2014 04:38 PM

Quote:

Originally Posted by ReaperX7 (Post 5205528)
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.

kikinovak 07-17-2014 04:56 PM

Quote:

Originally Posted by Woodsman (Post 5205506)
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

Woodsman 07-17-2014 05:40 PM

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?

ReaperX7 07-17-2014 06:51 PM

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.

Didier Spaier 07-18-2014 02:00 AM

Quote:

Originally Posted by ReaperX7 (Post 5205580)
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.

ruario 07-18-2014 02:43 AM

Quote:

Originally Posted by ReaperX7 (Post 5205580)
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).

ruario 07-18-2014 02:58 AM

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 (Post 4182564)
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?

a4z 07-18-2014 03:43 AM

Quote:

Originally Posted by ReaperX7 (Post 5205580)
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.

ruario 07-18-2014 04:35 AM

Quote:

Originally Posted by a4z (Post 5205768)
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.

kikinovak 07-18-2014 07:56 AM

Quote:

Originally Posted by ruario (Post 5205754)
If I had a vote (which obviously I don't), I would suggest Slackware adopts PAM.

+1.

Woodsman 07-18-2014 01:34 PM

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.

abesirovic1 07-22-2014 10:54 AM

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


All times are GMT -5. The time now is 04:43 PM.