Re: Using CentOS 5 as server; best way to setup NFSv4?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Chris Brentano wrote:
> I would second OpenLDAP, having used it in production at two different
> employers. It's always been stable and reliable. If you're restarting
> slapd every 15 minutes I'd take a good hard look at the problem versus
> just migrating away from it.

I've been using LDAP for quite a while. I discounted using it starting
about 4 years ago. I inherited the existing broken LDAP installation,
the person that was there before me tried all sorts of things to
make it work. I never wanted to use it in the first place. So out
it goes. I came up with, at least for me is a much more scalable,
stable system authentication system based on SSH keys, and automatically
generated passwd/group/shadow files. Managed by a couple scripts I
wrote and distributed to the hundreds of nodes with
CFengine(www.cfengine.org).

I can dynamically create passwd/group/shadow files on the fly for an
"unlimited" amount of systems(in quotes because I need to manage the
classes in cfengine to determine what class gets what set of files).
Though at my current job I just have 3 different configs(mainly
for different root passwords depending on the system type). I wrote
the system about 2 years ago and used it extensively at my last job
and it worked wonderfully.

LDAP is good I suppose for application level authentication(e.g.
web apps). But for system authentication(all I really care about),
while it does work, it is (to me):

- overly complicated(schema and stuff, my OpenLDAP 2.2 to 2.3
  migration on my home network was a real pain)
- not many good tools to manage it(well that I'm aware of at least,
  I use raw LDAP editors for the most part, I'm sure I could
  write some scripts if I was serious about long term support of
  it)
- Maybe it's improved recently but replication in OpenLDAP used
  to be real sketchy. Configuration was arcane, and it was purely
  a master->slave relationship (not master<->master).
- SSL is damn picky. One of the things the former guy at my company
  tried to do was load balance a pair of LDAP servers for higher
  availability but was unable to get that to work with SSL
  (I haven't tried myself). I'm fairly certain it would work without
  SSL, but don't care enough at this point to put any work into it.
- I aim to eliminate any external dependencies on everything I can,
  last thing I need is some problem in LDAP taking down authentication
  for the entire network. I suppose if I really hork my custom
  generated password files the same could happen.
- Has a funny way of not working when the network is down <g>
- nscd is iffy to say the least. It's been mostly reliable on my
  home network over the past 7 years or so, but on occasion I login
  to my system and it tells me my user name is "I have no name!"
  (at least I can login at all since I use SSH key authentication).
- Without nscd LDAP can be sluggish at times so it's a tough
  trade off..

Of course everyone's situation is different and I will admit that
LDAP is a suitable solution for some, just not for me(anymore).

The reason I use it at home still is because it was my testing
ground for my LDAP deployment at my company 7 years ago, I was
getting close to replacing the local NT4 authentication server
with samba-tng when they decided to downsize the company and
well there went that plan :)

It also helps that I don't have to support any windows users
(I saw your next comment about AD and exchange stuff).

LDAP was an interesting thing to play with, back in my early
days with it the documentation was so bad I spent weeks or
even months, with trial and error working with OpenLDAP, and
getting samba-tng with domain authentication working, Netscape
Roaming profiles with LDAP, and postfix mail routing. I even
wrote a HOWTO doc at http://howto.aphroland.org/HOWTO/LDAP
though I haven't updated it since 2003 I think. It was fun,
learned a lot. But have learned even more since.

I toyed with the idea of using the SSH patch to store SSH
public keys in LDAP a few years ago until I came up with the
idea to take advantage of CFengine (which is a hellishly
complicated tool in itself but I use it for far more things
than just this), and I decided to finally put my LDAP
ambitions to rest for good.

It's quite possible that my information about LDAP is out
of date, I admit I haven't been on the cutting edge of
that technology recently, though I still interface with
my home installation on a regular basis(just added some
new mail aliases into my LDAP config today actually), I
haven't changed the way I go about things in LDAP in
quite some time. Maybe I'm just gettin' old.

nate
(also don't like NIS, and hate kerberos)


_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux