Erweiterung der D‐Grid Basis für die kommerzielle Nutzung · Konzept zur Nutzerverwaltung Seite...
-
Upload
truongkhanh -
Category
Documents
-
view
213 -
download
0
Transcript of Erweiterung der D‐Grid Basis für die kommerzielle Nutzung · Konzept zur Nutzerverwaltung Seite...
ErweiterungderD‐GridBasisfürdiekommerzielleNutzung
KonzeptfürdieNutzerverwaltung
Koordination
Andreas Eberhart ([email protected])
Datum 23. Januar 2012
Version 1.0
Status Final
Referenz http://www.irf.tu‐dortmund.de/cms/de/IT/Projekte/D‐
Grid_IaaS/Nutzerverwaltung_Konzept.pdf
Konzept zur Nutzerverwaltung
Seite 2 von 20
Autoren:
Stefan Freitag (Technische Universität Dortmund)
Marcel Risch (fluid Operations GmbH)
Das diesem Bericht zugrunde liegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bil‐
dung und Forschung unter dem Förderkennzeichen 01IS10019B gefördert. Die Verantwortung für
den Inhalt dieser Veröffentlichung liegt bei den Autoren.
Konzept zur Nutzerverwaltung
Seite 3 von 20
InhaltsverzeichnisVorbemerkung ......................................................................................................................................... 4
Bezug der Nutzerinformationen .............................................................................................................. 4
Erhalt der Nutzerinformationen über das dgridmap‐Skript ................................................................ 4
Installationsschritte für den Einsatz von dgridmap ............................................................................. 5
Ausgabe des dgridmap‐Skript ............................................................................................................. 9
Erhalt der Nutzerinformationen über ein lokales Webfrontend ...................................................... 10
Lokale Registrierung .......................................................................................................................... 11
Nutzerverwaltung .................................................................................................................................. 11
Rollen im eCloudManager ................................................................................................................. 11
Einfügen von Konten für VO Mitglieder ............................................................................................ 13
Abfragen der Nutzerinformationen .................................................................................................. 13
Installation der D‐Grid Unterstützung ................................................................................................... 14
Einrichtung eines geplanten Tasks .................................................................................................... 14
Integration des User Provider ............................................................................................................... 15
Installation ......................................................................................................................................... 15
Abbildung der Attribute .................................................................................................................... 16
Erweiterungen des User Providers .................................................................................................... 17
Anhang .................................................................................................................................................. 18
Modifiziertes dgridmap‐Skript .......................................................................................................... 18
Konzept zur Nutzerverwaltung
Seite 4 von 20
VorbemerkungDieser Bericht stellt zwei wesentliche Punkte des in Arbeitspaket 1 erarbeiteten Konzepts im Detail dar und geht auf deren technische Umsetzung ein.
Im ersten Teil dieses Dokuments wird der Bezug der Nutzerinformationen von Mitgliedern der virtuellen Organisationen des D‐Grid über das dgridmap‐Skript beschrieben. Des Weiteren ist in diesem Teil die lokale Registrierung D‐Grid fremder Nutzer beschrieben.
Der zweite Teil geht auf die Nutzerverwaltung des eCloudManagers der fluidOperations AG ein. Die über das dgridmap bzw. durch die lokale Registrierung von Nutzern erhaltene Information muss in die Cloud Middleware integriert und z. B. der Authentifikations‐ und der Accounting‐Komponente verfügbar gemacht werden.
BezugderNutzerinformationen
ErhaltderNutzerinformationenüberdasdgridmap‐SkriptNachfolgend ist die Vorgehensweise für den Bezug der Nutzerinformationen mittels des dgridmap
Skripts beschrieben. Bevor die Nutzerinformationen durch die Compute Cloud Middleware bezogen
werden können, ist diese als im D‐Grid Grid Resource Registration Service (GRRS) zu registrieren. Die
notwendigen Schritte für die Registrierung sind
1. Öffnen der Webseite http://www.d‐grid.de/index.php?id=308 in einem Browser.
2. Sofern dies die erste Middleware bzw. Ressource der Site ist, die im GRRS angemeldet wird, ist dem Link https://dispatch.fz‐juelich.de:8814/D‐Grid‐Resource zu folgen, andernfalls dem Link https://dispatch.fz‐juelich.de:8814/D‐Grid‐ResourceChg.
In beiden Fällen muss das persönliches X.509 Zertifikat des anmeldenden Administrators im Browser
installiert ist. Da im letzteren Fall der Systemadministrator bereits eine Middleware im GRRS
angemeldet hat und daher den Ablauf bereits kennt, beschränkt sich dieses Dokument auf die
Beschreibung von Fall 1.
Der Aufruf des Links https://dispatch.fz‐juelich.de:8814/D‐Grid‐Resource leitet zu einer weiteren
Webseite um. Der Inhalt (u.a. Certification Authority, Zertifikatstyp, Common Name) des im
Webbrowser hinterlegten X.509 Zertifikats wurden bereits ausgelesen und muss manuelle durch
folgende Informationen ergänzt werden
Anrede
Titel
Institution
Vorwahl/ Durchwahl
E‐Mail
Sind alle Eingaben spezifiziert und der „Weiter“‐Knopf gedrückt, so öffnet sich ein weiterer Dialog.
Zunächst ist hier der Domain‐Name zu spezifizieren, der für die beiden einzurichtenden E‐Mail‐
Adressen dgrid-admin@<Domainname> und dgrid-support@<Domainname> (vgl. D‐Grid
Betriebskonzept) verwendet werden soll. Des Weiteren ist die Checkbox Compute Resource zu
markieren und ein neues Kürzel für die Site auszuwählen. Der Name unter dem die Compute
Konzept zur Nutzerverwaltung
Seite 5 von 20
Resource später geführt wird ist gemäß den angegebenen Konventionen zu wählen. Sind die
Eingaben abgeschlossen, gelangt man über den „Weiter“ Knopf zum nächsten Dialog.
Im Anschluss an die erfolgreiche Registrierung darf die Compute Cloud Middleware sich mit dem
dgridmap‐Server verbinden und von dort die notwendigen Informationen abholen. Hierzu kann das
von D‐Grid bereitgestellte dgridmap‐Skript herunterladen und genutzt werden. Das Herunterladen
ist z. B. über einen Besuch der Webseite http://www.d‐grid.de/index.php?id=308 oder über
folgenden Kommandozeilenaufruf möglich
wget --no-check-certificate https://dispatch.fz-juelich.de:8814/dgridmap
InstallationsschrittefürdenEinsatzvondgridmap
1. Beantragen eines Host‐Zertifikats und des Host‐Schlüssels bei z.B. der GridKa Certification Authority.
2. Installation des Host‐Zertifikats und des Host‐Schlüssels.
Anlegen des Verzeichnisses /etc/grid-security/
mkdir -p /etc/grid-security (Linux)
md C:\etc\grid-security (Windows)
Kopieren der Host‐Zertifikats und des Host‐Schlüssels in das Verzeichnis /etc/grid-
security
cp <PATH>/hostcert.pem /etc/grid-security/hostcert.pem (Linux)
cp <PATH>/hostkey.pem /etc/grid-security/hostkey.pem
copy hostcert.pem C:\etc\grid-security\hostcert.pem (Windows)
copy hostkey.pem C:\etc\grid-security\hostkey.pem
Setzen der Zugriffsrechte auf das Host‐Zertifikat und den Host‐Schlüssel
chmod 400 /etc/grid-security/hostkey.pem (Linux)
chmod 644 /etc/grid-security/hostcert.pem
3. Installation der aktuellen Version (hier: 1.37) Certification Authorities Zertifikate
wget http://dist.eugridpma.info/distribution/igtf/current/accredited/igtf-
preinstalled-bundle-classic-1.37.tar.gz -P /tmp/ (Linux)
mkdir -p /etc/grid-security/certificates/
tar xzf /tmp/igtf-preinstalled-bundle-classic-1.37.tar.gz -C /etc/grid-
security/certificates/
rm -f /tmp/igtf-preinstalled-bundle-classic-1.37.tar.gz
Download von http://dist.eugridpma.info/distribution/igtf/current/accredited/igtf-
preinstalled-bundle-classic-1.37.tar.gz per Webbrowser (Windows)
md C:\etc\grid-security\certificates
Entpacken des Archivs z. B. mittels 7-zip nach C:\etc\grid-security\certificates
4. Installation des dgridmap‐Skripts
wget --no-check-certificate https://dispatch.fz-juelich.de:8814/dgridmap -O
/usr/local/bin/dgridmap (Linux)
chmod a+x /usr/local/bin/dgridmap
Herunterladen des Skripts von https://dispatch.fz-juelich.de:8814/dgridmap per
Konzept zur Nutzerverwaltung
Seite 6 von 20
Webbrowser (Windows)
Speichern in /usr/local/bin/dgridmap
Das dgridmap‐Skript ist in Perl geschrieben. Unter Windows ist daher eine Perl‐Umgebung (z.
B. ActivePerl) zu installieren.
5. Testweises Abholen der Nutzerinformationen durch den Aufruf des dgridmap Skripts
perl dgridmap (Windows)
EinarbeitenderNutzerinformationenindieNutzerverwaltungderCloudMiddleware(vgl.AbschnittNutzerverwaltungIm D‐Grid Betriebskonzept ist unter dem Punkt “IT‐Sicherheit und Datenschutz” die eindeutige Zuordnung eines Grid Nutzers zu einem oder mehreren lokalen Nutzerkonten gefordert. Eine Abbildung auf mehrere Nutzerkonten ist nur erlaubt, wenn diese zu paarweise unterschiedlichen virtuellen Organisationen gehören.
Unter Vernachlässigung des Konzepts der virtuellen Organisationen ergibt sich somit eine eineindeutige Abbildung zwischen einem Kunden und einem lokalen Nutzerkonto. Die Grid Nutzerinformationen erhält der eCloudManager wie beschrieben über das dgridmap Skript und generiert hieraus diese eineindeutige Abbildung auf lokale Nutzerkonten.
Informationen zu diesen Nutzerkonten können entweder in einer lokalen Datenbank oder externen Authentifizierungsdiensten wie Active Directory oder LDAP abgelegt sein. Der eCloudManager besitzt für beide Fälle entsprechende Schnittstellen.
Für die erste prototypische Implementierung kommt eine lokale Datenbank in Form einer in‐memory Datenbank zum Einsatz. Das zu verwendende Datenbankschema muss u. U. die Strukturierung der D‐Grid Communities in virtuelle Organisationen berücksichtigen.
RollenimeCloudManagerMomentan ist im eCloudManager eine Unterscheidung in folgende Rollen möglich:
eCloudManager Admins
eCloudManager Admins verfügen über die vollständige Kontrolle über die Landschaft.
eCloudManager Operators eCloudManager Operators können die verwalteten Objekte betrachten, Ereignisse bestätigen und die Objekte in den Wartungszustand überführen. Der Zugriff auf die API ist nicht möglich und bleibt so den eCloudManager Admins vorbehalten.
eCloudManager Guests Guests dürfen die verwalteten Objekte betrachten, aber ansonsten keine Aktionen durchführen.
eCloudManager SelfServiceUsers SelfServiceUsers dürfen sich nur in der Self‐Service Umgebung des eCloudManagers einloggen und von dort Instanzen starten und stoppen.
Die in‐memory Datenbank wird über sogenannte Provider mit Informationen versorgt. Diese werden für spezielle Silos im Datencenter konfiguriert, d.h. ein Provider holt sich Informationen aus einem Silo (z. B. Storage oder Hypervisor) und speichert diese in der in‐
Konzept zur Nutzerverwaltung
Seite 7 von 20
memory Datenbank. Diese Provider sind normalerweise eng an die API ihres Silos gebunden. Allerdings gibt es auch einen generischen Provider, der mit Hilfe eines Groovy‐Skripts die relevanten Informationen einpflegen kann. Über diese Schnittstelle können die Benutzer des D‐Grids in die in‐memory Datenbank eingepflegt werden.
Nachfolgend ist beispielhaft ein Groovy‐Code gezeigt, der einzelne Zeilen aus der admin‐Datei ausliest und daraus eine Liste von User‐Objekten des eCloudManagers generiert. Diese Liste wird als Rückgabewert verwendet.
import java.util.ArrayList; import java.util.List; import java.io.File; import java.io.BufferedReader; import java.io.FileReader; import com.fluidops.coremgmt.common.model.NodeInfo; import com.fluidops.coremgmt.common.model.ProviderInfo; import com.fluidops.coremgmt.common.model.BasePojo; import com.fluidops.coremgmt.common.model.hosting.User; NodeInfo ni = (NodeInfo) args[0]; ProviderInfo pi = (ProviderInfo) args[1]; String filePath = null; for(String s : pi.options) { if(s != null && s.length() > 0) { if(s.startsWith("FilePath:")) { filePath = s.substring("FilePath:".length()); } } } if(filePath == null || filePath.length() == 0) throw new Exception("File path could not be found"); BufferedReader reader = new BufferedReader(new FileReader(new File(filePath))); List<BasePojo> resultList = new ArrayList<BasePojo>(); String line = reader.readLine(); int i = 0; while (line != null) { i++; String s = line.substring(line.indexOf("##") + 2); String[] array = s.split("#"); User user = new User(); user.name = array[0] + " " + array[1]; user.partner = array[2];
Konzept zur Nutzerverwaltung
Seite 8 von 20
user.location = array[3] + " " + array[4] + " " + array[5] + " " + array[6]; user.smsNumber = array[7]; user.email = array[9]; user.activeDirectoryUser = false; resultList.add(user); line = reader.readLine(); } return resultList;
EinfügenvonKontenfürVOMitgliederNachfolgend ist schematisch der Vorgang des Einfügens von Mitgliedern der virtuellen Organisationen des D‐Grid in die Nutzerverwaltung des eCloudManagers beschrieben.
1. Es liegt eine Menge von Zeilen in der durch das Skript dgridmap erhaltenen Admin‐Datei vor.
2. Aus jeder Zeile dieser Datei werden alle relevanten Informationen (Vorname, Nachname, E‐Mail Adresse etc.) extrahiert und als Vektor zurückgeliefert. Dieser Vektor wird um beispielsweise ausgelaufene Mitgliedschaften reduziert und in die in‐memory Datenbank des eCloudManagers eingepflegt. Der zuvor dargestellte Groovy‐Code deutet das Gesamtvorgehen an.
Relevant hierbei ist, dass sich später das Mitglied der virtuellen Organisation mit seinem vollständigen Namen (Vorname Leerzeichen Nachname) am eCloudManager Selfservice‐Portal anmelden kann. Dies bedeutet gleichzeitig auch, dass ein Nutzer, auch wenn dieser Mitglied in mehr als einer virtuellen Organisation ist, nur einmal in die in‐memory Datenbank des eCloudManagers aufgenommen wird.
AbfragenderNutzerinformationenUm die Funktion des im Projekt entwickelten UserProviders zu prüfen, werden für Mitglieder der virtuellen Organisationen die in der in‐memory Datenbank des eCloudManagers festgehaltenen Daten betrachtet. Das Abfragen der gespeicherten Daten für einen bestimmten Nutzer kann über die Kommandozeilen‐Schnittstelle des eCloudManagers erfolgen. Nach der Anmeldung am eCloudManager ist dies durch den Aufruf des getUser‐Kommandos möglich.
Kommando:
getUser -name "Franz Blaim" -password "blaim"
Ausgabe:
<com.fluidops.coremgmt.common.model.hosting.User> <isDisabled>false</isDisabled> <alert>false</alert> <name>Franz Blaim</name> <activeDirectoryUser>false</activeDirectoryUser> <password>[crypt:D9B4AC014A7882CF81B4CEF3BB8921522F62C865407C55DEB207A23B04EDD2A81B103ABD53C6C429]</password> <email>[email protected]</email> <smsNumber>++49(0)8960042839</smsNumber>
Konzept zur Nutzerverwaltung
Seite 9 von 20
<partner>Institut für Strahlantriebe, Universität der Bundeswehr München</partner> <location>Werner-Heisenberg-Weg 39 85577 Neubiberg Germany</location> <isAdmin>false</isAdmin> <admin>n/a</admin> <createdBy> <string>User Provider-1</string> <string>D-Grid IaaS UserProvider</string> </createdBy> <finalID>User/byName/Franz_Blaim</finalID> <tags/> <userEdits/> <lastUpdateTime>2011-10-27 10:33:25.766 CEST</lastUpdateTime> <lastUpdateDuration>0</lastUpdateDuration> </com.fluidops.coremgmt.common.model.hosting.User>
6. ) Aus den über das dgridmap‐Skript erhaltenen Nutzerinformationn werden Vor‐ und Nachnamen sowie die E‐Mail‐Adressen der Nutzer ermittelt und in die eCloudManager Nutzerverwaltung eingefügt.
Ausgabedesdgridmap‐Skript
2. Ein erfolgreicher Aufruf des dgridmap‐Skripts liefert eine oder mehrere Dateien mit Informationen zurück. Diese setzen sich aus vordefinierten Kürzeln sowie dem Namen der Site und der Ressource wie sie im GRRS registriert sind zusammen. Für die D‐Grid Ressource dgrzr der Site udo entstehen durch den Aufruf des dgridmap‐Skripts beispielsweise folgende Dateien
admin.udo.dgrzr (Administrative Informationen über die Nutzer)
gridmap.udo.dgrzr (grid‐mapfile zum Einsatz mit der Globus Toolkit Middleware)
ogsa.udo.dgrzr (Datei zum Einsatz mit der OGSA‐DAI Middleware)
uudb.udo.dgrzr (Datei zum Einsatz mit der UNICORE Middleware)
Die admin‐Datei enthält die wesentlichen Informationen über Nutzer, um diese gegenüber einer
Cloud Middleware bekannt zu machen. Nachfolgend ist der Aufbau einer Zeile der admin‐Datei
skizziert, wobei die Trennung der einzelnen Informationen innerhalb einer Zeile durch # erfolgt und
hier nicht dargestellt ist.
education # Name der Virtuellen Organisation
ed # Kürzel der Virtuellen Organisation
/education #
0075 # User ID innerhalb der Virtuellen Organisation
Approved #
2010-06-23 16:22:17 ##
Stefan # Vorname des Nutzers
Freitag # Nachname des Nutzers
Institut fuer Roboterforschung # Institut des Nutzers
Otto-Hahn-Strasse 8 # Anschrift des Instituts
44227 # Postleitzahl
Dortmund # Ort
Germany # Land
+49 231 755 7009 # Telefonnummer
Konzept zur Nutzerverwaltung
Seite 10 von 20
German # Nationalität
[email protected] # E-Mail
/C=DE/O=GermanGrid/OU=TU-Dortmund/CN=Stefan Freitag# Distinguished Name des
Nutzerzertifikats
/C=DE/O=GermanGrid/CN=GridKa-CA #
Approved #
/C=DE/O=GridGermany/OU=Forschungszentrum Juelich GmbH/CN=Thomas Fieseler#
/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Grid - G01
Das Werkzeug file gibt Aufschluss über die innerhalb der admin‐Datei verwendete Zeichenkodierung. Dies kann von Bedeutung sein, da die Darstellung von Umlauten/ Sonderzeichen abhängig von der Zeichencodierung variiert.
$ file admin.udo.grid.uni-dortmund.de admin.udo.grid.uni-dortmund.de: ISO-8859 text, with very long lines
ErhaltderNutzerinformationenübereinlokalesWebfrontendDie Nutzung der D‐Grid Ressourcen soll für externe Kunden wie etwa KMUs einfach und attraktiv
möglich sein. Eine zur Attraktivität beitragende Größe ist die Dynamik mit der Leistungen (z .B.
Rechen‐ oder Speicherleistung) in Anspruch genommen werden können. Im Bereich des Grid
Computing liegt die Zeit zwischen der initialen Entscheidung eines Anwenders für die Grid Nutzung
und dem tatsächlichen ersten Zugriff auf Grid Ressourcen im Bereich von mehreren Stunden bzw.
Tagen. Diese Zeitspanne inkludiert z. B. die notwendige Zeit zur Beantragung eines X.509
Nutzerzertifikats und die Beantragung der Mitgliedschaft in einer virtuellen Organisation. Die Idee
bzw. das Konzept der virtuellen Organisation weicht im Bereich des Cloud Computing auf, so dass
man eine solche Organisation zunächst als eine Menge voneinander unabhängiger Kunden auffassen
kann.
Um D‐Grid in eine konkurrenzfähige Lage im Vergleich mit anderen Compute Cloud Anbietern zu
bringen, dürfen von der Eingabe der Kundendaten an einer der D‐Grid IaaS Ressourcen bis hin zum
möglichen Start der ersten virtuellen Maschinen durch den Kunden nur wenige Minuten vergehen.
Die Erzielung dieser Dynamik ist durch verschiedenes Vorgehen erreichbar, wovon nachfolgend zwei
skizziert sind:
die Registrierung eines Kunden an einer D‐Grid IaaS Ressource Das im Betriebskonzept des D‐Grid beschriebene Verfahren zur Registrierung von Kunden sieht vor, dass diese sich an einer zentralen Stelle wie beispielsweise einem VOMRS Server registrieren. In periodischen Abständen synchronisieren die D‐Grid Ressourcen ihre Nutzerinformationen mit denen aus dem VOMRS Server. Der zeitliche Abstand zwischen zwei Synchronisationen liegt aber mitunter bei einem Tag, was zu lange ist. Registriert sich der Kunde direkt an der D‐Grid IaaS Ressource, welche er verwenden möchte, kann über einen Automatismus im Hintergrund die Nutzerverwaltung auf der Ressource unmittelbar aktualisiert werden. Nachteilhaft an dieser Lösung ist die Notwendigkeit der erneuten Registrierung des Kunden an anderen D‐Grid IaaS Resourcen.
die Anmeldung eines Kunden an einem Portal und die Nutzung von Robot‐Zertifikaten Der Einsatz von Robot‐Zertifikaten in Verbindung mit einem Portal bietet eine alternative Lösungsmöglichkeit, die insbesondere die Mehrfach‐Registrierung auf verschiedenen D‐Grid IaaS Ressourcen umgeht. Der Kunde muss sich lediglich einmal am Portal registrieren um auf alle D‐Grid IaaS Ressourcen zugreifen zu können. Unter Verwendung des Robot‐Zertifikats setzt sich das Portal mit den verschiedenen Ressourcen in Verbindung und führt im Auftrag des Kunden Aktionen aus.
Konzept zur Nutzerverwaltung
Seite 11 von 20
Dieser Lösung steht eine begrenzte Akzeptanz von Robot‐Zertifikaten seitens der Ressourcenanbieter im Wege. Teilweise verstößt der Einsatz eines solchen Zertifikattyps gegen die Acceptable Use Policy der Ressource. Des Weiteren benötigt das Portal Informationen über alle im D‐Grid verfügbaren IaaS Ressourcen.
Nachfolgend ist die Umsetzung der Registrierung von Kunden an einer einzelnen D‐Grid IaaS
Ressource beschrieben. Perspektivisch wäre später die angedeutete Portallösung wünschenswert.
LokaleRegistrierung
Vor der initialen Nutzung einer D‐Grid IaaS Ressource durch Kunden müssen sich diese lokal
registrieren. Bei der lokalen Registrierung ist ‐ analog zur Registrierung an einem VOMRS‐Server ‐
eine Mindestmenge an Informationen über den Kunden zu erfassen. Diese Menge beinhaltet:
Vorname des Nutzers
Nachname des Nutzers
Einrichtung (Name des Instituts)
Anschrift der Einrichtung
Postleitzahl
Ort
Land
Telefonnummer
Nationalität
E‐Mail
Der Name des Benutzers dient später am Self Service Portal des eCloudManagers als login name.
NutzerverwaltungIm D‐Grid Betriebskonzept ist unter dem Punkt “IT‐Sicherheit und Datenschutz” die eindeutige Zuordnung eines Grid Nutzers zu einem oder mehreren lokalen Nutzerkonten gefordert. Eine Abbildung auf mehrere Nutzerkonten ist nur erlaubt, wenn diese zu paarweise unterschiedlichen virtuellen Organisationen gehören.
Unter Vernachlässigung des Konzepts der virtuellen Organisationen ergibt sich somit eine eineindeutige Abbildung zwischen einem Kunden und einem lokalen Nutzerkonto. Die Grid Nutzerinformationen erhält der eCloudManager wie beschrieben über das dgridmap Skript und generiert hieraus diese eineindeutige Abbildung auf lokale Nutzerkonten.
Informationen zu diesen Nutzerkonten können entweder in einer lokalen Datenbank oder externen Authentifizierungsdiensten wie Active Directory oder LDAP abgelegt sein. Der eCloudManager besitzt für beide Fälle entsprechende Schnittstellen.
Für die erste prototypische Implementierung kommt eine lokale Datenbank in Form einer in‐memory Datenbank zum Einsatz. Das zu verwendende Datenbankschema muss u. U. die Strukturierung der D‐Grid Communities in virtuelle Organisationen berücksichtigen.
RollenimeCloudManagerMomentan ist im eCloudManager eine Unterscheidung in folgende Rollen möglich:
Konzept zur Nutzerverwaltung
Seite 12 von 20
eCloudManager Admins
eCloudManager Admins verfügen über die vollständige Kontrolle über die Landschaft.
eCloudManager Operators eCloudManager Operators können die verwalteten Objekte betrachten, Ereignisse bestätigen und die Objekte in den Wartungszustand überführen. Der Zugriff auf die API ist nicht möglich und bleibt so den eCloudManager Admins vorbehalten.
eCloudManager Guests Guests dürfen die verwalteten Objekte betrachten, aber ansonsten keine Aktionen durchführen.
eCloudManager SelfServiceUsers SelfServiceUsers dürfen sich nur in der Self‐Service Umgebung des eCloudManagers einloggen und von dort Instanzen starten und stoppen.
Die in‐memory Datenbank wird über sogenannte Provider mit Informationen versorgt. Diese werden für spezielle Silos im Datencenter konfiguriert, d.h. ein Provider holt sich Informationen aus einem Silo (z. B. Storage oder Hypervisor) und speichert diese in der in‐memory Datenbank. Diese Provider sind normalerweise eng an die API ihres Silos gebunden. Allerdings gibt es auch einen generischen Provider, der mit Hilfe eines Groovy‐Skripts die relevanten Informationen einpflegen kann. Über diese Schnittstelle können die Benutzer des D‐Grids in die in‐memory Datenbank eingepflegt werden.
Nachfolgend ist beispielhaft ein Groovy‐Code gezeigt, der einzelne Zeilen aus der admin‐Datei ausliest und daraus eine Liste von User‐Objekten des eCloudManagers generiert. Diese Liste wird als Rückgabewert verwendet.
import java.util.ArrayList; import java.util.List; import java.io.File; import java.io.BufferedReader; import java.io.FileReader; import com.fluidops.coremgmt.common.model.NodeInfo; import com.fluidops.coremgmt.common.model.ProviderInfo; import com.fluidops.coremgmt.common.model.BasePojo; import com.fluidops.coremgmt.common.model.hosting.User; NodeInfo ni = (NodeInfo) args[0]; ProviderInfo pi = (ProviderInfo) args[1]; String filePath = null; for(String s : pi.options) { if(s != null && s.length() > 0) { if(s.startsWith("FilePath:")) { filePath = s.substring("FilePath:".length()); } } }
Konzept zur Nutzerverwaltung
Seite 13 von 20
if(filePath == null || filePath.length() == 0) throw new Exception("File path could not be found"); BufferedReader reader = new BufferedReader(new FileReader(new File(filePath))); List<BasePojo> resultList = new ArrayList<BasePojo>(); String line = reader.readLine(); int i = 0; while (line != null) { i++; String s = line.substring(line.indexOf("##") + 2); String[] array = s.split("#"); User user = new User(); user.name = array[0] + " " + array[1]; user.partner = array[2]; user.location = array[3] + " " + array[4] + " " + array[5] + " " + array[6]; user.smsNumber = array[7]; user.email = array[9]; user.activeDirectoryUser = false; resultList.add(user); line = reader.readLine(); } return resultList;
EinfügenvonKontenfürVOMitgliederNachfolgend ist schematisch der Vorgang des Einfügens von Mitgliedern der virtuellen Organisationen des D‐Grid in die Nutzerverwaltung des eCloudManagers beschrieben.
3. Es liegt eine Menge von Zeilen in der durch das Skript dgridmap erhaltenen Admin‐Datei vor.
4. Aus jeder Zeile dieser Datei werden alle relevanten Informationen (Vorname, Nachname, E‐Mail Adresse etc.) extrahiert und als Vektor zurückgeliefert. Dieser Vektor wird um beispielsweise ausgelaufene Mitgliedschaften reduziert und in die in‐memory Datenbank des eCloudManagers eingepflegt. Der zuvor dargestellte Groovy‐Code deutet das Gesamtvorgehen an.
Relevant hierbei ist, dass sich später das Mitglied der virtuellen Organisation mit seinem vollständigen Namen (Vorname Leerzeichen Nachname) am eCloudManager Selfservice‐Portal anmelden kann. Dies bedeutet gleichzeitig auch, dass ein Nutzer, auch wenn dieser Mitglied in mehr als einer virtuellen Organisation ist, nur einmal in die in‐memory Datenbank des eCloudManagers aufgenommen wird.
AbfragenderNutzerinformationenUm die Funktion des im Projekt entwickelten UserProviders zu prüfen, werden für Mitglieder der virtuellen Organisationen die in der in‐memory Datenbank des eCloudManagers
Konzept zur Nutzerverwaltung
Seite 14 von 20
festgehaltenen Daten betrachtet. Das Abfragen der gespeicherten Daten für einen bestimmten Nutzer kann über die Kommandozeilen‐Schnittstelle des eCloudManagers erfolgen. Nach der Anmeldung am eCloudManager ist dies durch den Aufruf des getUser‐Kommandos möglich.
Kommando:
getUser -name "Franz Blaim" -password "blaim"
Ausgabe:
<com.fluidops.coremgmt.common.model.hosting.User> <isDisabled>false</isDisabled> <alert>false</alert> <name>Franz Blaim</name> <activeDirectoryUser>false</activeDirectoryUser> <password>[crypt:D9B4AC014A7882CF81B4CEF3BB8921522F62C865407C55DEB207A23B04EDD2A81B103ABD53C6C429]</password> <email>[email protected]</email> <smsNumber>++49(0)8960042839</smsNumber> <partner>Institut für Strahlantriebe, Universität der Bundeswehr München</partner> <location>Werner-Heisenberg-Weg 39 85577 Neubiberg Germany</location> <isAdmin>false</isAdmin> <admin>n/a</admin> <createdBy> <string>User Provider-1</string> <string>D-Grid IaaS UserProvider</string> </createdBy> <finalID>User/byName/Franz_Blaim</finalID> <tags/> <userEdits/> <lastUpdateTime>2011-10-27 10:33:25.766 CEST</lastUpdateTime> <lastUpdateDuration>0</lastUpdateDuration> </com.fluidops.coremgmt.common.model.hosting.User>
InstallationderD‐GridUnterstützungFür die Unterstützung der D‐Grid Nutzerverwaltung sind folgende Komponenten notwendig:
Java Runtime Environment (getestet mit Version 6.0 Update 23), wobei die Installation des JRE in das Standardverzeichnis erfolgen kann.
Perl und wget für die Ausführung des dgridmap‐Skripts
Modifiziertes dgridmap‐Skript (siehe Anhang)
Wie in Abschnitt Bezug der Nutzerinformationen beschrieben ist das dgridmap‐Skript auf dem eCloudManager‐Host zu installieren. Für eine kontinuierliche Abholung der Nutzer‐Informationen über das dgridmap‐Skript ist ein cron‐Job bzw. im Falle von Microsoft Windows ein sog. Geplanter Task anzulegen.
EinrichtungeinesgeplantenTasksDieser Abschnitt beschreibt die Einrichtung eines geplanten Tasks in Microsoft Windows 7. Zunächst ist die Aufgabenplanung zu öffnen. Diese befindet sich im Menü “Zubehör–>Systemprogramme”.
Konzept zur Nutzerverwaltung
Seite 15 von 20
Bevor man eine neue Aufgabe anlegt sollte man einen neuen Ordner Meine Aufgaben im linken Feld Aufgabenplanungsbibliothek anlegen.
Erstellen Sie in diesem Ordner eine einfache Aufgabe. In dem folgenden Dialog sind folgende Eingaben sinnvoll:
Name: Aufruf des dgridmap‐Skripts
Beschreibung: Aktualisierung der Nutzer‐Informationsbasis des eCloudManager User
Providers mittels des dgridmap‐Skripts.
Sicherheitsoptionen: Unabhängig von der Benutzeranmeldung ausführen
Im Tab Trigger sind folgende Einstellungen zweckmäßig:
Aufgabe starten: Nach einem Zeitplan
Einstellungen: Täglich, Wiederholung alle 1 Tage
Aktiviert: Haken setzen
Die Einstellungen für das Tab Aktion:
Programm/ Skript: Perl‐Executable
Argument: Vollständiger Pfad zur Windows‐Version von dgridmap
Starten in: Leer
IntegrationdesUserProviderDie erste Version des User Provider basierte auf einer Java‐Software, die die Ausgaben des Skripts dgridmap verarbeitete und in die in‐memory Datenbank des eCloudManagers integrierte. Aufgrund von Umstellungen innerhalb des eCloudManagers waren Änderungen am User Provider notwendig. Eine der wesentlichen Änderungen ist der Umstieg von Java auf die Programmiersprache Groovy.
Der User Provider selbst besteht aus einem einzigen Groovy‐Skript, welches u.a. folgende Funktionalität bereitstellt:
1. Einlesen der Informationen aus der durch das Skript dgridmap erzeugten admin‐Datei.
2. Entfernen aller Nutzer, deren Status in innerhalb der virtuellen Organisation nicht „approved“ ist. Dies kann beispielsweise im Falle einer ausgelaufenen VO‐Mitgliedschaft zutreffen.
3. Entfernen doppelter Nutzer anhand des Vergleichs von E‐Mail Adressen.
Installation1. Erstellen eines Unterverzeichnisses scripts im Verzeichnis fecm der eCloudManager
Installation
2. Kopieren des User Provider‐Skripts in das neu geschaffene Verzeichnis fecm/scripts
3. Hinzufügen des User Provider in den eCloudManager
addOrUpdateNode -node "User Provider" -providerClass com.fluidops.coremgmt.provider.GenericGroovyProvider -agentLocation ./scripts/UserProvider.groovy -pollInterval 86400000 -options ['FilePath:scripts/admin.udo.grid.uni-
Konzept zur Nutzerverwaltung
Seite 16 von 20
dortmund.de']
AbbildungderAttributeUser‐Attribut im
eCloudManager
Attribut aus dgridmap‐
Informationen/ Default‐
Werte
Bedeutung im eCloudManager
activeDirectoryUser false eCM SES can either manage users locally or
import them from LDAP or ActiveDirectory
admin n/a Name of the admin who created this SES user
alert user can opt to receive email alerts from eCM
atmosType to be set from the Atmos SES UI
attributes Map of additional attributes which can be
retrieved from LDAP and which belong to the
user's context
coach coe legacy: coach = boss
competence
CUSTOM
description The description.
email E‐Mail Adresse des Nutzers user email ‐ added by the user or a user
provider such as vCD SES Provider
firstLogonDone Flag that is set to true after first log on.
gender
GROUP
isAdmin false flag which can be set by the super‐admin.
isCaseSensitive if false the user will always be checked in
lowerCase
isDisabled Whether the user is enabled (=allowed to use
the SES user page) or not
Konzept zur Nutzerverwaltung
Seite 17 von 20
lastLogin last time the user logged in
location Straße, PLZ, Stadt und Land
für die Einrichtung
name Vorname und Nachname des
Nutzers
The username.
partner Name der Einrichtung
password user password used for authentication in the
self service portal.
phase
PRICE
projects The projects.
quota Deprecated.
QUOTA
smsNumber Telefonnummer user sms/text message number ‐ added by
the user or a user provider such as vCD SES
Provider
usages user consumed these resources
users
VISIBILITY
ErweiterungendesUserProviders In der Version 0.0.3 wurden Probleme in der Behandlung von Umlauten (aufgrund
unterschiedlicher Zeichenkodierungen ISO‐8859‐1 und UTF‐8) behoben.
In Version 0.0.4 wurde die Klasse VirtualOrganizationMember um eine Prüfung der Atrribute beim Setzen ergänzt.
Konzept zur Nutzerverwaltung
Seite 18 von 20
Anhang
Modifiziertesdgridmap‐SkriptDas ursprüngliche dgridmap-Skript wurde für die Verwendung mit Microsoft Windows wie folgt angepasst:
#!/usr/bin/env perl # use Getopt::Long; # Defaultwerte $opt_pre = "dg"; $opt_cert = "C:\\etc\\grid-security"; # Optionen einlesen $result = GetOptions ( "cert-path=s" => \$opt_cert, "pre=s" => \$opt_pre, "help" => \$opt_help ); if ((!$result) or (defined($opt_help))) { Usage(); exit(-1); } if ((length("$opt_pre") > 2)) { print "############################################################\n\n"; print "Fehler bei Option '-pre <zz>'; max. 2 Zeichen erlaubt !\n"; Usage(); exit(-1); } # Certificate-Spezifikationen $ca_dir = "$opt_cert"."\\certificates"; $cert_pub = "$opt_cert"."\\hostcert.pem"; $cert_priv = "$opt_cert"."\\hostkey.pem"; if (not -d $ca_dir) { print "############################################################\n\n"; print "Zertifikatsdirectory fuer certificates existiert nicht oder ist kein Directory ($ca_dir)!\n\n"; print "############################################################\n\n"; exit(-1); } if (not -f $cert_pub) { print "############################################################\n\n"; print "'Grid-Server-Zertifikat' existiert nicht oder ist keine Datei ($cert_pub)!\n\n";
Konzept zur Nutzerverwaltung
Seite 19 von 20
print "############################################################\n\n"; exit(-1); } if (not -f $cert_priv) { print "############################################################\n\n"; print "'privater Schluessel des Grid-Server-Zertifikats' existiert nicht oder ist keine Datei ($cert_priv)!\n\n"; print "############################################################\n\n"; exit(-1); } if (-z $cert_priv) { print "############################################################\n\n"; print "'privater Schluessel des Grid-Server-Zertifikats' ist leer ($cert_priv)!\n\n"; print "############################################################\n\n"; exit(-1); } $wget_cmd = "C:\\bin\\wget.exe --no-check-certificate -nv -t 1 --ca-directory=$ca_dir --certificate=$cert_pub --private -key=$cert_priv https://dispatch.fz-juelich.de:8814/get_admindata -O admin.txt"; @list = exec($wget_cmd); if ($? != 0) { print "############################################################\n\n"; print "wget command failed for admin; rc is '$?' \n\n"; print "############################################################\n\n"; exit(-1); } $err = grep (/ERROR/,@list); if ($err > 0) { print "############################################################\n\n"; foreach $line (@list) {print "$line\n";} print "############################################################\n\n"; exit(-1); } exit(0); sub Usage { print <<EndOfUsage;