Sun Desktop Manager 1.0 Installationshandbuch

Kapitel 3 Client-Komponenten

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:

  1. Laden Sie das ZIP-Archiv von Desktop Manager herunter und extrahieren Sie dessen Inhalt in ein temporäres Verzeichnis.


    # unzip SunDesktopMgr-1.0.zip
  2. 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.

  3. 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

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.


Hinweis –

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.


Hinweis –

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.


Startinformationen

Abbildung 3–1 Configuration Agent, Konfigurationsdatensammlung

Konfigurationsdatensammlung und Status


Hinweis –

Sofern zutreffend, sind die Schlüssel der entsprechenden Eigenschaftendatei in Klammern angegeben.


Abbildung 3–2 Configuration Agent, LDAP-Hierarchie und dateibasierte Speicherung

LDAP-Hierarchie und dateibasierte Speicherung


Hinweis –

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.


Abbildung 3–3 Configuration Agent, Authentifizierungsmechanismus

Authentifizierung

Port-Einstellungen

Configuration Agent verwendet zwei Ports:

Abbildung 3–4 Configuration Agent, Port-Einstellungen

Configuration Agent, Port-Einstellungen

Intervall zur Erkennung von Änderungen

Configuration Agent prüft die Konfigurationsdaten regelmäßig auf Änderungen. Hierbei gelten die folgenden Intervalle:

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.

Betriebseinstellungen

Abbildung 3–5 Configuration Agent, Datenverzeichnis

Configuration Agent, Datenverzeichnis

Die folgenden Einstellungen können konfiguriert werden:

Abbildung 3–6 Configuration Agent, Anforderungsbehandlung und Protokollierung

Configuration Agent, Anforderungsbehandlung und Protokollierung


Hinweis –

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.


Anwenden der Agent-Einstellungen

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.

Abbildung 3–7 Configuration Agent, Zusammenfassung

Zusammenfassungsseite

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.


Hinweis –

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.


Zusätzliche Agent-Einstellungen


Hinweis –

Die folgenden Einstellungen stehen im Konfigurationsassistenten nicht zur Verfügung.


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:

ProcedureBereitstellen lokaler Richtlinien

Schritte
  1. Erstellen Sie mithilfe von Desktop Manager ein Profil mit den erforderlichen Richtlinieneinstellungen.

  2. Exportieren Sie das Profil mithilfe von Desktop Manager in eine ZIP-Datei.

  3. 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.

  4. Kopieren Sie die zuvor exportierte ZIP-Datei in das Verzeichnis ${DataDir}/Policies/profiles/PROFILE_REPOSITORY_default .

  5. Vergewissern Sie sich, dass Configuration Agent so konfiguriert ist, dass verfügbare lokale Richtlinien angewendet werden (weitere Informationen im Abschnitt Zusätzliche Agent-Einstellungen).


    Hinweis –

    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.


Automatischer Neustart von Configuration Agent

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.

Zugriff auf Daten/Benutzerauthentifizierung

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

Adapter

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:

Es wird auch ein Desktop-Definitionsadapter bereitgestellt, welcher dem Benutzer-Desktop Desktop-Launcher, Menüelemente und Startprogramme hinzufügt.

GConf-Adapter

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:

Konfiguration des GConf-Adapters

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.

Java-Einstellungen-Adapter

Der Java-Einstellungen-Adapter ist Teil des Pakets SUNWapcj für Solaris.

Konfiguration des Java-Einstellungen-Adapters

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:

Folgende optionalen zusätzlichen Umgebungsvariablen können eingestellt werden:

Mozilla-Adapter

Der Mozilla-Adapter ist Teil des Pakets SUNWmozapoc-adapter auf Solaris.

Konfiguration des Mozilla-Adapters

Der Mozilla-Adapter wird während der Installation dieses Produkts eingerichtet und bedarf keiner zusätzlichen Konfiguration.

StarOffice-Adapter

Der StarOffice-Adapter ist in Standardinstallationen von StarOffice enthalten und ermöglicht den Zugriff auf Profilkonfigurationsdaten, ohne dass Sie spezielle Änderungen vornehmen müssen.

Konfiguration des StarOffice-Adapters

Der StarOffice-Adapter wird während der Installation dieses Produkts eingerichtet und bedarf keiner zusätzlichen Konfiguration.

