test

Guide d'installation de Sun Desktop Manager 1.0

Chapitre 3 Composants client

Pour accéder aux données de configuration de Desktop Manager, un client de bureau a besoin du système Java Desktop System Configuration Agent. Configuration Agent communique avec le référentiel des données de configuration distantes ainsi qu'avec les adaptateurs et intègre les données dans des systèmes de configuration spécifiques. Les systèmes de configuration actuellement pris en charge sont GConf, Java Preferences, Mozilla Preferences et StarOffice Registry.

Une version de Configuration Agent est fourni avec le système d'exploitation Solaris 10. Cependant, Desktop Manager exige une version plus récente de cet outil. Cette dernière est installée lors de l'installation des composants client de Desktop Manager et de leurs patchs respectifs.

Pour installer les composants client de Desktop Manager :

  1. Téléchargez l'archive zip de Desktop Manager et extrayez le contenu dans un répertoire temporaire.


    # unzip SunDesktopMgr-1.0.zip

  2. Installez les patchs recommandés.

    Ces patchs se trouvent dans le répertoire SunDesktopMgr-1.0/<plate-forme>/client/Patches. Conformez-vous aux instructions d'installation fournies pour chaque patch.

  3. Connectez-vous en tant que superutilisateur (root) et exécutez le script d'installation via : 


    # cd SunDesktopMgr-1.0/<plate-forme>/client
# ./setup

Configuration Agent

Configuration Agent est un élément intégré aux différents packages répertoriés dans le tableau suivant :

Nom du package Solaris 

Description 

SUNWapbas 

Bibliothèques partagées de Configuration 

SUNWapmsc 

Fichiers divers de Configuration Agent 

SUNWapoc 

Configuration Agent 

SUNWapdc 

Assistant de Configuration Agent 

Lorsque vous installez ces packages, les fichiers requis par cette API sont installés. Vous pouvez installer les packages manuellement ou au cours de l'installation de Java Desktop System. Une fois l'installation terminée, vous devez configurer et activer Configuration Agent sur votre système.

Remarque –

Les packages Configuration Agent sont installés sous Solaris lors de l'installation de Java Desktop System ; cependant, Desktop Manager regroupe ces fichiers en patchs au cours de l'installation afin d'offrir le niveau de fonctionnalité qui convient.

Pour accéder aux données de configuration distantes, Configuration Agent a besoin de quelques informations d'initialisation, telles que le nom d'hôte et le port du serveur LDAP. Ces informations figurent dans un jeu de fichiers de propriétés tels que policymgr.properties, apocd.properties et os.properties. Ces fichiers sont stockés en local dans le répertoire /etc/apoc. Vous pouvez modifier manuellement ces fichiers de propriétés (voir Annexe A, Paramètres de configuration ) ou utiliser l'assistant de configuration pour Configuration Agent.

L'assistant de configuration intègre une interface graphique utilisateur qui vous guide au cours de la définition des paramètres requis de Configuration Agent. Un écran d'aide est disponible pour chaque page de l'assistant. Vous pouvez lancer l'assistant en tant que superutilisateur (root) par le biais du script /usr/bin/apoc-config.

Remarque –

Vous pouvez également démarrer l'assistant sans lancer l'interface graphique. Par exemple, exécutez /usr/bin/apoc-config -nodisplay pour démarrer l'assistant en mode console.

Informations d'initialisation

Figure 3–1 Configuration Agent, référentiel de configuration

Référentiel de configuration et état

Remarque –

Les clés du fichier de propriétés associées sont indiquées entre parenthèses, le cas échéant.

Figure 3–2 Configuration Agent, hiérarchie LDAP et stockage fichier

Hiérarchie LDAP et stockage fichier

Remarque –

L'écran tel qu'il est illustré à la Figure 3–2 peut varier selon le type de référentiel choisi à l'écran précédent. Les champs Identificateur du serveur, Port du serveur et Suffixe doivent être remplis si un référentiel de type LDAP ou hybride est choisi. Vous devez remplir le champ URL des paramètres de configuration si le type est fichier ou hybride.

Figure 3–3 Configuration Agent, mécanisme d'authentification

Authentification

Paramètres de port

Configuration Agent utilise deux ports :

Figure 3–4 Configuration Agent, paramètres de port

Configuration Agent, paramètres de port

Intervalle de détection des changements

Configuration Agent recherche régulièrement les changements apportés aux données de configuration en utilisant deux intervalles :

Vous pouvez utiliser l'intervalle de détection général pour affiner la propagation des modifications des données de configuration distantes sur les applications côté client. La valeur entrée pour ce paramètre correspond à la durée maximum (en minutes) qui s'écoule avant que les modifications apportées à distance ne se reflètent dans les applications clientes.

Si vous indiquez des valeurs peu élevées, l'activité de Configuration Agent et du serveur LDAP est augmentée. Vous devez donc ajuster avec précaution la valeur de ces paramètres. Par exemple, dans une phase de déploiement initial, vous pouvez définir une valeur égale à une minute de manière à pouvoir tester l'impact de la configuration distante sur les applications clientes. Une fois le test terminé, rétablissez la valeur initiale du paramètre.

Paramètres de fonctionnement

Figure 3–5 Configuration Agent, répertoire de données

Configuration Agent, répertoire de données

Vous pouvez configurer les paramètres suivants :

Figure 3–6 Configuration Agent, gestion des demandes et enregistrement

Configuration Agent, gestion des demandes et enregistrement

Remarque –

La plupart des paramètres de fonctionnement, à l'exception des paramètres Répertoire de données et Délai d'expiration de connexion, peuvent être centralisés à l'aide des stratégies correspondantes stockées sur le serveur LDAP. Si vous souhaitez utiliser cette fonction, n'adaptez pas les paramètres correspondants à l'aide de l'assistant. Utilisez plutôt les stratégies de Configuration Agent disponibles dans Desktop Manager pour spécifier les paramètres de fonctionnement de manière globale.

Application des paramètres de l'agent

À l'exception des paramètres “Répertoire de données” et “Délai d'expiration de connexion”, les paramètres de fonctionnement stockés sur le serveur LDAP par le biais de Desktop Manager prennent automatiquement effet lors du prochain cycle de détection des changements de la configuration de l'agent (voir DaemonChangeDetectionInterval).

Figure 3–7 Configuration Agent, résumé

Page de résumé

Tous les paramètres modifiés en local nécessitent le rechargement ou le redémarrage de Configuration Agent. Cette opération s'effectue automatiquement si vous utilisez l'assistant de configuration.

Remarque –

Pour redémarrer manuellement Configuration Agent, assurez-vous qu'aucune application cliente n'est en cours d'exécution, connectez-vous en tant que root, puis tapez la commande /usr/lib/apoc/apocd restart.

Paramètres supplémentaires de l'agent

Remarque –

Les paramètres ne sont pas disponibles dans l'assistant de configuration.

Utilisation d'une stratégie locale

Vous pouvez configurer Configuration Agent pour appliquer les paramètres de configuration de la stratégie déployée localement en plus ou à la place d'une stratégie globalement disponible. Procédez de la manière suivante pour déployer une telle stratégie locale :

ProcedureDéploiement d'une stratégie locale

Étapes

  1. L'utilisation de Desktop Manager permet de créer un profil avec les paramètres de stratégie requis.

  2. L'utilisation de Desktop Manager permet d'exporter le profile vers un fichier zip.

  3. Sur votre hôte client, créez le répertoire ${DataDir}/Policies/profiles/PROFILE_REPOSITORY_default , s'il n'existe pas déjà.

    ${DataDir} correspond à la valeur du répertoire de données Configuration Agent qui est par défaut /var/opt/apoc.

  4. Copiez le fichier zip précédemment exporté vers ${DataDir}/Policies/profiles/PROFILE_REPOSITORY_default.

  5. Assurez-vous que Configuration Agent est configuré de manière à appliquer les stratégies locales disponibles (pour plus de détails, voir Paramètres supplémentaires de l'agent ).

    Remarque –

    Si vous modifiez le paramètre Profils locaux (ApplyLocalPolicy) de Configuration Agent, vous devez recharger Configuration Agent en vous connectant en tant que root et en tapant la commande /usr/lib/apoc/apocd reload.

    Toute stratégie locale ainsi déployée sera mise à la disposition des clients au cours du prochain cycle de détection des changements de Configuration Agent.

Redémarrage automatique de Configuration Agent

En cas d'échec, Configuration Agent sera automatiquement réinitialisé. Le fonction de gestion de service ( smf(5) ) est responsable de cette décision. Si cette fonction considère qu'un redémarrage n'est pas approprié (lorsque, par exemple, un grand nombre d'échecs se sont déjà produits), Configuration Agent passe en mode de maintenance.

Lorsque Configuration Agent n'est pas relancé, vous devez désactiver temporairement l'agent en vous connectant en tant qu'utilisateur root et en exécutant la commande /usr/lib/apoc/apocd disable. Vous devez ensuite résoudre les problèmes à l'origine de l'échec de l'agent et le réactivez en exécutant la commande /usr/lib/apoc/apocd enable.

Accès aux données / Authentification des utilisateurs

Configuration Agent récupère des informations auprès du serveur LDAP en fonction de l'ID de connexion d'un utilisateur de bureau. Le paramètre User/UniqueIdAttribute du fichier de mappage organisationnel associe l'ID de connexion à un élément d'utilisateur sur le serveur LDAP. Configuration Agent récupère également des informations relatives à l'hôte, par exemple son nom ou son adresse IP. Les informations sont associées à un élément d'hôte sur le serveur LDAP par le biais du paramètre Host/UniqueIdAttribute du fichier de mappage organisationnel. Pour plus d'informations sur le mappage organisationnel, voir Annexe C, Mappage organisationnel.

Il existe deux méthodes d'accès au serveur LDAP, à savoir la méthode anonyme et la méthode GSSAPI. Aucune action n'est requise sur le bureau pour un accès anonyme. Pour la méthode GSSAPI, des informations d'identification Kerberos doivent être obtenues sur le bureau. Pour intégrer l'obtention des informations d'identification de Kerberos à la connexion de l'utilisateur, le module pam_krb5 doit être installé et configuré sur l'hôte Java Desktop System.

Vous pouvez utiliser gdm pour intégrer Kerberos à la connexion de l'utilisateur, par exemple, en utilisant le fichier /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

Si vous intégrez Kerberos à la connexion de l'utilisateur de cette manière, vous devez activer la prise en charge de Kerberos par l'économiseur d'écran. Par exemple, vous pouvez utiliser le fichier /etc/pam.d/xscreensaver suivant :


auth required pamkrb5.so use_first_pass missing_keytab_ok 
ccache=SAFE putenv_direct

Adaptateurs

Les adaptateurs d'applications sont des extensions des systèmes de configuration prises en charge par Desktop Manager. Les adaptateurs permettent à différentes applications de prendre en compte les données de configuration centrales, en fonction des systèmes de configuration. Les systèmes de configuration pris en charge sont :

Un adaptateur de définition du bureau est également fourni. Il permet d'intégrer des lanceurs de bureau, des options de menu et des programmes de démarrage au bureau de l'utilisateur.

Adaptateur GConf

L'adaptateur GConf fait partie du package SUNWapoc-adapter-gconf pour Solaris. Lorsque vous installez l'adaptateur à partir du package correspondant, le chemin d'accès aux sources de données GConf dans /etc/gconf/2/path est mis à jour afin d'inclure les sources Desktop Manager. Les deux sources de données fournies par l'adaptateur sont les suivantes :

Configuration de l'adaptateur GConf

