Map Entries

Map Entries

The format of the map entries varies by database. The full list of attributes that can be used with an entry and a detailed description of each attribute can be found in the DBIS IETF drafts. This page provides a summary and an example for each database.

Note that the map entries shown here match the DBIS schema, and rely on configuration maps set-up as described in [Configuration Maps]. If you are supporting older legacy RFC2307 entries, see [ConfigurationMaps-RFC2307]

The netgroup database

Netgroups are groups of users and hosts, and generally used in access control lists.

Traditionally, a netgroup is defined as a triple of the format:

(user, host, domain)

While the DBIS Reference Implementation supports netgroup triples for backwards compatibility with NIS and RFC2307, the netgroup format has been revised in DBIS so that users are represented by the netgroupUser attribute and hosts by the netgroupHost attribute.

The table below gives an example of how a traditional netgroup triple is represented in the new format:

nisNetgroupTriple	netgroupUser	netgroupHost
(mark, , )	mark	-
(, riker, )	-	riker
(, , uss.net)	-	*.uss.net
(mark, riker, )	mark@riker	-
(mark, riker, uss.net)	mark@riker.uss.net	-
(mark, , uss.net)	mark@*.uss.net	-
(, riker, uss.net)	-	riker.uss.net

The innetgr library call has not changed and supports netgroups defined using either scheme.

Here is an example netgroup defined using the DBIS schema:

dn: en=sales-mgmt,ou=netgroup,ou=sales,o=infra
objectClass: top
objectClass: netgroupObject
en: sales-mgmt
netgroupHost: picard.sales.corp
netgroupHost: *.fleet.sales.corp
netgroupUser: mark@riker.sales.corp
netgroupUser: julie@*.market.sales.corp
exactNetgroup: board-mgmt
exactNetgroup: board-mgmt-remote
description: Sales Management Privileges

The exactNetgroup attribute is used to include other netgroups inside this one.

The DBIS schema also defines the netgroupTriple attribute for backwards compatibility with RFC2307 client software. This may be used as well as or instead of the netgroupHost and netgroupUser attributes.

The netservice database

The netservice database is a new feature of DBIS that allows application services or roles to be assigned by netgroup membership, and is described in [Netservices].

A netservice is defined by a netserviceObject underneath which is a hierarchy of netserviceDescriptor entries. The following example defines a netservice called ssh:login, granting the service to hosts and users in the unix2-admin netgroup and to the same hosts and users that have the ftp:login and web:login/anonymous service.

dn: en=login,en=ssh,ou=netservice,o=infra
objectClass: top
objectClass: netserviceDescriptor
en: login
exactNetservice: ftp:login
exactNetservice: web:login/anonymous
exactNetgroup: unix2-admin

The passwd database

DBIS defines the posixUserAccount object class for user entries that appear in the passwd database. This is an auxiliary class, not a structural class, which means that user entries will also need a structural class assigned to them too. The DBIS IETF drafts suggest using inetOrgPerson although there are several other choices.

The user name is identified by the en attribute (exactName) which is used in the RDN and is case sensitive.

Here is an example passwd entry that uses the inetOrgPerson and posixUserAccount classes. In this case, the configuration map that uses this entry will have the dbisMapGecos attribute set to displayName.

dn: en=mark,ou=passwd,ou=sales,o=infra
objectClass: top
objectClass: inetOrgPerson
objectClass: posixUserAccount
cn: Mark
sn: Bannister
displayName: Bannister, Mark
en: mark
uidNumber: 801
gidNumber: 900
homeDirectory: /home/mark
loginShell: /bin/bash

The group database

Entries in the group database are identified by the posixGroupAccount object class. The group name is contained in the en attribute (exactName) which is used in the RDN and is case sensitive.

If this is a user's primary group then the group ID (gidNumber) will appear in that user's posixUserAccount entry (see above). If this is to be one of the user's secondary groups, then the user name must be assigned to the group entry using the exactUser attribute, which is case sensitive.

Here is an example:

dn: en=finance,ou=group,ou=sales,o=infra
objectClass: top
objectClass: posixGroupAccount
en: finance
gidNumber: 952
exactUser: mark
exactUser: julie

