Contidos dentro
Localizar Mais DocumentaçãoDestaques de Recursos de Suporte |  Fazer download desta apostila em PDF (647 KB)
Chapter 3 Client ComponentsTo 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:
Configuration AgentThe Configuration Agent is part of a number of different packages, which are listed in the following table:
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 InformationFigure 3–1 Configuration Agent, Configuration Repository
Note – Associated property file keys are indicated in parentheses, where appropriate.
Figure 3–2 Configuration Agent, LDAP Hierarchy 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
Port SettingsThe Configuration Agent uses two ports:
Figure 3–4 Configuration Agent, Port Settings
Change Detection IntervalThe 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 SettingsFigure 3–5 Configuration Agent, Data Directory
The following settings can be configured:
Figure 3–6 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 SettingsWith 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
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 SettingsNote – The following settings are not available in the configuration wizard.
Using Local PolicyYou 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:
|
Deploying a Local Policy
#%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:
-
GConf: Gnome configuration system, used by the desktop and most Gnome applications, such as Evolution
-
StarOfficeRegistry: configuration system used by StarOffice and OpenOffice.org
-
Mozilla Preferences: configuration system used by Mozilla
-
Java Preferences: configuration API offered to Java applications
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:
-
"apoc:readonly:": provides access to non-protected settings from the policies. Insert this data source after the user settings and before the local defaults.
-
"apoc:readonly:mandatory@": provides access to protected settings from the policies. Insert this data source after the local mandatory settings and before the user settings.
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:
-
JAVA: contains the path to the Java runtime executable
-
APPLICATION: contains the trailing part of the regular Java runtime invocation for that applications. For example,classname [arguments] for a single class startup, or -jar jarname [arguments] for a jar archive startup.
The optional additional environment variables that can be set are:
-
CLASSPATH: colon-separated list of jars or class files that need to be part of the application class path
-
DEFINES: string containing the define statements that need to be part of the application startup
-
PREFFACTORY: class name of the factory in the underlying Preferences API implementation that the application needs to use
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:
-
Caching any downloaded policy in a locally available cache for future client use
-
Sharing any expensive resources (for example, connections to an LDAP server where policy is hosted ) that can and should be shared
The typical scenario where interaction occurs between client applications and the Configuration Agent is extremely simple and can be described as follows:
-
A user launches one of the relevant desktop client applications ( gconfd, Mozilla or StarOffice )
-
The client application connects to the Configuration Agent
-
The client application requests policy data that it needs from the Configuration Agent
-
The Configuration Agent searches its cache for the requested policy data
-
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
-
The policy data is sent to the requesting client application
-
The Configuration Agent monitors the policy repository for any modifications to policy data
-
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:
-
Using the Configuration Agent Wizard ( /usr/bin/apoc-config), set the Agent State to Active.
-
Using the Configuration Agent controller program ( /usr/lib/apoc/apocd), execute the following as root:
/usr/lib/apoc/apocd enable
-
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:
-
The Agent starts
-
Any desktop client applications started after the Agent is enabled can retrieve policy data
-
The Agent automatically restarts during system boot
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:
-
Use the controller program for the Configuration Agent. Become super user and type the following command:
/usr/lib/apoc/apocd is-enabled
If the Agent is enabled, the controller program returns the following message:
Checking Configuration Agent enabled status ... Enabled
Otherwise, the controller program returns the following message:
Checking Configuration Agent enabled status ... Not enabled
-
Use smf(5) to execute the following command:
/usr/bin/svcs svc:/network/apocd/udp:default
If the Agent is enabled, svcs returns the following message:
STATE STIME FMRI online 8:36:04 svc:/network/apocd/udp:default
If the Agent is disabled, svcs returns the following message:
STATE STIME FMRI disabled 15:58:34 svc:/network/apocd/udp:default
If the Agent is in maintenance mode, svcs returns the following message:
STATE STIME FMRI maintenance 8:38:42 svc:/network/apocd/udp:default
How do I know if the Configuration Agent is running?
Use one of the following methods to determine if the Configuration Agent is running:
-
Become superuser and execute the Configuration Agent controller program:
/usr/lib/apoc/apocd status
If the Agent is enabled, the controller program returns the following message:
Checking Configuration Agent status ... Running
Otherwise, the controller program returns the following message:
Checking Configuration Agent status ... Not running
-
Execute the following command:
/usr/bin/svcs svc:/network/apocd/udp:default
If the Agent is running, svcs returns the following message:
STATE STIME FMRI online 8:36:04 svc:/network/apocd/udp:default
If the Agent is not running, svcs returns the following message:
STATE STIME FMRI disabled 15:58:34 svc:/network/apocd/udp:default
If the Agent is in maintenance mode, svcs returns the following message:
STATE STIME FMRI maintenance 8:38:42 svc:/network/apocd/udp:default
-
Execute the following command:
ps -ef | grep apoc
If the Configuration Agent is running, you should see the following associated Java process in the output of ps:
daemon 29295 29294 0 13:05:22? 0:03 java -Djava.library.path=/usr/lib/apoc -cp /usr/share/lib/apoc/apocd.jar:/usr/s daemon 29294 1 0 13:05:22? 0:00 sh -c java -Djava.library.path=/usr/lib/apoc -cp /usr/share/lib/apoc/apocd.jar: root 29345 28134 0 13:08:59 pts/1 0:00 grep apoc
Where are the log files?
You can consult the following log files when you need to troubleshoot a Configuration Agent problem:
-
smf(5) log files:
-
The /var/svc/log/network-apocd-udp:default.log file records events that relate to attempts to start and stop specific instances of the Configuration Agent. The file also contains the messages that Configuration Agent controller program, /usr/lib/apoc/apocd, writes to its standard output as well as the output messages for the JVM or the Configuration Agent.
-
The /var/svc/log/svc.startd.log log file keeps a record of higher level smf(5) events. For example, if multiple failed attempts to start the Configuration Agent occur in quick succession, smf(5) might decide that the Configuration Agent cannot be started. If this occurs, smf(5) places the Configuration Agent in maintenance mode and writes a log entry to that effect.
Both of these log files are typically useful if you experience problems with the Configuration Agent starting.
-
-
Configuration Agent logs:
The Configuration Agent writes log messages to log files in the default log directory, /var/opt/apoc/Logs. The "Data Directory" for the Configuration Agent is /var/opt/apoc. You can change the location of this directory with the Configuration Agent Wizard (/usr/bin/apoc-config) application. You can change the granularity of log messages by changing the "Log Level" with the Configuration Agent Wizard. If you think you did not configure the Configuration Agent correctly, or if you are experiencing some other sort of agent failure, use the Configuration Agent Wizard to set the Log Level to "Finest" before you consult the agent log files. This step ensures that you acquire the maximum amount of available logging information.
-
System logs:
You can also check the /var/adm/messages log file, or the /var/opt/SUNWut/log/messages log file on a SunRay machine to diagnose problems with the Configuration Agent.
How do I increase the granularity of the Agent logging mechanism?
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:
-
Desktop client applications that started while the Agent was enabled/running do not need to be restarted.
-
Desktop client applications that started while the Agent was not enabled/running must be restarted.
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:
-
Ensure that the Agent is configured.
-
Ensure that the Agent is enabled/running. If you need to start the Agent, you must also restart the desktop client applications that are currently open.
-
If your problems persist, temporarily increase the granularity of the Agent logging mechanism and, if possible, restart the Agent, so that you have complete and fine grained log messages from the time the Agent starts.
-
If the Agent fails to start correctly, consult the section Problems starting the Configuration Agent.
-
If the Agent starts correctly but your desktop client applications do not use an available policy, consult the section "Problems getting policy from a running Configuration Agent".
-
If you are still unable to resolve your problems, please contact Technical Support.
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.