directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <enriqu...@gmail.com>
Subject Re: [LDAP] LDAP usage in GRID technology
Date Fri, 01 Jun 2007 20:57:39 GMT
On 6/1/07, Ersin Er <ersin.er@gmail.com> wrote:
> ...
> I have been doing some research on GRID technology recently. I saw
> that LDAP is being used in a few places in GRID engines. Can someone
> clarify how LDAP is being used in GRID technology today?

Hi, Ersin,

I've worked with Sun's GridEngine, with both OpenLDAP and MS Active
Directory for various network infrastructure services.  We
mass-produced Xen hosts and used Kerberos to centralize authentication
and LDAP for storing every bit of infrastructure data we could.  In
the end, you could boot up a Xen host (guest) and have it ready to
accept jobs by as little configuration as setting its MAC address.
You can put users and groups in LDAP or use Samba Winbind to store
mappings of users/groups to Active Directory users/groups by storing
the mappings in LDAP.  In either case you can then configure the
relevant PAM modules in Linux and use those users/groups on any host.
We also put automount information in LDAP and mounted shares using
NFSv4.  MS AD is storing DHCP/DNS in a DIT so you could consider that
as using LDAP, too.

Recently there was a thread on storing sudo information in LDAP.  That
was news to me, but I would probably do that, too.

Though your question was about LDAP I'd like to add that Kerberos
played a role in securing the NFSv4 mounts and in providing
centralized authentication so you could seamlessly SSH between hosts.
Kerberos also secured LDAP itself (via SASL GSSAPI).  Kerberos can be
a requirement when the executing jobs access sensitive data, such as
in national labs.

The benefit of LDAP/Kerberos was that we limited the amount of one-off
configuration we had to do per Xen host and there can be a lot of
hosts in a grid.  Also, we had a lot of different platforms and
processors since the customer was an ISV (independent software vendor)
testing their products and Kerberos/LDAP is widely supported.

Most of my notes are in a raw form but they provide the foundation for
the INTEROP space in Confluence:

http://cwiki.apache.org/confluence/display/DIRxINTEROP/Index

My hope has always been to revisit those notes and simplify what was a
disparate mix of proprietary and open-source infrastructure and really
hone it to make it easier to use, with a focus on ApacheDS.

Enrique

Mime
View raw message