Re: PAM still a goal for slink?
jdassen@wi.leidenuniv.nl writes:
> On Wed, Sep 02, 1998 at 12:07:03PM +0000, Duncan Thomson wrote:
> > Having looked at the debian project history document, the aims for slink
> > appear to be FHS compliance, integration of APT, and the appearance of
> > GNOME.
> > Previously, I'd thought that PAM integration was a goal of slink too. Has
> > this fallen by the wayside, or is it still a goal? Is it progressing -
> > are any of the base packages already PAM-ised in slink?
> Not that I'm aware of. I suspect that the best way of getting PAM in slink
> is to find a small dedicated group of volunteers to PAMify packages (and
> establish communication with the upstream PAM developers) and provide the
> regular package maintainers with easily integratable patches for PAM
> support.
> Additionaly, the last PAM packages release that was done by the maintainer
> was in March 1997. Klee, perhaps it is time to find new maintainer for them?
> > At the moment, I don't need PAM, but in six months time, I will. RedHat
> > supports PAM, and has done for several releases. I feel PAM integration
> > is too important to disappear from slink's goals... and I don't want to
> > have to change to RedHat just to get PAM support...
> I think that with our new dedication to achieving timely releases, the
> emphasis on release goals has diminished somewhat. Don't expect the slink
> release to be postponed because it isn't fully PAMified yet. Instead, if you
> want to see a fully PAMified slink, work on it.
I've done a netstd. As I said there are two open issues:
1. When we move to PAM 0.64, we will have to recompile all of the
PAM stuff. If we want to retain compatibility with Red Hat, we have
to keep the same soname for libpam.so.0. Either way, I suspect the
libraries in /usr/lib/security will only work with one or the other
PAM.
2. The libraries should be in /lib/security, not /usr/lib/security,
if we expect login to work before the /usr partition is mounted (do
we need this?) Also, for compatibility, we should put them in
/lib/security.
If we decide to bump the soname, we could move the modules at the same
time, and both versions could coexist for a time. As far as I know,
only ppp-pam currently uses the PAM library.
Is klee still maintaining the PAM package (I see a few non-maintainer
releases in the changelog)? What solutions do people like to the
above problems? (Judging from Red Hat's patches to rsh, there are
incompatibilities between 0.53 and newer versions of PAM.)
As far as actually tweaking packages, it's fairly easy. Red Hat's
source RPMs have their PAM patches nicely seperated and
rpm -q --whatrequires pam
will list all of the PAM dependent packages on a Red Hat system. (An
alternative checklist would be the directory listing of /etc/pam.d on
a Red Hat system.)
Steve
dunham@cps.msu.edu
Reply to: