LDAP Programming in Python
You've heard about the next generation directory protocol called LDAP (lightweight directory access protocol), and you're wondering if it's possible to write programs that can interact with it. Maybe you've even set up an LDAP server of your own, and now you want to write programs for it. To these ends, this article gets you ready to write your own programs to automate the querying process of LDAP servers. Hopefully, it also provides you with a solid foundation for extending your knowledge to write configuration scripts and whatever else you want to do with LDAP.
Most major programming languages have an LDAP API, but I chose to use Python because it is perhaps the easiest and clearest language with which to demonstrate. If you do not already understand the basics of the Python programming language and LDAP, you probably should come back to this tutorial after you have become better acquainted with them.
Writing programs that access LDAP servers is easy to do using Python and python-ldap. The python-ldap package contains a module that wraps the OpenLDAP C API and provides an object-oriented client API to interact with LDAP directory servers. The package also contains modules to do other tasks related to LDAP, such as processing LDIF, LDAPURLs and LDAPv3 schemes and more.
Currently, standard implementations of Python do not come with python-ldap, but you can download it as a third-party package from SourceForge.
The best way to learn is to write an example program, so let's write a small and complete program to fetch some specific contact information from an LDAP server. Because indentation matters in Python, all the code given below is indented, so copy it as you see it.
The first thing we need to do is import the ldap module. So open your favorite text editor and type import ldap. For this program, we need to create two simple functions:
a main() function that binds the program to an LDAP server and calls a search function
a function called my_search() that is used to retrieve/display data from the server.
Let's create our main function and set up variables to authenticate with the LDAP server by using def main():.
If you are using a public server, you can leave the values for the who and cred blank. You can get a list of some public LDAP servers here
. It looks something like this:
server = "ldap.somewhere.edu" who = "" cred = ""
Now we need to make a keyword set to what we want our search string to be. I use my first name for this sample program:
keyword = "ryan"
Next, we need to bind to the LDAP server. Doing so creates an object named "l" that is then used throughout the program.
try: l = ldap.open(server) l.simple_bind_s(who, cred) print "Successfully bound to server.\n"
We're now ready to query the server. We also now catch any possible errors if there is a problem authenticating:
print "Searching..\n" my_search(l, keyword) except ldap.LDAPError, error_message: print "Couldn't Connect. %s " % error_message
Having written our main function, we now can create our search function:
def my_search(l, keyword):
In a moment we will be calling python-ldap's built-in search method on our l object. Four variables--base, scope, filter and retrieve_attributes--are the parameters of that search method. Base is used for the DN (distinguished name) of the entry where the search should start. You can leave it blank for this example:
base = ""
For scope we use SCOPE_SUBTREE to search the object and all its descendants:
scope = ldap.SCOPE_SUBTREE
Our search filter consists of a cn (common name) and our keyword. Putting asterisks around our keyword (ryan) will match anything with the string ryan, such as Bryant.
filter = "cn=" + "*" + keyword + "*"
The last argument we pass to the search method is used to return all the attributes of each entry:
retrieve_attributes = None
Now, let's setup a few more variables, including a counter to keep track of the number of results returned:
count = 0
a list to append the results to:
result_set = 
and a variable to specify the length, in seconds, we're willing to wait for a response from the server:
timeout = 0
Now we can begin our search by calling python-ldap's search method on our l object:
try: result_id = l.search(base, scope, filter, retrieve_attributes)
Store any results in the result_set list
while 1: result_type, result_data = l.result(result_id, timeout) if (result_data == ): break else: if result_type == ldap.RES_SEARCH_ENTRY: result_set.append(result_data)
If we were to print result_set now, it might look like a big list of tuples and dicts. Instead, step through it and select only the data we want to see
if len(result_set) == 0: print "No Results." return for i in range(len(result_set)): for entry in result_set[i]: try: name = entry['cn'] email = entry['mail'] phone = entry['telephonenumber'] desc = entry['description'] count = count + 1
Display the data, if any was found, in the following format:
1. Name: Description: E-mail: Phone: 2. Name: Description: E-mail: Phone: etc..
print "%d.\nName: %s\nDescription: %s\nE-mail: %s\nPhone: %s\n" %\ (count, name, desc, email, phone) except: pass except ldap.LDAPError, error_message: print error_message
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Interview with Patrick Volkerding
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide