LinuxQuestions.org
Visit Jeremy's Blog.
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 10-12-2015, 04:47 PM   #196
kikinovak
MLED Founder
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: CentOS, OpenSUSE
Posts: 3,440

Rep: Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108

Quote:
Originally Posted by ivandi View Post
Well, I hate to be pedantic. But only the second project in your list provides "out of the box" directory integration. And it can definitely be used as a base for implementing this functionality in Slackware. So far that's the main reason threads like this have been revived.

BUT only in a fantasy world called Slackware a complete and utter idiot will deploy my project "as is" in production environment and will be waiting for me to finish my glass of wine and eventually look at some important security updates.


Cheers
While I concur with you from a purely factual and technical point of view, you could have stated this in a more civil manner.
 
Old 10-12-2015, 09:44 PM   #197
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,764

Rep: Reputation: 137Reputation: 137
No one has addressed my issue. Is there a way for a member server to authenticate if not with PAM? Seems to me that if Slackware were usable in an AD/DC environment, then this functionality would be crucial. All web posts I've seen so far say PAM is a must for single-sign-on. How would one do this in Slackware without PAM?
 
Old 10-12-2015, 11:20 PM   #198
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,449
Blog Entries: 15

Rep: Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023
Only if you want to do a lot of extra work, break things, and reconfigure a lot of stuff that will take you down a no-man's-land path. It can be done, but it's more akin to pulling teeth while performing an amputation, open heart surgery, and delicate brain surgery on the same patient at the same time without anesthesia.

If you do need PAM, just build PAM, install it, and rebuild packages to use PAM as needed. It's very cut and dry.

Last edited by ReaperX7; 10-12-2015 at 11:34 PM.
 
Old 10-13-2015, 12:28 AM   #199
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,727

Rep: Reputation: 741Reputation: 741Reputation: 741Reputation: 741Reputation: 741Reputation: 741Reputation: 741
Quote:
Originally Posted by ivandi View Post
Well, I hate to be pedantic. But only the second project in your list provides "out of the box" directory integration. And it can definitely be used as a base for implementing this functionality in Slackware. So far that's the main reason threads like this have been revived.

BUT only in a fantasy world called Slackware a complete and utter idiot will deploy my project "as is" in production environment and will be waiting for me to finish my glass of wine and eventually look at some important security updates.


Cheers
agree, except, it's not the fantasy world called Slackware, just some guys here that repeat 'use this use that do it your self' without having to much clue what they are talking about, and this since years. we have here a good archive that not only documents the lack of understanding of a problem but also the absolute inability to learn and adopt to facts.
 
Old 10-13-2015, 03:40 AM   #200
Qury
Member
 
Registered: Feb 2004
Location: Naas,IE
Distribution: Slackware
Posts: 200

Rep: Reputation: 180Reputation: 180
I think we can debate all we want about the inclusion of PAM into Slackware it is nothing more than feedback(?) to Patrick and the core dev team. While Slackware development is not a democratic process, and wishes and request are not necessarily granted, i say it out loud:

@Volkerdi
Please consider the inclusion of PAM into Slackware.


and if you do not that will still be OK with me
 
3 members found this post helpful.
Old 10-13-2015, 03:57 AM   #201
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,449
Blog Entries: 15

Rep: Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023Reputation: 2023
Packages could be available on slackpkg+ if the authors would get their act together and release standardized Slackbuild scripts with proper licenses, gpg keys, and binary packages with proper tags and labels. We have one developer of PAM packages who absolutely refuses to do this, so blame that person for their own lack of following the rules to get packages out for not making them publicly available over the standard channels.

I think Vincent's could be added though, but it would be limited to Slackware 14.1 until 14.2 is completed and released. However, Vincent's does have packages with properly tagged package names to discern between pam and non-pam packages.

Last edited by ReaperX7; 10-13-2015 at 04:01 AM.
 
Old 10-13-2015, 04:46 AM   #202
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
Blog Entries: 2