L'adaptateur GConf est configuré au cours de son installation, cependant son fonctionnement dépend de la présence du fichier de chemin GConf (/etc/GConf/2/path) de deux sources de données représentant les paramètres centraux obligatoires et les paramètres par défaut. Bien que le fichier du chemin d'accès contient les informations GConf correctes pour la prise en compte des paramètres centralisés comme requis après l'installation du système, les administrateurs doivent s'assurer que les sources de données munies du préfixe "apoc" sont encore présentes dans le fichier. En effet, ils pourraient être amenés à modifier ce chemin afin d'inclure des sources de données personnalisées supplémentaires. Vous devez également contrôler que les sources de données se trouvent entre les paramètres locaux obligatoires et les paramètres d'utilisateur pour ce qui est de la source de données représentant les paramètres centraux obligatoires et entre les paramètres d'utilisateur et les paramètres locaux par défaut pour ce qui est de la source de données représentant les paramètres centraux par défaut.

Adaptateur Java Preferences

L'adaptateur Java Preferences fait partie du package SUNWapcj pour Solaris.

Configuration de l'adaptateur Java Preferences

L'adaptateur Java Preferences est fourni comme implémentation de l'API des préférences qui doit être utilisée en tant que wrapper d'une autre implémentation existante (telle que le système fichier par défaut fourni avec JRE). Pour activer l'utilisation de la configuration centrale dans une application Java utilisant l'API des préférences, un script de démarrage doit être écrit pour cette application, à l'aide du script /usr/lib/apoc/apocjlaunchJava. Ce script doit définir quelques variables d'environnement, puis inclure le script apocjlaunch à la fin (ce qui démarre l'application Java dans l'environnement qui convient). Les variables d'environnement à définir sont les suivantes :

Les variables d'environnement facultatives supplémentaires pouvant être définies sont :

Adaptateur Mozilla

L'adaptateur Mozilla fait partie du package SUNWmozapoc-adapter pour Solaris.

Configuration de l'adaptateur Mozilla

L'adaptateur Mozilla est configuré au cours de l'installation de ce produit et n'exige aucune configuration supplémentaire.

Adaptateur StarOffice

L'adaptateur StarOffice est inclus dans une installation StarOffice standard et permet d'accéder aux données de configuration de profil sans que des modifications particulières ne soient nécessaires.

Configuration de l'adaptateur StarOffice

L'adaptateur StarOffice est configuré au cours de l'installation de ce produit et n'exige aucune configuration supplémentaire.

Adaptateur de définition du bureau

L'adaptateur de définition du bureau se compose des packages suivants :

Nom du package 

Description 

SUNWapleg 

binaires d'accès à la configuration 

SUNWardsa 

adaptateur de définition du bureau 

SUNWardsa-misc 

intégration système pour adaptateur 

Ces packages sont installés si les composants client Desktop Manager sont installés et ne demandent aucune configuration supplémentaire.

Configuration de l'adaptateur de définition du bureau

L'adaptateur de définition du bureau est configuré par le processus d'installation à utiliser à la connexion d'un utilisateur et ne demande aucune configuration supplémentaire.

Suppression des adaptateurs

Les adaptateurs Mozilla et StarOffice sont supprimés à la désinstallation de ces produits. Il est possible de supprimer les adaptateurs GConf, Java Preferences et l'adaptateur de définition du bureau à l'aide des outils système de gestion de package adéquats en retirant les packages mentionnés dans la section Installation.

Après la suppression de l'adaptateur Java Preferences, les scripts de démarrage écrits en vue de lancer les applications Java au moyen de l'API des préférences ne doivent plus être utilisés. L'appel de Java qu'ils contiennent échoue, puisque certains d'entre eux exigent des classes qui ne sont plus disponibles.

Dépannage de l'adaptateur

La plupart des problèmes aboutissant à l'absence de données de configuration centrales au sein des applications correspondantes provient probablement de Configuration Agent. En effet, il s'agit du système couramment utilisé par les adaptateurs afin de récupérer des données.

