test

Sun Desktop Manager 1.0 Installation Guide

Chapter 3 Client Components

To access the configuration data from the Desktop Manager, a desktop client requires the Java Desktop System Configuration Agent. The Configuration Agent communicates with the remote configuration data repository and the adapters, as well as integrates data into specific configuration systems. The configuration systems that are currently supported are GConf, Java Preferences, Mozilla Preferences, and StarOffice Registry.

A version of the Configuration Agent is provided with the Solaris 10 operating system. However, the Desktop Manager requires a newer version of that tool. That newer version is installed as part of the setup of the Desktop Manager client components and associated patches.

To install the Desktop Manager client components:

  1. Download the Desktop Manager zip archive and extract the content in a temporary directory.


    # unzip SunDesktopMgr-1.0.zip

  2. Install the recommended patches.

    These patches are provided in the SunDesktopMgr-1.0/<platform>/client/Patches directory. Follow the installation instructions provided with each patch.

  3. Become the super-user (root) and execute the setup script through:


    # cd SunDesktopMgr-1.0/<platform>/client
# ./setup

Configuration Agent

The Configuration Agent is part of a number of different packages, which are listed in the following table:

Solaris Package Name 

Description 

SUNWapbas 

Configuration Shared libraries 

SUNWapmsc 

Configuration Agent miscellaneous files 

SUNWapoc 

Configuration Agent 

SUNWapdc 

Configuration Agent wizard 

When you install these packages, the files that are required for this API are installed. You can install the packages manually or through the Java Desktop System installation. After installation, you must configure and enable the Configuration Agent on your system.

Note –

Configuration Agent packages are installed as part of the Solaris with Java Desktop System installation; however, the Desktop Manager patches these files during installation to provide the proper level of functionality.

To access the remote configuration data, the Configuration Agent requires some minimal bootstrap information, such as the host name and port of the LDAP server. This information is maintained in a set of properties files, such as policymgr.properties, apocd.properties, os.properties. These files are stored locally in the /etc/apoc directory. You can manually edit these properties files (see Appendix A, Configuration Parameters), or you can use the configuration wizard for the Configuration Agent.

The configuration wizard offers a graphical user interface that guides you through the necessary settings of the Configuration Agent. For each page of the wizard, a corresponding help screen is available. You can start the wizard as super user (root) by means of the /usr/bin/apoc-config script.

Note –

The wizard can also be started without launching the graphical interface. For example, execute /usr/bin/apoc-config -nodisplay to start the wizard in console mode.

Bootstrap Information

Figure 3–1 Configuration Agent, Configuration Repository

Configuration Repository and State

Note –

Associated property file keys are indicated in parentheses, where appropriate.

Figure 3–2 Configuration Agent, LDAP Hierarchy and File-Based Storage

LDAP Hierarch and File-Based storage

Note –

The screen in Figure 3–2 varies, depending on the Context Type chosen on the previous screen. Server Identifier, Server Port and Suffix are required if an LDAP or Hybrid context type is chosen. Configuration Settings URL is required if a File-based or Hybrid context type is chosen.

Figure 3–3 Configuration Agent, Authentication Mechanism

Authentication

Port Settings

The Configuration Agent uses two ports:

Figure 3–4 Configuration Agent, Port Settings

Configuration Agent, Port Settings

Change Detection Interval

The Configuration Agent periodically checks for any changes in the configuration data using the following two intervals:

You can use the general detection interval to tune the propagation of remote configuration data changes to client side applications. The value provided for this setting is the maximum length of time in minutes that elapses before remotely made changes are reflected in the client applications.

Smaller values result in increased Configuration Agent and LDAP server activity. As a result, use caution when you adjust the value of the settings. For example, in an initial deployment phase, you can set the value to one minute so that you can test the impact of remote configuration on client applications. After you complete the testing, return this setting to the initial value.

Operational Settings

Figure 3–5 Configuration Agent, Data Directory

Configuration Agent, Data Directory

The following settings can be configured:

Figure 3–6 Configuration Agent, Request Handling and Logging

Configuration Agent, Request Handling and Logging

Note –

Most of the operational settings, with the exception of the Data Directory and Connection Timeout settings, can also be maintained centrally through corresponding policies stored in the LDAP server. If you want to use this feature, do not adapt the corresponding settings by means of the wizard. Instead, use the Configuration Agent policies within the Desktop Manager to centrally specify operational settings.

