2 ways
ssh and at/cron/date, where you have to "activate" it yourself
or comparing a file from that usb in rc.S/M + cron/at/whatever

i don't find "time intervals" clear enough to be more precise
if it means like 16-20h then date + at

The complexity is mostly invisible to the user, but the effects from it may be felt nonetheless. Whenever there is more complexity, there are more opportunities for bugs and security vulnerabilities which impact the user's experience.

To put it another way, if there is a bug in PAM, then linking an otherwise well-working program against the PAM libraries could introduce that PAM bug's consequences to that program. An intruder could take advantage of a PAM vulnerability to gain access to your system, which would have been impossible had the system been built without PAM.

Also, if you follow the slackware-current changelogs, you've seen here and there where Patrick updated a package and forgot to recompile a package which depended on it, or used the wrong configuration option, and had to go back and fix the mistake. Adding PAM to the distribution also adds more opportunities for these kinds of mistakes.

Even though he's really good at catching and correcting these, it still takes time and effort which he could've spent fixing/improving other things in Slackware, which hurts everyone.

(I know you said you understand those last points already, but wanted to throw them in there anyway; a lot of people just don't get it.)

2 members found this post helpful.

Maybe both OpenPAM and Linux-PAM should get equal trials.

I also support this petition. While I do not work in large enterprise, I do have my dealings with various Slackware servers and there definitely were some times I wished PAM was there (however I was able to get away without it).

I am wondering, would it be at least possible to make Slackware PAM-aware, so the actual implementation could be as easy as installing PAM from extra and then configuring it? Or at least it would be easier for separate PAM SlackBuilds project to offer builds and/or configurations without having to mess with core system too much?

1 members found this post helpful.

+1 for adding PAM

I also support inclusion of a PAM with kerberos/LDAP support.

In my last job running a specialist computer lab at a large university, I spent the last 10 years sidestepping requests for authentication against the uni's central kerberized LDAP user database. I had to maintain a local user database, using NIS for client machine authentication and, overall, I thought it was something of a victory - being able to demonstrate SLackware as being as capable as any other distro in a pretty high end graphics area. However, in retrospect, I can see that it also highlighted SLackware's big shortcoming in an enterprise environment (not to mention my own shortcoming of not being able to make it happen).

chris

3 members found this post helpful.

I do support inclusion of PAM aswell. but like chris.willing said this should come with kerberos/LDAP if possible.
otherwise it has no advantage for the enterprise.

If you accept the argument that Slackware needs PAM to be relevant in the enterprise, then this potentially becomes the thin end of the wedge for further additions to meet accepted enterprise standards. NFS4, SELinux and systemd come to mind.

I actually use Slackware as a "special snowflake" server precisely because it does not have PAM. The server is a gateway to keep central IT out of my little intranet.

Does Slackware have to be a clone of other enterprise class distributions? For me, the lack of concessions to the Windows world of computing is part of what makes me happy using Slackware.

10 members found this post helpful.

Same here. I'm running NIS as a "lesser evil" in the meantime, until Slackware decides to ship PAM.

Take a look at my PAM slackbuilds here: http://www.bisdesign.ca/ivandi/slackware/PAM/

There is no way to make Slackware PAM-aware w/o PAM. And there is no way to implement PAM w/o recompiling or even replacing a lot of packages. The above list is not complete.

Cheers

4 members found this post helpful.

Audit has to be added too.

Cheers

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.

For what it's worth, I'd like to be able to use this coupled to this in a 100 % Slackware environment. No Windows here, just free and open source software. Yes, I know that Slackware is shipping openLDAP-client. Yes, I also know that it can be rebuilt to be a server. But then again, missing PAM is the showstopper if you want to use the thing for authentication.

I'm not an "enterprise" Linux expert, but one of those people who are not missing PAM, barely knowing what it is all about. However, if Patrick Volkerding decides that it is going to be included, then I will accept it and consider it as an improvement. So, please correct me if you feel that I'm talking nonsense here.

According to what I've read from other posters it seems that the introduction of PAM in -current would entail a heavy load of additional work for Patrick himself and crew. I mentioned -current, because I guess that's where PAM would go, along with all PAM-ified packages, before "being ready" for a stable release.

I also learned that Vincent Batts is already working on something, and that his project is targeting -current. However, it seems that being an unofficial project it is not sufficiently exposed to potential testers.

That being said, what about doing a compromise, like opening an experimental section in the SlackBuilds.org project (which has a lot of exposure), specifically focused on PAM for -current? That section would include all needed disclaimers and warnings, and of course it would gather slackbuilds for all needed PAM-packages, including those already in Slackware that have to be rebuilt with PAM support.

Eventually, if Patrick is OK with such a sub-project of SlackBuilds.org, he might decide to merge it in the official -current release. If not, the sub-project might stay at SlackBuilds.org and eventually target the stable release, thus offering an actual choice for interested "enterprise" administrators, who would also be the maintainers of such a project.

One step at a time I say. But again, please be vocal if I talked nonsense.

1 members found this post helpful.

The only viable alternative to adopting PAM directly in the distribution would be if someone from the core Slackware team (Vincent? Eric? Robbie?) stepped forward and decided to maintain a third-party repository for a PAM-ified Slackware. More or less what Vincent Batts already did for current, but for future stable versions and both architectures. The repository could be used with slackpkg+ and a corresponding higher priority. Of course, it would have to be kept in sync with any upstream updates. Sounds like quite a lot of responsibility (understand: work) to me.

Niki