The hosts database

Host names and their IP addresses in the hosts database are represented by entries using the structural class ipHostObject. An auxiliary class is used to identify whether this is for an IPv4 or IPv6 address: ipv4HostObject vs. ipv6HostObject.

The fully-qualified canonical host name is identified by the rn attribute (regularName) which is case insensitive. Then either the ipv4Address or ipv6Address attribute is used to provide the IP address, depending on class.

Host aliases may also be configured, as described in [Aliases].

Here is an IPv4 example:

dn: rn=picard,ou=hosts,o=infra
objectClass: top
objectClass: ipHostObject
objectClass: ipv4HostObject
rn: picard
ipv4Address: 10.11.12.13

Here is an IPv6 example:

dn: rn=picard-hive,ou=hosts,o=infra
objectClass: top
objectClass: ipHostObject
objectClass: ipv6HostObject
rn: picard-hive
ipv6Address: 0:1:2:3:4:5:6:7

The ethers database

A host object may be extended to contain the Ethernet address (aka "MAC address") reported in the ethers database. This is achieved by adding the auxiliary class ieee802Device and attribute macAddress to a host entry, as in the following example:

dn: rn=picard-hive,ou=hosts,o=infra
objectClass: top
objectClass: ipHostObject
objectClass: ipv6HostObject
objectClass: ieee802Device
rn: picard-hive
ipv6Address: 0:1:2:3:4:5:6:7
macAddress: 08:00:27:00:50:f4

The bootparams database

A host object may be extended to contain boot parameters reported in the bootparams database. This is achieved by adding the auxiliary class bootableDevice and multi-value attribute bootParameter to a host entry, as in the following example:

dn: rn=picard-hive,ou=hosts,o=infra
objectClass: top
objectClass: ipHostObject
objectClass: ipv6HostObject
objectClass: ieee802Device
objectClass: bootableDevice
rn: picard-hive
ipv6Address: 0:1:2:3:4:5:6:7
macAddress: 08:00:27:00:50:f4
bootParameter: root=hive:/export/cube/root
bootParameter: domain=resistance.futile.org

The networks database

IP network names and netmasks are stored in LDAP entries that use the class ipNetworkObject. The network name is identified by the en attribute (exactName) which is case sensitive. The network number and netmask are recorded by the ipNetworkNumber and ipNetmaskNumber attributes respectively.

Network aliases may also be configured, as described in [Aliases].

Here is an example network entry:

dn: en=lab,ou=networks,o=infra
objectClass: top
objectClass: ipNetworkObject
en: lab
ipNetworkNumber: 10.23.10
ipNetmaskNumber: 255.255.255.0

The protocols database

Network protocol names and numbers are stored in LDAP entries using the class ipProtocolObject. The protocol name is identified by the en attribute (exactName) which is case sensitive. The protocol number is stored in the ipProtocolNumber attribute.

Protocol aliases may also be configured, as described in [Aliases].

Here is an example protocol entry:

dn: en=ip,ou=protocols,o=infra
objectClass: top
objectClass: ipProtocolObject
en: ip
ipProtocolNumber: 0

The rpc database

RPC program names and numbers are stored in LDAP entries that use the class rpcObject. The RPC program name is identified by the en attribute (exactName) which is case sensitive. The RPC program number is stored in the rpcNumber attribute.

RPC aliases may also be configured, as described in [Aliases].

Here is an example rpc entry:

dn: en=rpcbind,ou=rpc,o=infra
objectClass: top
objectClass: rpcObject
en: rpcbind
rpcNumber: 100000

The services database

Network service names, port numbers and protocols are stored in LDAP entries using the class ipServiceObject. The service name is identified by the en attribute (exactName) which is case sensitive. The port number and protocol are stored in the ipServicePort and ipProtocolName attributes respectively.

Service aliases may also be configured, as described in [Aliases].

Here is an example service entry:

dn: en=smtp,ou=services,o=infra
objectClass: top
objectClass: ipServiceObject
en: smtp
ipServicePort: 25
ipProtocolName: tcp

If the same service name supports two protocols, two entries must be provided using a multi-value RDN, as in the following example:

dn: en=rpcbind+ipProtocolName=udp,ou=services,o=infra
objectClass: top
objectClass: ipServiceObject
en: rpcbind
ipServicePort: 111
ipProtocolName: udp

dn: en=rpcbind+ipProtocolName=tcp,ou=services,o=infra
objectClass: top
objectClass: ipServiceObject
en: rpcbind
ipServicePort: 111
ipProtocolName: tcp

The automount database

DBIS supports three different types of automount entries: master map entries, direct map entries and indirect map entries. It additionally supports multiple mount entries, i.e. where multiple mount-points are defined for a single key in an indirect map.

Master map entries are identified by the automountMapObject and automountMaster classes. The key is recorded in the en attribute (exactName) which is case sensitive. The corresponding automount options (optional) and automount map are given in the automountOption and automountUseMap attributes respectively.

Here are two example master map entries, the first for a direct map entry, the second for an indirect map entry:

dn: en=/-,ou=master,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
objectClass: automountMaster
en: /-
automountUseMap: auto_direct
description: Master entry for direct maps, see auto_direct

dn: en=/home,ou=master,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
objectClass: automountMaster
en: /home
automountOption: nobrowse
automountUseMap: auto_home
description: Master entry for /home, see auto_home map

Automount maps have a top-level entry with the automountMapObject class, followed by the map entries themselves as child objects with the automountEntry class. In both cases the map key is identified by the en attribute (exactName) which is case sensitive. An automountEntry object also has a automountLocation attribute and may have one or more automountOption attributes.

Here is an example of a direct map entry:

dn: en=auto_direct,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
en: auto_direct
description: auto_direct map entries are child objects

dn: en=/usr/install,en=auto_direct,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: /usr/install
automountOption: ro
automountLocation: esher,kingston(1):/export/install
automountLocation: hampton(3):/usr/install
description: Mount /usr/install from three possible servers

Here are some example indirect map entries:

dn: en=auto_home,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
en: auto_home
description: auto_home map entries are child objects

dn: en=fred,en=auto_home,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: fred
automountLocation: surbiton:/export/home/&
description: /home/fred

dn: en=sheila,en=auto_home,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: sheila
automountLocation: surbiton:/export/home/&
description: /home/sheila

dn: en=*,en=auto_home,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: *
automountLocation: ditton:/export/home/&
description: Catch-all for user home directories not listed

Multiple mount entries use an additional level by inserting an entry with the automountMulti class underneath the automountMapObject and then the automountEntry objects come under that. Here is an example:

dn: en=qa,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountMapObject
en: qa
description: qa map entries are child objects

dn: en=qa_root,en=qa,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountMulti
en: qa_root
automountOption: ro
description: qa_root multi-mount entries are child objects

dn: en=/,en=qa_root,en=qa,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: /
automountLocation: esher:/export/qa
description: /qa

dn: en=/docs,en=qa_root,en=qa,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: /docs
automountLocation: surbiton:/export/qa/docs
description: /qa/docs

dn: en=/tmp,en=qa_root,en=qa,ou=maps,ou=automount,o=infra
objectClass: top
objectClass: automountEntry
en: /tmp
automountOption: rw
automountLocation: surbiton:/export/qa/tmp
description: /qa/tmp

The custom database

Custom map entries are identified by the customMapEntry object class. The map key is recorded by the en attribute (exactName) which is case sensitive. The map value is given by the customMapValue attribute.

Here are some example custom map entries:

dn: ou=console,ou=custom,o=infra
objectClass: top
objectClass: organizationalUnit
ou: console

dn: en=kirk,ou=console,ou=custom,o=infra
objectClass: top
objectClass: customMapEntry
en: kirk
customMapValue: 2079 ssh

dn: en=spock,ou=console,ou=custom,o=infra
objectClass: top
objectClass: customMapEntry
en: spock
customMapValue: 53179 telnet

Next Steps

Return to [Configuring DBIS] for the next steps in setting up a new installation. This includes setting up advanced features such as [Remapping Rules], [Transformation Rules], [Overlays], [Netgroup Constraints] and [Netservices].