Applying Agent Settings

With the exception of "Data Directory" and "Connection Timeout", operational settings that have been stored on the LDAP server by means of the Desktop Manager take effect automatically at the next change detection cycle for the agent configuration (see DaemonChangeDetectionInterval).

Figure 3–7 Configuration Agent, Summary Page

Summary page

All other settings changed locally require a reload or restart of the Configuration Agent. The reload or restart is performed automatically if you use the configuration wizard.

Note –

To manually restart the Configuration Agent, ensure that no related client applications are running, log in as root, and type the command /usr/lib/apoc/apocd restart.

Additional Agent Settings

Note –

The following settings are not available in the configuration wizard.

Using Local Policy

You may configure the Configuration Agent to apply configuration settings from locally deployed policy in addition to or as an alternative to any globally available policy. Use the following steps to deploy any such local policy:

ProcedureDeploying a Local Policy

Steps

  1. Using the Desktop Manager create a profile with the required policy settings.

  2. Using the Desktop Manager export the profile to a zip file.

  3. On your client host, create the directory ${DataDir}/Policies/profiles/PROFILE_REPOSITORY_default, if it does not already exist.

    ${DataDir} corresponds to the value of the Configuration Agent's Data Directory which is /var/opt/apoc by default.

  4. Copy the previously exported zip file to ${DataDir}/Policies/profiles/PROFILE_REPOSITORY_default.

  5. Ensure that the Configuration Agent is configured to apply available local policies (see Additional Agent Settings for more details ).

    Note –

    If you change the Configuration Agent's “ApplyLocalPolicy” setting, you should reload the Configuration Agent by logging in as root and typing the command /usr/lib/apoc/apocd reload.

    Any local policy deployed in this manner will be made available to clients during the next Configuration Agent change detection cycle.

Automatic Restart of the Configuration Agent

In the event of a failure, the Configuration Agent will be automatically restarted. The service management facility ( smf(5) ) is responsible for making this decision. If the service management facility decides that a restart is inappropriate (for example, if too many failures have already occurred), the Configuration Agent is placed in maintenance mode.

In the event that the Configuration Agent is not restarted, you should disable the Agent temporarily by logging in as root and executing the command /usr/lib/apoc/apocd disable, rectify any problems causing the Agent to fail and re-enable the Agent by executing the command /usr/lib/apoc/apocd enable.

Data Access/User Authentication

The Configuration Agent retrieves information from the LDAP server based on the login ID of a desktop user. The User/UniqueIdAttribute setting of the organizational mapping file maps the login ID to a user element in the LDAP server. The Configuration Agent also retrieves information about the host, such as the name or the IP address of the host. This information is mapped to a host element in the LDAP server through the Host/UniqueIdAttribute setting of the organizational mapping file. For more information about organizational mapping, see Appendix C, Organizational Mapping.

There are two methods to access the LDAP server, namely anonymously or with GSSAPI. For anonymous access, no action is required on the desktop. For the GSSAPI method, Kerberos credentials must be acquired on the desktop. To integrate Kerberos credential acquisition with the user login, the pam_krb5 module must be installed and configured on the Java Desktop System host.

You can use gdm to integrate Kerberos with the user login, for example, by using the following /etc/pam.d/gdm file:


#%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

If you integrate Kerberos with user login in this way, you should enable the screensaver's Kerberos support. For example, by using the following /etc/pam.d/xscreensaver file:


auth required pamkrb5.so use_first_pass missing_keytab_ok 
ccache=SAFE putenv_direct

Adapters

The application adapters are extensions of the configuration systems supported by the Desktop Manager. The adapters allow the various applications to take the central configuration data into account, depending on configuration systems. The supported configuration systems are:

A desktop definition adapter is also provided, which adds desktop launchers, menu items, and startup programs to the user desktop.

GConf Adapter

The GConf adapter is part of the SUNWapoc-adapter-gconf package for Solaris. When you install the adapter from the corresponding packageAdapter, the GConf data sources path in /etc/gconf/2/path is updated to include the Desktop Manager sources. The two data sources that are provided by the adapter are:

GConf Adapter Configuration

