The small installations network filesystem and users.
Daniel Eischen
deischen at freebsd.org
Tue Jun 21 02:11:17 UTC 2016
On Mon, 20 Jun 2016, Zaphod Beeblebrox wrote:
>
> That-all-said, authentication is a possible huge win. I was recently
> involved in a deployment of ubuntu that included LDAP and even though it
> was a mess, it eventually was hammered into working. Ubuntu and the
> implementation were not my choice, but you do-what-you're-told when someone
> else is paying the bill. Honestly, I don't know how I would have pitched
> FreeBSD there. Not even ubuntu itself had LDAP right. It was a
> combination of third parties. Even with that gigantic head start, LDAP was
> a bear --- but AFAICT, LDAP is _required_ for NFSv4 deployments. Now, LDAP
> without Winblows is slightly less of a bear, _but_
>
> Maybe this dovetails with a subtext at BSDCan's keysigning BOF: that many
> projects risk irrelevance with their complexity. It's not that I believe
> complex setups are bad. But simple things need be simple. I have 3
> machines at home (for instance) and a cluster of 8 machines in colo (run
> the ISP). On my 3 machines at home, I run NFSv3 because it works and I can
> get it setup. I'd like to run NFSv4 because then my windows machines would
> look at it, but I run SMB instead (v3, no less) because it roughly works.
> So at home... I have three machines and a fairly liberal hacking time
> budget. I have failed at LDAP several times. I'm back to copying the
> master.password file around because that works. I don't like it, but it
> works. It seems like the breakeven for LDAP effort vs. scp master.password
> is somewhere around 50 machines. -ish.
>
> I realize the real problem is that authentication has become more complex
> in the world since networks can't be trusted. I have to wonder if we're
> getting back closer to that now with all the tunneling on wifi and campus
> networks. Sigh. I'm starting to feel like this whole post has no purpose.
We should support LDAP client out of the box, in base. What
sucks now is that we need 3 packages (plus their dependencies)
and multiple config files for ldap:
pam_ldap
nss_ldap
openldap-client
And modify/tailor 3 config files in ${LOCALBASE}, all similarly:
ldap.conf
nss_ldap.conf
openldap/ldap.conf
Then the secret files also in ${LOCALBASE}, again with the same
info:
etc/ldap.secret
etc/nss_ldap.secret
Then you have to deal with the certificates, and more than one is a
pain.
Then in ${BASE} you have to add an ldap file in /etc/pam.d/. And
modify /etc/nsswitch.conf.
It seems easier, with less config duplication, in Solaris (11):
# Initialize the NSS database.
$ certutil -N -d /var/ldap
$ chmod 444 /var/ldap/*.db
# Add your certificate(s).
$ certutil -A -n <certname> -i /tmp/certfile.pem -t CT -d /var/ldap
# Setup the system as an LDAP client.
$ ldapclient init <various ldap config options>
Modifying /etc/nsswitch.conf on FreeBSD is easier than Solaris, still
haven't gotten use to the many keystrokes needed for svc mods:
$ svccfg
svc:/system/name-service/switch> setprop config/host = astring: "files dns"
svc:/system/name-service/switch> setprop config/password = astring: "files [NOTFOUND=continue] ldap"
svc:/system/name-service/switch> setprop config/group = astring: "files [NOTFOUND=continue] ldap"
svc:/system/name-service/switch> select system/name-service/switch:default
svc:/system/name-service/switch:default> refresh
svc:/system/name-service/switch:default> validate
svc:/system/name-service/switch:default> quit
$ svcadm refresh name-service/switch
--
DE
More information about the freebsd-fs
mailing list