Desktop-Definitionsadapter

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.

Konfiguration des Desktop-Definitionsadapters

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.

Entfernen von Adaptern

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.

Problemlösung für Adapter

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.

Configuration Agent – Problembehebung

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.

Fragen und Antworten

Was ist Configuration Agent und wie funktioniert diese Anwendung?

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:

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:

  1. Ein Benutzer startet eine der relevanten Desktop-Client-Anwendungen ( gconfd, Mozilla oder StarOffice ).

  2. Die Client-Anwendung stellt eine Verbindung mit Configuration Agent her.

  3. Die Client-Anwendung fordert von Configuration Agent die erforderlichen Richtliniendaten an.

  4. Configuration Agent durchsucht seinen Cache nach den angeforderten Richtliniendaten.

  5. 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.

  6. Die Richtliniendaten werden an die entsprechende Client-Anwendung gesendet.

  7. Configuration Agent überwacht die Richtliniensammlung auf Änderungen an den Richtliniendaten.

  8. 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.

Wo erhalte ich Configuration Agent und wie installiere ich die Anwendung?

Configuration Agent ist standardmäßig in Solaris 10 enthalten und wird mit diesem installiert.

Ich habe die Installation von Solaris 10 abgeschlossen. Wie muss ich nun vorgehen?

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.

Ich möchte Configuration Agent konfigurieren. Wie muss ich vorgehen?

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.

Ich möchte Configuration Agent aktivieren. Wie muss ich vorgehen?

Configuration Agent kann auf drei Arten aktiviert werden:

  1. Setzen Sie den Status von Configuration Agent mithilfe von Configuration Agent Wizard ( /usr/bin/apoc-config ) auf "Aktiv".

  2. 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
  3. Führen Sie als Superuser den folgenden Befehl aus, um smf(5) zu verwenden:


    /usr/sbin/svcadm enable svc:/network/apocd/udp

Ich habe Configuration Agent konfiguriert und installiert. Wie kann ich feststellen, ob die Anwendung korrekt arbeitet?

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.

Welche Bedeutung hat das Aktivieren von Configuration Agent?

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:

Wie kann ich feststellen, ob Configuration Agent aktiviert ist?

Es gibt mehrere Möglichkeiten festzustellen, ob Configuration Agent aktiviert ist:

Wie kann ich feststellen, ob Configuration Agent gerade ausgeführt wird?

Sie haben mehrere Möglichkeiten festzustellen, ob Configuration Agent läuft:

Wo sind die Protokolldateien?

Sie können zur Problemsuche für Configuration Agent die folgenden Protokolldateien zurate ziehen:

Wie kann ich detailliertere Protokolle erhalten?

Siehe Wo sind die Protokolldateien?

Was ist der Wartungsmodus?

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.

Wie kann ich den Wartungsmodus verlassen und/oder den smf(5)-Status aufheben?

Melden Sie sich als Superuser an und führen Sie den Befehl /usr/sbin/svcadm clear svc:/network/apocd/udp aus.

Was geschieht, wenn Configuration Agent unerwartet beendet wird?

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.

Muss ich Desktop-Client-Anwendungen neu starten, wenn ich Configuration Agent aktiviere bzw. starte?

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:

Meine Desktop-Client-Anwendungen scheinen nicht die konfigurierten Richtlinien zu verwenden. Was kann ich tun?

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:

Probleme beim Starten von Configuration Agent

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.

Ungültiges oder nicht verfügbares Agent-Datenverzeichnis

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 ]

Verwenden eines bereits belegten Anforderungs-Ports

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)

Verwenden eines bereits belegten Administrations-Ports

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 

Probleme beim Abrufen einer Richtlinie von Configuration Agent

Fehlende oder ungültige Angabe von Konfigurationsdatensammlung

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

Fehler beim Herstellen der Verbindung mit der Richtliniensammlung

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

Verbindungen mit nicht konfigurierten Richtliniensammlungen

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)

Die Configuration Agent-Protokolle enthalten eine Meldung, die "Max. Client-Verbindungen" betreffen. Was bedeutet dies?

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.

Ich habe einige Richtlinien mithilfe von Desktop Manager geändert. Diese Änderungen werden auf den Client-Rechnern jedoch nicht angezeigt.

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.