Si un changement de configuration centralisée ne semble pas être répercuté au niveau d'un paramètre donné (ou d'un groupe de paramètres), il est possible que l'utilisateur ait défini explicitement une valeur pour ce paramètre dans l'application (généralement, en utilisant la boîte de dialogue Options ou Préférences du produit). Dans ce cas, la préférence utilisateur prime sur les valeurs définies via Desktop Manager, sauf si les paramètres centralisés sont protégés, ce qui signifie que la valeur est imposée par l'administrateur et que l'utilisateur n'a pas l'autorisation de modifier celle-ci.

Dépannage de Configuration Agent

Cette section répond à certaines des interrogations que vous pouvez vous poser vis à vis de la nature et du fonctionnement de Configuration Agent ; elle présente également des conseils qui vous permettront de résoudre les problèmes liés à l'Agent.

Questions et réponses

Qu'est-ce que Configuration Agent et comment fonctionne-t-il ?

Configuration Agent est une application de mise en cache et de livraison de stratégie. Il a été conçu de manière à garantir la centralisation de la configuration des applications clientes de bureau sans que cela nuise aux performances de ces applications et des hôtes sur lesquelles elles fonctionnent. Pour réaliser cet objectif, les points suivants sont mis en œuvre :

Le scénario type selon lequel une interaction se produit entre les applications clientes et Configuration Agent est extrêmement simple et peut être décrit de la manière suivante :

  1. Un utilisateur lance une des applications clientes de bureau (gconfd, Mozilla ou StarOffice).

  2. L'application cliente se connecte à Configuration Agent.

  3. L'application cliente demande les données de stratégie dont elle a besoin auprès de Configuration Agent.

  4. Configuration Agent recherche dans la mémoire cache les données de stratégie demandées.

  5. Si ces données ne s'y trouvent pas, Configuration Agent télécharge les données en question depuis un référentiel de stratégie préconfiguré et les place dans le cache.

  6. Les données de stratégie sont envoyées à l'application cliente à l'origine de la demande.

  7. Configuration Agent vérifie dans le référentiel de stratégie toute modification apportée aux données de stratégie.

  8. Si une modification est détectée, Configuration Agent actualise son cache de manière à le mettre à jour et en informe l'application cliente.

Comment obtenir et installer Configuration Agent ?

Configuration Agent est disponible et installé par défaut avec Solaris 10.

Je viens d'installer Solaris 10. Que dois-je faire ensuite ?

Par défaut, Configuration Agent est désactivé et n'est pas configuré. Pour utiliser Configuration Agent, vous devez lui appliquer, au moins, la configuration minimale et l'activer. À la suite de ces opérations, vos applications clientes de bureau utiliseront automatiquement la stratégie indiquée dès que vous les relancez.

Je veux configurer Configuration Agent. Comment faire ?

Pour configurer correctement Configuration Agent, servez-vous de son assistant. Vous pouvez lancer l'assistant en exécutant (en tant qu'utilisateur root) la commande /usr/bin/apoc-config. L'assistant vous guide tout au long de la procédure de configuration de l'agent. Dans la plupart des cas, la seule information à indiquer obligatoirement concerne l'emplacement de votre référentiel de stratégie.

Il est possible également de configurer Configuration Agent en modifiant manuellement les fichiers de configuration. Notez que cette solution n'est pas recommandée car il est très facile de configurer l'agent de manière non appropriée. De plus, l'assistant de Configuration Agent propose une option supplémentaire qui permet de déterminer si une modification de configuration donnée requiert le redémarrage ou le rechargment de l'agent.

Je veux activer Configuration Agent. Comment faire ?