Rep: Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866
Quote:
Originally Posted by ReaperX7 View Post
Packages could be available on slackpkg+ if the authors would get their act together and release standardized Slackbuild scripts with proper licenses, gpg keys, and binary packages with proper tags and labels. We have one developer of PAM packages who absolutely refuses to do this, so blame that person for their own lack of following the rules to get packages out for not making them publicly available over the standard channels.
Are you seriously telling other people that they should blame ivandi for not obeying your made up rules with providing his work in a format that is not compatible with a non-standard tool?
 
2 members found this post helpful.
Old 10-13-2015, 06:44 AM   #203
chemfire
Member
 
Registered: Sep 2012
Posts: 251

Rep: Reputation: Disabled
mfoley,

Yes you can integrate Slackware as a member server in and AD environment without PAM.

There are some limitations:
1) No of the X11 session managers well be able to authenticate you will have to login to run level 3 and than "startx" or via SSH
2) Other server daemons like apache / proftpd etc won't be able to remote authenticate user. Application layer work arounds are possible for both
3) NFS
4) consistent rid/gid/uid mappings accross servers, as long as everything stays local on one box or is accessed via samba its all fine, but if you copy files off to removable media or via nfs or something like that from SlackwareBoxA to SlackwareBoxB the user and group owners will 'change' the 'physical' uid and gids will of course remain the same but users they map to will change just as if the two boxes had different /etc/passwd and /etc/group files.

What will work:
1) Console logons
2) ssh logons
3) users and group memberships
4) file + print sharing via Samba (with users AD credentials) (as client and server)

There are some old articles on doing it, if you Google but you can figure it out yourself pretty easily if you can find them. The basic recipe is this. I don't recall all the specifics because I don't have an AD environment handy just now, but I did this a few years ago on Slackware 14.0

1) build / install the MIT kerberos package from slackbuilds
2) recompile Samba using the slackbuild add the switches to build nss_windbindd.so and link the MIT kerberos package
3) join the domain using samba's 'net' command
3a) make sure the rid/gid/uid mapping in samba won't conflict with what you have in /etc/passwd and /etc/group
4) replace login with login.krb5 in /etc/inittab (be sure to leave at least one VC with a regular /sbin/login ! otherwise if the domain is unavailable you won't be able to logon even as root!)
5) rebuild ssh with kerberos support from the slackbuild
6) add winbindd to /etc/nsswhich
7) debug / troubleshoot / cry a little

If you just need a web/file/ftp server or just want to share your AD password for your workstation it can work well enough but its kludgy.
 
4 members found this post helpful.
Old 10-13-2015, 06:54 AM   #204
pcninja
Member
 
Registered: Oct 2013
Location: SE Wisconsin, USA
Distribution: Arch Linux
Posts: 93

Rep: Reputation: Disabled
Unless PAM offers an advantage for a large amount of users, don't include it.
 
1 members found this post helpful.
Old 10-13-2015, 07:44 AM   #205
ivandi
Member
 
Registered: Jul 2009
Location: Québec, Canada
Distribution: CRUX, Debian, Slackware64-current
Posts: 500

Rep: Reputation: 830Reputation: 830Reputation: 830Reputation: 830Reputation: 830Reputation: 830Reputation: 830
Quote:
Originally Posted by chemfire View Post

1) build / install the MIT kerberos package from slackbuilds
2) recompile Samba using the slackbuild add the switches to build nss_windbindd.so and link the MIT kerberos package
3) join the domain using samba's 'net' command
3a) make sure the rid/gid/uid mapping in samba won't conflict with what you have in /etc/passwd and /etc/group
4) replace login with login.krb5 in /etc/inittab (be sure to leave at least one VC with a regular /sbin/login ! otherwise if the domain is unavailable you won't be able to logon even as root!)
5) rebuild ssh with kerberos support from the slackbuild
6) add winbindd to /etc/nsswhich
7) debug / troubleshoot / cry a little
Let's see how the same process looks using PAM:

