LDAP System Administration [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

LDAP System Administration [Electronic resources] - نسخه متنی

Gerald Carter

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید










8.5 Resolving Hosts


Now let's turn our
attention to data describing hosts on a network. One of the most
fundamental services provided in any TCP/IP network is the
resolution of machine names to network
addresses. The most widespread mechanism for looking up IP addresses
is the Domain Name System (DNS). Again, coverage of DNS is beyond the
scope of this book; for more information, see
DNS and
BIND, Fourth Edition, by Cricket Liu and Paul
Albitz (O'Reilly).

Chapter 1 already made it clear that LDAP is not a
replacement for a specialized directory service such as DNS. However,
you can use LDAP effectively as a backend storage system for DNS zone
files. Stig
Venaas has written such a patch for Bind 9 using its new
simplified
database interface (SDB).
The latest release of the patch for BIND 9.1 (or later) and the
necessary schema file for OpenLDAP 2 can be obtained from http://www.venaas.no/ldap/bind-sdb/. For
performance reasons, I recommend that you obtain the latest patch,
rather than using the one included in the
contrib/ subdirectory of the latest BIND 9
release.

Venaas has included a brief list of the steps necessary for
integrating LDAP-sdb support in Bind 9. Here are the
instructions contained in the INSTALL file of
the ldap-sdb archive:


    Copy the ldap.c source file to the
    bin/named/ subdirectory of the BIND 9 source
    tree.


    Copy the ldap.h header file to the
    bin/named/include/ subdirectory of the BIND 9
    source tree.


    Edit bin/named/Makefile.in and add the following
    lines:

    DDRIVER_OBJS = ldapdb.@O@
    DDRVIVER_SRCS = ldapdb.c
    DDRIVER_LIBS = -lldap -llber

    The Makefile variables may already exist; if this is the case, simply
    append the references to the LDAP files to the existing definitions.
    You may also need to add the path to the LDAP include files and
    libraries to the DDRIVER_INCLUDES and
    DDRIVER_LIBS respectively.


    Edit bin/named/main.c and add the line
    #include <ldapdb.h> below
    #include "xxdb.h"; add the line
    ldapdb_init( ); below xxdb_init(
    );
    and finally, add ldapdb_clear( );
    below xxdb_clear( );.



After making these changes, you're ready to build
the LDAP-enabled named binary by executing ./configure
&& make && /bin/su -c "make install
". It is
a good idea to ensure that the new server is working with an existing
set of zone files before continuing. Here is a zone file for the
plainjoe.org domain; it contains four hosts,
localhost, dns1,
ldap, and ahab:

plainjoe.org. IN SOA dns1.plainjoe.org. root.dns.plainjoe.org. (
3 ; Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
; Name Servers
plainjoe.org. IN NS dns1.plainjoe.org.
; Addresses for local printers
localhost.plainjoe.org. IN A 127.0.0.1
dns1.plainjoe.org. IN A 192.168.1.10
ldap.plainjoe.org. IN A 192.168.1.70
ahab.plainjoe.org. IN A 192.168.1.80

Figure 8-6 shows the schema for the structural
dNSZone object class. This schema allows you to
store DNS records in the directory. All of the attributes used to
represent the various DNS records (MX, A, PTR, etc.) are optional,
which means that a dNSZone entry can represent any
type of DNS record.


Figure 8-6. The dNSZone object class required for the Bind 9 LDAP-sdb backend


I have chosen to place all plainjoe.org hosts in
the hosts organizational unit. The following LDIF
entry represents the A record for the host
ahab.plainjoe.org:

dn: relativeDomainName=ahab,ou=hosts,dc=plainjoe,dc=org
aRecord: 192.168.1.80
objectClass: dNSZone
relativeDomainName: ahab
dNSTTL: 86400
zoneName: plainjoe.org

After placing your DNS zone data into the LDAP directory, you need to
tell the named server how to locate the zone
information. The database keyword specifies the
SDB type holding the zone information; in this case,
you're using an LDAP database. Any remaining
arguments after the database type are passed directly to the SDB
backend module. Here, you use an LDAP URI to define the directory
server's hostname and the base search suffix. The
final number (172800) specifies the default time-to-live (TTL) for
entries that do not possess a
dNSTTL attribute value.

zone "plainjoe.org" in {
type master;
database "ldap ldap://192.168.1.70/ou=hosts,dc=plainjoe,dc=org 172800";
};

You can now use the dig utility to test the new LDAP-served DNS
zone. Figure 8-7 describes what will happen when
the dig or nslookup tools
are executed.

$ dig ahab.plainjoe.org +short
; <<>> DiG 9.1.0 <<>> ahab.plainjoe.org +short
;; global options: printcmd
192.168.1.80


Figure 8-7. Retrieving zone information using LDAP lookups in Bind 9


The zone2ldap tool included with the Bind distribution
provides a quick way to transfer existing zone files into an LDAP
directory. Newer versions of this utility can also be downloaded from
Venaas's web site. I decided against using it
because it creates an entry for each component of the FQDN for each
host. For example, the host ahab.plainjoe.org
results in three entries: one for dc=org, one for
dc=plainjoe,dc=org, and one for
relativeDomainName=ahab,dc=plainjoe,dc=org. For
more information, refer to the zone2ldap
manpage.


/ 129