Vous disposez de trois moyens différents pour activer l'agent :

  1. Dans l'assistant de Configuration Agent ( /usr/bin/apoc-config ), définissez l'état de l'agent sur Actif.

  2. Dans le programme contrôleur de Configuration Agent (/usr/lib/apoc/apocd ), exécutez la commande suivante en tant qu'utilisateur root : 


    /usr/lib/apoc/apocd enable

  3. À l'aide de smf(5), exécutez la commande suivante en tant que superutilisateur :


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

J'ai configuré et activé Configuration Agent. Comment savoir s'il fonctionne ?

La manière la plus simple pour contrôler que Configuration Agent est configuré et qu'il fonctionne consiste à créer une stratégie à l'aide de Desktop Manager et de l'assigner à un utilisateur. Connectez-vous ensuite à l'ordinateur de bureau sous l'identité de cet utilisateur et vérifiez si les paramètres de stratégie utilisés correspondent à ceux que vous avez définis. De nombreux paramètres de stratégie sont facilement détectables au cours d'une session de bureau, comme l'arrière-plan ou le thème.

Que signifie activer Configuration Agent ?

Configuration Agent est un service conforme à smf(5) et, à ce titre, la notion d'activation de l'agent provient de l'utilitaire smf(5). Lorsque l'agent est activé, il est prêt à fournir le service pour lequel il est conçu. Les actions suivantes se produisent lorsque vous activez l'agent :

Comment savoir si Configuration Agent est activé ?

Servez-vous de l'une des méthodes suivantes pour déterminer si Configuration Agent est activé :

Comment savoir si Configuration Agent fonctionne actuellement ?

Servez-vous de l'une des méthodes suivantes pour déterminer si Configuration Agent fonctionne :

Où se trouvent les fichiers journaux ?

Vous pouvez consulter les fichiers journaux suivants lorsque vous avez besoin de résoudre un problème concernant Configuration Agent :

Comment augmenter la granularité du système de journalisation de l'agent ?

Voir Où se trouvent les fichiers journaux ?

Qu'est-ce que le mode de maintenance ?

Dès qu'il détecte des problèmes de démarrage ou de redémarrage de l'agent, smf(5) place Configuration Agent en mode de maintenance. Si smf(5) ne parvient pas à exécuter l'agent, il essaie de le redémarrer à plusieurs reprises jusqu'à ce que l'agent démarre ou qu'il décide que ce dernier ne peut pas être lancé. Dans le dernier cas, smf(5) place l'agent en mode de maintenance pour vous indiquer qu'il est nécessaire de remédier aux problèmes rencontrés. Lorsque les problèmes sont résolus, vous pouvez effacer l'état de smf(5) de l'agent pour revenir en mode normal.

Comment sortir du mode de maintenance en effaçant l'état de smf(5) ?

Connectez-vous en tant que superutilisateur et exécutez la commande /usr/sbin/svcadm clear svc:/network/apocd/udp.

Que se passe-t-il si Configuration Agent s'arrête de fonctionner de manière inattendue ?

En pareille situation, smf(5) détecte que l'agent s'est interrompu et tente de le redémarrer. Si, pour une raison quelconque, plusieurs tentatives successives échouent, smf(5) bascule l'agent en mode de maintenance. Si l'agent redémarre, cela n'a pas d'impact sur les applications clientes de bureau en cours d'exécution. Toute application cliente se reconnecte automatiquement à l'agent dès qu'il redémarre.

Dois-je redémarrer les applications clientes de bureau si j'active/je démarre l'agent ?

Tout dépend, en réalité, si l'agent était activé ou en cours d'exécution au moment du démarrage de l'application cliente de bureau considérée. Si l'agent était activé ou en cours d'exécution, l'application cliente avait établi une connexion avec celui-ci et tente de rétablir la connexion perdue. Ainsi, chaque fois que vous démarrez, activez ou désactivez l'agent, les applications clientes tentent de se reconnecter à l'agent. En revanche, si l'agent n'est pas activé/en cours d'exécution lorsque l'application cliente est lancée, celle-ci n'utilise pas Configuration Agent et ne tente alors pas de s'y connecter lorsque ce programme démarre. En résumé, il convient de noter les points suivants :

