Difference between revisions of "V4 Name Server"

From EPICSWIKI
(JNDI)
(First LDAP tests)
Line 1: Line 1:
== Name Server ==
== Directory Server ==
What would a name server look like that supports


1) Life channels (ChannelAccess), including channels provided by backup systems in a redundant setup.
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, ...


2) Archived channels
== OpenLDAP ==


3) Possibly other EPICS data sources like Alarm channels?
OpenLDAP [http://www.openldap.org]
promises a Directory for simple attribute-based information
for fast, high volume lookup, including filtering.


Hoping to use something existing. Get OpenLDAP [http://www.openldap.org] and check the following:
LDAP is well defined, there are existing open-source servers & clients,
* Can it be used to store record names, server addresses,  maybe more ('primary' server, fields, ...)? Try a simple setup, use the command-line ldapsearch to retrieve data.
it is supported by perl, Java, ..., often already build into the OS (MacOS, Linux).
* Does it allow for redundant servers, automatically syncing?
OpenLDAP includes authentication and encrypted (SSL) transport,
* How to best interface it (API)?
replication (single master -> multiple slaves),
and referrals from one server to another one which has more details.


== API ==
=== LDAP Terminology ===
Gasper suggested to look at the Java  JNDI API for inspiration.
Quote from his emai:


Java has a language-neutral interface to Naming and Directory service, in packages javax.naming.*. Again, can be consulted for an inspiration or actually used in client sw, because it is designed to be an IF through which Java clients access CORBA Naming, LDAP, file system, ... It is simple, small and modular (if you need only naming, you can use it without a directory services, such as search and attributes, etc).
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.
* Replication: How to use it, how fast is it etc.
* authentication and encryption: How hard is it to configure?

Revision as of 21:08, 24 May 2005

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.
  • Replication: How to use it, how fast is it etc.
  • authentication and encryption: How hard is it to configure?
Retrieved from "https://wiki-ext.aps.anl.gov/epics/index.php?title=V4_Name_Server&oldid=196"