The GConf adapter is configured as part of its installation, however its operation is dependent on the presence in the GConf path file (/etc/GConf/2/path) of two data sources representing the mandatory central settings and the default settings. While this path file contains the proper information for GConf to take the central settings into account as expected after the installation of the system, administrators should ensure, that the data sources prefixed with "apoc" are still present in the file, should they need to modify that path to include additional custom data sources. You should also ensure that the data sources are located between local mandatory settings and user settings for the data source representing the mandatory central settings, and between the user settings and local default settings for the data source representing the default central settings.

Java Preferences Adapter

The Java Preferences adapter is part of the SUNWapcj package for Solaris.

Java Preferences Adapter Configuration

The Java Preferences adapter is provided as an implementation of the Preferences API that must be used as a wrapper to another existing implementation (such as the default file based system provided with the JRE). To enable the use of central configuration in a Java application that makes use of the Preferences API, a startup script for that application must be written, using the /usr/lib/apoc/apocjlaunch script as a helper. This script needs to define a few environment variables and then include the apocjlaunch script at its end (which starts the Java application with the necessary environment). The environment variables that must be set are:

The optional additional environment variables that can be set are:

Mozilla Adapter

The Mozilla adapter is part of the SUNWmozapoc-adapter package on Solaris.

Mozilla Adapter Configuration

The Mozilla adapter is setup as part of the installation of this product, and does not need any additional configuration.

StarOffice Adapter

The StarOffice adapter is included in a standard StarOffice installation and allows you to access the profile configuration data without any special modifications.

StarOffice Adapter Configuration

The StarOffice adapter is setup as part of the installation of this product, and does not need any additional configuration.

Desktop Definition Adapter

The Desktop Definition adapter consists of the following packages:

Package Name 

Description 

SUNWapleg 

configuration access binaries 

SUNWardsa 

desktop definition adapter 

SUNWardsa-misc 

system integration for adapter 

These packages are installed when the Desktop Manager client components are installed, and do not require any additional setup.

Desktop Definition Adapter Configuration

The Desktop Definition adapter is configured by the setup process to be used whenever a user logs in, and does not require any additional setup.

Removing Adapters

The Mozilla and StarOffice adapters are removed when these products are removed. The GConf, Java Preferences and Desktop Definition adapters can be removed using the appropriate package management system tools by removing the packages mentioned in the Installation section.

Upon removing the Java Preferences adapter, the startup scripts written for the purpose of launching Java applications using the Preferences API should not be used anymore. The Java invocation in them fails, since some needed classes will no longer be available.

Adapter Troubleshooting

Most of the problems that can result in not seeing the central configuration data in the corresponding applications are likely to come from the Configuration Agent, since it is the common mechanism used by all adapters to retrieve the data.

If a central configuration change does not seem to take effect for a given setting (or group thereof), a possible explanation is that the user has explicitly set a value for that setting in the application (usually by using the Options or Preferences dialogs of the product). In that case, unless the central settings are defined as protected, which means that value is forced by the administrator and the user is not allowed to modify it, the user preference will take precedence over the values set using the Desktop Manager.

Configuration Agent Troubleshooting

This section answers some of the questions you may have regarding the nature and workings of the Configuration Agent along with some tips for troubleshooting problems with the Agent.

Questions and Answers

What is the Configuration Agent, and how does it work?

The Configuration Agent is a policy caching and delivery application. It was designed and built to ensure that desktop client applications could be centrally configured without significant impact to the performance of these applications and the hosts they run on. This is achieved by:

The typical scenario where interaction occurs between client applications and the Configuration Agent is extremely simple and can be described as follows:

  1. A user launches one of the relevant desktop client applications ( gconfd, Mozilla or StarOffice )

  2. The client application connects to the Configuration Agent

  3. The client application requests policy data that it needs from the Configuration Agent

  4. The Configuration Agent searches its cache for the requested policy data

  5. If the policy data is not found in the cache, the Configuration Agent downloads the required data from a pre configured policy repository and stores it in the cache

  6. The policy data is sent to the requesting client application

  7. The Configuration Agent monitors the policy repository for any modifications to policy data

  8. If a modification is detected, the Configuration Agent refreshes its cache so that it is up to date and informs the client application of the modification.

How do I get and install the Configuration Agent?

The Configuration Agent is available and installed by default with Solaris 10

I've just installed Solaris 10. What do I do next?

