PAM Kerberos and ADS for Slackware-current - Call for testing
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.
Rebuilt exim with sasl support. The new default config supports both PAM and GSSAPI.
Tested the Single Sign On.
So far everything is working fine with apache cups imapd exim ldap firefox and thunderbird.
You have to create http/ imap/ and smtp/ principals and export their keys to keytabs readable by apache exim and imapd.
To enable the SPNEGO for firefox and thunderbird you have to add a "network.negotiate-auth.trusted-uris" string in about:config.
Cups serves a shared PDF printer with Kerberos authentication. No password needed for printing if the user is known.
Apache serves a mod_auth_kerb protected webdav folder with calendar for Lightning.
And Lightning happily uses its webdav calendar w/o prompting for password.
Thunderbird connects to imap and smtp by GSSAPI. No password needed.
Thunderbird address book connects fine to the LDAP by GSSAPI and pulls users info.
Firefox connects to kerberos protected folder w/o asking for password. Trying the same with links pops the authentication dialog.
Addendum 20150422: We already know that PAM is desired by some and not by others. This is not a place to discuss it or give pros/cons of either, as those are pretty much known too. Whether it's ever been or is currently under consideration is not my place to say, but I will point out that every time there's a new flame fest about it, none of us want to touch it again for a while. Let that be a point of education.
That makes the maintenance of this stuff pointless.
The latest blackout at slackware.com was enlightening. The goal of this project was to bring some functionality needed in a multiuser production environment. After this long radio silence I can't see how someone in his right mind will consider Slackware for such environment. So there is no need to add this extra level of complexity. No one will need it.
That makes the maintenance of this stuff pointless.
The latest blackout at slackware.com was enlightening. The goal of this project was to bring some functionality needed in a multiuser production environment. After this long radio silence I can't see how someone in his right mind will consider Slackware for such environment. So there is no need to add this extra level of complexity. No one will need it.
EOF
Your interpretation is incorrect.
Slackware has a closed development model: there are regular updates to the ChangeLog.txt but you are not informed what happens inbetween updates. That's how it has always been so do not act surprised.
There are various people on this forum who work closely with Patrick, and who have been pretty vocal in telling everybody that Slackware is not dead by far, that development is continuing and that (big) updates are coming up. Those people are all open to suggestions and Pat watches these threads too. What's being discussed on LQ is often taken into account when updates to Slackware occur.
What you fail to grasp is that the update of certain core libraries is not trivial and will require multiple rebuilds of a lot of packages in order to get rid of all references to no longer available library files. It takes time! Hence the delay in updates.
And making strategic decisions (PAM, Kerberos, systemd which are of a different category than most other requests) will take even more time because all options have to be considered carefully. Slackware is a conservative distro in that regard.
Slackware is a one-man show. There are some helper monkeys who prepare the way for Pat but bottomline is that every package is compiled by Patrick before it goes into the distro. It takes time!
If you interpret that as "blackouts" and "radio silence" then you, like some others, have fallen victim to the same update frenzy that affects several other distro communities. Try to get used to this, will you?
I see no justification for your interpretation of that anonymized context-less quoting of Robby Workman in another thread. Robby talks about the PAM flame-fests that resurface from time to time and will only serve to irritate the Slackware team. He politely asks not to keep requesting PAM.
Having a clean set of PAM/Kerberos/LDAP and even systemd packages (or instructions) for Slackware - provided by the community - is irrelevant to that comment made by Robby. In fact I think that this valued valued by several others. Why then would your effort be pointless? This distro allows people to make changes to the core and get away with it.
You yourself asked "Please don't turn this thread into pro/anti PAM discussion" in your original post. Yet you bring PAM into this thread yourself...
That makes the maintenance of this stuff pointless.
The latest blackout at slackware.com was enlightening. The goal of this project was to bring some functionality needed in a multiuser production environment. After this long radio silence I can't see how someone in his right mind will consider Slackware for such environment. So there is no need to add this extra level of complexity. No one will need it.
EOF
I have a suggestion to make for this. There's a famous Austrian saying: "Don't throw rocks when you sit in a glass house." That's me, by the way, sitting in the glass house, so I won't throw any rocks. Here's the lesson that I have retained after the big controversy earlier this year.
The work you have done here is quite an achievement. What you could do now is go that extra bit further and try to maintain a binary package repo for Slackware stable, sporting your packages. This way, folks who want to implement this stuff in Slackware can simply point to your repo, define a priority in slackpkg+, and voilà, that's it.
And then, once this has gained some popularity and more and more folks start using it, there's a chance this stuff will eventually (...) find its way into the official release.
As far as I understand, this is how Slackware works.
I have a suggestion to make for this. There's a famous Austrian saying: "Don't throw rocks when you sit in a glass house." That's me, by the way, sitting in the glass house, so I won't throw any rocks. Here's the lesson that I have retained after the big controversy earlier this year.
The work you have done here is quite an achievement. What you could do now is go that extra bit further and try to maintain a binary package repo for Slackware stable, sporting your packages. This way, folks who want to implement this stuff in Slackware can simply point to your repo, define a priority in slackpkg+, and voilà, that's it.
And then, once this has gained some popularity and more and more folks start using it, there's a chance this stuff will eventually (...) find its way into the official release.
As far as I understand, this is how Slackware works.
Cheers,
Niki
I support this proposition.
I would be willing to help test and report bugs or even maintain some of this project.
I have a small network of ten or so hardware and virtual machines running slackware stable (32/64) and current. And you know how hard it is to manage this kind of network without a centralized directory.
Distribution: slack 7.1 till latest and -current, LFS
Posts: 368
Rep:
Quote:
Originally Posted by kikinovak
I have a suggestion to make for this. There's a famous Austrian saying: "Don't throw rocks when you sit in a glass house." That's me, by the way, sitting in the glass house, so I won't throw any rocks. Here's the lesson that I have retained after the big controversy earlier this year.
The work you have done here is quite an achievement. What you could do now is go that extra bit further and try to maintain a binary package repo for Slackware stable, sporting your packages. This way, folks who want to implement this stuff in Slackware can simply point to your repo, define a priority in slackpkg+, and voilà, that's it.
And then, once this has gained some popularity and more and more folks start using it, there's a chance this stuff will eventually (...) find its way into the official release.
As far as I understand, this is how Slackware works.
Cheers,
Niki
That is definitely the way to start.
On the side note, lets make sure we unify the implementation on things like pam.
so 1 place that we all can grab pam files and build upon that part.
@ivandi
If you like, we can make a github page under Dlackware for pam
No citation needed, I think this is about the dumbest claim about copyright infringement I have seen in many years. He removed himself from the discussion a few posts ago anyway. Just another person full of spite who removes his Slackware scripts because he does not like what he hears. Pity.
No citation needed, I think this is about the dumbest claim about copyright infringement I have seen in many years. He removed himself from the discussion a few posts ago anyway. Just another person full of spite who removes his Slackware scripts because he does not like what he hears. Pity.
The dumbest copyright claim can be found in the header of thousands of scripts at SBO or Slackware.
A few posts ago I said that I see no point to maintain this stuff along with Slackware (keeping up with the ChangeLog and so on). That didn't mean that I would stop playing with it. I redirected the url above to point to the PAM folder of my home setup that I shared in another thread.
I removed the scripts because I refuse to play your silly copyright games.
And yes, its a pity to call someone "full of spite" just because you aren't agree with him.
I fail to see how a template needs a license especially when those templates have always been public domain.
The only time we've ever griped about a license is when someone redistributes work without noted changes to the existing BSD/MIT style licensed completed work script.
Take your criticism and grow from it. I took a badgering from some of my packages, but I didn't go yanking my repo.
However, you should use a license ivandi. There are good reasons to do so especially to protect your work and claim the work comes without warranty.
The dumbest copyright claim can be found in the header of thousands of scripts at SBO or Slackware.
A few posts ago I said that I see no point to maintain this stuff along with Slackware (keeping up with the ChangeLog and so on). That didn't mean that I would stop playing with it. I redirected the url above to point to the PAM folder of my home setup that I shared in another thread.
I removed the scripts because I refuse to play your silly copyright games.
And yes, its a pity to call someone "full of spite" just because you aren't agree with him.
Cheers
OK I'll bite.
Please point me to the spots in a licence block in a SlackBuild script (example below taken from liboil.SlackBuild in Slackware itself) where there's a "copyright game" being played by which you are affected in such a way that you needed to remove access to your SlackBuild scripts?
Code:
# Copyright 2008 Michiel van Wessem <michiel@slackbuilds.org>
# Copyright 2008, 2009, 2010 Patrick J. Volkerding, Sebeka, Minnesota, USA
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met:
#
# * Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
# Slackware build script for liboil
# Modified by Robby Workman <rworkman@slackware.com>
As you can see, the text asks you to keep the original copyright lines intact so that future readers know who started with this script. If your rework does not cause a fundamental change to the SlackBuild script's logic, it is OK to add a line "Modified by" like the above example shows.
Don't think that this is a game. It is about giving credit where credit is due. You will notice from the above example that the script was originally not written by the Slackware team, and after all this time you will still find that the original submitter is credited. How is that wrong?
Writing a SlackBuild script is NOT trivial by default, if that is what you are thinking. Yes, many of the scripts move along the same lines, but using a SlackBuild template does not mean that a package will follow with minimal effort. You still have to check your new package for anomalities and omissions; check if the SlackBuild script installs files outside of the package straight into the filesystem etc. If you do all this quality checking then you deserve the credit.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
