On Mar 17,  9:31pm, Miles Nordin wrote:
} On Tue, 16 Mar 1999, Thor Lancelot Simon wrote:
} 
} > Is there a good argument against PAM
} 
} 1. lack of support for S/Key, KerberosIV, and GSSAPI.

     So, write a module to do those.  At least you only have to write
the module once, rather than implementing it for every application you
have that does authentication.

}   i suspect most PAM users do not use Kerberos or S/Key, and that most
}   Kerberos and S/Key users do not use PAM, and base my judgement partly
}   on this.

     These are not mutually exclusive concepts.  When it comes right
down to it, most users use a plain passwd file (possibly with some
form of shadowing).

} 2. flakiness (still) of the current versions of PAM, and likelihood of 

     This is an attribute of a particular implementation, not of the
API, and therefore doesn't belong in a discussion of whether NetBSD
should adopt PAM.

}    substantial future architectural changes in PAM.  unlikelihood that 

     So what?  Everything is open to change.

}    the NetBSD project would have much influence on these changes, which 
}    would intimately affect the source tree.

     No, it wouldn't.  NetBSD could do anything it wanted with its
implementation as long as it followed the "standard" API, so that
third-party apps would continue to work.

} 3. likelihood that future versions of PAM will become needlessly 
}    complex, as its advocates try to compete feature-for-feature
}    with Solaris.

     There are at least three (four?) major versions of UNIX using PAM
now.  I don't think this is that much of a problem.

} 4. good, consistent, shadow-capable authentication support already in the
}    NetBSD tree (something Linux didn't have, which largely motivated the
}    adoption of PAM)

     There is a lot more to PAM then just shadow password files.

} > or modular rc scripts?
} 
} i have several NFS-rooted NetBSD boxes, and one NFS-rooted Linux box.  
} All the NetBSD boxes can halt or reboot just fine, but the RedHat box
} cannot.  I have fixed two rc.d-related problems that get it _closer_ to

     This isn't unusual.  I've seen this problem with a number of SysV
variants.  That's why when people were talking about adding
/etc/rc.shutdown, I was pushing for a timeout.

} it works better with vendor package management software.  many UNIX
} sysadmins are not comfortable editing text files, and prefer to use HP's
} sam or RedHat's glint.  however i think people ditch vendorware in favor

     These people are not sysadmins, they only play at being one.

}-- End of excerpt from Miles Nordin