Weitere APIs und Protokolle
SIP2
SIP2 (Session Initiation Protocol) ist ein Protokoll für die Kommunikation zwischen Geräten.
Im Kontext von Koha wird SIP2 für die Kommunikation zwischen den Selbstverbuchungsgeräten (SC) und dem automatischen Ausleihsystem (auch ACS genannt und in diesem Fall der Server mit Koha) verwendet.
Die SIP2-Kommunikation besteht aus Anfragen (requests) und Antworten (responses).
Die Selbstverbuchungsgeräte sind an sich „dumm“ und schicken Anfragen an den Koha-Server, der die Logik für die betreffende Anfrage ausführt und eine Antwort zurück an den Client des Selbstverbuchungsgeräts schickt, der diese an den Benutzer weitergibt.
Warnung
Sicherheitshinweis für die Verwendung des SIP2-Service: Damit die SIP2-Kommunikation über das Internet auf sichere Weise erfolgt, müssen Sie sicherstellen, dass ein VPN oder Stunnel verwendet wird.
Konfiguration von SIP2
Wenn Sie Koha über die Debian-Pakete installiert haben, dann ist die Konfiguration von SIP2 relativ einfach, folgen Sie einfach den folgenden Schritten:
1. In your terminal (in the root Koha directory) write in: sudo koha-enable-sip <instancename>
2. Now you need to configure the SIP2 settings, to do this you need to edit the SIPconfig.xml file which exists in the /etc/koha/sites/<instancename>/ directory. You will need to edit this file as root because it contains passwords (to do so write ‘sudo’ at the start of your command).
Z.B. sudo vi /etc/koha/sites/<instancename>/SIPconfig.xml
Bemerkung
Wichtiger Hinweis: Es gibt drei Bereiche in der Datei SIPconfig.xml die geändert werden müssen. Diese sind: service, account und institution.
Service
2.1 Ändern sie den Port am Anfang der Datei SIPconfig.xml (gekennzeichnet mit der Nummer 1 im folgenden Screenshot), so dass die selbe IP-Adresse wie weiter unten in der Datei, gekennzeichnet mit Nummer 2, verwendet wird.
Bemerkung
Stellen Sie sicher, dass für die beiden Portnummern nicht der gleiche Port verwendet wird, da ein Port nicht für zwei verschiedene Services verwendet werden kann. Wenn Sie die Ports festlegen, wählen Sie einen Port mit einer höheren Nummer (über 1000), da alle Ports unter 1000 Root-Berechtigungen erfordern.
Account
Die Konten, die Sie in der Datei SIPconfig.xml definieren, sind die Konten die den SIP2-Service verwenden würden. Sie legen also fest, wer SIP2-Befehle senden und empfangen kann.
Warnung
Die Kontoinformation, die Sie hier angeben, muss auch in der Koha-Datenbank existieren, d.h. Sie müssen einen Benutzer in der Dienstoberfläche von Koha anlegen, der den gleichen Benutzernamen und das gleiche Passwort hat (und die circulate-Berechtigung) wie das Konto, dass Sie in der Datei SIPconfig.xml angeben.
Bemerkung
Es wird stark empfohlen, dass nur Benutzerkonten mit ausschließlich der circulate-Berechtigung verwendet werden.
Der Grund, warum nur Benutzer mit circulate-Berechtigung, statt weiteren Berechtigungen wie superlibrarian, verwendet werden sollten, ist den Zugriff auf vertrauliche Daten für SIP2-Benutzer für den Fall einer Kompromittierung des Systems möglichst einzuschränken.
Wenn der ACS oder der SC kompromittiert wurden, dann können Angreifer nur über das Terminal auf Benutzerdaten zugreifen, statt auch auf die Dienstoberfläche (was mit anderen und superlibrarian-Berechtigungen möglich wäre). Es geht hier also um den Schutz der Daten.
Definition der Werte unter Accounts:
Login id: Dies ist der Benutzername. - Passen Sie dies entsprechend an
Password: Dies ist das Passwort des Konto. - Passen Sie dies entsprechend an
Delimiter: Das Trennzeichen für Kontoinformationen. - Belassen Sie die Voreinstellung
error-detact - Belassen Sie die Voreinstellung
Institution: Dies ist das Bibliothekskürzel der Bibliothek, zu der dieser Benutzer gehört. HINWEIS: Diese institution muss weiter unten im Bereich für institution der Datei SIPconfig.xml definiert sein und in der Koha-Datenbank existieren, d.h. Sie müssen eine Bibliothek mit dem gleichen Bibliothekskürzel über die Dienstoberfläche in Koha anlegen.
encoding: Dies ist der Standard, der für die Codierung der Daten verwendet wird
Terminator: Dies muss dem Wert für den Terminator des SIP-Servers entsprechen. - Ändern Sie dies nur, wenn Sie den Wert für Ihren SIP2-Server kennen.
Sie können auch zusätzliche Benutzerfelder zu den SIP2-Profilen im folgenden Format hinzufügen:
<patron_attribute field=“XX“ code=“CODE1“ /> <patron_attribute field=“XY“ code=“CODE2“ /> <patron_attribute field=“XZ“ code=“CODE3“ />
Institution
Die institution, die Sie hier definieren, müssen einer Bibliothek entsprechen, die in Koha angelegt wurde.
Warnung
Stellen Sie sicher, dass alle weiter oben unter accounts genannten institutions auch im Bereich für institution der Datei SIPconfig.xml definiert werden.
Definition der Werte unter Institutions:
1: Institution id: Das Bibliotheksküzrel der Bibliothek. - Passen Sie dies entsprechend an. Dies muss das gleiche Kürzel sein, das auch in Koha und im Bereich accounts angegeben wurde.
Implementation: Definiert, welcher Code ausgeführt wird. - Belassen Sie die Voreinstellung
3. Policy: Policy defines the permitted SIP2 commands allowed from SC’s in this institution. For example: renewal=”true” means that SC’s at that institution have permission to send renewal item SIP2 commands.
4: Um SIP2 zu starten, schreiben Sie einfach den Befehl: sudo koha-start-sip <instancename>
Bemerkung
Jetzt haben Sie einen laufenden SIP2-Server.
SIP2 verwenden
SIP2 ist ein Kommunikationsprotokoll. Die SIP2-Nachrichten sind entweder Anfragen (requests) oder Antworten (responses). Der SC schickt eine Nachricht an den ACS, der eine Logik ausführt und das Ergebnis an den SC als Antwort schickt.
Die Anfragen enthalten Argumente, Daten die der ACS in seinen Funktionen für die Erfüllung seiner Aufgaben, wie die Durchführung eine Verlängerung, verwendet.
SIP2-Befehle
Wenn Sie SIP2 händisch verwenden/testen möchten, dann müssen Sie Nachrichten über das Linux-Terminal schreiben und empfangen.
Um Nachrichten an den SIP2-Server senden und empfangen zu können, müssen Sie Telnet verwenden, um eine SIP2-Verbindung aufzubauen. Sie müssen dabei die Portnummer angeben, die Telnet verwenden soll.
Diese Information finden Sie im Bereich service am Anfang der Datei SIPconfig.xml (suchen Sie nach der Portnummer wie durch den Pfeil im Screenshot hervorgehoben).
Schreiben Sie auf der Kommandozeile
telnet localhost <portnumber>
d.h. telnet localhost 8023
Schreiben Sie nun den Benutzernamen und das Passowort aus einem der unter accounts angegeben Konten in der SIPconfig.xml.
Nun sind Sie mit dem SIP2-Server verbunden und können damit beginnen Befehle zu schreiben und abzusenden. Die Verbindung zum SIP2-Server läuft schnell in einen Timeout, um das zu verhindern, bevor Sie mit dem Schreiben und Empfangen von Befehlen fertig sind, schreiben Sie einfach:
telnet localhost <portnumber>
um die SIP2-Verbindung neu aufzubauen.
Syntax der SIP2-Befehle
Jeder SIP2-Befehlt hat ein zweistelliges numerisches Präfix, das festlegt, was der Befehlt tut.
Z.B. Um Informationen zu einem Benutzer zu erhalten, beginnen Sie den Befehl mit dem Präfix 63. Die Antwort des Servers enthält ebenfalls ein korrespondierendes numerisches Präfix.
Unten sehen Sie ein Beispiel für eine SIP2-Anfrage nach Benutzerinformationen (in diesem Beispiel einem Koha-Benutzerkonto mit dem Benutzernamen „joe“, Passwort „joes“ und Ausweisnummer „y76t5r43“, der in der Dienstoberfläche angelegt wurde).
Zusätzlich wurde eine Bibliothek mit dem Bibliohtekskürzel „WEL“ in der Koha-Dienstoberfläche angelegt und im Bereich institutions der Datei SIPconfig.xml definiert):
Das Format der SIP2-Anfrage ist:
Bemerkung
Die Zusammenfassung besteht aus 10 Zeichen. Wenn ein Y in der Zusammenfassung steht, können Sie sowohl eine Zusammenfassung, als auch eine detailliertere Ausgabe erhalten.
Der Wert in <YYYYMMDD> <HHMMSS> ist die aktuelle Zeitangabe, durch frei lassen von 4 zeichen zwischen YYYYMMDD und HHMMSS ist erkenntlich, dass es sich um eine Angabe in lokaler Zeit und nicht um UTC handelt.
Bemerkung
In diesem Handbuch werden wenn möglich Buchstabencodes für die verschiedenen Felder verwendet, um die verschiedenen SIP2-Nachrichtenfelder zu beschreiben, z.B. AO<institutionid>.
Diese Buchstabencodes können in den SIP2-Befehlen in der Linuxkonsole verwendet werden, aber stellen Sie sicher, dass wenn Sie die Werte in den Feldern (Werte in den <>) ersetzen, Sie die spitzen Klammern entfernen.
SIP2-Nachrichten:
Benutzer sperren
Dies verwendet das Präfix 01 für die Anfrage und 24 für die Antwort.
Anfrage:
Bemerkung
Karte einbehalten ist ein Feld mit einem Zeichen, entweder „Y“ oder „N“, dass dem ACS mitteilt, dass eine Karte vom Selbstverbucher einbehalten wurde.
Antwort:
Bemerkung
<patronstatus> ist ein 14 Zeichen langer Wert. Der Wert Y in der Zeichenkette bedeutet wahr (true). Jede Position in dieser Zeichenkette (beginnend mit 0) hat einen einzelnen entsprechenden Wert (Y oder N).
Z.b. ein Y an Position 1 (zweiter Wert der Zeichenkette) bedeutet, dass der Benutzer keine Verlängerungen durchführen kann.
Exemplare zurückgegeben
Dies verwendet in der Anfrage (Nachricht an den ACS) das Präfix 09 und die Antwort verwendet 10 (gesendet an den SC).
Anfrage:
Bemerkung
<no block (Offline)> ist ein Feld mit einem Zeichen, entweder „Y“ oder „N“, welches anzeigt, ob die Transaktion offline durchgeführt wird. Da Offline-Transaktionen nicht unterstützt werden, müssen Sie „N“ angeben, wenn Sie diese Nachricht händisch testen.
<transactiondate> Dies ist ein 18-Zeichen langes Feld mit dem Datum im Format: JJJJMMTTZZZZHHMMSS.
ZZZZ ist die Zeitzone, um die lokale Zeit zu verwenden, können 4 Leerzeichen verwendet werden, aber wenn Sie UTC (Coordinated Universal Time) verwenden möchten, schreiben sie 3 Leerzeichen und ein Z.
Antwort:
Bemerkung
Alert kann einen von mehreren Werten annehmen: 00: Unbekannt, 01: Lokale Vormerkung, 02: Vormerkung vom anderen Standort, 03: Fernleihbestellung, 04: Transport, 99: Sonstiges
Wenn ein Exemplar gesichert wird, dann sollte der Wert von <resensitize> Y sein, anderenfalls ein N. Exemplare werden gesichert, um eine Meldung auszulösen, wenn jemand versucht das Exemplar zu stehlen.
Exemplare ausleihen
Diese Nachricht verwendet das Präfix 11 für die Anfrage und das Präfix 12 für die Antwort. Sie hat eine ähnliche Syntax wie der Rückgabebefehl, der oben beschrieben wird, mit Ausnahme der Präfixe.
Vormerkung - Wird eventuell noch nicht von allen Systemen unterstützt. Die Anfrage hat den Präfix 15 und die Antwort das Präfix 16.
Anfrage:
Bemerkung
<holdmode> ist ein Wert von einem Zeichen Länge. + bedeutet, eine Vormerkung eintragen, - bedeutet, eine Vormerkung stornieren und * bedeutet eine Änderung an einer Vormerkung.
Antwort:
Bemerkung
<ok> ist ein Wert von einem Zeichen Länge der entweder 0 (für Vormerkung nicht erlaubt oder nicht erfolgreich) oder 1 (für Vormerkung ist erlaubt und war erfolgreich) annehmen kann.
<available> ist ein Wert von einem Zeichen Länger, der entweder Y oder N ist. Y bedeutet, dass das Exemplar aktuell in der Bibliothek ist, während N bedeutet, dass das Exemplare aktuell an jemanden entliehen oder für jemand anderen vorgemerkt ist.
Exemplarinformation: Dies verwendet in der Anfrage den Präfix 17 und in der Antwort den Präfix 18
Anfrage:
Bemerkung
Lesen Sie im Rückgabebefehl (oben beschrieben) nach, was der <xact_date>-Wert ist.
Das Terminalpasswort ist optional.
Antwort:
Update des Exemplarstatus: Dies verwendet in der Anfrage den Präfix 19 und in der Antwort den Präfix 20
Anfrage:
Bemerkung
<itemproperties> ist kein Wert mit fester Länge und Sie können optional Werte wie die Grüße des Exemplars angeben und diese Werten in der Koha-Datenbank für das Exemplar gespeichert.
Antwort:
Bemerkung
<itempropertiesok> ist ein Wert mit einem Zeichen Länge, der entweder 0 oder 1 ist. 1 bedeutet, dass der in <itemproperties> angegeben Wert für ein Update des Exemplarstatus erfolgreich in der Datenbank gespeichert wurde.
Benutzerstatus
Dieser verwendet den Präfix 23 in der Anfrage und den Präfix 24 in der Antwort.
Anfrage:
Antwort:
Bemerkung
Der Wert, der für <patronvalidity> angezeigt wird, ist entweder Y (gültig) oder N (ungültig). Der Wert in <YYYYMMDD> < HHMMSS> ist das aktuelle Datum und Uhrzeit.
Der Grund für den Abstand zwischen den beiden Werte ist, dass hier lokale Zeit, statt UTC angegeben wird.
Benutzer aktivieren - Dies wird noch nicht unterstützt. Dieser Befehl verwendet das Präfix 25 in der Anfrage und 26 in der Antwort
Bemerkung
Dieser Befehl macht den Befehl zum Sperren eines Benutzers rückgängig.
Anfrage:
Antwort:
** Verlängern: Dieser Befehl verwendet das Präfix 29 in der Anfrage und 30 in der Antwort**
Anfrage:
Bemerkung
<thirdpartyallowed> ist ein Wert von einem Zeichen Länge, der entweder Y oder N ist. Wenn er Y ist, dann können auch Dritte Ausleihen verlängern.
<noblock> ist ein Wert von einem Zeichen Länge, der entweder Y oder N ist. Wenn er Y ist, dann bedeuutet dies, dass der Selbstverbucher offline war, als die Ausleihe/Rückgabe erfolgt ist.
<nbduedate> ist das Transaktionsdatum der Rückgabe/Ausleihe, während der Selbstverbucher offline war.
<feeacknowledged> ist ein Wert mit einem Zeichen Länder, der entweder Y oder N ist. Dieser zeigt an, ob der Benutzer die mit der Verlängerung verbundenen Gebühren akzeptiert hat.
Antwort:
Bemerkung
<ok> ist ein Wert mit einem Zeichen Länge, der entweder 0 oder 1 ist. Ein Wert von 1 bedeutet, dass das Exemplar erfolgreich verlängert wurde, 0 bedeutet, dass die Verlängerung nicht ausgeführt wurde.
<renewalok> ist ein Wert mit einem Zeichen Länge, der entweder Y oder N ist. Die Logik hinter <renewalok> ist, dass Y gesetzt wird, wenn das Exemplar bereits von diesem Benutzer entliehen ist und daher entsichert und verlängert werden sollte, während N gesetzt wird, wenn es bereits vom Benutzer entliehen ist, aber nicht verlängert werden soll.
In anderen Worten: Lasse Benutzer keine Medien verlängern, die bereits an sie entliehen sind.
<magneticmedia> ist ein Wert mit einem Zeichen Länge der entweder Y (für Ja) oder N (für Jein) oder U (für Unbekannt) ist.
<mediatype> ist ein Wert von 3 Zeichen Länge. Eine Liste der möglichen Werte finden Sie in: http://multimedia.3m.com/mws/media/355361O/sip2-protocol.pdf
Sitzung beenden
Dieser verwendet das Präfix 35 in der Anfrage und 36 in der Antwort
Anfrage:
Antwort:
Bemerkung
<success_or_failure> ist entweder Y für Erfolg oder N für Fehlschlag.
Gebühr bezahlt - Ist möglicherweise noch nicht implementiert. Dieser verwendet ein Präfix von 37 für die Anfrage und ein Präfix von 38 für die Antwort
Anfrage:
Bemerkung
<feetype> ist ein zweistelliges numerisches Feld mit enem Wert zwischen 01 und 99. Eine Liste der Gebührenarten finden Sie in http://multimedia.3m.com/mws/media/355361O/sip2-protocol.pdf
<paymenttype> ist ein zweistelliges numerisches Feld mit einem Wert zwischen 00 und 99. 00 ist Bar, 01 ist Visa und 02 ist Kreditkarte.
<currencytype> ist ein dreistelliges alphanumerisches Feld, dass die Währung angibt, in der eine Gebühr bezahlt wurde.
Antwort:
Bemerkung
<paymentaccepted> ist ein einstelliger Wert, der entweder Y (Zahlung wurde akzeptiert) oder N (Zahlung wurde nicht akzeptiert) annehmen kann.
Benutzerinformation
Dieser verwendet das Präfix 63 in der Anfrage und 64 in der Antwort
Anfrage:
Antwort:
Bemerkung
<valid patron> ist Y für gültig und N für ungültig.
Bemerkung
<hold itemcount><overdueitemcount><chargeditemscount><fienitemscount><recallitemscount><unavaliableholdscount> sind alle vierstellige numerische Werte.
Alle verlängern
Dieser verwendet ein Präfix von 65 in der Anfrage und 66 in der Antwort.
Anfrage:
Antwort:
Bemerkung
<renewedcount> ist ein vierstelliger numerischer Wert, der die Anzahl der verlängerten Exemplare angibt.
<unrenewedcount> hat das gleiche Format wie <renewedcount>, aber gibt die Anzahl der Exemplare an, die nicht verlängert wurden.
Anmeldung
Dieser verwendet das Präfix 93 in der Anfrage und 94 in der Antwort.
Anfrage:
Bemerkung
<UIDalgorithm> und <PWDalgorithm> sind einstellige Werte, die angeben, welcher Algorithmus für die Verschlüsselung von loginuserid und loginpassword verwendet werden soll.
Die Angabe 0 bedeutet, dass die Werte nicht verschlüsselt werden.
Antwort: 941 ist eine erfolgreiche Anmeldung. 940 ist eine fehlgeschlagene Anmeldung. [connection closed by foreign host.] ist ebenfalls eine fehlgeschlagene Anmeldung
Erneutes senden
Dies fordert das empfangende Gerät dazu auf, seine letzte Nachricht erneut zu schicken.
SC -> ACS für erneutes Senden ist 97
ACS -> SC für erneutes Senden ist 96
Status des ACS und SC
Dieser verwendet das Präfix 99 in der Anfrage und 98 in der Antwort.
Anfrage:
Bemerkung
Der Statuscode hat einen von 3 Werten. * 0: SC ist in Ordnung * 1: SC hat kein Papier mehr * 2: SC: fährt herunter. Die Druckbreite sind 3 Zeichen, die er Anzahl der Zeichen entspricht, die der Client drucken kann. Protokoll-Vresion ist ein 4 Zeichen langer Wert im Format x.xx
Antwort:
Bemerkung
Wenn Sie die Antwort „96“ erhalten, bedeutet dies, dass die Anfrage nicht verstanden wurde oder ungültig war.
SIP2-Troubleshooting
Es ist keien Verbindung mit dem Host über das Telnet-Kommando localhost <portnumber> möglich
3 mögliche Lösungen für dieses Problem sind:
Prüfen Sie die Portnummer in Ihrem Befehl in der SIPconfig.xml an der mit Nummer 1 markierten Stelle nach. D.h. In dem untenstehenden Beispiel, wäre das korrekte Kommando telnet localhost 6001, da die Portnummer 6001 ist.
Prüfen Sie, ob eine userid mehr als einmal in der SIPconfig.xml-Datei definiert ist. Die userid (die dem Benutzernamen des Koha-Benutzers entspricht) darf in der SIPconfig.xml nur einmal vorkommen. Wenn die selbe userid mehrfach in der SIPconfig.xml verwendet wurde, schlägt die Verbindung über SIP2 fehlt, bevor Sie die Möglichkeit hatten sich zu authentifizieren.
Prüfen Sie nach, dass der account der in der Datei SIPconfig.xml definiert wurde auch in der Koha-Datenbank mit dem gleichen Benutzernamen und Passwort existiert und die circulate-Berechtigung hat. Wenn Sie die Koha-Datenbank gelöscht und neu angelegt haben, nachdem das Benutzerkonto in der Dienstoberfläche von Koha und in der SIPconfig.xml angelegt wurde, dann wird dieses Konto nicht mehr in Koha existierten und muss neu angelegt werden.
Um auf die SIP2-Logs in Koha zuzugreifen, navigieren Sie in das folende Verzeichnis: /var/log/koha/<instancename>
Dann lassen Sie sich die Ausgaben in sip-error.log und sip-output.log anzeigen, die genauere Informationen über den SIP2-Fehler enthalten.
cat sip-error.log
cat sip-output.og
Nützliche Linsk für SIP2-Befehle:
http://multimedia.3m.com/mws/media/355361O/sip2-protocol.pdf
LDAP
Die Anbindung an LDAP (Lightweight Directory Access Protocol) an Koha erlaubt Ihnen Benutzerdaten in einer zentralen Datenbank zu verwalten, auf die von Koha aus und von Ihren Benutzern zugegriffen wird, um sich in existierenden Systemen anzumelden.
LDAP ist ein Protokoll zur Durchführung von Abfragen und Änderungen in einem verteilten Verzeichnisdienst.
Die Konfigurationsmöglichkeiten von LDAP sind mächtig und erlauben es anzupassen, wie Koha und LDAP miteinander interagieren. LDAP kann so konfiguriert werden, dass neue Konten, die in LDAP angelegt werden oder auch zusätzlich Updates an LDAP-Benutzern in die Koha-Datenbank übertragen werden.
Allerdings kann Koha keine Daten in den LDAP-Server synchronisieren, der Datenfluss bei LDAP läuft also nur in eine Richtung.
Auth_By_Bind ist 1, wenn ein Microsoft Windows Active Directory als Datenbank für LDAP verwendet wird.
Bevor Sie die nächsten Schritte Schritte zur Konfiguration von LDAP ausführen, benötigen Sie die folgenden Informationen von Ihrer Einrichtung
Die Organisation muss einen Port öffnen, um den Zugriff auf das AD von Ihrem Server aus zu erlauben.
Informationen für den Zugriff auf den AD-Server (IP-Adresse/Hostname, Port, SSL-Info)
Informationen zur Konfiguration des AD-Servers (relevante OUs, DCs, CN-Formate relativ zu Benutzernamen)
Mapping zwischen AD-Feldern und Koha-Feldern, inklusive der Voreinstellungen
Voreinstellungen für Werte, die nicht vom AD geliefert werden (z.B. Benutzertyp, Heimatbibliothek)
Um einen Benutzer zu authentifizieren melden wir uns ald dies an (üblich bei AD) oder verwenden wir ein Konto für das Login und prüfen dann? Für das Letztere benötigen wir die Angaben für die Anmeldung
Stimmen die in Koha existierenden Benutzernamen mit denen überein, die wir im AD vorfinden? Wenn ja, gut. Wenn nicht, wie gehen wir mit dubletten Benutzern um?
Schritte für die Konfiguration von LDAP mit Koha
1 Navigieren Sie im Linux-Terminal in das Verzeichnis mit der koha-conf.xml, diese liegt entweder unter * /etc/koha/sites/<instance-name>/ ODER * /etc/koha/
2 Öffnen Sie die koha-conf.xml mit Root-Berechtigung: sudo vi koha-conf.xml
3 Scrollen Sie zu der Zeile mit ‘<useldapserver>0</useldapserver>’ und ändern Sie den Eintrag zu <useldapserver>1</useldapserver>
4 Dann in der nächsten Zeile darunter geben Sie die LDAP-Konfiguration an: Alle in gelb hervorgehobenen Felder müssen mit den korrekten Werten für den LDAP-Server Ihrer Einrichtung ersetzt werden.
<ldapserver id="<ldapserverid>">
<hostname><hostname></hostname>
<base>dc=<domaincontroller>,dc=<domaincontroller></base>
<user>cn=<nameofuser>, dc=<domaincontroller>,dc=<domaincontroller></user> <!--This is the username of user account with permissions to query the LDAP server -->
<pass><password></pass> <!-- This is password of the user account with permissions to query the LDAP server-->
<replicate><either0or1></replicate> <!-- add new users from LDAP to Koha database -->
<update><either0or1></update> <!-- update existing users in Koha database -->
<auth_by_bind><either0or1></auth_by_bind> <!-- set to 1 to authenticate by binding instead of password comparison, e.g., to use Active Directory -->
<principal_name><principalname></principal_name> <!-- optional, for auth_by_bind: a printf format to make userPrincipalName from koha userid -->
<mapping> <!-- match koha SQL field names to your LDAP record field names-->
<firstname is="givenname"></firstname>
<surname is="sn"></surname>
<address is="postaladdress"></address>
<city is="l">Athens, OH</city> <!-- Athens,OH is the default value for
city of all users logging into Koha -->
<zipcode is="postalcode"></zipcode>
<branchcode is="branch">Central</branchcode>
<userid is="uid"></userid>
<password is="userpassword"></password>
<email is="mail"></email>
<categorycode is="employeetype">EM</categorycode>
<phone is="telephonenumber"></phone>
</mapping>
</ldapserver>
5 Speichern und Verlassen Sie die Datei koha-conf.xml
6 Prüfen Sie, ob die LDAP-Verbindung funktioniert, über:
ldapsearch -H ldaps://host.name -s base -x -w „“ -d 1
Bemerkung
Hinweis zum Hostname: Der Hostname kann entweder eine alphanumerische Bezeichnung oder die IP-Adresse des LDAP-Servers sein (die Angabe der Portnummer ist optional). Die Voreinstellung ist die Portnummer von LDAPS 636 und von LDAP 389
Bemerkung
Hinweis zu den Feldern replicate und udpate: Das Feld replicate für LDAP in der koha-conf.xml erlaubt es einen neuen Benutzer in der Koha-Datenbank anzulegen, wenn sich dieser in Koha mit seinem LDAP-Benutzernamen und Passwort anmeldet (entweder im OPAC oder der Dienstoberfläche und nur wenn dieses Login noch nicht in der Datenbank existiert).
Das Feld update (in der gleichen Datei) hingegen erlaubt es Benutzerinformationen der Koha-Datenbank mit denen in der LDAP-Datenbank zu synchronisieren, d.h. wenn jemand heiratet und sich der Nachname ändert, muss der Nachname nur in der LDAP-Datenbank geändert werden und wird von dort in die Koha-Datenbank übertragen, wenn der Benutzer sich anmeldet und update auf 1 gesetzt wurde.
Zu den Mapping-Feldern (in grün hervorgehoben): <city is=“l“>Athens, OH</city>
Der Spaltenname links (hervorgehoben in gelb) ist der Name der Spalte in der LDAP-Datenbank.
Der Spaltenname in den Anführungszeichen (hervorgehoben in pink) ist der Name der Spalte in der Koha-Datenbank. HINWEIS: Diese Angabe kann beliebig gewählt werden, wenn es keine entsprechende Spalte in der Koha-Datenbank gibt.
Der Wert in hellblau ist die Voreinstellung für die angegebenen Koha- und LDAP-Spalten. Im oberen Beispiel erhalten alle Benutzerdatensätze in der Koha-Datenbank in der Voreinstellung die Stadt „Athens, Oh“.
Beispiele von LDAP-Konfigurationen:
<useldapserver>1</useldapserver><!-- see C4::Auth_with_ldap for extra configs you must add if you want to turn this on -->
<ldapserver id="ldapserver" listenref="ldapserver">
<hostname>ldaps://example.co.au</hostname>
<base>ou=employees,dc=companya,dc=com,dc=au</base>
<user></user> <!-- DN, if not anonymous -->
<pass></pass> <!-- password, if not anonymous -->
<auth_by_bind>1</auth_by_bind>
<replicate>1</replicate> <!-- add new users from LDAP to Koha database -->
<update>0</update> <!-- update existing users in Koha database -->
<principal_name>ou=employees,dc=companya,dc=com,dc=au</principal_name>
<mapping>
<userid is="uid" ></userid>
<cardnumber is="uid" ></cardnumber>
<email is="mail" ></email>
<surname is="sn" ></surname>
<firstname is="givenname" ></firstname>
<categorycode is="1">EM</categorycode>
<branchcode is="1">SYD</branchcode>
</mapping>
</ldapserver>
Die Werte in den Mappings werden variieren und hängen davon ab, was in Ihrer LDAP-Datenbank gespeichert ist. Zum Beispiel verwenden einige Organisationen nicht das Feld <userid> sondern identifizieren den Benutzer über das Feld <email>, so dass keine <userid> ausgegeben wird.
Troubleshooting LDAP
Das Log, in dass LDAP-Fehler ausgegeben werden, hängt von verschiedenen Faktoren ab:
Wenn Plack aktiviert ist, dann werden LDAP-Fehler im plack-error.log ausgegeben. Wenn Plack deaktiviert ist, dann werden die LDAP-Fehler entweder im opac-error.log (bei Anmeldung im OPAC) oder im intranet-error.log (bei Anmeldung in der Dienstoberfläche) ausgegeben. Alle drei Logdateien finden sich im folgenden Verzeichnis:
/var/log/koha/<instance>/