Les applications clientes de bureau ne semblent pas utiliser les stratégies configurées. Que dois-je faire ?

Le problème le plus courant lié à Configuration Agent représente l'impossibilité de détecter les effets d'une stratégie configurée sur des applications clientes de bureau. Une configuration incorrecte de l'agent, du référentiel de stratégie ou encore la non-disponibilité du référentiel de stratégie sont, le plus souvent, à l'origine de ce problème. Les consignes suivantes peuvent contribuer à localiser et éliminer ce genre de problème :

Problèmes de démarrage de Configuration Agent

Si Configuration Agent ne peut pas être démarré et que vous êtes certain d'avoir configuré et activé Configuration Agent, pensez à consulter les fichiers journaux. Les sections suivantes décrivent les erreurs les plus courantes liées à ce problème.

Répertoire de données de Configuration Agent erroné ou inaccessible

Le répertoire de données de Configuration Agent est créé ou utilisé par l'agent en vue de stocker les fichiers journaux, les caches de stratégies, etc. L'emplacement par défaut de ce répertoire est /var/opt/apoc.

Configuration Agent génère le message d'erreur suivant dans les fichiers journaux smf(5) lorsque le répertoire de données se trouve à un emplacement inaccessible, c'est-à-dire qui correspond à /dev/null/cant/write/here. Pour résoudre ce problème, utilisez l'assistant de Configuration Agent (/usr/bin/apoc-config) pour désigner un emplacement accessible pour le répertoire de données.


[ 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 ]

Utilisation d'une demande client relative à un port déjà occupé

Configuration Agent utilise des sockets de connexion TCP/IP pour communiquer avec les applications clientes de bureau. Par défaut, ces connexions transitent par le port 38900.

Le message d'erreur suivant est généré lorsque Configuration Agent est configuré pour utiliser le port 1234 qui est déjà utilisé par un autre service. Le message d'erreur est enregistré dans les fichiers journaux de Configuration Agent. Pour résoudre ce problème, utilisez l'assistant de Configuration Agent (/usr/bin/apoc-config) pour remplacer la valeur du paramètre Port de l'agent par un numéro de port non utilisé.


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)

Utilisation d'un port d'administration déjà occupé

Configuration Agent utilise les sockets de connexion TCP/IP pour communiquer avec le programme contrôleur de Configuration Agent (/usr/lib/apoc/apocd). Par défaut, ces connexions transitent par le port 38901.

Le message d'erreur suivant apparaît dans les journaux de Configuration Agent lorsque ce dernier est configuré pour utiliser le port 1234 qui est déjà utilisé par un autre service. Pour résoudre ce problème, utilisez l'assistant de Configuration Agent (/usr/bin/apoc-config) pour remplacer la valeur du paramètre Port d'administration par un numéro de port non utilisé.


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

Problèmes d'obtention d'une stratégie de Configuration Agent en cours d'exécution

Spécification d'un référentiel de configuration incorrect ou absent

Configuration Agent doit se connecter à un référentiel de configuration valide pour être en mesure de télécharger et de mettre en cache les informations de stratégie. Si vous n'avez pas correctement identifié le référentiel de configuration dans la configuration de l'agent (vous avez utilisé un format erroné ou omis de spécifier un référentiel, par exemple), des erreurs similaires à l'erreur suivante sont enregistrées dans les fichiers journaux de Configuration Agent au moment du démarrage des applications clientes de bureau. Pour résoudre ce problème, servez-vous de l'assistant de Configuration Agent (/usr/bin/apoc-config ) pour identifier le référentiel de configuration à utiliser.


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

Impossible de se connecter à un référentiel de stratégie