The Configuration Agent is disabled and not configured by default. To use the Configuration Agent, you must at least minimally configure it and enable it. Once you've completed these steps, your desktop client applications will automatically start to use any policy you provide when they are next started.

I want to configure the Configuration Agent. How do I do that?

To configure the Configuration Agent correctly, use the Configuration Agent Wizard. You can start the wizard by executing (as root) the command /usr/bin/apoc-config. The wizard guides you through the steps required to correctly configure the agent. In most cases, the only piece of information you absolutely need to complete the wizard is the location of your policy repository.

It is also possible to configure the Configuration Agent by manually editing its configuration files. This is not recommended as it is far easier to incorrectly configure the Agent this way. Additionally, the Configuration Agent Wizard contains additional logic which determines whether or not a particular configuration change requires a restart or a reload of the Agent.

I want to enable the Configuration Agent. How do I do that?

There are three possible mechanisms you can use to enable the Agent:

  1. Using the Configuration Agent Wizard ( /usr/bin/apoc-config), set the Agent State to Active.

  2. Using the Configuration Agent controller program ( /usr/lib/apoc/apocd), execute the following as root: 


    /usr/lib/apoc/apocd enable

  3. Using smf(5), execute the following as superuser:


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

I've configured and enabled the Configuration Agent. How do I know it's working?

The easiest way to know if the Configuration Agent is correctly configured and working is to create a policy with the Desktop Manager, assign the policy to a user, login to the desktop machine as that user and verify that the policy settings you made are being used. There are many policy settings which are easily detectable in a desktop session, for example, background and theme.

What is the significance of enabling the Configuration Agent?

The Configuration Agent is an smf(5) compliant service and, as such, the notion of enabling the Agent comes from smf(5). Once the Agent is enabled, the Agent is ready to provide service. The following actions occur when you enable the Agent:

How do I know if the Configuration Agent is enabled?

You can use one of the following methods to determine if the Configuration Agent is enabled:

How do I know if the Configuration Agent is running?

Use one of the following methods to determine if the Configuration Agent is running:

Where are the log files?

You can consult the following log files when you need to troubleshoot a Configuration Agent problem:

How do I increase the granularity of the Agent logging mechanism?

See Where are the log files?

What is maintenance mode?

smf(5) places the Configuration Agent in maintenance mode when it detects problems with starting or restarting the Agent. If smf(5) fails to start the Agent, it attempts multiple restarts until the Agent startup is successful or smf(5) decides that the Agent cannot be started. In the latter case, smf(5) places the Agent in maintenance mode to indicate to you that you need to address the problems it has encountered. Once you have addressed the problems, you can clear the smf(5) state of the Agent to return to normal operations.

How do I get out of maintenance mode - clearing the smf(5) state?

Become superuser and execute the command /usr/sbin/svcadm clear svc:/network/apocd/udp.

What happens if the Configuration Agent stops running unexpectedly?

smf(5) detects that the Agent has stopped running and tries to restart it. If successive attempts to restart fail for any reason, smf(5) places the Agent in maintenance mode. Running desktop client applications are unaffected if the Agent is restarted successfully. Any such client application reconnects to the Agent automatically when it restarts.

Do I need to restart desktop client applications if I enable/start the Agent?

The action that you take actually depends on whether the Agent was enabled/running at the time when the specific desktop client application was started. If the Agent was enabled/running, the client application established a connection to the Agent and tries to reestablish the connection when it is lost. That is, every time you start, enable or disable the Agent, client applications always try to reconnect to the Agent once it's running. If the Agent was not enabled/running when the client application started, the client application does not use the Configuration Agent and does not even attempt to connect when the Agent starts. All this effectively means that:

My desktop client applications appear not to be using configured policies. What do I do?

The most common problem that relates to the Configuration Agent is the inability to see the effects of a configured policy on desktop client applications. The most common reasons for this problem are an incorrectly configured Agent, an incorrectly configured policy repository or the unavailability of the policy repository. The following guidelines can help you to discover and eliminate such problems:

Problems starting the Configuration Agent

If the Configuration Agent cannot be started and you are satisfied that you have configured and enabled the Configuration Agent, you need to consult the log files. The following sections describe the most common errors for this problem.

Invalid or inaccessible Agent Data Directory

