An Introduction to perl-ldap
As systems get larger and the number of users they support increases, it becomes more difficult to manage systems using only the old-fashioned UNIX /etc/passwd file. A common solution to this problem is to use a Lightweight Directory Access Protocol (LDAP) server. The use of an LDAP server presents a problem to the system administrator, however, in that the contents of the database are no longer available in an easy to read or modify format. Hence, new tools must be written that allow standard, everyday tasks, such as adding or deleting users, to be performed.
This is where perl-ldap comes in. perl-ldap provides the Net::LDAP perl module, which enables easy access to the data contained in LDAP directories from Perl scripts. This makes the module a useful tool for system administrators and Web developers alike. The perl-ldap home page is located at http://perl-ldap.sourceforge.net/.
For this article, I assume you have a reasonable knowledge of LDAP and are a competent Perl programmer. If not, plenty of published material is available on the Internet covering both of these topics.
If you're running one of the popular Linux distributions, chances are perl-ldap already has been packaged for you, which makes installation simple. Under Debian Linux, perl-ldap is found in the libnet-ldap-perl package. Assuming that your /etc/apt/sources.list file contains an up-to-date Debian server, the following commands should install perl-ldap:
apt-get update apt-get install libnet-ldap-perl
Mandrake users will find what they need in the perl-ldap package; for Mandrake 9.1, the specific package is perl-ldap-0.27.01-1mdk.noarch.rpm. If you have urpmi configured correctly, you can install perl-ldap simply by entering:
This command also installs the perl-Authen-SASL and perl-XML-Parser packages, which are perl-ldap dependencies in Mandrake.
Red Hat does not appear to provide a perl-ldap package, so users of this distribution either have to obtain it from another RPM-based distribution or install it from the tar.gz package as described below.
If a pre-built package isn't available for your system, you have to download the tar.gz package from CPAN and install it yourself. As the LDAP protocol uses ASN1 encodings, you also need the Convert::ASN1 library. Although you probably can install perl-ldap without it, perl-ldap certainly won't run unless this library available. Both of these libraries are easy to install:
perl Makefile.PL make make test su root make install
As with other Perl libraries, perl-ldap is invoked with the use statement:
A new LDAP connection is opened using the new() function call. In the following example, we open a connection to a machine with hostname ldapserver.domain.name:
$ldap = Net::LDAP->new("ldapserver.domain.name");
Because we haven't specified which port number to use, perl-ldap assumes a default of port 389, the well-known LDAP port. If we want to use a different port, say 1389, we need to pass the port parameter:
$ldap = Net::LDAP->new("ldapserver.domain.name", port=>1389);
If the server is not reachable, the above function calls return an error after 120 seconds. You can use the timeout parameter to alter this:
$ldap = Net::LDAP->new("ldapserver.domain.name", timeout=>30);
After the connection has been initiated, you no longer need to refer explicitly to the Net::LDAP package. All of the perl-ldap functions are accessed as methods of the reference returned from the new() call. The most commonly used methods provided by perl-ldap are as follows:
$ldap->add(); # Add an entry to the server $ldap->bind(); # Bind to a directory server $ldap->delete(); # Delete an entry from the server $ldap->moddn(); # Modify an entry's Distinguished Name (DN) $ldap->modify(); # Modify the contents of an entry $ldap->search(); # Perform a search on a directory $ldap->unbind(); # Unbind from a server
These are described in detail below.
For this example, we assume that I have an LDAP directory with the following contents:
dn: dc=leapster,dc=org | -- dn: cn=admin,dc=leapster,dc=org | -- dn: ou=People,dc=leapster,dc=org | -- dn: uid=paul,ou=People,dc=leapster,dc=org | -- dn: uid=mike,ou=People,dc=leapster,dc=org
Put simply, my LDAP base DN is dc=leapster,dc=org. The administrative user of the system (the entry that has superuser control) is cn=admin,dc=leapster,dc=org. It also contains two user entries, uid=paul and uid=mike.
Once you have created a connection to an LDAP server, you need to bind to it. If you're writing a program to talk to public LDAP directories, chances are you need to use only an anonymous bind:
$mesg = $ldap->bind;
However, if you're writing scripts to manage the directory of a server used for storing the account information of local users or customers, you are likely to allow only write access to specific, high-privilege users. In this case, you need to give the DN of the LDAP entry which has these privileges, as well as the password. For example:
$mesg = $ldap->bind("cn=admin,dc=leapster,dc=org", password=>"secret");
In this case, I use the following privileged user on my system: cn=admin,dc=leapster,dc=org. If I'd bound to one of the unprivileged users (for example, uid=paul,dc=leapster,dc=org), I may not have had any access to read or write options on the system at all, depending on how the server was configured.
The return value, which we store in $mesg, is an object of class New::LDAP::Message. It is discussed later in this article.
If you wish to close a connection, you must unbind from it:
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
- Interview with Patrick Volkerding
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- 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