1) compile MIT Kerberos
2) compile Linux-PAM
3) recompile shadow with pam support
4) recompile samba with pam support and use pam_winbind in your PAM setup.
5) add winbindd to /etc/nsswhich
6) join the domain using samba's 'net' command
6a) make sure the rid/gid/uid mapping in samba won't conflict with what you have in /etc/passwd and /etc/group
6b) use pam_group to give domain users a local group membership upon login (like audio,video ....)
7) recompile any other package that you need to be AD aware with pam support. there is no limitations


Cheers
 
2 members found this post helpful.
Old 10-13-2015, 07:57 AM   #206
kikinovak
MLED Founder
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: CentOS, OpenSUSE
Posts: 3,440

Rep: Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108Reputation: 2108
Quote:
Originally Posted by pcninja View Post
Unless PAM offers an advantage for a large amount of users, don't include it.
Last summer, the poll I published about the subject triggered a heated debate about the respective merits and disadvantages of PAM. I don't want to rehash this, but here's what we can say for sure: 54 Slackware users explicitly voted for the inclusion of PAM, and another 54 Slackware users explicitly voted against it. Now it's up to the Slackware developers to draw their own conclusions. As far as I'm concerned, though I admit being heavily biased, either decision will be OK with me.

Cheers,

Niki
 
Old 10-13-2015, 09:19 AM   #207
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,889

Rep: Reputation: Disabled
Seems like Pat and the other devs are damned if they do and damned if they don't... That said I think the simpler and easier option with less redhat abstractions is preferable. If someone really wants pam, but is not willing to administrate their own system they should probably use another distro anyways.
 
Old 10-13-2015, 10:08 AM   #208
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,764

Rep: Reputation: 137Reputation: 137
Quote:
Originally Posted by chemfire View Post
mfoley,

Yes you can integrate Slackware as a member server in and AD environment without PAM.

There are some limitations:
Thank you for your response. Let me go through your comments:

Quote:
1) No of the X11 session managers well be able to authenticate you will have to login to run level 3 and than "startx" or via SSH
Hmmm, this is less than desirable. I would like a GUI login.

Quote:
2) Other server daemons like apache / proftpd etc won't be able to remote authenticate user. Application layer work arounds are possible for both
Not a problem. I don't need apache, etc. to authenticate in this way.

Quote:
3) NFS
Could you elaborate? What about NFS won't work? Could my Samba4 server not export with the AD user's UID:GID?

Quote:
4) consistent rid/gid/uid mappings accross servers, as long as everything stays local on one box or is accessed via samba its all fine, but if you copy files off to removable media or via nfs or something like that from SlackwareBoxA to SlackwareBoxB the user and group owners will 'change' the 'physical' uid and gids will of course remain the same but users they map to will change just as if the two boxes had different /etc/passwd and /etc/group files.
I'll burn that bridge when I get to it ...

Would all of the above limitations work wit PAM?

Quote:
What will work:
1) Console logons
2) ssh logons
3) users and group memberships
4) file + print sharing via Samba (with users AD credentials) (as client and server)

There are some old articles on doing it, ...
"Old articles ..." Why old? I would think that "Single sign on" would be well established in the Unix world for decades now, and would be a useful and common implementation for Linux networks.

Quote:
... if you Google but you can figure it out yourself pretty easily if you can find them.
No, it's not been easy. To date probably the most difficult thing I've tried to do in Linux. Setting up Samba4 as our SBS 2008 replacement was a snap by comparison. Lots of articles out there, yes, and I've joined several maillists and forums. For every 3 respondants there are 5 ways of doing this! Articles are not at all clear on e.g. where Kerberos gets installed. etc. etc. etc.

Quote:
...I don't have an AD environment handy just now
and, despite all the maillists and forums, I too have not found anyone who is actually doing this now.

