V4 Name Server

Directory Server

As Larry Hoff pointed out, we really want a "Directory" server for EPICS, something beyond a "name server", that will not only map PV names to IP addresses of ChannelAccess servers, but in the future also

provide details on

• redundant servers
• archived data servers
• backup/restore locations
• site-specific details like engineer-in-charge,

 CA security rules, ...

OpenLDAP

OpenLDAP [1] promises a Directory for simple attribute-based information for fast, high volume lookup, including filtering.

LDAP is well defined, there are existing open-source servers & clients, it is supported by perl, Java, ..., often already build into the OS (MacOS, Linux). OpenLDAP includes authentication and encrypted (SSL) transport, replication (single master -> multiple slaves), and referrals from one server to another one which has more details.

LDAP Terminology

LDAP maintains a hierarchical directory of Entries. Each Entry has a globally unique distinguished name (dn), and various Attributes, that is Type/Value pairs. Certain types like "Common Name" (cn) are predefined, but one can define a custom schema. Values might include binaries like for example images.

Step 0: EPICS PVs and CA Server Info

At least for now, PV names must be unique within the EPICS_CA_ADDR_LIST that the participating parties use. Will directory servers provide information across such boundaries, for example site-wide or even larger? In that case, the entries in the directory server need more specific names that are unique beyond e.g. a "linac" subnet.

I created a simple "EPICS" schema for PVs and CA server addresses, that allows entry of PV names in a hierarchical name space. Extract from an "LDIF" file that defines names:

dn: cn=llrf,cn=linac,dc=epics
objectclass: NameSpaceElement
cn: llrf

dn: cn=DTL_LLRF:FCM1:cavV,cn=llrf,cn=linac,dc=epics
objectclass: ProcessVariable
cn: DTL_LLRF:FCM1:cavV
cas: 192.1.2.3:46
description: Example PV

Used a perl script to create an LDIF file with 10000 PV names and imported that with the ldapadd command-line tool.

A command-line tool 'ldapsearch' can be used to search PVs:

ldapsearch -x -b 'cn=llrf,cn=linac,dc=epics' '(cn=testpv00010)'  cas

retrieves the ChannelAccess Server for the given PV.

A problem arises when trying to list all PVs: Per default, the server config will only allow 500 answers. The configuration can be changed to e.g. 10000, but generic browsers will only get that limited number of PVs under e.g. the name-space '*.llrf.linac.epic'.

Recent LDAP servers and clients should support RFC 2696 - "Simple Paged Results" and thus handle long responses in several "pages", but I haven't figured out how to use that to get beyond the limit.

What _does_ work with OpenLDAP: Send the request as the rootdn. Is that a problem? Or is it a feature, limiting "list all" calls to those who have the rootdn?

To be investigated

• Before late 1990, there was LDAPv2, which is now obsolete. How stable is the current LDAPv3?
• Performance
• How to access it from vxWorks
• How does an LDAP server used for EPICS cooperate with existing LDAP servers for DNS, email etc. Should it be one and the same? Use special port numbers for 'EPICS' LDAP?
• API: What type of API would EPICS tools use? Whatever LDAP library they use? An 'EPICS wrapper' around LDAP? Gasper suggested to look at the Java JNDI API for inspiration.
• Common Database headaches:
  • To simply get a PV into LDAP, one has to check if this PV already exists and then either 'add' or 'modify'.
  • What if a channel is no longer available? An IOC shutting down could remove PVs from the LDAP server, but an IOC that crashes won't.
• Replication: How to use it, how fast is it etc.
• authentication and encryption: How hard is it to configure?