Für den Zugriff auf die Konfigurationsdaten von Desktop Manager muss auf dem Desktop-Client Java Desktop System Configuration Agent installiert sein. Configuration Agent kommuniziert mit der entfernten Konfigurationsdatensammlung und den Adaptern und fügt Daten in spezifische Konfigurationssysteme ein. Derzeit werden die Konfigurationssysteme GConf, Java-Einstellungen, Mozilla-Einstellungen und StarOffice Registry unterstützt.
Eine Version von Configuration Agent wird mit dem Betriebssystem Solaris 10 bereitgestellt. Desktop Manager erfordert jedoch eine neuere Version dieses Tools. Diese neuere Version wird als Teil der Installation von Client-Komponenten für Desktop Manager und damit verbundenen Patches installiert.
So installieren Sie die Client-Komponenten für Desktop Manager:
Laden Sie das ZIP-Archiv von Desktop Manager herunter und extrahieren Sie dessen Inhalt in ein temporäres Verzeichnis.
# unzip SunDesktopMgr-1.0.zip |
Installieren Sie die empfohlenen Patches.
Diese Patches werden im Verzeichnis SunDesktopMgr-1.0/<Plattform>/client/Patches bereitgestellt. Befolgen Sie die für jeden Patch bereitgestellten Anweisungen.
Melden Sie sich als Superuser (Root) an und führen Sie das Setup-Skript wie folgt aus:
# cd SunDesktopMgr-1.0/<Plattform>/client # ./setup |
Configuration Agent ist Bestandteil verschiedener Packages, die in folgender Tabelle aufgeführt sind:
Name des Solaris-Packages |
Beschreibung |
---|---|
SUNWapbas |
Gemeinsam genutzte Konfigurationsbibliotheken |
SUNWapmsc |
Diverse Configuration Agent-Dateien |
SUNWapoc |
Configuration Agent |
SUNWapdc |
Configuration Agent-Assistent |
Mit der Installation dieser Packages werden die für diese API erforderlichen Dateien installiert. Sie können die Packages entweder manuell oder gemeinsam mit Java Desktop System installieren. Nach der Installation müssen Sie Configuration Agent auf Ihrem System konfigurieren und aktivieren.
Configuration Agent-Packages werden als Teil der Solaris-Installation mit Java Desktop System installiert. Jedoch ergänzt Desktop Manager diese Dateien während der Installation, um eine korrekte Funktionsweise sicherzustellen.
Für den Zugriff auf die entfernten Konfigurationsdaten benötigt Configuration Agent einige Bootstrap-Informationen wie den Rechnernamen und den Port des LDAP-Servers. Diese Informationen werden in einem Satz Eigenschaftendateien wie policymgr.properties, apocd.properties und os.properties geführt. Diese Dateien sind lokal im Verzeichnis /etc/apoc gespeichert. Sie können diese Eigenschaften manuell bearbeiten (siehe Anhang A, Konfigurationsparameter) oder Sie können den Konfigurationsassistenten für Configuration Agent verwenden.
Der Konfigurationsassistent bietet eine grafische Benutzeroberfläche, die Sie durch die für Configuration Agent erforderlichen Einstellungen leitet. Für jede Seite im Assistenten steht Ihnen ein Hilfefenster zur Verfügung. Sie können den Assistenten mit dem Skript /usr/bin/apoc-config als Superuser (root) starten.
Der Assistent kann auch ohne die grafische Benutzeroberfläche gestartet werden. Führen Sie beispielsweise /usr/bin/apoc-config -nodisplay aus, um den Assistenten im Konsolenmodus zu starten.
Sofern zutreffend, sind die Schlüssel der entsprechenden Eigenschaftendatei in Klammern angegeben.
Status: Status von Configuration Agent. Das Kontrollkästchen dient zum Aktivieren bzw. Deaktivieren von Configuration Agent. Auf die Konfigurationsdatensammlung kann nur zugegriffen werden, wenn Configuration Agent aktiviert ist. Die Aktivierung schließt automatisch die notwendige Registrierung bei der Dienstverwaltungsfunktion ( smf(5) ) von Solaris ein.
Host-Kennung (HostIdentifierType): kann "Host-Name" oder "IP-Adresse" sein. Bei der Suche nach Host-spezifischen Richtliniendaten identifiziert Configuration Agent den aktuellen Host entweder über den Host-Namen oder die IP-Adresse. Wählen Sie entsprechend der Art und Weise, wie Ihr Host im ausgewählten Kontexttyp identifiziert wird, den korrekten Wert.
Kontexttyp: Verwenden Sie diese Einstellung, um für Configuration Agent anzugeben, ob Ihre Organisationshierarchie und Konfigurationsdaten in LDAP oder in einer dateibasierten Speicherung oder einer Kombination aus beiden definiert sind.
Um Configuration Agent manuell zu aktivieren bzw. zu deaktivieren, melden Sie sich als root an und geben Sie den Befehl /usr/lib/apoc/apocd enable bzw. /usr/lib/apoc/apocd disable ein.
Der Bildschirm in Abbildung 3–2 variiert je nach im vorhergehenden Bildschirm gewähltem Kontexttyp. Server-Kennung, Server-Port und Suffix sind erforderlich, wenn LDAP oder ein hybrider Kontexttyp gewählt wird. Eine URL für die Konfigurationseinstellungen ist erforderlich, wenn ein dateibasierter oder hybrider Kontexttyp gewählt wird.
Server-Kennung: Rechnername des LDAP-Servers.
Server-Port: Port-Nummer des LDAP-Servers.
Suffix: Base-DN der LDAP-Datensammlung
URL für Konfigurationseinstellungen: URL, die den Speicherort der dateibasierten Datensammlung angibt.
Eine Liste von URLs kann dafür verwendet werden, Ersatzdatensammlungen anzugeben, falls die Verbindung mit der ersten fehlschlägt. Die Liste kann aus einer oder mehreren URLs bestehen, die durch Leerzeichen getrennt aufgeführt werden und die folgende Form haben: file://<Dateipfad> , http://<host>:<Port>/<Dateipfad> oder https://<Host>:<Port>/<Dateipfad>. Weitere Informationen finden Sie in Anhang A, Konfigurationsparameter.
Configuration Agent versucht zunächst, mithilfe einer SSL-Verbindung auf den LDAP-Server zuzugreifen. Gelingt dies nicht, versucht Configuration Agent, eine einfache SSL-Verbindung herzustellen.
Für eine erfolgreiche SSL-Verbindung muss im Schlüsselspeicher der Java-Laufzeitumgebung das korrekte Zertifikat vorliegen. Dieser Schlüsselspeicher befindet sich bei einer Standard-JRE im Verzeichnis <Installationsverzeichnis>/lib/security/cacerts und bei einem Standard-JDK im Verzeichnis <Installationsverzeichnis>/jre/lib/security/cacerts. Diesem Speicher müssen entweder der Zertifikataussteller oder das LDAP-Serverzertifikat mithilfe des Befehls keytool -import -file <Zertifikatdatei> -keystore <cacerts-Speicherort> hinzugefügt werden. Das Standardpasswort für diesen Schlüsselspeicher ist changeit.
Authentifizierungsart für Configuration Agent: Entweder "Anonym" oder "Einfach". Wird "Anonym" ausgewählt, werden die Felder "Qualifizierter Benutzername" und "Passwort" automatisch deaktiviert.
Qualifizierter Benutzername (AuthDn): vollständiger DN eines Benutzers mit Lese- und Suchberechtigung für die Datensammlung.
Passwort (Password): Passwort eines registrierten LDAP-Benutzers
Wenn für das Verzeichnis der anonyme Zugriff aktiviert ist, können die Einstellungen "Qualifizierter Benutzername" und "Passwort" leer bleiben.
Authentifizierungsart für Anwendungen (AuthType): "Anonym" oder "GSSAPI", je nach der Methode zur Benutzerauthentifizierung auf dem LDAP-Server
Weitere Informationen finden Sie im Abschnitt Zugriff auf Daten/Benutzerauthentifizierung.
Configuration Agent verwendet zwei Ports:
Agent-Port (DaemonPort): Port, den der Agent für die Kommunikation mit Client-Anwendungen nutzt (Standardeinstellung ist 38900).
Administrations-Port (DaemonAdminPort): Port, über den das Agent-Controller-Programm apocd mit dem Agent kommuniziert (Standardeinstellung ist 38901).
Configuration Agent prüft die Konfigurationsdaten regelmäßig auf Änderungen. Hierbei gelten die folgenden Intervalle:
Allgemeines Erkennungsintervall (ChangeDetectionInterval): Intervall in Minuten zwischen Zyklen zur Erkennung von Änderungen an Konfigurationsdaten der Desktop-Anwendung (des Clients).
Durch Angabe von -1 wird die Änderungserkennung deaktiviert.
Intervall für Agent-Einstellungen (DaemonChangeDetectionInterval): Intervall in Minuten zwischen Zyklen zur Erkennung von Änderungen an Agent-spezifischen Konfigurationseinstellungen.
Durch Angabe von -1 wird die Änderungserkennung deaktiviert.
Mit dem allgemeinen Erkennungsintervall lässt sich die Weitergabe von entfernten Konfigurationsdatenänderungen an Client-seitige Anwendungen einstellen. Der für diese Einstellung festgelegte Wert bestimmt, wie viele Minuten maximal verstreichen, bevor entfernt vorgenommene Änderungen auf die Client-Anwendungen übertragen werden.
Je niedriger der Wert, desto höher die Configuration Agent- und LDAP-Server-Aktivität. Bedenken Sie dies bitte, wenn Sie einen Wert für diese Einstellungen wählen. Geschickt wäre es zum Beispiel, den Wert für die anfängliche Bereitstellungsphase auf eine Minute einzustellen, damit sich die Auswirkung der entfernten Konfiguration auf die Client-Anwendungen testen lässt, und die Einstellung nach Abschluss dieser Tests auf den Ausgangswert zurückzusetzen.
Die folgenden Einstellungen können konfiguriert werden:
Datenverzeichnis (DataDir): Verzeichnis, in dem Laufzeitdaten abgelegt werden. Das Standardverzeichnis ist /var/opt/apoc.
Aufbewahrungsdauer für zwischengespeicherte Daten (TimeToLive): Aufbewahrungsdauer in Minuten für Nicht-Offline-Konfigurationsdaten in der lokalen Datenbank
Zyklus zur Cache-Bereinigung (GarbageCollectionInterval): Intervall in Minuten zwischen Zyklen zur Bereinigung (garbage collection) der lokalen Konfigurationsdatenbank
Max. Client-Threads (MaxClientThreads): Höchstanzahl für Client-Anforderungen, die gleichzeitig abgearbeitet werden können.
Max. Client-Verbindungen (MaxClientConnections): Höchstanzahl für Client-Verbindungen
Max. Anforderungsgröße (MaxRequestSize): maximale Größe für Client-Anforderungen
Zeitüberschreitung für Verbindungen (ConnectTimeout): zulässige Verzögerung der Reaktion des LDAP-Servers auf Verbindungsanforderungen. Das Standardintervall beträgt eine Sekunde.
Protokollgenauigkeit (LogLevel): Genauigkeit der Agent-Protokolldateien. Die Stufen der Protokollgenauigkeit stimmen mit den Java Logger-Levels überein. Diese lauten, nach abnehmender Wichtigkeit geordnet:
ERNST
WARNUNG
INFO
KONFIGURATION
DETAILS
MEHR DETAILS
MAX. DETAILS
Die meisten Betriebseinstellungen außer "Datenverzeichnis" und "Zeitüberschreitung für Verbindungen" lassen sich auch zentral mithilfe entsprechender auf dem LDAP-Server gespeicherter Richtlinien verwalten. Wenn Sie dieses Leistungsmerkmal verwenden möchten, passen Sie diese Einstellungen nicht über den Assistenten an, sondern geben Sie die Betriebseinstellungen zentral mit den Configuration Agent-Richtlinien in Desktop Manager an.
Betriebseinstellungen außer "Datenverzeichnis" und "Zeitüberschreitung für Verbindungen", die mithilfe von Desktop Manager auf dem LDAP-Server gespeichert wurden, werden beim nächsten Erkennungsintervall für Änderungen an der Agent-Konfiguration (siehe DaemonChangeDetectionInterval) automatisch wirksam.
Für alle anderen lokal geänderten Einstellungen muss Configuration Agent neu geladen oder gestartet werden. Bei Verwendung des Konfigurationsassistenten erfolgt das erneute Laden oder der Neustart automatisch.
Um Configuration Agent manuell neu zu starten, vergewissern Sie sich, dass keine der dazugehörigen Client-Anwendungen ausgeführt wird. Melden Sie sich als Root an, und geben Sie den Befehl /usr/lib/apoc/apocd restart ein.
Die folgenden Einstellungen stehen im Konfigurationsassistenten nicht zur Verfügung.
Anwendung lokaler Richtlinien (ApplyLocalPolicy): Diese Einstellung wird verwendet, um anzugeben, ob die auf dem lokalen Host verfügbaren Richtliniendaten Client-Anwendungen zur Verfügung gestellt werden sollten. Der Wert "true" bedeutet, dass die lokalen Richtliniendaten verfügbar gemacht werden sollten. Der Wert "false" bedeutet, dass die lokalen Richtliniendaten nicht verfügbar gemacht werden sollten. Weitere Informationen finden Sie im Abschnitt Verwendung lokaler Richtlinien.
Sie können Configuration Agent so konfigurieren, dass Konfigurationseinstellungen von lokal bereitgestellten Richtlinien zusätzlich oder alternativ zu den global verfügbaren Richtlinien angewendet werden. Gehen Sie zum Bereitstellen solcher lokaler Richtlinien wie folgt vor:
Erstellen Sie mithilfe von Desktop Manager ein Profil mit den erforderlichen Richtlinieneinstellungen.
Exportieren Sie das Profil mithilfe von Desktop Manager in eine ZIP-Datei.
Erstellen Sie auf dem Client-Host das Verzeichnis ${DataDir}/Policies/profiles/PROFILE_REPOSITORY_default , sofern es nicht bereits vorhanden ist.
${DataDir} entspricht dem Wert des Datenverzeichnisses von Configuration Agent, welcher standardmäßig /var/opt/apoc lautet.
Kopieren Sie die zuvor exportierte ZIP-Datei in das Verzeichnis ${DataDir}/Policies/profiles/PROFILE_REPOSITORY_default .
Vergewissern Sie sich, dass Configuration Agent so konfiguriert ist, dass verfügbare lokale Richtlinien angewendet werden (weitere Informationen im Abschnitt Zusätzliche Agent-Einstellungen).
Wenn Sie die ApplyLocalPolicy-Einstellung von Configuration Agent ändern, müssen Sie Configuration Agent erneut laden, indem Sie sich als root anmelden und den Befehl /usr/lib/apoc/apocd reload eingeben.
Jede auf diese Weise bereitgestellte lokale Richtlinie wird den Clients während des nächsten Zyklus zur Erkennung von Änderungen von Configuration Agent zur Verfügung gestellt.
Tritt ein Fehler auf, wird Configuration Agent automatisch neugestartet. Die Dienstverwaltungsfunktion ( smf(5) ) ist für diese Entscheidung zuständig. Entscheidet die Dienstverwaltungsfunktion, dass ein Neustart nicht angebracht ist (beispielsweise, wenn bereits zu viele Fehler aufgetreten sind), wird Configuration Agent in den Wartungsmodus versetzt.
Wenn Configuration Agent nicht neugestartet wird, sollten Sie Configuration Agent temporär deaktivieren, indem Sie sich als root anmelden und dann den Befehl /usr/lib/apoc/apocd disable ausführen. Beheben Sie die Probleme, die dazu führen, dass der Agent nicht korrekt ausgeführt werden kann, und aktivieren Sie ihn erneut mit dem Befehl /usr/lib/apoc/apocd enable.
Configuration Agent ruft in Abhängigkeit von der Anmelde-ID des jeweiligen Desktop-Benutzers Informationen vom LDAP-Server ab. Durch die User/UniqueIdAttribute-Einstellung der organisatorischen Zuordnungsdatei wird die Anmelde-ID einem Benutzerelement auf dem LDAP-Server zugeordnet. Außerdem ruft Configuration Agent Informationen über den Rechner ab, wie zum Beispiel dessen Namen oder IP-Adresse. Diese Informationen werden durch die Host/UniqueIdAttribute-Einstellung der organisatorischen Zuordnungsdatei eines Rechnerelements auf dem LDAP-Server zugeordnet. Weitere Informationen zu Organisationszuordnungen finden Sie im Anhang C, Organisatorische Zuordnung.
Es kann anonym oder mit der GSSAPI-Methode auf den LDAP-Server zugegriffen werden. Der anonyme Zugriff erfordert keinen Eingriff seitens des Desktops. Für die GSSAPI-Methode müssen auf dem Desktop Kerberos-Berechtigungsnachweise erworben werden. Damit der Kerberos-Berechtigungsnachweiserwerb in die Benutzeranmeldung integriert werden kann, muss das Modul pam_krb5 auf dem Java Desktop System-Rechner installiert und konfiguriert sein.
Mithilfe von gdm lässt sich Kerberos in die Benutzeranmeldung integrieren. Verwenden Sie hierzu beispielsweise die folgende Datei /etc/pam.d/gdm:
#%PAM-1.0 auth required pam_unix2.so nullok #set_secrpc auth optional pam_krb5.so use_first_pass missing_keytab_ok ccache=SAFE putenv_direct account required pam_unix2.so password required pam_unix2.so #strict=false session required pam_unix2.so # trace or none session required pam_devperm.so session optional pam_console.so |
Wenn Sie Kerberos auf diese Weise in die Benutzeranmeldung einbinden, sollten Sie die Kerberos-Unterstützung im Bildschirmschoner aktivieren. Beispielsweise durch Verwendung der folgenden Datei /etc/pam.d/xscreensaver :
auth required pamkrb5.so use_first_pass missing_keytab_ok ccache=SAFE putenv_direct |
Die Anwendungsadapter sind Erweiterungen des Konfigurationssystems, die durch Desktop Manager unterstützt werden. Mithilfe der Adapter können die verschiedenen Anwendungen (je nach Konfigurationssystem) die zentralen Konfigurationsdaten berücksichtigen. Folgende Konfigurationssysteme werden unterstützt:
GConf: Das Gnome-Konfigurationssystem wird vom Desktop und den meisten Gnome-Anwendungen, wie etwa Evolution, verwendet.
StarOfficeRegistry: Dieses Konfigurationssystem wird von StarOffice und OpenOffice.org verwendet.
Mozilla-Einstellungen: Dieses Konfigurationssystem wird von Mozilla verwendet.
Java-Einstellungen: Dies ist eine Konfigurations-API, die für Java-Anwendungen bereitgestellt wird.
Es wird auch ein Desktop-Definitionsadapter bereitgestellt, welcher dem Benutzer-Desktop Desktop-Launcher, Menüelemente und Startprogramme hinzufügt.
Der GConf-Adapter ist Teil des Pakets SUNWapoc-adapter-gconf für Solaris. Bei der Installation des Adapters aus dem entsprechenden packageAdapter wird der GConf-Datenquellenpfad in /etc/gconf/2/path aktualisiert, d. h. die Desktop Manager-Quellen werden hinzugefügt. Der Adapter stellt die folgenden beiden Datenquellen zur Verfügung:
"apoc:readonly:": ermöglicht den Zugriff auf ungeschützte Einstellungen über die Richtlinien. Fügen Sie diese Datenquelle nach den Benutzereinstellungen und vor den lokalen Standardwerten ein.
"apoc:readonly:mandatory@": ermöglicht den Zugriff auf geschützte Einstellungen über die Richtlinien. Fügen Sie diese Datenquelle nach den obligatorischen lokalen Einstellungen und vor den Benutzereinstellungen ein.
Der GConf-Adapter wird während seiner Installation konfiguriert, jedoch hängt sein Betrieb von der Gegenwart von zwei Datenquellen, die die obligatorischen zentralen Einstellungen und die Standardeinstellungen repräsentieren, in der GConf-Pfaddatei (/etc/GConf/2/path ) ab. Diese Pfaddatei enthält die korrekten Informationen, damit GConf die zentralen Einstellungen wie erwartet nach der Installation des Systems berücksichtigt. Zugleich sollten Administratoren sicherstellen, dass die Datenquellen mit dem Präfix "apoc" noch in der Datei vorhanden sind, für den Fall, dass sie diesen Pfad für zusätzliche benutzerdefinierte Datenquellen ändern müssen. Sie sollten auch sicherstellen, dass sich die Datenquellen zwischen den lokalen obligatorischen Einstellungen und den Benutzereinstellungen für die Datenquelle befinden, welche die obligatorischen zentralen Einstellungen repräsentiert, und zwischen den Benutzereinstellungen und den lokalen Standardeinstellungen für die Datenquelle, welche die standardmäßigen zentralen Einstellungen repräsentiert.
Der Java-Einstellungen-Adapter ist Teil des Pakets SUNWapcj für Solaris.
Der Java-Einstellungen-Adapter wird als Implementierung der Einstellungen-API bereitgestellt, die als Wrapper für eine andere vorhandene Implementierung (wie das mit der JRE gelieferte standardmäßige dateibasierte System) verwendet werden muss. Für die Aktivierung der zentralen Konfiguration in einer Java-Anwendung, die die Einstellungen-API verwendet, muss ein Startskript für diese Anwendung geschrieben werden. Dabei muss das Skript /usr/lib/apoc/apocjlaunch als Hilfsprogramm verwendet werden. Dieses Skript muss einige Umgebungsvariablen definieren und dann an seinem Ende das Skript apocjlaunch enthalten, welches die Java-Anwendung mit der notwendigen Umgebung startet. Folgende Umgebungsvariablen müssen eingestellt werden:
JAVA: Enthält den Pfad zur ausführbaren Datei der Java-Laufzeit
APPLICATION: Enthält den nachgestellten Teil des regulären Aufrufs der Java-Laufzeit für diese Anwendungen. Beispielsweise Klassendatei [Argumente] für den Start einer einzelnen Klasse oder -jar JAR-Datei [Argumente] für den Start eines JAR-Archivs.
Folgende optionalen zusätzlichen Umgebungsvariablen können eingestellt werden:
CLASSPATH: Eine durch Kommas getrennte Liste von JAR- oder Klassendateien, die Teil eines Anwendungsklassenpfads sein müssen
DEFINES: String, der die Anweisungen enthält, die Teil des Anwendungsstarts sein müssen
PREFFACTORY: Klassenname der Factory in der zugrundeliegenden Implementierung der Einstellungen-API, die die Anwendung verwenden muss
Der Mozilla-Adapter ist Teil des Pakets SUNWmozapoc-adapter auf Solaris.
Der Mozilla-Adapter wird während der Installation dieses Produkts eingerichtet und bedarf keiner zusätzlichen Konfiguration.
Der StarOffice-Adapter ist in Standardinstallationen von StarOffice enthalten und ermöglicht den Zugriff auf Profilkonfigurationsdaten, ohne dass Sie spezielle Änderungen vornehmen müssen.
Der StarOffice-Adapter wird während der Installation dieses Produkts eingerichtet und bedarf keiner zusätzlichen Konfiguration.
Der Desktop-Definitionsadapter besteht aus folgenden Paketen:
Package-Name |
Beschreibung |
---|---|
SUNWapleg |
Konfiguration von Zugriffsbinärdateien |
SUNWardsa |
Desktop-Definitionsadapter |
SUNWardsa-misc |
Systemintegration für Adapter |
Diese Pakete werden bei der Installation der Desktop Manager-Client-Komponenten installiert und bedürfen keiner weiteren Konfiguration.
Der Desktop-Definitionsadapter wird vom Installationsvorgang so konfiguriert, dass er immer dann verwendet werden kann, wenn sich ein Benutzer anmeldet. Er bedarf keiner weiteren Konfiguration.
Der Mozilla- und der StarOffice-Adapter werden entfernt, wenn die zugehörigen Produkte entfernt werden. Der GConf-, Java-Einstellungen- und Desktop-Definitionsadapter können mithilfe der entsprechenden System-Tools für die Paketverwaltung entfernt werden, indem die im Abschnitt über die Installation erwähnten Pakete entfernt werden.
Nach dem Entfernen des Java-Einstellungen-Adapters, sollten die für das Starten von Java-Anwendungen geschriebenen Startskripte, die die Einstellungen-API verwenden, nicht mehr verwendet werden. Ein darin vorgenommener Java-Aufruf schlägt fehl, da einige der benötigten Klassen nicht mehr verfügbar sind.
Die meisten der Probleme, die dazu führen können, dass die zentralen Konfigurationsdaten in den entsprechenden Anwendungen nicht zu sehen sind, werden mit hoher Wahrscheinlichkeit von Configuration Agent verursacht, da diese Anwendung von allen Adaptern zum Abrufen von Daten verwendet wird.
Wenn eine zentrale Konfigurationsänderung keine Auswirkung auf eine bestimmte Einstellung (oder eine Gruppe von Einstellungen) zu haben scheint, ist eine mögliche Erklärung hierfür, dass der Benutzer für diese Einstellung in der Anwendung explizit einen Wert festgelegt hat (normalerweise über die Dialogfelder für Optionen oder Einstellungen im jeweiligen Produkt). In diesem Fall hat die Benutzereinstellung Vorrang vor dem mithilfe von Desktop Manager eingestellten Wert, es sei denn die zentralen Einstellungen sind als geschützt definiert, was bedeutet, dass dieser Wert durch den Administrator erzwungen wird und der Benutzer diesen Wert nicht ändern darf.
Dieser Abschnitt geht auf einige Fragen ein, die Sie möglicherweise zur Funktionsweise von Configuration Agent haben, und gibt Tipps zur Behebung von Problemen bei der Arbeit mit Configuration Agent.
Configuration Agent ist eine Anwendung, die Richtlinien speichert und bereitstellt. Sie stellt sicher, dass Desktop-Client-Anwendungen zentral konfiguriert werden können, ohne dass die Leistung dieser Anwendungen auf den Hosts beträchtlich gemindert wird. Dies wird durch folgende Funktionen erreicht:
Zwischenspeichern aller heruntergeladenen Richtlinien in einem lokalen Cache für die Verwendung durch Clients
Gemeinsames Nutzen teurer Ressourcen, bei denen dies möglich und sinnvoll ist (beispielsweise Verbindungen mit einem LDAP-Server, auf dem sich die Richtlinie befindet)
Der typische Anwendungsfall, bei dem die Interaktion zwischen den Client-Anwendungen und Configuration Agent abläuft, ist sehr einfach und kann wie folgt beschrieben werden:
Ein Benutzer startet eine der relevanten Desktop-Client-Anwendungen ( gconfd, Mozilla oder StarOffice ).
Die Client-Anwendung stellt eine Verbindung mit Configuration Agent her.
Die Client-Anwendung fordert von Configuration Agent die erforderlichen Richtliniendaten an.
Configuration Agent durchsucht seinen Cache nach den angeforderten Richtliniendaten.
Werden die Richtliniendaten nicht im Cache gefunden, lädt Configuration Agent die erforderlichen Daten aus einer zuvor konfigurierten Datensammlung herunter und speichert sie im Cache.
Die Richtliniendaten werden an die entsprechende Client-Anwendung gesendet.
Configuration Agent überwacht die Richtliniensammlung auf Änderungen an den Richtliniendaten.
Wird eine Änderung erkannt, aktualisiert Configuration Agent seinen Cache-Speicher, sodass dieser auf dem neuesten Stand ist, und benachrichtigt die Client-Anwendung von der Änderung.
Configuration Agent ist standardmäßig in Solaris 10 enthalten und wird mit diesem installiert.
Configuration Agent ist standardmäßig deaktiviert und nicht konfiguriert. Um Configuration Agent zu verwenden, müssen Sie eine Mindestkonfiguration durchführen und die Anwendung aktivieren. Nach Durchführung dieser Schritte wird automatisch die entsprechende Desktop-Client-Anwendung gestartet, sodass sie beim nächsten Starten automatisch die von Ihnen bereitgestellte Richtlinie verwenden.
Die korrekte Konfiguration von Configuration Agent erfolgt mit dem entsprechenden Assistenten (Configuration Agent Wizard). Diesen können Sie (als Root-Benutzer) mit dem Befehl /usr/bin/apoc-config starten. Configuration Agent Wizard führt Sie durch die Schritte, die zur korrekten Konfiguration von Configuration Agent erforderlich sind. In den meisten Fällen ist die einzige Angabe, die zum Abschluss des Assistenten erforderlich ist, der Speicherort der Richtliniensammlung.
Sie können Configuration Agent auch durch manuelles Bearbeiten der entsprechenden Konfigurationsdateien konfigurieren. Dies wird jedoch nicht empfohlen, da auf diese Weise eher eine Fehlkonfiguration vorgenommen wird. Außerdem prüft Configuration Agent Wizard, ob die vorgenommene Änderung an der Konfiguration einen Neustart oder ein erneutes Laden von Configuration Agent erfordert.
Configuration Agent kann auf drei Arten aktiviert werden:
Setzen Sie den Status von Configuration Agent mithilfe von Configuration Agent Wizard ( /usr/bin/apoc-config ) auf "Aktiv".
Führen Sie als Root-Benutzer den folgenden Befehl aus, um das Configuration Agent-Steuerprogramm ( /usr/lib/apoc/apocd ) zu verwenden:
/usr/lib/apoc/apocd enable |
Führen Sie als Superuser den folgenden Befehl aus, um smf(5) zu verwenden:
/usr/sbin/svcadm enable svc:/network/apocd/udp |
Die einfachste Art, die korrekte Funktionsweise von Configuration Agent zu prüfen, ist das Erstellen einer Richtlinie mit Desktop Manager und das Zuweisen der Richtlinie zu einem Benutzer. Nun können Sie sich am Desktop-Rechner als dieser Benutzer anmelden und überprüfen, ob die von Ihnen vorgenommenen Einstellungen verwendet werden. Hierzu eignen sich Richtlinieneinstellungen, deren Änderungen in einer Desktop-Sitzung einfach erkannt werden können, beispielsweise der Hintergrund oder das Motiv.
Configuration Agent ist ein smf(5)-kompatibler Dienst und wird daher für smf(5) aktiviert. Nach der Aktivierung von Configuration Agent kann die Anwendung eingesetzt werden. Beim Aktivieren von Configuration Agent geschieht Folgendes:
Configuration Agent wird gestartet.
Alle Desktop-Client-Anwendungen, die nach der Aktivierung von Configuration Agent gestartet werden, können Richtliniendaten abrufen.
Configuration Agent wird beim Neustart des Systems automatisch erneut gestartet.
Es gibt mehrere Möglichkeiten festzustellen, ob Configuration Agent aktiviert ist:
Verwenden Sie das Steuerprogramm für Configuration Agent. Melden Sie sich als Superuser an und geben Sie den folgenden Befehl ein:
/usr/lib/apoc/apocd is-enabled |
Ist Configuration Agent aktiviert, gibt das Steuerprogramm die folgende Meldung aus:
Checking Configuration Agent enabled status ... Enabled |
Anderenfalls gibt es die folgende Meldung aus:
Checking Configuration Agent enabled status ... Not enabled |
Führen Sie mit smf(5) den folgenden Befehl aus:
/usr/bin/svcs svc:/network/apocd/udp:default |
Ist Configuration Agent aktiviert, gibt svcs die folgende Meldung aus:
STATE STIME FMRI online 8:36:04 svc:/network/apocd/udp:default |
Ist Configuration Agent deaktiviert, gibt svcs die folgende Meldung aus:
STATE STIME FMRI disabled 15:58:34 svc:/network/apocd/udp:default |
Befindet sich Configuration Agent im Wartungsmodus, gibt svcs die folgende Meldung aus:
STATE STIME FMRI maintenance 8:38:42 svc:/network/apocd/udp:default |
Sie haben mehrere Möglichkeiten festzustellen, ob Configuration Agent läuft:
Melden Sie sich als Superuser an und führen Sie das Steuerprogramm für Configuration Agent aus:
/usr/lib/apoc/apocd status |
Ist Configuration Agent aktiviert, gibt das Steuerprogramm die folgende Meldung aus:
Checking Configuration Agent status ... Running |
Anderenfalls gibt das Steuerprogramm die folgende Meldung aus:
Checking Configuration Agent status ... Not running |
Führen Sie folgenden Befehl aus:
/usr/bin/svcs svc:/network/apocd/udp:default |
Wird Configuration Agent gerade ausgeführt, gibt svcs die folgende Meldung aus:
STATE STIME FMRI online 8:36:04 svc:/network/apocd/udp:default |
Wird Configuration Agent nicht ausgeführt, gibt svcs die folgende Meldung aus:
STATE STIME FMRI disabled 15:58:34 svc:/network/apocd/udp:default |
Befindet sich Configuration Agent im Wartungsmodus, gibt svcs die folgende Meldung aus:
STATE STIME FMRI maintenance 8:38:42 svc:/network/apocd/udp:default |
Führen Sie folgenden Befehl aus:
ps -ef | grep apoc |
Wird Configuration Agent ausgeführt, sollte die Ausgabe des Befehls ps den folgenden Java-Prozess enthalten:
daemon 29295 29294 0 13:05:22? 0:03 java -Djava.library.path=/usr/lib/apoc -cp /usr/share/lib/apoc/apocd.jar:/usr/s daemon 29294 1 0 13:05:22? 0:00 sh -c java -Djava.library.path=/usr/lib/apoc -cp /usr/share/lib/apoc/apocd.jar: root 29345 28134 0 13:08:59 pts/1 0:00 grep apoc |
Sie können zur Problemsuche für Configuration Agent die folgenden Protokolldateien zurate ziehen:
smf(5)-Protokolldateien:
In der Datei /var/svc/log/network-apocd-udp:default.log werden alle Ereignisse aufgezeichnet, die sich auf das Starten und Anhalten von Configuration Agent-Instanzen beziehen. Diese Datei enthält außerdem die Meldungen, die das Configuration Agent-Steuerprogramm ( /usr/lib/apoc/apocd) in seine Standardausgabe schreibt, und die Ausgabemeldungen von JVM oder Configuration Agent.
Die Protokolldatei /var/svc/log/svc.startd.log zeichnet smf(5)-Ereignisse höherer Ebene auf. Schlagen mehrere kurz aufeinander folgende Startversuche Configuration Agent fehl, entscheidet smf(5) möglicherweise, dass Configuration Agent nicht gestartet werden kann. In diesem Fall versetzt smf(5) Configuration Agent in den Wartungsmodus und schreibt einen entsprechenden Eintrag in das Protokoll.
Diese beiden Protokolldateien sind in der Regel nützlich, wenn Sie Probleme beim Starten von Configuration Agent haben.
Configuration Agent-Protokolle:
Configuration Agent schreibt die Protokollmeldungen in Protokolldateien im Standardverzeichnis für Protokolle (/var/opt/apoc/Logs ). Das "Datenverzeichnis" für Configuration Agent ist /var/opt/apoc . Sie können den Speicherort für dieses Verzeichnis mithilfe von Configuration Agent Wizard (/usr/bin/apoc-config) ändern. Wie detailliert die Protokollmeldungen sind, können Sie durch Ändern der "Protokollgenauigkeit" mithilfe von Configuration Agent Wizard anpassen. Wenn Sie glauben, dass Sie Configuration Agent nicht korrekt konfiguriert haben, oder falls Sie andere Probleme mit der Anwendung haben, können Sie die Protokollgenauigkeit mit Configuration Agent Wizard auf "Max. Details" stellen, bevor Sie die Protokolldateien der Anwendung auswerten. So stellen Sie sicher, dass Sie die größtmögliche Menge an Protokollinformationen erhalten.
Systemprotokolle:
Sie können außerdem die Protokolldateien /var/adm/messages und /var/opt/SUNWut/log/messages (SunRay) prüfen, um eine Diagnose von Problemen mit Configuration Agent durchzuführen.
Siehe Wo sind die Protokolldateien?
smf(5) versetzt Configuration Agent in den Wartungsmodus, wenn es Probleme beim Starten oder erneuten Starten von Configuration Agent erkennt. Kann smf(5) Configuration Agent nicht starten, unternimmt es mehrere Versuche, bis der Start erfolgreich ist oder smf(5) entscheidet, dass Configuration Agent nicht gestartet werden kann. In letzterem Fall versetzt smf(5) Configuration Agent in den Wartungsmodus, um anzuzeigen, dass Sie die erkannten Probleme beheben müssen. Wurden die Probleme behoben, können Sie den smf(5)-Status von Configuration Agent aufheben, um zum Normalbetrieb zu wechseln.
Melden Sie sich als Superuser an und führen Sie den Befehl /usr/sbin/svcadm clear svc:/network/apocd/udp aus.
smf(5) erkennt, dass die Anwendung nicht mehr ausgeführt wird und versucht, sie erneut zu starten. Sollten mehrere aufeinander folgende Versuche fehlschlagen, versetzt smf(5) Configuration Agent in den Wartungsmodus. Laufende Desktop-Client-Anwendungen sind nicht betroffen, wenn Configuration Agent erfolgreich erneut gestartet wird. Diese Client-Anwendungen stellen automatisch erneut eine Verbindung zu Configuration Agent her, wenn diese Anwendung neu gestartet wird.
Welche Maßnahmen Sie ergreifen, hängt davon ab, ob Configuration Agent zum Zeitpunkt des Starts der entsprechenden Desktop-Client-Anwendung aktiviert war und ausgeführt wurde. Wurde Configuration Agent aktiviert und wird die Anwendung ausgeführt, stellte die Client-Anwendung eine Verbindung mit Configuration Agent her und versucht, die Verbindung bei einer Trennung wiederherzustellen. Das heißt, dass die Client-Anwendungen bei jedem Starten, Aktivieren oder Deaktivieren von Configuration Agent versuchen, die Verbindung mit Configuration Agent wiederherzustellen, sobald diese Anwendung wieder ausgeführt wird. War Configuration Agent beim Starten der Client-Anwendung nicht aktiviert bzw. wurde nicht ausgeführt, verwendet die Client-Anwendung Configuration Agent nicht und versucht auch nicht, beim Start von Configuration Agent eine Verbindung herzustellen. Dies führt zu folgendem Verhalten:
Desktop-Client-Anwendungen, die gestartet wurden, während Configuration Agent aktiviert war und ausgeführt wurde, müssen nicht erneut gestartet werden.
Desktop-Client-Anwendungen, die gestartet wurden, während Configuration Agent nicht aktiviert war bzw. nicht ausgeführt wurde, müssen erneut gestartet werden.
Das gängigste Problem im Zusammenhang mit Configuration Agent ist, dass die Auswirkungen von konfigurierten Richtlinien für Desktop-Client-Anwendungen nicht gesehen werden können. Die häufigsten Ursachen hierfür sind eine fehlerhafte Konfiguration von Configuration Agent, eine fehlerhafte Konfiguration der Richtliniensammlung und eine nicht erreichbare Richtliniensammlung. Die folgenden Schritte unterstützen Sie beim Auffinden und Beheben von Problemen:
Stellen Sie sicher, dass Configuration Agent konfiguriert ist.
Stellen Sie sicher, dass Configuration Agent aktiviert ist und ausgeführt wird. Wenn Sie Configuration Agent starten müssen, müssen Sie auch die aktuell geöffneten Desktop-Client-Anwendungen erneut starten.
Bestehen die Probleme weiterhin, erhöhen Sie vorübergehend die Detailstufe der Configuration Agent-Protokolle und starten Sie Configuration Agent nach Möglichkeit erneut, sodass Sie ein vollständiges und detailliertes Protokoll ab dem Startzeitpunkt von Configuration Agent haben.
Wird Configuration Agent nicht korrekt gestartet, lesen Sie den Abschnitt Probleme beim Starten von Configuration Agent.
Wird Configuration Agent korrekt gestartet, aber die Desktop-Client-Anwendungen verwenden eine verfügbare Richtlinie nicht, lesen Sie den Abschnitt "Probleme beim Abrufen einer Richtlinie von Configuration Agent".
Sollte Ihr Problem weiterhin bestehen, wenden Sie sich an den technischen Support.
Kann Configuration Agent nicht gestartet werden, obwohl Sie sicher sind, dass Sie Configuration Agent konfiguriert und aktiviert haben, müssen Sie die Protokolldateien prüfen. In den folgenden Abschnitten werden die häufigsten Fehler erläutert, die dieses Problem verursachen können.
Das Configuration Agent-Datenverzeichnis wird von Configuration Agent erstellt und zum Speichern von Protokolldateien, Richtlinien-Caches usw. verwendet. Der standardmäßige Pfad für dieses Verzeichnis ist /var/opt/apoc.
Configuration Agent gibt die folgende Meldung in den smf(5)-Protokollen aus, wenn als Pfad für das Datenverzeichnis ein nicht verfügbarer Speicherort ( /dev/null/cant/write/here) bestimmt wurde. Um dieses Problem zu beheben, können Sie mithilfe von Configuration Agent Wizard (/usr/bin/apoc-config) einen verfügbaren Speicherort als Datenverzeichnis festlegen.
[ Nov 17 14:35:38 Executing start method ("/usr/lib/apoc/apocd svcStart") ] Starting Configuration Agent ... Warning: Cannot create Log directory '/dev/null/cant/write/here/Logs' Warning:Failed to create log file handler Nov 17, 2005 2:35:39 PM com.sun.apoc.daemon.misc.APOCLogger config CONFIG: Daemon configuration: MaxRequestSize = 4096 DaemonAdminPort = 38901 ThreadTimeToLive = 5 DaemonChangeDetectionInterval = 10 IdleThreadDetectionInterval = 15 PROVIDER_URL = DataDir = /dev/null/cant/write/here ApplyLocalPolicy = true ChangeDetectionInterval = 60 MaxClientConnections = 50 GarbageCollectionInterval = 10080 InitialChangeDetectionDelay = 10 TimeToLive = 10080 ConnectionReadTimeout = 5000 DaemonPort = 38900 LogLevel = FINEST MaxClientThreads = 5 Nov 17, 2005 2:35:39 PM Daemon main FINER: THROW com.sun.apoc.daemon.misc.APOCException at com.sun.apoc.daemon.apocd.Daemon.initAuthDir(Unknown Source) at com.sun.apoc.daemon.apocd.Daemon.init(Unknown Source) at com.sun.apoc.daemon.apocd.Daemon.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.Daemon.main(Unknown Source) [ Nov 17 14:36:08 Method or service exit timed out. Killing contract 980 ] [ Nov 17 14:36:08 Method "start" failed due to signal KILL ] |
Configuration Agent kommuniziert über TCP/IP-Socketverbindungen mit Desktop-Client-Anwendungen. Diese Verbindungen werden standardmäßig über Port 38900 hergestellt.
Die folgende Fehlermeldung wird ausgegeben, wenn Configuration Agent für den Port 1234 konfiguriert wird und dieser bereits von einem anderen Dienst verwendet wird. Die Fehlermeldung wird in den Configuration Agent-Protokollen aufgezeichnet. Um dieses Problem zu beheben, können Sie die Einstellung "Agent-Port" mithilfe von Configuration Agent Wizard (/usr/bin/apoc-config) auf einen nicht verwendeten Port einstellen.
Nov 17, 2005 2:50:59 PM com.sun.apoc.daemon.misc.APOCLogger config CONFIG: Daemon configuration: MaxRequestSize = 4096 DaemonAdminPort = 38901 ThreadTimeToLive = 5 DaemonChangeDetectionInterval = 10 IdleThreadDetectionInterval = 15 PROVIDER_URL = DataDir = /var/opt/apoc ApplyLocalPolicy = true ChangeDetectionInterval = 60 MaxClientConnections = 50 GarbageCollectionInterval = 10080 InitialChangeDetectionDelay = 10 TimeToLive = 10080 ConnectionReadTimeout = 5000 DaemonPort = 1234 LogLevel = FINEST MaxClientThreads = 5 Nov 17, 2005 2:50:59 PM com.sun.apoc.daemon.misc.APOCLogger info INFO: Daemon starting Nov 17, 2005 2:50:59 PM com.sun.apoc.daemon.misc.APOCLogger fine FINE: Garbage collection scheduled ( interval = 10080 minutes ) Nov 17, 2005 2:50:59 PM Daemon main FINER: THROW com.sun.apoc.daemon.misc.APOCException: java.net.BindException: Address already in use at com.sun.apoc.daemon.transport.ChannelManager.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.Daemon.run(Unknown Source) at com.sun.apoc.daemon.apocd.Daemon.main(Unknown Source) Caused by: java.net.BindException: Address already in use at sun.nio.ch.Net.bind(Native Method) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52) |
Configuration Agent kommuniziert über TCP/IP-Socketverbindungen mit dem Configuration Agent-Steuerprogramm (/usr/lib/apoc/apocd). Diese Verbindungen werden standardmäßig über Port 38901 hergestellt.
Die folgende Fehlermeldung wird in den Configuration Agent-Protokollen aufgezeichnet, wenn Configuration Agent für den Port 1234 konfiguriert wird und dieser bereits von einem anderen Dienst verwendet wird. Um dieses Problem zu beheben, können Sie die Einstellung "Administrations-Port" mithilfe von Configuration Agent Wizard (/usr/bin/apoc-config ) auf einen nicht verwendeten Port einstellen.
ONFIG: Daemon configuration: MaxRequestSize = 4096 DaemonAdminPort = 1234 ThreadTimeToLive = 5 DaemonChangeDetectionInterval = 10 IdleThreadDetectionInterval = 15 PROVIDER_URL = DataDir = /var/opt/apoc ApplyLocalPolicy = true ChangeDetectionInterval = 60 MaxClientConnections = 50 GarbageCollectionInterval = 10080 InitialChangeDetectionDelay = 10 TimeToLive = 10080 ConnectionReadTimeout = 5000 DaemonPort = 38900 LogLevel = FINEST MaxClientThreads = 5 Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger info INFO: Daemon starting Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger fine FINE: Garbage collection scheduled ( interval = 10080 minutes ) Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger fine FINE: Client manager started Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger fine FINE: Channel manager started Nov 17, 2005 2:55:11 PM Daemon main FINER: THROW com.sun.apoc.daemon.misc.APOCException: java.net.BindException: Address already in use at com.sun.apoc.daemon.admin.AdminManager.initChannel(Unknown Source) at com.sun.apoc.daemon.admin.AdminManager.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.Daemon.run(Unknown Source) at com.sun.apoc.daemon.apocd.Daemon.main(Unknown Source) Caused by: java.net.BindException: Address already in use at sun.nio.ch.Net.bind(Native Method) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52) ... 4 more |
Configuration Agent muss eine Verbindung zu einer gültigen Konfigurationsdatensammlung herstellen, um die Richtlinieninformationen herunterzuladen und im Cache zu speichern. Ist die Angabe der Konfigurationsdatensammlung in der Konfiguration von Configuration Agent nicht korrekt (beispielsweise durch Verwendung eines ungültigen Formats oder Unterlassen der Angabe), werden beim Start der Desktop-Client-Anwendungen in den Configuration Agent-Protokollen Fehler wie die folgenden aufgezeichnet. Um dieses Problem zu beheben, können Sie mithilfe von Configuration Agent Wizard (/usr/bin/apoc-config ) die zu verwendende Konfigurationsdatensammlung angeben.
FINER: New client added Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finer FINER: CreateSession transaction started Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finer FINER: Creating new client session Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finest FINEST: Authenticating user geoffh Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finest FINEST: Authentication successful Nov 18, 2005 1:59:23 PM PolicyBackend openPolicyBackend FINER: THROW com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.spi.environment.InvalidParameterException: The parameter organisation PROVIDER_URL#protocol (null) is not valid, the value must be comprised in {ldaps,ldap,https,http,file}. at com.sun.apoc.daemon.apocd.PolicyBackend.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.HostPolicyBackend.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyBackend(Unknown Source) at com.sun.apoc.daemon.apocd.Cache$DataSource.openPolicyBackend(Unknown Source) at com.sun.apoc.daemon.apocd.Cache$DataSource.open(Unknown Source) at com.sun.apoc.daemon.apocd.Cache.createDataSources(Unknown Source) at com.sun.apoc.daemon.apocd.Cache.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.CacheFactory.createNewCache(Unknown Source) at com.sun.apoc.daemon.apocd.CacheFactory.openCache(Unknown Source) at com.sun.apoc.daemon.apocd.Session.<init>(Unknown Source) at com.sun.apoc.daemon.transaction.CreateSessionTransaction.executeTransaction (Unknown Source) at com.sun.apoc.daemon.transaction.Transaction.execute(Unknown Source) at com.sun.apoc.daemon.apocd.ClientEventHandler.handleEvent(Unknown Source) at com.sun.apoc.daemon.apocd.EventWorkerThread.run(Unknown Source) Caused by: com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.spi.environment.InvalidParameterException: The parameter organisation PROVIDER_URL#protocol (null) is not valid, the value must be comprised in {ldaps,ldap,https,http,file}. at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyMgr(Unknown Source) ... 14 more Caused by: com.sun.apoc.spi.environment.InvalidParameterException: The parameter organisation PROVIDER_URL#protocol (null) is not valid, the value must be comprised in {ldaps,ldap,https,http,file}. at com.sun.apoc.spi.PolicyMgrFactoryImpl.createPolicyMgr(Unknown Source) ... 15 more Nov 18, 2005 1:59:23 PM PolicyBackend openPolicyBackend |
Configuration Agent muss eine Verbindung zu einer gültigen Konfigurationsdatensammlung herstellen, um die Richtlinieninformationen herunterzuladen und im Cache zu speichern. Kann keine Verbindung hergestellt werden, werden beim Start von Desktop-Client-Anwendungen Fehler ähnlich der folgenden in den Configuration Agent-Protokollen aufgezeichnet. Im folgenden Fall existiert der Host "sobuild" nicht, es kann keine Verbindung zum Host hergestellt werden oder der Host kann nicht über Port 389 auf einen LDAP-Server zugreifen. Sie können dieses Problem beheben, indem Sie mithilfe von Agent Configuration Wizard (/usr/bin/apoc-config) überprüfen, ob die Richtliniensammlung korrekt angegeben ist, und - sollte dies der Fall sein - sicherstellen, dass der Zugriff auf die Richtliniensammlung möglich ist. Beispielsweise müssen Sie bei einer LDAP-Datensammlung sicherstellen, dass ein LDAP-Server ausgeführt wird, der Rechner, auf dem der LDAP-Server läuft, im Netzwerk verfügbar ist und dass der von Ihnen angegebene Port mit dem übereinstimmt, den der LDAP-Server verwendet.
Wenn Sie über eine SSL-Verbindung auf einen LDAP-Server zugreifen möchten, müssen Sie sicherstellen, dass im Schlüsselspeicher das Zertifikat für die Java-Laufzeitumgebung enthalten ist, auf die Configuration Agent zurückgreift. Lesen Sie den Abschnitt Configuration Agent, um detaillierte Informationen zu apoc-config zu erhalten.
FINER: New client added Nov 18, 2005 2:17:43 PM com.sun.apoc.daemon.misc.APOCLogger finer FINER: CreateSession transaction started Nov 18, 2005 2:17:43 PM com.sun.apoc.daemon.misc.APOCLogger finer FINER: Creating new client session Nov 18, 2005 2:17:43 PM com.sun.apoc.daemon.misc.APOCLogger finest FINEST: Authenticating user geoffh Nov 18, 2005 2:17:43 PM com.sun.apoc.daemon.misc.APOCLogger finest FINEST: Authentication successful Nov 18, 2005 2:17:43 PM PolicyBackend openPolicyBackend FINER: THROW com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.spi.OpenConnectionException: An error occured while connecting to ldap://sobuild:389. at com.sun.apoc.daemon.apocd.PolicyBackend.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.HostPolicyBackend.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyBackend(Unknown Source) at com.sun.apoc.daemon.apocd.Cache$DataSource.openPolicyBackend(Unknown Source) at com.sun.apoc.daemon.apocd.Cache$DataSource.open(Unknown Source) at com.sun.apoc.daemon.apocd.Cache.createDataSources(Unknown Source) at com.sun.apoc.daemon.apocd.Cache.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.CacheFactory.createNewCache(Unknown Source) at com.sun.apoc.daemon.apocd.CacheFactory.openCache(Unknown Source) at com.sun.apoc.daemon.apocd.Session.<init>(Unknown Source) at com.sun.apoc.daemon.transaction.CreateSessionTransaction.executeTransaction (Unknown Source) at com.sun.apoc.daemon.transaction.Transaction.execute(Unknown Source) at com.sun.apoc.daemon.apocd.ClientEventHandler.handleEvent(Unknown Source) at com.sun.apoc.daemon.apocd.EventWorkerThread.run(Unknown Source) Caused by: com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.spi.OpenConnectionException: An error occured while connecting to ldap://sobuild:389. at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyMgr(Unknown Source) ... 14 more Caused by: com.sun.apoc.spi.OpenConnectionException: An error occured while connecting to ldap://noSuchHost:389. at com.sun.apoc.spi.ldap.LdapClientContext.prepareConnection(Unknown Source) at com.sun.apoc.spi.ldap.LdapClientContext.connect(Unknown Source) at com.sun.apoc.spi.ldap.LdapConnectionHandler.openAuthorizedContext(Unknown Source) at com.sun.apoc.spi.ldap.LdapConnectionHandler.connect(Unknown Source) at com.sun.apoc.spi.ldap.entities.LdapOrganizationProvider.open(Unknown Source) at com.sun.apoc.spi.PolicyMgrFactoryImpl.createPolicyMgr(Unknown Source) ... 15 more Caused by: netscape.ldap.LDAPException: failed to connect to server sobuild:389 (91); Cannot connect to the LDAP server at netscape.ldap.LDAPConnSetupMgr.connectServer(LDAPConnSetupMgr.java:422) at netscape.ldap.LDAPConnSetupMgr.openSerial(LDAPConnSetupMgr.java:350) at netscape.ldap.LDAPConnSetupMgr.connect(LDAPConnSetupMgr.java:244) at netscape.ldap.LDAPConnSetupMgr.access$0(LDAPConnSetupMgr.java:241) at netscape.ldap.LDAPConnSetupMgr$1.run(LDAPConnSetupMgr.java:179) at java.lang.Thread.run(Thread.java:595) Nov 18, 2005 2:17:44 PM PolicyBackend openPolicyBackend |
Damit Configuration Agent die Richtliniendaten in einer Richtliniensammlung finden kann, muss die Richtliniensammlung ordnungsgemäß konfiguriert sein. Wenn Sie eine Richtliniensammlung angeben, die überhaupt nicht oder falsch konfiguriert ist, werden beim Start von Desktop-Client-Anwendungen Fehlermeldungen ähnlich der folgenden in den Configuration Agent-Protokollen aufgezeichnet. Informationen zur Behebung dieses Problems finden Sie im entsprechenden Abschnitt.
FINER: New client added Nov 18, 2005 2:36:55 PM com.sun.apoc.daemon.misc.APOCLogger finer FINER: CreateSession transaction started Nov 18, 2005 2:36:55 PM com.sun.apoc.daemon.misc.APOCLogger finer FINER: Creating new client session Nov 18, 2005 2:36:55 PM com.sun.apoc.daemon.misc.APOCLogger finest FINEST: Authenticating user geoffh Nov 18, 2005 2:36:55 PM com.sun.apoc.daemon.misc.APOCLogger finest FINEST: Authentication successful Nov 18, 2005 2:36:55 PM PolicyBackend openPolicyBackend FINER: THROW com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.spi.environment.RemoteEnvironmentException: Error on reading the configuration data on LDAP server ldap://sobuild:389. at com.sun.apoc.daemon.apocd.PolicyBackend.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.HostPolicyBackend.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyBackend(Unknown Source) at com.sun.apoc.daemon.apocd.Cache$DataSource.openPolicyBackend(Unknown Source) at com.sun.apoc.daemon.apocd.Cache$DataSource.open(Unknown Source) at com.sun.apoc.daemon.apocd.Cache.createDataSources(Unknown Source) at com.sun.apoc.daemon.apocd.Cache.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.CacheFactory.createNewCache(Unknown Source) at com.sun.apoc.daemon.apocd.CacheFactory.openCache(Unknown Source) at com.sun.apoc.daemon.apocd.Session.<init>(Unknown Source) at com.sun.apoc.daemon.transaction.CreateSessionTransaction.executeTransaction (Unknown Source) at com.sun.apoc.daemon.transaction.Transaction.execute(Unknown Source) at com.sun.apoc.daemon.apocd.ClientEventHandler.handleEvent(Unknown Source) at com.sun.apoc.daemon.apocd.EventWorkerThread.run(Unknown Source) |
Jede Desktop-Client-Anwendung (gconfd, Mozilla, StarOffice), die von Configuration Agent aktiviert ist, stellt eine Verbindung zu Configuration Agent her, wenn sie ausgeführt wird. Die maximale Anzahl dieser Verbindungen wird in der Konfiguration von Configuration Agent festgelegt. Standardmäßig ist diese Zahl auf 50 Verbindungen beschränkt. Auf einem Rechner mit mehreren Benutzern müssen Sie diesen Wert möglicherweise erhöhen, indem Sie mit Configuration Agent Wizard (/usr/bin/apoc-config) die Einstellung "Max. Client-Verbindungen" ändern. Erreicht Configuration Agent die maximale Anzahl von Verbindungen, werden in den Configuration Agent-Protokollen Fehlermeldungen ähnlich der folgenden aufgezeichnet:
Nov 18, 2005 3:20:55 PM com.sun.apoc.daemon.misc.APOCLogger warning WARNING: The maximum number of client connections ( 50 ) has been reached. No new client connections can be established at this time. |
Bei der Entwicklung von Configuration Agent wurde unter anderem davon ausgegangen, dass mit Desktop Manager erstellte Richtliniendaten relativ statisch sind, das heißt, dass sie sich nicht häufig ändern. Hieraus ergibt sich ein Ansatz, der dazu führt, dass Configuration Agent periodisch die Richtliniensammlung auf durchgeführte Änderungen prüft. Standardmäßig prüft Configuration Agent die Datensammlung stündlich für alle Desktop-Anwendungen. Wenn Sie mit Desktop Manager eine Änderung durchführen, müssen Sie daher bis zu eine Stunde warten, bevor laufende Desktop-Anwendungen Kenntnis von der Änderung erhalten. Bei Bedarf können Sie den Wert von "Allgemeines Erkennungsintervall" mithilfe von Agent Configuration Wizard (/usr/bin/apoc-config ) erhöhen, um die Datensammlung häufiger zu prüfen. Alternativ können Sie in Configuration Agent die Aktualisierung der Richtliniendaten für alle verbundenen Anwendungen erzwingen, indem Sie sich als Superuser anmelden und den Befehl /usr/lib/apoc/apocd change-detect ausführen.