The Configuration Agent Data Directory is created and used by the Agent to store log files, policy caches, and so on. The default location for this directory is /var/opt/apoc.

The Configuration Agent produces the following error message in the smf(5) logs when the Data Directory is set to an inaccessible location, that is, /dev/null/cant/write/here. To solve this problem, use the Configuration Agent Wizard (/usr/bin/apoc-config) to point the Data Directory to an accessible location.


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

Using a client request port that's already busy

The Configuration Agent uses TCP/IP socket connections to communicate with desktop client applications. By default, these connections are made through port 38900.

The following error message is produced when the Configuration Agent is configured to use port 1234, which is already in use by another service. The error message is recorded in the Configuration Agent Logs. To solve this problem, use the Configuration Agent Wizard (/usr/bin/apoc-config) to change the Agent Port setting to a port number which is not in use.


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)

Using an administration port that's already busy

The Configuration Agent uses TCP/IP socket connections to communicate with the Configuration Agent controller program (/usr/lib/apoc/apocd). By default, these connections are made through port 38901.

The following error message occurs in the Configuration Agent logs when the Configuration Agent is configured to use port 1234, which is already in use by another service. To solve this problem, use the Configuration Agent Wizard (/usr/bin/apoc-config) to change the Administration Port setting to a port number which is not in use.


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

Problems getting policies from a running Configuration Agent

Missing or invalid configuration repository specification

The Configuration Agent needs to connect to a valid configuration repository to download and to cache policy information. If you do not correctly identify the configuration repository in the Agent's configuration, for example, by using an invalid format or by not specifying a repository, errors similar to the following one are recorded in the Configuration Agent logs when desktop client applications start up. To solve this problem, use the Configuration Agent Wizard (/usr/bin/apoc-config) to identify the configuration repository that you want to use.


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

Unable to connect to Policy Repository

The Configuration Agent needs to connect to a valid configuration repository to download and cache policy information. If a connection cannot be established, errors similar to the following one are recorded to the Configuration Agent logs when desktop client applications are started. In the following case, the host sobuild does not exist, cannot be contacted, or cannot access an LDAP server through port 389. To solve this problem, use the Agent Configuration Wizard (/usr/bin/apoc-config) to ensure that you have correctly identified the Policy Repository and, if so, to ensure that access to the Policy Repository is available. For example, for an LDAP repository, you need to ensure that an LDAP server is running, the machine hosting the LDAP server is available on the network, and that the port that you specified is the one being used by the LDAP server.

If you are trying to access an LDAP server using an SSL connection, ensure that the proper certificate is available in the key store associated with the Java runtime environment used to run the Configuration Agent. See the section Configuration Agent for more details about 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

Connection to a non-configured Policy Repository

Before the Configuration Agent can locate policy data in a Policy Repository, the Policy Repository must be correctly configured. If you specify a non-configured or incorrectly configured Policy repository, errors similar to the following are recorded in the Configuration Agent logs when desktop client applications are started. To solve this problem, please see the 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)

I see a message in the Configuration Agent Logs regarding a "maximum number of client connections". What does it mean?

Each desktop client application (gconfd, Mozilla, StarOffice) that is enabled by the Configuration Agent opens a connection to the Configuration Agent when it runs. The limit of such connections is specified in the configuration of the Agent. The default limit for connections is 50. On a machine with multiple users, you might have to increase this limit by changing the “Maximum Client Connections” settings with the Configuration Agent Wizard (/usr/bin/apoc-config). If the Configuration Agent reaches the maximum number of connections, error messages similar to the following one are recorded in Configuration Agent logs:


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.

I modified some policies using the Desktop Manager but the modification is not seen on my client machines

One of the assumptions made when designing the Configuration Agent is that policy data created by the Desktop Manager is relatively static, that is, not subject to frequent change. This assumption results in an approach where the Agent intermittently consults the Policy Repository to see if modifications have occurred. By default, the Agent checks the repository once an hour for all running desktop applications. As a result, when you make a change with the Desktop Manager, you need to wait up to one hour before running desktop applications are notified of the change. If you want, you can use the Agent Configuration Wizard (/usr/bin/apoc-config) to change the value of the "General Detection Interval" to increase the frequency of repository checks. Alternatively, you can force the Configuration Agent to refresh policy data for all connected applications by becoming superuser and executing the /usr/lib/apoc/apocd change-detect command.