ingenieurbüro für innovative informationstechnik
Dipl.-Ing. Jörg Beckmann
Der iiitAccessServer wird über eine XML-Datei konfiguriert. Nach dem Start sucht das Programm in den Verzeichnissen ., etc, /usr/local/etc und /etc nach einer Datei mit dem Namen AccessServer.xml. Wenn der iiitAccessServer über den Start-Script run.sh gestartet wird, so wird vor dem Start des Programms automatisch in das Installationsverzeichnis gewechselt, so dass die Suche dort beginnt. Andernfalls beginnt die Suche im aktuellen Verzeichnis.
Hier soll und kann nicht der grundsätzliche Aufbau von XML-Dateien erläutert werden, Informationen zu XML finden Sie z.B. bei http://www.xml.org.
Um die Verarbeitung der Konfigurationsdatei einfach zu halten, werden nicht alle Möglichkeiten von XML genutzt. Im Gegensatz zur üblichen XML-Notation wird bei den Namen der Elemente und Attribute nicht zwischen Groß- und Kleinschreibung unterschieden. Der grundsätzliche Aufbau sieht so aus:
<?xml version="1.0" encoding="UTF-8"?>
<AccessServer>
<Element1
Attribute1 = "value1"
Attribute2 = "value2"
...
AttributeN = "valueN"
/>
<Element2
Attribute1 = "value1"
Attribute2 = "value2"
...
AttributeN = "valueN"
>
<SubElement1
Attribute1 = "value1"
Attribute2 = "value2"
...
AttributeN = "valueN"
/>
<SubElement2
Attribute1 = "value1"
Attribute2 = "value2"
...
AttributeN = "valueN"
/>
</Element2>
</AccessServer>
Dabei können die einzelnen Elemente beliebig tief geschachtelt werden.
Es gibt zwei Möglichkeiten, Log-Ausgaben zu konfigurieren. Im einfachsten Fall wird nur der Log-Level eingestellt, indem dem Element AccessServer das Attribut LogLevel hinzugefügt wird:
<?xml version="1.0" encoding="UTF-8"?>
<AccessServer LogLevel = "DEBUG">
...
</AccessServer>
Die Log-Ausgabe geschieht dann auf STDOUT.
Etwas detailierter kann das Logging mit einem eigenen Element Logger konfiguriert werden:
<?xml version="1.0" encoding="UTF-8"?>
<AccessServer>
<Logger
LogLevel = "INFO"
LogFile = "./accessserver.log"
MaxFileSize = "1000000"
MaxBackupFiles = "5"
/>
...
</AccessServer>
Das Attribut LogLevel definiert die Art der Log-Ausgaben, gültig sind die Werte OFF, FATAL, ERROR, WARN, INFO, DEBUG und ALL. Bei fehlenden oder ungültigen Werten wird DEBUG als Vorgabe verwendet.
Mit den Attributen LogFile, MaxFileSize und MaxBackupFiles wird bestimmt, in welche Datei die Ausgaben umgelenkt werden sollen, wie groß diese Datei maximal werden darf, bevor automatisch eine neue angefangen wird und wieviele alte Dateien aufbewahrt werden sollen.
Das Element Logger soll nur einmal in der Konfigurationsdatei definiert werden. Wenn es mehrfach vorkommt wird nur das erste berücksichtigt.
Die Konfiguration der LDAP-Anbindung wird sowohl für den LDAP Resolver wie auch für den CacheManager benötigt. Sie kann bei den jeweiligen Konfigurationen der Plug-Ins oder der Einfachheit halber auch global eingetragen werden. Sie hat folgenden Aufbau:
<?xml version="1.0" encoding="UTF-8"?>
<AccessServer>
...
<LdapConfig
RootDN = "dc=iiit,dc=de"
LdapPersonSearchBase = "ou=person,dc=iiit,dc=de"
LdapGroupSearchBase = "ou=group,dc=iiit,dc=de"
LdapFormulaSearchBase = "ou=formula,dc=iiit,dc=de"
LdapPersonClass = "iiitPerson"
LdapGroupClass = "iiitGroup"
LdapFormulaClass = "iiitFormula"
LdapExpressionField = "iiitExpression"
LdapCommonNameField = "cn"
LdapUserIdField = "uid"
LdapMemberUserIdField = "memberUid"
>
<server
java.naming.provider.url = "ldap://ldap1.iiit.de/"
java.naming.factory.initial = "com.sun.jndi.ldap.LdapCtxFactory"
java.naming.security.protocol = ""
java.naming.security.authentication = "simple"
java.naming.security.principal = ""
java.naming.security.credentials = ""
/>
<server
java.naming.provider.url = "ldap://ldap2.iiit.de/"
java.naming.factory.initial = "com.sun.jndi.ldap.LdapCtxFactory"
java.naming.security.protocol = ""
java.naming.security.authentication = "simple"
java.naming.security.principal = ""
java.naming.security.credentials = ""
/>
</LdapConfig>
...
</AccessServer>
Das Attribut RootDN legt die Wurzel aller LDAP-Daten fest, LdapPersonSearchBase, LdapGroupSearchBase und LdapFormulaSearchBase bestimmen die Basis-Einträge für die Suche nach Personen, Gruppen und Formeln fest. Mit den Attributen LdapPersonClass, LdapGroupClass und LdapFormulaClass wird definiert nach welchen Objekt-Klassen innerhalb der LDAP-Datenbank gesucht werden soll. Zusätzlich muss mit den Attributen LdapExpressionField, LdapCommonNameField, LdapUserIdField und LdapMemberUserIdField eingestellt werden, aus welchen LDAP-Attributen die entsprechenden Informationen auszulesen sind. Alle diese Attribute haben keine Default-Werte. Der iiitAccessServer kann damit völlig frei an beliebige LDAP-Datenstrukturen angepasst werden.
Neben diesem Basis-Einstellungen muss noch konfiguriert werden, wie auf den oder die LDAP-Server zugegriffen werden kann. Dazu dienen die Server-Elemente innerhalb des LdapConfig-Elements. Dieses Element kann beliebig oft eingetragen werden, für jeden LDAP-Server, der zur Verfügung steht, einmal. Die Attribute dieses Elements werden an die jeweilige JNDI-Implementierung der Java-Laufzeitumgebung weitergereicht. Hier sind die Properties entsprechend der JNDI-Dokumentation einzutragen.
Das Element AccessServer hat ein weiteres Attribut: IgnoreCase. Mit diesem Attribut kann festgelegt werden, ob der iiitAccessServer intern bei Namen von Usern, Gruppen, und Ausdrücken zwischen Groß- und Kleinschreibung unterscheidet oder nicht. Vorgabewert für dieses Attribut ist false, d.h. es wird unterschieden. Die Konfiguration sieht so aus:
<?xml version="1.0" encoding="UTF-8"?>
<AccessServer IgnoreCase = "true">
...
</AccessServer>
Anmerkung: Der LDAP Resolver erzwingt, dass dieser Wert intern auf true gesetzt wird.
Mit dem Attribut VerifyUser wird definiert, ob User-IDs, die mit dem Kommando SETUSER an den Server übergeben werden, auf Gültigkeit überprüft werden sollen oder nicht. Vorgabewert ist true, d.h. es soll überprüft werden. Die eigentliche Überprüfung wird vom ResolverPlugin durchgeführt. ResolverPlugins, die keinen Zugriff auf eine User-Datenbank haben – wie z.B. der PropertyFileResolver – setzen diesen Wert intern auf false.
<?xml version="1.0" encoding="UTF-8"?>
<AccessServer VerifyUser = "true">
...
</AccessServer>
Der iiitAccessServer unterstützt drei Arten von Plug-Ins, die in den folgenden Kapiteln dargestellt werden. Der grundsätzliche Aufbau der Konfiguration ist jeweils gleich:
<?xml version="1.0" encoding="UTF-8"?>
<AccessServer>
...
<xxxPlugin
PluginClass = [Classname]
>
<PluginConfig
Attribute1 = "value1"
Attribute2 = "value2"
AttributeN = "valueN"
>
<Element
Attribute1 = "value1"
Attribute2 = "value2"
AttributeN = "valueN"
>
<SubElement1
Attribute1 = "value1"
Attribute2 = "value2"
AttributeN = "valueN"
/>
<SubElement2
Attribute1 = "value1"
Attribute2 = "value2"
AttributeN = "valueN"
/>
</Element>
</PluginConfig>
</xxxPlugin>
...
</AccessServer>
Der Name des Elements ist ResolverPlugin, CachePlugin oder ThreadPlugin. Mit dem Attribut PluginClass ist jeweils der Name der zu ladenden Klasse anzugeben. CachePlugin- und ResolverPlugin-Elemente dürfen nur einmal definiert werden. Wenn weitere Elemente dieser Art vorhanden sind, werden sie ignoriert. Dagegen dürfen beliebig viele ThreadPlugin-Elemente vorhanden sein.
Resolver-Plugins werden benötigt, um Namen, die von der Applikation abgefragt werden, aufzulösen. In jeder Konfigurationsdatei muß dieses Element daher genau einmal vorhanden sein. Zur Zeit sind zwei Klassen von ResolverPlugins definiert, die im folgenden vorgestellt werden.
Dieser Resolver liest seine Daten aus einer gewöhnlichen Java-Property-Datei. Da die Einträge nur einmal beim Start eingelesen werden, ist dieser Resolver nicht für den produktiven Einsatz geeignet, sondern nur für Tests und Entwicklung. Er ist wie folgt zu konfigurieren:
<?xml version="1.0" encoding="UTF-8"?>
<AccessServer>
...
<ResolverPlugin
PluginClass = "de.iiit.AccessServer.parser.PropertyFileResolver"
>
<PluginConfig
FileName = "etc/expressions.properties"
/>
</ResolverPlugin>
...
</AccessServer>
Die einzige Konfigurationsvariable ist der Name der Property-Datei. In diesem Beispiel ist der Name der mitgelieferten Datei eingetragen. Die Property-Datei hat folgenden Aufbau:
ga1=a1,a2 ga2=a3,a4 ga3=a5,a6 gn= ga12=ga1+ga2 ga23=ga2+ga3 ga13=ga1+ga3 ga=ga1 + ga2 + ga3
ga1, ga2 und ga3 sind jeweils Gruppen mit zwei Mitgliedern, gn ist eine leere Gruppe. ga12, ga23, ga13 und ga stellen jeweils Ausdrücke dar.
Der LDAP-Resolver ist für den produktiven Einsatz gedacht. Er benötigt eine LDAP-Konfiguration wie weiter oben dargestellt. Diese kann entweder global oder im Element PluginConfig abgelegt werden. Der LDAP-Resolver hat keine weiteren Einstellmöglichkeiten und kann daher so konfiguriert werden:
<?xml version="1.0" encoding="UTF-8"?>
<AccessServer>
...
<LdapConfig
...
>
<server
...
/>
...
</LdapConfig>
...
<ResolverPlugin
PluginClass = "de.iiit.AccessServer.parser.LdapResolver"
/>
...
</AccessServer>
Der iiitAccessServer beinhaltet zwei verschiedene Cache-Implementierungen.
Der einfache Cache ist ein reiner 1st-Level-Cache. Die Konfiguration sieht so aus:
<?xml version="1.0" encoding="UTF-8"?>
<AccessServer>
...
<CachePlugin
PluginClass = "de.iiit.AccessServer.cache.SimpleCache"
>
<PluginConfig
InvalidationTimeout = "600"
LRUTimeout = "100"
SleepTime = "10"
/>
</CachePlugin>
...
</AccessServer>
Mit dem InvalidationTimeout kann erzwungen werden, dass Cache-Einträge, die ein bestimmtes Alter überschreiten grundsätzlich ignoriert werden. Dadurch wird sichergestellt, dass alle Änderungen im Datenbestand nach einer gewissen Zeit berücksichtigt werden. Mit dem Attribut LRUTimeout kann erzwungen werden, dass Cache-Einträge, die längere Zeit nicht benötigt wurden, aus dem Cache entfernt werden. Zu diesem Zweck wird ein Hintergrund-Thread gestartet der nach jedem Durchlauf SleepTime-Sekunden schläft. Alle diese Zeiten werden in Sekunden angegeben.
Der Datenbank-Cache enthält einen 1st- und einen persistenten 2nd-Level-Cache. Letzterer stützt sich auf eine oder mehrere MySQL-Datenbanken und ist daher etwas aufwendiger zu konfigurieren. Dieser Cache wird auch nicht automatisch gefüllt, sondern benötigt ein eigenes Plug-In – den CacheManager – der die Daten aus der LDAP-Datenbank liest und im Cache in optimierter Form ablegt.
<?xml version="1.0" encoding="UTF-8"?>
<AccessServer>
...
<CachePlugin
PluginClass = "de.iiit.AccessServer.cache.DbCache"
>
<PluginConfig
InvalidationTimeout = "600"
LRUTimeout = "100"
SleepTime = "10"
Md5PatternLength = "1"
>
<JdbcDriver
ClassName = "com.mysql.jdbc.Driver"
/>
<CacheDatabase
Url = "jdbc:mysql://jacomo/AccessServerCache"
UserName = "checker"
Password = "checker"
Connections = "5"
/>
<CacheDatabase
Url = "jdbc:mysql://wuppi/AccessServerCache"
UserName = "checker"
Password = "checker"
Connections = "5"
/>
</PluginConfig>
</CachePlugin>
...
</AccessServer>
Die Attribute InvalidationTimeout, LRUTimeout und SleepTime steuern den 1st-Level-Cache, genau wie oben beschrieben. Intern benutzt der 2nd-Level-Cache MD5-Summen als Zugriffs-Schlüssel. Um die Cache-Daten über mehrere Datenbanken zu verteilen, kann mit dem Attribut Md5PatternLength die Anzahl Bits festgelegt werden, mit denen die Datenbank ausgewählt wird. Für n Bit werden entsprechend 2n Datenbanken benötigt. Gültig sind 0 - 8 Bits entsprechend 1 - 256 Datenbanken.
Innerhalb der Plug-In-Konfiguration sind weitere Elemente mit der eigentlichen Datenbank-Konfiguration notwendig. Im Element JdbcDriver wird mit dem Attribut ClassName der Klassen-Name des benötigten JDBC-Treibers definiert.
Für jede benötigte Datenbank werden in einem CacheDatabase-Element mit den Attributen Url, UserName und Password die jeweiligen Verbindungsdaten hinterlegt. Zusätzlich kann mit dem Parameter Connections festgelegt werden, wieviele Datenbank-Verbindungen auf Vorrat geöffnet werden sollen, um später die Zugriffe zu beschleunigen. Wenn dieser Eintrag fehlt, werden keine Verbindungen vorab geöffnet. Um die Einstellung für diesen Wert optimieren zu können, wird beim Öffnen jeder zusätzlichen Verbindung ein Eintrag in der Log-Datei erzeugt, der angibt wie viele Verbindungen zur jeweiligen Datenbank schon geöffnet sind.
Wenn mehr Datenbanken angegeben werden als benötigt, so werden diese weiteren Datenbanken ignoriert. Wichtig ist in diesem Zusammenhang, dass die Datenbanken in der gleichen Reihenfolge wie beim CacheManager angegeben werden. Wenn einzelne Datenbank-Server deutlich leistungsfähiger sind als andere, so können diese auch mehrfach angegeben werden, um ihnen einen größeren Anteil an der Gesamt-Last zu übertragen.
Der RMI-Server stellt die Schnittstelle der Wahl für Java-Applikationen dar. Die einzige Konfigurationseinstellung ist die Nummer des TCP-Ports, auf dem der Server seine private RMI Registry betreiben soll. Der Default-Wert für die Port-Nummer ist 54322.
<?xml version="1.0" encoding="UTF-8"?>
<AccessServer>
...
<ThreadPlugin
PluginClass = "de.iiit.AccessServer.server.RMIServer"
>
<PluginConfig
Port = "54322"
/>
</ThreadPlugin>
...
</AccessServer>
Der TCP/IP-Server ist zur Zeit die einzige Schnittstelle für nicht-Java Applikationen zum iiitAccessServer. Auch Java Applikationen können diese Schnittstelle nutzen. Besser ist dafür aber der oben beschriebene RMI-Server geeignet. Die einzige Konfigurationseinstellung ist die Nummer des TCP-Ports, auf dem der Server auf Verbindungen warten soll. Dieses Plug-In kann mehrfach mit unterschiedlichen Port-Nummern eingerichtet werden. Der Default-Wert für die Port-Nummer ist 54321.
<?xml version="1.0" encoding="UTF-8"?>
<AccessServer>
...
<ThreadPlugin
PluginClass = "de.iiit.AccessServer.server.TcpServer"
>
<PluginConfig
Port = "54321"
/>
</ThreadPlugin>
...
</AccessServer>
Wenn mehrere Instanzen des iiitAccessServers installiert sind, so darf und muss der CacheManager nur bei einer davon aktiviert werden.
Der CacheManager liest beim ersten Start den Inhalt der LDAP-Datenbank und füllt damit den persistenten 2nd-Level-Cache. Danach werden alle Änderungen in der LDAP-Datenbank mitgelesen und in den Cache übertragen. Wenn dabei Fehler auftreten, kann automatisch eine e-Mail mit einer Fehlermeldung an den verantwortlichen Administrator gesendet werden.
<?xml version="1.0" encoding="UTF-8"?>
<AccessServer>
...
<ThreadPlugin
PluginClass = "de.iiit.AccessServer.cachemanager.CacheManager"
>
<PluginConfig
ReplicationFile = "/var/lib/ldap/replication.log"
RefreshInterval = "10"
Md5PatternLength = "1"
SMTPServer = "jacomo.iiit.de"
SMTPPort = "-1"
SMTPUser = ""
SMTPPassword = ""
SMTPMailTo = "root@iiit.de"
>
<JdbcDriver
ClassName = "com.mysql.jdbc.Driver"
/>
<AdminDatabase
Url = "jdbc:mysql://wuppi/AccessServerAdmin"
UserName = "checker"
Password = "checker"
Connections = "5"
/>
<CacheDatabase
Url = "jdbc:mysql://jacomo/AccessServerCache"
UserName = "checker"
Password = "checker"
Connections = "5"
/>
<CacheDatabase
Url = "jdbc:mysql://wuppi/AccessServerCache"
UserName = "checker"
Password = "checker"
Connections = "5"
/>
</PluginConfig>
</ThreadPlugin>
...
</AccessServer>
Genau wie beim LDAP Resolver kann die LDAP-Konfiguration global oder als Element innerhalb der Plug-In-Konfiguration abgelegt werden.
Mit den Attributen SMTPServer, SMTPPort, SMTPUser, SMTPPassword und SMTPMailTo wird die Verbindung zu einem Mail-Server konfiguriert. Wenn beim SMTPPort -1 oder gar nichts angegeben wird, wird der Standard SMTP-Port genutzt. Wenn diese Einstellungen nicht angegeben werden, werden keine Fehlermeldungen per e-Mail verschickt.
Die Cache-Datenbanken müssen genauso wie beim Datenbank-Cache konfiguriert werden. Zusätzlich wird eine Datenbank für temporäre Daten des CacheManagers benötigt. Diese wird analog zu den anderen Datenbanken mit dem Element AdminDatabase konfiguriert. In einer Minimal-Konfiguration kann dies die gleiche Datenbank wie die Cache-Datenbank sein.
Um Änderungen in der LDAP-Datenbank in den Cache übertragen zu können, liest der CacheManager die Replikationsdatei des OpenLDAP-Servers und simuliert damit quasi den slurpd. Mit dem Attribut ReplicationFile wird der Name der Replikationsdatei und mit RefreshInterval die Wartezeit zwischen zwei Durchläufen definiert. Die Konfiguration des LDAP-Serservs selbst wird im nächsten Abschnitt erläutert.
Hier kann und soll nicht die Konfiguration von OpenLDAP erläutert werden, sondern nur die Besonderheiten, die beim Betrieb des iiitAccessServers zusammen mit OpenLDAP zu beachten sind.
Im Unterverzeichnis ldap des Installationsverzeichnisses liegt u.a. die Datei iiit.schema. Diese enthält eine Schema-Erweiterung für den LDAP-Server mit den Klassendefinitionen iiitFormula, iiitPerson und iiitGroup. Diese sollen für alle für den iiitAccessServer relevanten Daten in der LDAP-Datenbank genutzt werden. Die Klassen iiitPerson und iiitGroup sind kompatibel zu anderen Personen- und Gruppendefinitionen in LDAP, so dass sie mit diesen zusammen verwendet werden können.
Um diese Schema-Erweiterung in den LDAP-Server einzubinden, ist die Datei iiit.schema in das schema-Verzeichnis der LDAP-Konfiguration zu kopieren. Unter SuSE-Linux ist dies z.B. das Verzeichnis /etc/openldap/schema. Zusätzlich ist in der Konfigurationsdatei slapd.conf im LDAP-Konfigurationsverzeichnis hinter allen anderen Schema-Definitionen die Zeile
include /etc/openldap/schema/iiit.schema
einzutragen.
Der entsprechende Abschnitt der Konfigurationsdatei sieht dann in etwa so aus:
... include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/iiit.schema ...
Zusammen mit dem iiitAccessServer haben sich folgenden Index-Definitionen für die LDAP-Datenbank bewährt:
... index default pres,eq index uid index cn,sn pres,eq index objectClass eq ...
Damit der iiitAccessServer die Änderungen in der LDAP-Datenbank mitlesen kann, muss beim LDAP-Server Replikation eingeschaltet werden. Bei der Replikation schreibt der LDAP-Server alle Änderungen im LDIF-Format in eine Datei, die normalerweise vom Programm slurpd gelesen und an andere (Slave-) LDAP-Server übertragen wird. Der iiitAccessServer übernimmt in diesem Fall die Rolle des slurpd, nur dass die Daten nicht an andere LDAP-Server sondern in den persistenten Cache übertragen werden. Dazu muß der iiitAccessServer Zugriff auf diese Datei erhalten. Am einfachsten ist dies möglich, wenn er dazu auf dem gleichen Rechner wie der LDAP-Server installiert wird. Er muß obendrein im Datei-System die Berechtigung haben, die Datei zu lesen und zu schreiben, weshalb er am besten mit der gleichen User-ID wie der LDAP-Server gestartet werden sollte.
Wenn der iiitAccessServer in einer Umgebung mit replizierten LDAP-Servern läuft, so kann er nicht zusammen mit dem Master-Server sondern nur mit einem der Slave-Server zusammen installiert werden, da es sonst zu Konflikten zwischen dem iiitAccessServer und dem slurpd kommt.
Wichtig: Der iiitAccessServer kann nicht zusammen mit dem slurpd auf eine Replikationsdatei zugreifen.
Um die Replikation im OpenLDAP-Server einzuschalten sind Einträge der folgenden Art in der Konfigurationsdatei slapd.conf notwendig:
...
replogfile /var/lib/ldap/replication.log
replica host=AccessServer
binddn="cn=Replicator,dc=iiit,dc=de"
bindmethod=simple credentials=secret
Diese Einträge müssen hinter der Datenbank-Definition, also überlicherweise ganz am Ende der Konfigurationsdatei vorgenommen werden. Der Eintrag replogfile muss natürlich mit dem Attribut ReplicationFile der CacheManager-Konfiguration übereinstimmen.