Quote:
1) build / install the MIT kerberos package from slackbuilds
2) recompile Samba using the slackbuild add the switches to build nss_windbindd.so and link the MIT kerberos package
Samba4 supposedly has its own Heimdal Kerberos built in. Theoretically, I don't need a separate Kerberos package. Not yet sure if that work with a MIT kerberos on the clients.

Quote:
3) join the domain using samba's 'net' command
I have been following the instructions at https://wiki.samba.org/index.php/Set..._Member_Server but the join doesn't work.

Code:
$ net ads join -U administrator
Enter administrator's password:
Failed to join domain: failed to lookup DC info for domain 'HPRS.LOCAL' over rpc: Undetermined error
I am researching this now. Still could use help.

Quote:
3a) make sure the rid/gid/uid mapping in samba won't conflict with what you have in /etc/passwd and /etc/group
I believe I've just solved that issue yesterday.

Quote:
4) replace login with login.krb5 in /etc/inittab (be sure to leave at least one VC with a regular /sbin/login ! otherwise if the domain is unavailable you won't be able to logon even as root!)
What's a VC?

Quote:
5) rebuild ssh with kerberos support from the slackbuild
That sucks. Where? Server? Client? Both? What goes on the server and what goes on the client kerberos-wise are quite different, yet as I mentioned, webdocs are not clear about what goes where. They switch contexts (server/client) without much notice. Maybe the authors believe it's obvious.

Quote:
6) add winbindd to /etc/nsswhich
Did that.

Quote:
7) debug / troubleshoot / cry a little
Have been doing that -- a lot!

BeginRant (skip if you want)
I've been using Unix since 1988 (yep, that long) and virtually all flavors. This is the first time I've run across functionality that is actually easier in Windows than Unix. The Linux Samba4 AD/DC installed quite easily and replaced our Windows Small Business Server functionality pretty seamlessly. All the Windows 7 domain clients connected without problem (Start > computer > properties > Advanced System Settings > Computer Name > Change > Member of Domain, done!). Users were added with RSAT 'Active Directory Computers and Users'. The user simply logging into the WIN7 workstation was sufficient to "register" the user with redirected folders working perfectly on the AD/DC. These workstations need no PAM, Kerberos, etc configured on the AD/DC. Why can't Linux workstations simply ape what the Windows workstations are doing? Clearly the Linux AD/DC can handle it. And why is this process not straightforward on Linux anyway? The notion of single-sign-on has been around for decades -- I recall "clustering" on VAXNET back in the 90's, maybe before that. This seems like it should be a mature and commonly used technology in the Unix universe, yet I cannot find a single person who is actually doing it, nor any agreement on how it should be done.
EndRant

Last edited by mfoley; 10-13-2015 at 10:11 AM.
 
2 members found this post helpful.
Old 10-13-2015, 10:34 AM   #209
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,727

Rep: Reputation: 741Reputation: 741Reputation: 741Reputation: 741Reputation: 741Reputation: 741Reputation: 741
Quote:
Originally Posted by orbea View Post
Seems like Pat and the other devs are damned if they do and damned if they don't... That said I think the simpler and easier option with less redhat abstractions is preferable. If someone really wants pam, but is not willing to administrate their own system they should probably use another distro anyways.
they can not be damed by people that do not want PAM because they lose no functionality.
people that do not need PAM will not even notice that is's onboard
and go through the discussions, the arguments against PAM have 0 quality, it always the same, and since technical there is no reason, there is the 'you can do it yourself' approach for arguing against PAM.
 
1 members found this post helpful.
Old 10-13-2015, 11:23 AM   #210
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,889

Rep: Reputation: Disabled
I would notice if pam was added, I would also go out of my way to remove it assuming no one better qualified beat me to it. That said it would be far easier to maintain packages that would add pam as a few already are doing than it would be to maintain packages to remove pam. If you really want pam, then I would personally suggest you take charge of your own system and do it yourself or find another distro where the devs are more willing to spoon feed you like say ubuntu.
 
  


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

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 08:46 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