Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- kb [2016/03/29 08:00]
flacco [Active Directory auf invis-Server]
+++ kb [2016/04/23 08:25]
flacco [Paketbenennung und Konfliktverhalten]
@@ Zeile 9: / Zeile 9: @@
 ==== Microsoft Actice Directory ====
-"Active Directory" ist eine von Microsoft entwickelte Kombination aus Kerberos, LDAP-Verzeichnis und Domain-Name-Service. Dabei dient Kerberos der Benutzer-Authentifizierung und ermöglicht sogenanntes "Single-Sign-On", das LDAP-Verzeichnis dient als zentraler Informationsspeicher und DNS wird für eine Technik namens "Service Location" genutzt. Eingeführt wurde "Active Directory" mit Einführung des "Microsoft Servers 2000".
+"Active Directory" ist eine von Microsoft entwickelte Kombination aus [[https://de.wikipedia.org/wiki/Kerberos_%28Informatik%29|Kerberos]], [[https://de.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol|LDAP]]-Verzeichnis und Domain-Name-Service. Dabei dient Kerberos der Benutzer-Authentifizierung und ermöglicht sogenanntes "Single-Sign-On", das LDAP-Verzeichnis dient als zentraler Informationsspeicher und DNS wird für eine Technik namens "Service Location" genutzt. Eingeführt wurde "Active Directory" mit Einführung des "Microsoft Servers 2000".{{ :active-directory_ms.png?300|}}
-Single-Sign-On (SSO) ermöglicht, dass nur eine Anmeldung am System auch als Autorisierung für alle im Netzwerk angebotenen Dienste gilt. D.h. es genügt beispielsweise sich am eigenen PC mit Benutzernamen und Passwort anzumelden um danach ohne weitere Angabe von Benutzernamen oder Passwort auch Zugriff auf Dienste wie beispielsweise einen Exchange-Server zu erhalten.{{ :active-directory_ms.png?300|}}
+[[https://de.wikipedia.org/wiki/Single_Sign-on|Single-Sign-On]] (SSO) ermöglicht, dass nur eine Anmeldung am System auch als Autorisierung für alle im Netzwerk angebotenen Dienste gilt. D.h. es genügt beispielsweise sich am eigenen PC mit Benutzernamen und Passwort anzumelden um danach ohne weitere Angabe von Benutzernamen oder Passwort auch Zugriff auf Dienste wie beispielsweise einen Exchange-Server zu erhalten.
 Kerberos seinerseits verwaltet keinerlei eigenen Datenbestand. Die Daten auf die Kerberos zurückgreift werden in einem sogenannten LDAP-Verzeichnis abgelegt. Das LDAP-Verzeichnis stellt somit den zentralen Informationsspeicher des Active Directories dar. LDAP (Lightweight Directory Access Protocol) steht dabei sowohl für das Netzwerkprotokoll über welches auf die Informationen im Verzeichnis zugegriffen wird, als auch den Informationsspeicher selbst. Der Datenspeicher arbeitet "objektorientiert" und somit gänzlich anders als eine relationale Datenbank. Der objektorientierte Ansatz ermöglicht es Netzwerk- oder Organisationsstrukturen eins zu ein im Datenspeicher abzubilden.
@@ Zeile 21: / Zeile 21: @@
 ==== Active Directory auf invis-Server ====
-Die Verwendung eines LDAP-Verzeichnisses als zentralen Informationsspeicher für Benutzerverwaltung, DNS- & DHCP-Server sowie weitere Zwecke zu nutzen ist für invis-Server nicht neu. Mit openLDAP verfügte auch der invis Classic schon immer über ein LDAP-Verzeichnis. Was fehlte waren Kerberos und Service Location.{{ :active-directory_invis-server.png?350|}}
+{{ :active-directory_invis-server.png?350|}}Die Verwendung eines LDAP-Verzeichnisses als zentralen Informationsspeicher für Benutzerverwaltung, DNS- & DHCP-Server sowie weitere Zwecke zu nutzen ist für invis-Server nicht neu. Mit openLDAP verfügte auch der invis Classic schon immer über ein LDAP-Verzeichnis. Was fehlte waren Kerberos und Service Location.
 Mit Einführung von Samba 4.0 brachte Samba eine eigene Implementation von Microsofts Active Directory mit. Dies ermöglichte uns den Umstieg von openLDAP auf Active Directory. Um alle Informationen die der invis Classic im LDAP speicherte auch im AD speichern zu können mussten wir eigene Schemaerweiterungen einspielen und darüber hinaus auch den von uns verwendeten DHCP-Server des ISC (Internet Systems Consortium) patchen.
-Als DNS-Server verwenden wir nicht den "Samba Internal DNS", sondern weiterhin "bind" (ebenfalls vom ISC). Dies wird allerdings von Samba direkt unterstützt. Die Anbindung erfolgt hier über einen DLZ-Treiber den Samba selbst mitbringt.
+Als DNS-Server verwenden wir nicht den "Samba Internal DNS", sondern weiterhin "bind" (ebenfalls vom ISC). Dies wird allerdings von Samba direkt unterstützt. Die Anbindung erfolgt hier über einen DLZ-Treiber ([[http://bind-dlz.sourceforge.net/|Dynamic Loadable Zone]]) den Samba selbst mitbringt. Nebenbei bemerkt ist es auch in Microsoft AD-Umgebungen den DNS-Dienst auszulagern, ich habe das mit "ISC bind" bereits erfolgreich getestet.
-Für die Benutzerverwaltung haben sich die Vorzeichen umgekehrt. Beim invis Classic wurden im LDAP prinzipiell POSIX-kompatible Benutzerkonten angelegt, die um Windows- respektive Samba-Attribute ergänzt wurden. Mit Active Directory bilden jetzt Windows-Benutzerkonten die Basis, die um POSIX-Attribute erweitert werden. Da Microsoft dies selbst unter Verwendung der eigenen Erweiterung "Services for UNIX" (SFU) anbietet, bricht dies nicht die Kompatibilität zur MS-Welt. Unter Samba wird diese Ergänzung "RFC 2307 Erweiterung" genannt.
+Für die Benutzerverwaltung haben sich die Vorzeichen umgekehrt. Beim invis Classic wurden im LDAP prinzipiell POSIX-kompatible Benutzerkonten angelegt, die um Windows- respektive Samba-Attribute ergänzt wurden. Mit Active Directory bilden jetzt Windows-Benutzerkonten die Basis, die um POSIX-Attribute erweitert werden. Da Microsoft dies selbst unter Verwendung der eigenen Erweiterung "Services for UNIX" (SFU) anbietet, bricht es nicht die Kompatibilität zur MS-Welt. Unter Samba wird diese Ergänzung "RFC 2307 Erweiterung" genannt.
-Die Anbindung von Linux-Clients wird über eine Kombination aus Samba und {{https://fedoraproject.org/wiki/Features/SSSD|SSSD}} (System Security Services Daemon) realisiert. Dabei wird Samba genutzt um (genau wie Windows Clients) der Domäne beizutreten und SSSD ist für die Abbildung der Benutzerkonten via PAM auf Linux-Systemen sowie die Benutzeranmeldung selbst zuständig. Selbstverständlich wird auch hier Kerberos verwendet.
+Die Anbindung von Linux-Clients wird über eine Kombination aus Samba und [[https://fedoraproject.org/wiki/Features/SSSD|SSSD]] (System Security Services Daemon) realisiert. Dabei wird Samba genutzt um (genau wie Windows Clients) der Domäne beizutreten und SSSD ist für die Abbildung der Benutzerkonten via PAM auf Linux-Systemen sowie die Benutzeranmeldung selbst zuständig. Selbstverständlich wird auch hier Kerberos verwendet.
 Genau wie es für Windows-Domänenmitglieder möglich ist, ermöglicht der SSSD auch für Linux-Clients Offline-Logins an der Domäne.
+Grundsätzlich beherrschen invis-Server damit auch Single Sign On, leider haben wir dass noch nicht für die Dienste des invis-Servers umgesetzt.
 ==== Active Directory und Firewall ====
@@ Zeile 49: / Zeile 49: @@
 |SMB/CIFS  |  TCP & UDP  |  445  |  Zugriff auf sysvol Freigabe  |
 |RPC  |  TCP  |  135  |Früheres Microsoft Messaging Protokoll, wird genutzt für die Replikation der sysvol Freigabe. Dies wird von Samba noch nicht unterstützt.  |
-===== DNS-Server bind und LDAP =====
+==== ISC DHCP mit ActiveDirectory ====
+Um den DHCP-Server des ISC mit einem Active Directory als Backend zu verwenden, muss dieser so gepatcht werden, dass er andere LDAP-Attribut- und Objektklassen-Namen akzeptiert. Dies ist notwendig, da Microsoft für seinen DHCP-Server teils identische Namen für Attribute und Objektklassen verwendet. Ohne das Patchen führt der Versuch einen ISC DHCP-Server Datenbestand aus einem OpenLDAP Verzeichnis in ein Active Directory zu migrieren zu "Objectclass Violations" die nicht zu beheben sind.
+=== LDAP Patch erzeugen ===
+Den Patch zu erstellen ist etwas umständlich, da im openSUSE-Paket bereits Patches auf die von uns zu patchenden Dateien angewendet werden. D.h. um unseren Patch zu erzeugen müssen zunächst die anderen Patches auf den Quellcode angewendet werden.
+Zu patchen sind folgende Dateien:
+  * server/ldap.c
+  * contrib/ldap/README.ldap
+  * contrib/ldap/dhcpd-conf-to-ldap
+  * contrib/ldap/dhcp.shema
+Im ersten Schritt müssen aus dem Repository "network:dhcp" (https://build.opensuse.org/package/show/network:dhcp/dhcp) des openSUSE Buildservice das Quellcode-Archiv (dhcp-4.x.y.tar.gz), sowie die beiden Patches "0007-dhcp-4.2.6-ldap-mt01.patch" und "0022-dhcp-4.2.x-contrib-conf-to-ldap-reorder.886094.patch" heruntergeladen werden.
+Das Quellcode-Archiv ist in ein Arbeitsverzeichnis zu extrahieren. Danach sind die beiden heruntergeladenen Patches darauf anzuwenden:
+<code>
+heinzb@knurps:~/baustelle/dhcp-4.2.6> patch -p1 server/ldap.c 0007-dhcp-4.2.6-ldap-mt01.patch
+heinzb@knurps:~/baustelle/dhcp-4.2.6> patch -p1 contrib/ldap/dhcpd-conf-to-ldap 0022-dhcp-4.2.x-contrib-conf-to-ldap-reorder.886094.patch
+</code>
+Treten dabei Fehler auf, sind diese in einer auf **.rej** endenden Datei im Verzeichnis der zu patchenden Datei zu finden. Sind die Fehler überschaubar, lassen sich die Änderungen auch manuell durchführen.
+Jetz sind per suchen und ersetzen der Attributnamen und Objektklassen mit **//sed//** neue Dateien mit den gewünschten Änderungen zu erzeugen:
+<code>
+heinzb@knurps:~/baustelle/dhcp-4.2.6> cat server/ldap.c | sed /dhcp[A-Z]/s/dhcp/iscDhcp/g > server/ad.ldap.c
+heinzb@knurps:~/baustelle/dhcp-4.2.6> cat contrib/ldap/README.ldap | sed /dhcp[A-Z]/s/dhcp/iscDhcp/g > contrib/ldap/ad.README.ldap
+heinzb@knurps:~/baustelle/dhcp-4.2.6> cat contrib/ldap/dhcpd-conf-to-ldap | sed /dhcp[A-Z]/s/dhcp/iscDhcp/g > contrib/ldap/ad.dhcpd-conf-to-ldap
+heinzb@knurps:~/baustelle/dhcp-4.2.6> cat contrib/ldap/dhcp.schema | sed /dhcp[A-Z]/s/dhcp/iscDhcp/g > contrib/ldap/ad.dhcp.schema
+</code>
+Jetzt werden mit //**diff**// einzelne Patches für jede der Dateien erzeugt:
+<code>
+heinzb@knurps:~/baustelle/dhcp-4.2.6> diff -u server/ldap.c server/ad.ldap.c > ../ldap.c.patch
+heinzb@knurps:~/baustelle/dhcp-4.2.6> diff -u contrib/ldap/README.ldap contrib/ldap/ad.README.ldap > ../README.ldap.patch
+heinzb@knurps:~/baustelle/dhcp-4.2.6> diff -u contrib/ldap/dhcpd-conf-to-ldap contrib/ldap/ad.dhcpd-conf-to-ldap > ../dhcpd-conf-to-ldap.patch
+heinzb@knurps:~/baustelle/dhcp-4.2.6> diff -u contrib/ldap/dhcp.schema contrib/ldap/ad.dhcp.schema > ../dhcp.schema.patch
+</code>
+Jetzt müssen noch die Kopfzeilen der Einzelpatches angepasst werden. Aus:
+<code>
+--- server/ldap.c       2015-03-26 14:24:44.905456906 +0100
++++ server/ad.ldap.c    2015-03-26 17:12:52.783318249 +0100
+</code>
+wird:
+<code>
+--- a/server/ldap.c       2015-03-26 14:24:44.905456906 +0100
++++ b/server/ldap.c    2015-03-26 17:12:52.783318249 +0100
+</code>
+Danach werden alle Einzelpatches zum Gesamtpatch zusammengesetzt:
+<code>
+heinzb@knurps:~/baustelle> cat ldap.c.patch > 0099-AD-LDAP.patch
+heinzb@knurps:~/baustelle> cat README.ldap.patch >> 0099-AD-LDAP.patch
+heinzb@knurps:~/baustelle> cat dhcpd-conf-to-ldap.patch >> 0099-AD-LDAP.patch
+heinzb@knurps:~/baustelle> cat dhcp.schema.patch >> 0099-AD-LDAP.patch
+</code>
+Danach den Patch in unser Testing-Repositorie hochladen und die Spec-Datei des dhcp-Paketes anpassen:
+Ab Zeile 138 (ca.)
+<code>
+# invis-server.org Stefan Schaefer
+Patch99:        0099-AD-LDAP.patch
+</code>
+Ab Zeile: 282 (ca.)
+<code>
+%if %{with_ldap}
+# Stefan Schaefer - invis-server.org
+%patch99 -p1
+%endif
+%endif
+## clean up after patching
+find . -type f -name \*.orig\* -exec rm -f {} \;
+find . -type f -name \*.rej\* -exec rm -f {} \;
+</code>
+Die Zeilenangaben sind natürlich nicht genau, das sich das Spec-File mit jeder neuen Version ändern kann. Wichtig ist nur, dass unser Patch als letzter angewendete wird.
+=== Paketbenennung und Konfliktverhalten ===
+Um nicht mit den regulären DHCP-Paketen in den SUSE Repositories in Konkurrenz zu geraten, haben wir unsere Pakete umbenannt. Sie tragen jetzt die Vorsilbe "invis":
+  * invisdhcp
+  * invisdhcp-server
+  * invisdhcp-client
+  * invisdhcp-relay
+  * invisdhcp-devel
+  * invisdhcp-doc
+Die Umbenennung erfolgt im Specfile. Weiterhin wurde in den Paketen die Direktive "Conflict" im Specfile verwendet. Dadurch können nur entweder die ungepatchten oder die gepatchten Pakete auf einem System installiert werden. Auch dies wird im Specfile eingetragen:
+**Namensdefinition**
+ab Zeile 35:
+<code>
+Name:           invisdhcp
+%define originname		dhcp
+....
+Source0:        dhcp-%{isc_version}.tar.gz
+Source1:        dhcp-%{isc_version}.tar.gz.asc
+Source2:        %{originname}.keyring
+</code>
+Die Variable %originname musste hinzugefügt werden, da der Originalname weiterhin beim Paketbau benötigt wird.
+**Conflict & Requires Direktiven**
+ab Zeile 146
+<code>
+Conflicts: dhcp
+%package server
+Summary:        ISC DHCP Server
+Group:          Productivity/Networking/Boot/Servers
+Requires:       invisdhcp = %{version}
+Requires:       net-tools
+Conflicts:	dhcp-server
+PreReq:         %insserv_prereq %fillup_prereq /bin/cat /bin/mkdir /bin/cp /usr/sbin/useradd
+%package client
+Summary:        ISC DHCP Client
+Group:          Productivity/Networking/Boot/Clients
+Requires:       /sbin/arping
+Requires:       /usr/bin/host
+Requires:       invisdhcp = %{version}
+Requires:       iproute2
+Requires:       net-tools
+Conflicts:	dhcp-client
+PreReq:         %insserv_prereq %fillup_prereq /bin/cat /bin/mkdir /bin/cp /bin/grep
+%package relay
+Summary:        ISC DHCP Relay Agent
+Group:          Productivity/Networking/Boot/Servers
+Requires:       invisdhcp = %{version}
+Requires:       net-tools
+Conflicts:	dhcp-relay
+PreReq:         %insserv_prereq %fillup_prereq /bin/cat /bin/mkdir /bin/cp
+%package devel
+Summary:        Header Files and Libraries for dhcpctl API
+Group:          Development/Libraries/C and C++
+Requires:       invisdhcp = %{version}
+Conflicts:	dhcp-devel
+Conflicts:      bind-devel
+%if %{with_doc_package}
+%package doc
+Summary:        Documentation
+Conflicts:	dhcp-doc
+Group:          Productivity/Networking/Boot/Servers
+%endif
+</code>
+Wie gezeigt sind Anpassungen in allen Einzelpaketen erforderlich. Mittels Conflicts und Requires werden die erforderlichen Paketabhängigkeiten gelöst.
+===== Aufbau einer Public Key Infrastruktur mit easy-rsa =====
+Unter anderem zur Nutzung im invis-Server wurde ein easy-rsa 3.x RPM im Repository "spins:invis:common" gebaut. Die nachfolgende Anleitung beschreibt, wie mit easy-rsa eine PKI manuell aufgebaut wird. Die spätere Verwaltung von Zertifikaten übernimmt auf invis-Servern das Script //**inviscerts**//.
+Ab Version 3.0 stellt easy-rsa nur noch ein einziges Script //**easyrsa**// für alle Aufgaben zur Verfügung. Sämtliche Konfigurationsdateien liegen in: <file>/etc/easy-rsa</file>
+Vor dem Aufbau einer PKI muss im genannten Verzeichnis die Datei "vars" an die eigenen Bedürfnisse angepasst werden. Es ist im Unterschied zu älteren easy-rsa Versionen nicht mehr notwendig die Variablen in dieser Datei manuell mittels //**source**// in die aktuelle Shell Umgebung zu laden. Dies erledigt //**easyrsa**//  selbsttätig.
+=== Vorbereitung ===
+Angepasst werden müssen zumindest folgende Zeilen:
+Name der PKI:\\
+(Zeile 65)
+<code>
+...
+set_var EASYRSA_PKI             "$EASYRSA/fsp-net.loc"
+...
+</code>
+PKI individualisieren:\\
+(Ab Zeile 84)
+<code>
+...
+set_var EASYRSA_REQ_COUNTRY     "DE"
+set_var EASYRSA_REQ_PROVINCE    "Hessen"
+set_var EASYRSA_REQ_CITY        "Schotten"
+set_var EASYRSA_REQ_ORG         "FSP Computer und Netzwerke"
+set_var EASYRSA_REQ_EMAIL       "stefan@invis-server.org"
+set_var EASYRSA_REQ_OU          "invis-Server.org"
+...
+</code>
+Die vorgegebene Länge der DH-Parameter ist auf 2048 Bit eingestellt, dies reicht nach gegenwärtigem Stand der Technik aus. Eine Erhöhung auf 4096 Bits verlängert den Bau der DH-Datei immens (Die Rede ist hier von Stunden).
+Voreingestellt sind Gültigkeitsdauern für CA und damit signierte Zertifikate von 10 Jahren. Kann man lassen, die Lebensdauer der Zertifikate im Vergleich zur CA zu verkürzen ist auch OK.
+Jetzt kann die PKI vorbereitet werden:
+<code>
+linux:~ # easyrsa init-pki
+</code>
+Damit wird unter "/etc/easy-rsa" eine Verzeichnisstruktur für die neue PKI angelegt und die Vorbereitungen sind abgeschlossen.
+=== PKI erzeugen ===
+Benötigt werden für OpenVPN folgende Komponenten:
+  - Eine CA zum signieren von Server und Client Zertifikaten
+  - Eine Diffie-Hellman Parameter Datei für sicheren Schlüsselaustausch
+  - Eine CRL Datei um Zertifikate zurückzuziehen
+**CA erstellen:**
+Auch hier genügt ein einziger Befehl:
+<code>
+linux:~ # easyrsa build-ca
+</code>
+Beim Bau der CA wird ein Passwort erfragt, dieses Passwort wird später beim signieren von Zertifikaten benötigt. Dieses Passwort darf nicht in falsche Hände gelangen.
+**Diffie-Hellman Parameter erstellen:**
+<code>
+linux:~ easyrsa gen-dh
+</code>
+**CRL erzeugen**
+<code>
+linux:~ easyrsa gen-crl
+</code>
+Hierfür wird wieder das CA-Passwort benötigt.
+===== DNS-Server bind und LDAP (invis Classic) =====
 Schon von Anfang an setzen wir ein LDAP-Verzeichnis als Daten-Backend für den DNS-Server //bind// ein. Der zugrunde liegende Patch, welchen wir schon seit einiger Zeit selbst in die Software-Pakete einbauen müssen, wird inzwischen kaum noch weiter entwickelt. Statt dessen gehört der sogenannte DLZ (dynamic loadable zone) Treiber seit etwa openSUSE 11.2 (oder so) fest zum Funktionsumfang der openSUSE-Pakete. Die Nutzung dieses Treibers würde uns eine Menge Arbeit ersparen, da wir keine eigenen //bind// Pakete mehr im openSUSE-Buildservice pflegen müssten.
@@ Zeile 620: / Zeile 869: @@
 ...to be continued.
-===== ISC DHCP mit ActiveDirectory =====
-Um den DHCP-Server des ISC mit einem Active Directory als Backend zu verwenden, muss dieser so gepatcht werden, dass er andere LDAP-Attribut- und Objektklassen-Namen akzeptiert. Dies ist notwendig, da Microsoft für seinen DHCP-Server teils identische Namen für Attribute und Objektklassen verwendet. Ohne das Patchen führt der Versuch einen ISC DHCP-Server Datenbestand aus einem OpenLDAP Verzeichnis in ein Active Directory zu migrieren zu "Objectclass Violations" die nicht zu beheben sind.
-==== LDAP Patch erzeugen ====
-Den Patch zu erstellen ist etwas umständlich, da im openSUSE-Paket bereits Patches auf die von uns zu patchenden Dateien angewendet werden. D.h. um unseren Patch zu erzeugen müssen zunächst die anderen Patches auf den Quellcode angewendet werden.
-Zu patchen sind folgende Dateien:
-  * server/ldap.c
-  * contrib/ldap/README.ldap
-  * contrib/ldap/dhcpd-conf-to-ldap
-  * contrib/ldap/dhcp.shema
-Im ersten Schritt müssen aus dem Repository "network:dhcp" (https://build.opensuse.org/package/show/network:dhcp/dhcp) des openSUSE Buildservice das Quellcode-Archiv (dhcp-4.x.y.tar.gz), sowie die beiden Patches "0007-dhcp-4.2.6-ldap-mt01.patch" und "0022-dhcp-4.2.x-contrib-conf-to-ldap-reorder.886094.patch" heruntergeladen werden.
-Das Quellcode-Archiv ist in ein Arbeitsverzeichnis zu extrahieren. Danach sind die beiden heruntergeladenen Patches darauf anzuwenden:
-<code>
-heinzb@knurps:~/baustelle/dhcp-4.2.6> patch -p1 server/ldap.c 0007-dhcp-4.2.6-ldap-mt01.patch
-heinzb@knurps:~/baustelle/dhcp-4.2.6> patch -p1 contrib/ldap/dhcpd-conf-to-ldap 0022-dhcp-4.2.x-contrib-conf-to-ldap-reorder.886094.patch
-</code>
-Treten dabei Fehler auf, sind diese in einer auf **.rej** endenden Datei im Verzeichnis der zu patchenden Datei zu finden. Sind die Fehler überschaubar, lassen sich die Änderungen auch manuell durchführen.
-Jetz sind per suchen und ersetzen der Attributnamen und Objektklassen mit **//sed//** neue Dateien mit den gewünschten Änderungen zu erzeugen:
-<code>
-heinzb@knurps:~/baustelle/dhcp-4.2.6> cat server/ldap.c | sed /dhcp[A-Z]/s/dhcp/iscDhcp/g > server/ad.ldap.c
-heinzb@knurps:~/baustelle/dhcp-4.2.6> cat contrib/ldap/README.ldap | sed /dhcp[A-Z]/s/dhcp/iscDhcp/g > contrib/ldap/ad.README.ldap
-heinzb@knurps:~/baustelle/dhcp-4.2.6> cat contrib/ldap/dhcpd-conf-to-ldap | sed /dhcp[A-Z]/s/dhcp/iscDhcp/g > contrib/ldap/ad.dhcpd-conf-to-ldap
-heinzb@knurps:~/baustelle/dhcp-4.2.6> cat contrib/ldap/dhcp.schema | sed /dhcp[A-Z]/s/dhcp/iscDhcp/g > contrib/ldap/ad.dhcp.schema
-</code>
-Jetzt werden mit //**diff**// einzelne Patches für jede der Dateien erzeugt:
-<code>
-heinzb@knurps:~/baustelle/dhcp-4.2.6> diff -u server/ldap.c server/ad.ldap.c > ../ldap.c.patch
-heinzb@knurps:~/baustelle/dhcp-4.2.6> diff -u contrib/ldap/README.ldap contrib/ldap/ad.README.ldap > ../README.ldap.patch
-heinzb@knurps:~/baustelle/dhcp-4.2.6> diff -u contrib/ldap/dhcpd-conf-to-ldap contrib/ldap/ad.dhcpd-conf-to-ldap > ../dhcpd-conf-to-ldap.patch
-heinzb@knurps:~/baustelle/dhcp-4.2.6> diff -u contrib/ldap/dhcp.schema contrib/ldap/ad.dhcp.schema > ../dhcp.schema.patch
-</code>
-Jetzt müssen noch die Kopfzeilen der Einzelpatches angepasst werden. Aus:
-<code>
---- server/ldap.c       2015-03-26 14:24:44.905456906 +0100
-+++ server/ad.ldap.c    2015-03-26 17:12:52.783318249 +0100
-</code>
-wird:
-<code>
---- a/server/ldap.c       2015-03-26 14:24:44.905456906 +0100
-+++ b/server/ldap.c    2015-03-26 17:12:52.783318249 +0100
-</code>
-Danach werden alle Einzelpatches zum Gesamtpatch zusammengesetzt:
-<code>
-heinzb@knurps:~/baustelle> cat ldap.c.patch > 0099-AD-LDAP.patch
-heinzb@knurps:~/baustelle> cat README.ldap.patch >> 0099-AD-LDAP.patch
-heinzb@knurps:~/baustelle> cat dhcpd-conf-to-ldap.patch >> 0099-AD-LDAP.patch
-heinzb@knurps:~/baustelle> cat dhcp.schema.patch >> 0099-AD-LDAP.patch
-</code>
-Danach den Patch in unser Testing-Repositorie hochladen und die Spec-Datei des dhcp-Paketes anpassen:
-Ab Zeile 138 (ca.)
-<code>
-# invis-server.org Stefan Schaefer
-Patch99:        0099-AD-LDAP.patch
-</code>
-Ab Zeile: 282 (ca.)
-<code>
-%if %{with_ldap}
-# Stefan Schaefer - invis-server.org
-%patch99 -p1
-%endif
-%endif
-## clean up after patching
-find . -type f -name \*.orig\* -exec rm -f {} \;
-find . -type f -name \*.rej\* -exec rm -f {} \;
-</code>
-Die Zeilenangaben sind natürlich nicht genau, das sich das Spec-File mit jeder neuen Version ändern kann. Wichtig ist nur, dass unser Patch als letzter angewendete wird.
-==== Paketbenennung und Konfliktverhalten ====
-Um nicht mit den regulären DHCP-Paketen in den SUSE Repositories in Konkurrenz zu geraten, haben wir unsere Pakete umbenannt. Sie tragen jetzt die Vorsilbe "invis":
-  * invisdhcp
-  * invisdhcp-server
-  * invisdhcp-client
-  * invisdhcp-relay
-  * invisdhcp-devel
-  * invisdhcp-doc
-Die Umbenennung erfolgt im Specfile. Weiterhin wurde in den Paketen die Direktive "Conflict" im Specfile verwendet. Dadurch können nur entweder die ungepatchten oder die gepatchten Pakete auf einem System installiert werden. Auch dies wird im Specfile eingetragen:
-**Namensdefinition**
-ab Zeile 35:
-<code>
-Name:           invisdhcp
-%define originname		dhcp
-....
-Source0:        dhcp-%{isc_version}.tar.gz
-Source1:        dhcp-%{isc_version}.tar.gz.asc
-Source2:        %{originname}.keyring
-</code>
-Die Variable %originname musste hinzugefügt werden, da der Originalname weiterhin beim Paketbau benötigt wird.
-**Conflict & Requires Direktiven**
-ab Zeile 146
-<code>
-Conflicts: dhcp
-%package server
-Summary:        ISC DHCP Server
-Group:          Productivity/Networking/Boot/Servers
-Requires:       invisdhcp = %{version}
-Requires:       net-tools
-Conflicts:	dhcp-server
-PreReq:         %insserv_prereq %fillup_prereq /bin/cat /bin/mkdir /bin/cp /usr/sbin/useradd
-%package client
-Summary:        ISC DHCP Client
-Group:          Productivity/Networking/Boot/Clients
-Requires:       /sbin/arping
-Requires:       /usr/bin/host
-Requires:       invisdhcp = %{version}
-Requires:       iproute2
-Requires:       net-tools
-Conflicts:	dhcp-client
-PreReq:         %insserv_prereq %fillup_prereq /bin/cat /bin/mkdir /bin/cp /bin/grep
-%package relay
-Summary:        ISC DHCP Relay Agent
-Group:          Productivity/Networking/Boot/Servers
-Requires:       invisdhcp = %{version}
-Requires:       net-tools
-Conflicts:	dhcp-relay
-PreReq:         %insserv_prereq %fillup_prereq /bin/cat /bin/mkdir /bin/cp
-%package devel
-Summary:        Header Files and Libraries for dhcpctl API
-Group:          Development/Libraries/C and C++
-Requires:       invisdhcp = %{version}
-Conflicts:	dhcp-devel
-Conflicts:      bind-devel
-%if %{with_doc_package}
-%package doc
-Summary:        Documentation
-Conflicts:	dhcp-doc
-Group:          Productivity/Networking/Boot/Servers
-%endif
-</code>
-Wie gezeigt sind Anpassungen in allen Einzelpaketen erforderlich. Mittels Conflicts und Requires werden die erforderlichen Paketabhängigkeiten gelöst.