CS290I Lecture notes -- LDAP

Lecture notes: http://www.cs.ucsb.edu/~rich/class/cs290I-grid/notes/LDAP/index.html

LDAP and You

LDAP is a directory service that is used in Grid Computing, among other things. As project 2 so vividly illustrates, resource discovery and naming are some of the core issues in Grid systems. Globus has standardized on an LDAP-based system known as the Metacomputing Directory Service (MDS). You will learn more about the specifics of this service later in the class; in this lecture we will cover LDAP in general and discuss how it can be used to retrieve NWS data for project 2.

Background

The Lightwight Directory Access Protocol (LDAP) was originally defined by RFC1487 in 1993. As we go through the LDAP interface and system you may find yourself wondering "...lightweight as compared to what??" In the "old" days, standards were defined before there were a number of implementations and the phrase "time to market" was rarely uttered by engineers. In this environment a standards body known as the ISO (progenitor of the much-maligned OSI standards) defined a system known as X.500. (Catchy, no? And they wonder why it didn't catch on...) This system was to act as "The Directory" of people -- a sort of "white pages" for the Internet. Despite a lot of work by a number of smart folks, the original implementation didn't catch on. However, to mitigate the complexity of the directory access protocol, a lighter-weight version was defined in the Internet Engineering Task Force (IETF). Now, at version 3 (defined in RFC2251), LDAP is widely used in the Internet at large, and in Grid systems in particular. We will cover:

Basic architecture of LDAP
Query Tutorial
C Example

Architecture

LDAP is an instance of a heirarchical database. That is, unlike a relational database, the main relations in a heirarchical database are parent-child. So, the structure of LDAP information is like an inverted tree. This structure is very familar to computer users as it is like filesystems and the like. However, unlike filesystems LDAP strings grow from right to left.

	c=us
	o=University of California, c=us
	ou=Santa Barbara, o=University of California, c=us
	ou=Department of Computer Science, ou=Santa Barbara, o=University of California, c=us

This string is known as the Distinguished Name (DN) of an object. The last component of this is called the Relative DN (RDN.) Obviously, like a filename, the RDNs under a single parent have to be unique. Objects in LDAP consist of attribute / value pairs. The RDN can be thought of as a distinguished attribute. In the above example, there are some typically-used attributes.

o stands for organization
ou stands for organizational unit
c is country (clearly)
cn is "common name"

So, a person's DN might look something like this:

	cn=Martin Swany, ou=Department of Computer Science, ou=Santa Barbara, o=University of California, c=us

LDAP and the NWS

However, what we need to focus on now is the specific use of LDAP in the NWS. First the part of the tree which NWS uses is:

		service=NWS, o=Grid

Other elements under the o=Grid part of the tree may be discussed later in conjunction with Globus.

Queries

	ldapsearch -h nws.cs.ucsb.edu -p 3389 -b "service=nws,o=grid" "objectclass=GridDaemon"

Caveat: If you get an error like this ldap_sasl_interactive_bind_s: No such attribute, you are using a newer version of the LDAP client library. In that case, you need to respectfully decline to use SASL (Simple Authentication and Security Layer) by giving the -x flag to ldapsearch. This query returns something like this:


	# bird:8060, NWS, Grid
	dn: daemon=bird:8060,service=NWS,o=Grid
	objectClass: top
	objectClass: service
	objectClass: GridDaemon	
	daemon: bird:8060
	fqdn-port: bird:8060
	daemonType: sensor
	ipAddress: 128.111.49.44

Which is just what you want. But, it also returns this:

	# pompone.cs.ucsb.edu:8051, NWS, Grid
	dn: daemon=pompone.cs.ucsb.edu:8051,service=NWS,o=Grid
	objectClass: top
	objectClass: service
	objectClass: GridDaemon
	daemon: pompone.cs.ucsb.edu:8051
	fqdn-port: pompone.cs.ucsb.edu:8051
	daemonType: memory
	ipAddress: 128.111.41.35

Which is not what we want. This object represents the NWS Memory process running on pompone. So, let's refine our search as follows:

	ldapsearch -h nws.cs.ucsb.edu -p 3389 -b "service=nws,o=grid" "(&(objectclass=GridDaemon)(daemonType=sensor))"

I think that you'll find that gives you only the results that you want. Now, let's look at a query that will actually return the data from the NWS. The data from the NWS is in a different part of the tree. This is primarily because it is "lazily evaluated". That is to say that there are no LDAP objects there until they are asked for. For this reason, future versions of the NWS LDAP server may disallow global searches. At any rate, this part of the tree is identified by the base "o=data,service=nws,o=grid" and queries against it look like this:

	ldapsearch -h nws.cs.ucsb.edu -p 3389 -b "o=data,service=nws,o=grid" "forecast=linus*availableCpu*"

Which returns things that look like:

	# linus:8060.availableCpu.0, data, NWS, Grid
	dn: forecast=linus:8060.availableCpu.0,o=data,service=NWS,o=Grid
	objectClass: top
	objectClass: service
	objectClass: GridForecast
	forecast: linus:8060.availableCpu.0
	timestamp: 1011837468
	value: 0.999330
    mse-forecast: 0.649350
    mse-error: 0.000031
    mae-forecast: 0.649350
    mae-error: 0.034391

To use the real power of the NWS, you don't need the measurements -- you need the forecasts. Unlike previous versions, this one only provides the forecasts. The most recently measured value is provided as well.

C Example

A simple C example is available here (along with its makefile.