Configuration Agent doit se connecter à un référentiel de configuration valide pour être en mesure de télécharger et de mettre en cache les informations de stratégie. Si la connexion ne peut pas être établie, des erreurs similaires à la suivante sont enregistrées dans les fichiers journaux de Configuration Agent au démarrage des applications clientes de bureau. Dans le cas suivant, l'hôte sobuild n'existe pas, ne peut pas être contacté, ni ne peut accéder à un serveur LDAP via le port 389. Pour résoudre ce problème, servez-vous de l'assistant de Configuration Agent (/usr/bin/apoc-config) pour vous assurer que vous avez convenablement identifié le référentiel de stratégie et, dans ce cas-là, que l'accès au référentiel est possible. Par exemple, pour un référentiel LDAP, vous devez vérifier le fonctionnement d'un serveur LDAP, la disponibilité sur le réseau de l'ordinateur hébergeant le serveur LDAP et le fait que le port spécifié est celui qui est utilisé par le serveur LDAP.

Si vous essayez d'accéder à un serveur LDAP par une connexion SSL, assurez-vous que le certificat approprié est disponible dans le keystore correspondant de l'environnement d'exécution Java utilisé pour exécuter Configuration Agent. Reportez-vous à la section Configuration Agent pour plus d'informations sur la commande apoc-config. 


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

Connexion à un référentiel de stratégie non configuré

Avant que Configuration Agent puisse localiser les données de stratégie dans un référentiel de stratégie, il convient de configurer celui-ci correctement. Si vous spécifiez un référentiel de stratégie non configuré ou incorrectement configuré, des erreurs similaires à celle indiquée par la suite sont enregistrées dans les fichiers journaux de Configuration Agent au démarrage des applications clientes de bureau. Pour résoudre ce problème, veuillez consulter la section 


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)

J'ai remarqué, dans les fichiers journaux de Configuration Agent, un message relatif à un "nombre maximal de connexions des clients". Que signifie-t-il ?

Chaque application cliente de bureau (gconfd, Mozilla, StarOffice) activée par Configuration Agent établit une connexion avec Configuration Agent lorsqu'il fonctionne. La limite de telles connexions est spécifiée dans la configuration de l'agent. Par défaut, elle est fixée à 50. Si un ordinateur est utilisé par plusieurs utilisateurs, il est possible d'augmenter cette limite en changeant le paramètre “Nombre maximal de connexions des clients” dans l'assistant de Configuration Agent (/usr/bin/apoc-config). Lorsque Configuration Agent atteint le nombre maximal de connexions, un message d'erreur similaire au message suivant est reporté dans les fichiers journaux de Configuration Agent :


Nov 18, 2005 3:20:55 PM com.sun.apoc.daemon.misc.APOCLogger warning
AVERTISSEMENT : le nombre maximal de connexions de clients ( 50 ) a été atteint. 
Aucune nouvelle connexion client ne peut être établie à ce stade.

J'ai modifié certaines stratégies à l'aide de Desktop Manager mais les modifications ne sont pas visibles sur mes ordinateurs client.

Lors de la conception de Configuration Agent, le principe selon lequel les données de stratégies créées par Desktop Manager sont relativement statiques a été établi. En d'autres termes, elles ne sont pas susceptibles d'être modifiées régulièrement. Ce principe est le résultat de l'approche selon laquelle Configuration Agent consulte, par intermittence, le référentiel de stratégie pour prendre connaissance d'éventuels changements. Par défaut, l'agent vérifie le référentiel une fois par heure pour toutes les applications de bureau en cours. En conséquence, lorsque vous apportez une modification à l'aide de Desktop Manager, les applications de bureau en cours n'en sont informées qu'au bout d'une heure. Si vous le voulez, vous pouvez utiliser l'assistant de Configuration Agent (/usr/bin/apoc-config ) pour modifier la valeur de l'"Intervalle de détection générale" afin d’augmenter la fréquence des vérifications du référentiel. Une autre solution consiste à obliger Configuration Agent à actualiser les données de stratégie pour l'ensemble des applications connectées. Pour cela, vous vous connectez en tant que superutilisateur et exécutez la commande /usr/lib/apoc/apocd change-detect.