Sun Desktop Manager 1.0 安装指南

Configuration Agent 疑难解答

本部分解答了一些与 Configuration Agent 的特性和使用方法相关的问题,并提供了一些用于解决代理问题的提示。

问题和解答

什么是 Configuration Agent,它是如何工作的?

Configuration Agent 是一种策略缓存和传送应用程序。设计和构建此应用程序的目的是确保能够集中配置桌面客户端应用程序,同时不会对这些应用程序及其所在主机的性能造成显著影响。这一点是通过以下方式实现的:

客户端应用程序与 Configuration Agent 进行交互的典型方案极其简单,其过程可描述如下:

  1. 用户启动一种相关的桌面客户端应用程序(gconfd、Mozilla 或 StarSuite)

  2. 客户端应用程序连接到 Configuration Agent

  3. 客户端应用程序从 Configuration Agent 中请求所需的策略数据

  4. Configuration Agent 在缓存中搜索请求的策略数据

  5. 如果在缓存中未找到策略数据,Configuration Agent 将从预配置的策略系统信息库中下载所需数据,然后将其存储在缓存中

  6. 将策略数据发送给发出请求的客户端应用程序

  7. Configuration Agent 监视策略系统信息库中是否存在对策略数据进行的任何修改

  8. 如果检测到修改,Configuration Agent 会刷新缓存以保持最新状态,并向客户端应用程序通知此修改。

如何获得和安装 Configuration Agent?

Configuration Agent 随 Solaris 10 一起提供,并在默认情况下随 Solaris 10 一起安装

我刚刚安装了 Solaris 10,接下来应该怎么做?

默认情况下,Configuration Agent 处于禁用状态且未进行配置。要使用 Configuration Agent,必须至少对其进行最低配置,然后启用该程序。完成以上步骤后,桌面客户端应用程序将在下一次启动时自动开始使用提供的所有策略。

我要对 Configuration Agent 进行配置,应该如何做?

要正确配置 Configuration Agent,请使用 Configuration Agent 向导。可以通过执行(以 root 身份)/usr/bin/apoc-config 命令来启动向导。向导会指导您逐步完成正确配置代理所需的步骤。多数情况下,完成向导过程中唯一必需的信息是策略系统信息库的位置。

也可以通过手动编辑 Configuration Agent 的配置文件来配置 Configuration Agent。但不建议这样做,因为使用此方法配置代理很容易发生错误。另外,Configuration Agent 向导还包含其他逻辑,用于确定进行特定的配置更改后是否需要重新启动或重新加载代理。

我要启用 Configuration Agent,应该如何做?

可以使用三种可能的机制来启用代理:

  1. 使用 Configuration Agent 向导 ( /usr/bin/apoc-config ),将“代理状态”设置为“活动”。

  2. 使用 Configuration Agent 控制器程序 ( /usr/lib/apoc/apocd ),以 root 身份执行以下命令:


    /usr/lib/apoc/apocd enable
  3. 使用smf(5),以超级用户身份执行以下命令:


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

我已经配置并启用了 Configuration Agent,如何知道它是否正在工作?

了解 Configuration Agent 是否正确配置且正常工作的最简单方法是:使用 Desktop Manager 创建一个策略,将其指定给一个用户,然后以该用户身份登录到桌面计算机,再验证创建的策略设置是否正被使用。在桌面会话中有很多容易检测到的策略设置,例如背景和主题。

启用 Configuration Agent 的意义何在?

Configuration Agent 是一种符合 smf(5) 的服务,因此,启用该代理的意义来源于 smf(5)。启用代理之后,代理即可开始提供服务。启用代理后会发生以下行为:

如何判断 Configuration Agent 是否已启用?

可以使用以下任一方法来确定 Configuration Agent 是否已启用:

如何判断 Configuration Agent 是否正在运行?

可以使用以下任一方法来确定 Configuration Agent 是否正在运行:

日志文件在什么位置?

需要解决 Configuration Agent 问题时,可以参考以下日志文件:

如何提高代理日志记录机制的详细程度?

请参见日志文件在什么位置?

什么是维护模式?

当 smf(5) 检测到与启动或重新启动代理相关的问题时,就会将 Configuration Agent 置于维护模式。如果 smf(5) 启动代理失败,它将多次尝试重新启动,直到代理启动成功,否则,smf(5) 将认为代理无法启动。如果是后一种情况,smf(5) 会将代理置于维护模式,以指明您需要解决代理所遇到的问题。解决这些问题之后,您可以清除代理的 smf(5) 状态以返回到正常运行模式。

如何退出维护模式(清除 smf(5) 状态)?

以超级用户身份登录并执行 /usr/sbin/svcadm clear svc:/network/apocd/udp 命令。

Configuration Agent 异常停止运行时会出现什么情况?

smf(5) 会检测到代理已停止运行并尝试重新启动代理。如果由于某种原因导致连续尝试重新启动失败,smf(5) 会将代理置于维护模式。如果代理重新启动成功,则不会影响正在运行的桌面客户端应用程序。任何此类客户端应用程序都会在代理重新启动后自动重新连接到代理。

如果启用/启动代理,是否需要重新启动桌面客户端应用程序?

实际操作取决于启动特定桌面客户端应用程序时代理是否已启用/正在运行。如果代理已启用/正在运行,则客户端应用程序会建立与代理的连接,并在连接断开后尝试重新建立连接。也就是说,每次启动、启用或禁用代理时,客户端应用程序都会一直尝试重新连接代理(在代理运行之后)。如果在客户端应用程序启动时代理未启用/正在运行,则客户端应用程序不会使用 Configuration Agent,甚至在代理启动之后也不会尝试与其连接。综上所述可以得出以下结论:

我的桌面客户端应用程序似乎未使用已配置的策略,应该怎么做?

与 Configuration Agent 相关的最常见问题是:看不到已配置的策略对桌面客户端应用程序产生的效果。造成这种问题最常见的原因是:代理配置不正确、策略系统信息库配置不正确或策略系统信息库不可用。以下指导方法可以帮助您发现和解决上述问题:

启动 Configuration Agent 时出现的问题

如果无法启动 Configuration Agent,并且确定已配置并启用了 Configuration Agent,则需要参考日志文件。以下各部分描述了关于此问题的最常见错误。

代理数据目录无效或无法访问

Configuration Agent 数据目录由代理创建并使用,用于存储日志文件、策略缓存等。此目录的默认位置为 /var/opt/apoc

如果将数据目录设置为无法访问的位置(即, /dev/null/cant/write/here),则 Configuration Agent 会在 smf(5) 日志中生成以下错误消息。要解决此问题,请使用 Configuration Agent 向导 (/usr/bin/apoc-config) 将数据目录指向一个可访问的位置。


[ Nov 17 14:35:38 Executing start method ("/usr/lib/apoc/apocd svcStart") ]
Starting Configuration Agent ... Warning: Cannot create Log directory
   '/dev/null/cant/write/here/Logs'
Warning:Failed to create log file handler
Nov 17, 2005 2:35:39 PM com.sun.apoc.daemon.misc.APOCLogger config
CONFIG: Daemon configuration:
 MaxRequestSize = 4096
 DaemonAdminPort = 38901
 ThreadTimeToLive = 5
 DaemonChangeDetectionInterval = 10
 IdleThreadDetectionInterval = 15
 PROVIDER_URL =
 DataDir = /dev/null/cant/write/here
 ApplyLocalPolicy = true
 ChangeDetectionInterval = 60
 MaxClientConnections = 50
 GarbageCollectionInterval = 10080
 InitialChangeDetectionDelay = 10
 TimeToLive = 10080
 ConnectionReadTimeout = 5000
 DaemonPort = 38900
 LogLevel = FINEST
 MaxClientThreads = 5


Nov 17, 2005 2:35:39 PM Daemon main
FINER: THROW
com.sun.apoc.daemon.misc.APOCException
    at com.sun.apoc.daemon.apocd.Daemon.initAuthDir(Unknown Source)
    at com.sun.apoc.daemon.apocd.Daemon.init(Unknown Source)
    at com.sun.apoc.daemon.apocd.Daemon.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.Daemon.main(Unknown Source)
[ Nov 17 14:36:08 Method or service exit timed out.  Killing contract 980 ]
[ Nov 17 14:36:08 Method "start" failed due to signal KILL ]

使用处于忙碌状态的客户端请求端口

Configuration Agent 使用 TCP/IP 套接字连接与桌面客户端应用程序进行通信。 默认情况下,这些连接都是通过端口 38900 建立的。

如果将 Configuration Agent 配置为使用端口 1234(此端口已由其他服务使用),则会生成以下错误消息。错误消息将记录在 Configuration Agent 日志中。要解决此问题,请使用 Configuration Agent 向导 (/usr/bin/apoc-config) 将代理端口设置更改为未使用的端口号。


Nov 17, 2005 2:50:59 PM com.sun.apoc.daemon.misc.APOCLogger config
CONFIG: Daemon configuration:
 MaxRequestSize = 4096
 DaemonAdminPort = 38901
 ThreadTimeToLive = 5
 DaemonChangeDetectionInterval = 10
 IdleThreadDetectionInterval = 15
 PROVIDER_URL =
 DataDir = /var/opt/apoc
 ApplyLocalPolicy = true
 ChangeDetectionInterval = 60
 MaxClientConnections = 50
 GarbageCollectionInterval = 10080
 InitialChangeDetectionDelay = 10
 TimeToLive = 10080
 ConnectionReadTimeout = 5000
 DaemonPort = 1234
 LogLevel = FINEST
 MaxClientThreads = 5


Nov 17, 2005 2:50:59 PM com.sun.apoc.daemon.misc.APOCLogger info
INFO: Daemon starting
Nov 17, 2005 2:50:59 PM com.sun.apoc.daemon.misc.APOCLogger fine
FINE: Garbage collection scheduled ( interval = 10080 minutes )
Nov 17, 2005 2:50:59 PM Daemon main
FINER: THROW
com.sun.apoc.daemon.misc.APOCException: java.net.BindException: Address already in use
    at com.sun.apoc.daemon.transport.ChannelManager.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.Daemon.run(Unknown Source)
    at com.sun.apoc.daemon.apocd.Daemon.main(Unknown Source)
Caused by: java.net.BindException: Address already in use
    at sun.nio.ch.Net.bind(Native Method)
    at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119)
    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52)

使用处于忙碌状态的管理端口

Configuration Agent 使用 TCP/IP 套接字连接与 Configuration Agent 控制器程序 (/usr/lib/apoc/apocd) 进行通信。默认情况下,这些连接都是通过端口 38901 建立的。

如果将 Configuration Agent 配置为使用端口 1234(此端口已由其他服务使用),Configuration Agent 日志中将出现以下错误消息。要解决此问题,请使用 Configuration Agent 向导 (/usr/bin/apoc-config ) 将管理端口设置更改为未使用的端口号。


ONFIG: Daemon configuration:
 MaxRequestSize = 4096
 DaemonAdminPort = 1234
 ThreadTimeToLive = 5
 DaemonChangeDetectionInterval = 10
 IdleThreadDetectionInterval = 15
 PROVIDER_URL =
 DataDir = /var/opt/apoc
 ApplyLocalPolicy = true
 ChangeDetectionInterval = 60
 MaxClientConnections = 50
 GarbageCollectionInterval = 10080
 InitialChangeDetectionDelay = 10
 TimeToLive = 10080
 ConnectionReadTimeout = 5000
 DaemonPort = 38900
 LogLevel = FINEST
 MaxClientThreads = 5


Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger info
INFO: Daemon starting
Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger fine
FINE: Garbage collection scheduled ( interval = 10080 minutes )
Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger fine
FINE: Client manager started
Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger fine
FINE: Channel manager started
Nov 17, 2005 2:55:11 PM Daemon main
FINER: THROW
com.sun.apoc.daemon.misc.APOCException: java.net.BindException: Address already in use
    at com.sun.apoc.daemon.admin.AdminManager.initChannel(Unknown Source)
    at com.sun.apoc.daemon.admin.AdminManager.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.Daemon.run(Unknown Source)
    at com.sun.apoc.daemon.apocd.Daemon.main(Unknown Source)
Caused by: java.net.BindException: Address already in use
    at sun.nio.ch.Net.bind(Native Method)
    at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119)
    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52)
    ... 4 more 

从正在运行的 Configuration Agent 获取策略时出现的问题

配置系统信息库规范缺少或无效

Configuration Agent 需要连接到有效的配置系统信息库,以便下载和缓存策略信息。如果未在代理配置中正确标识配置系统信息库(例如,使用了无效格式或未指定系统信息库),则当桌面客户端应用程序启动时,会在 Configuration Agent 日志中记录类似以下内容的错误消息。要解决此问题,请使用 Configuration Agent 向导 (/usr/bin/apoc-config ) 来标识要使用的配置系统信息库。


FINER: New client added
Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finer
FINER: CreateSession transaction started
Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finer
FINER: Creating new client session
Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finest
FINEST: Authenticating user geoffh
Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finest
FINEST: Authentication successful
Nov 18, 2005 1:59:23 PM PolicyBackend openPolicyBackend
FINER: THROW
com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.daemon.misc.APOCException: 
com.sun.apoc.spi.environment.InvalidParameterException: The parameter organisation 
PROVIDER_URL#protocol (null) is not valid, the value must be comprised in 
{ldaps,ldap,https,http,file}.
    at com.sun.apoc.daemon.apocd.PolicyBackend.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.HostPolicyBackend.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyBackend(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache$DataSource.openPolicyBackend(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache$DataSource.open(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache.createDataSources(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.CacheFactory.createNewCache(Unknown Source)
    at com.sun.apoc.daemon.apocd.CacheFactory.openCache(Unknown Source)
    at com.sun.apoc.daemon.apocd.Session.<init>(Unknown Source)
    at com.sun.apoc.daemon.transaction.CreateSessionTransaction.executeTransaction
(Unknown Source)
    at com.sun.apoc.daemon.transaction.Transaction.execute(Unknown Source)
    at com.sun.apoc.daemon.apocd.ClientEventHandler.handleEvent(Unknown Source)
    at com.sun.apoc.daemon.apocd.EventWorkerThread.run(Unknown Source)
Caused by: com.sun.apoc.daemon.misc.APOCException: 
 com.sun.apoc.spi.environment.InvalidParameterException:
 The parameter organisation PROVIDER_URL#protocol (null) is not valid, 
 the value must be comprised in {ldaps,ldap,https,http,file}.
    at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyMgr(Unknown Source)
    ... 14 more
Caused by: com.sun.apoc.spi.environment.InvalidParameterException: The parameter 
organisation PROVIDER_URL#protocol (null) is not valid, the value must be comprised in 
{ldaps,ldap,https,http,file}.
    at com.sun.apoc.spi.PolicyMgrFactoryImpl.createPolicyMgr(Unknown Source)
    ... 15 more
Nov 18, 2005 1:59:23 PM PolicyBackend openPolicyBackend

无法连接到策略系统信息库

Configuration Agent 需要连接到有效的配置系统信息库,以便下载和缓存策略信息。如果无法建立连接,则当桌面客户端应用程序启动时,会在 Configuration Agent 日志中记录类似以下内容的错误消息。在以下情况中,主机 sobuild 不存在、无法连接或无法通过端口 389 访问 LDAP 服务器。要解决此问题,请使用 Agent Configuration 向导 (/usr/bin/apoc-config) 确保正确标识了策略系统信息库,并在此基础上确保可以访问该策略系统信息库。例如,对于 LDAP 系统信息库,必须确保 LDAP 服务器正在运行、LDAP 服务器所在的计算机在网络上可用,并且指定的端口为 LDAP 服务器正在使用的端口。

如果尝试使用 SSL 连接来访问 LDAP 服务器,请确保与 Java 运行时环境(用于运行 Configuration Agent)关联的密钥库中包含合适的证书。有关 apoc-config 的详细信息,请参见 Configuration Agent 部分。


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

连接到未配置的策略系统信息库

要使 Configuration Agent 能够在策略系统信息库中找到策略数据,必须先正确配置策略系统信息库。如果指定了未配置或错误配置的策略系统信息库,则当桌面客户端应用程序启动时,会在 Configuration Agent 日志中记录类似以下内容的错误消息。要解决此问题,请参见


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)

我在 Configuration Agent 日志中看到一条关于“客户端最大连接数”的消息。这是什么意思?

由 Configuration Agent 启用的每个桌面客户端应用程序(gconfd、Mozilla 或 StarSuite)在运行时都会打开一个与 Configuration Agent 的连接。这些连接的限制是在代理配置中指定的。默认的连接数限制为 50。如果一台计算机上有多个用户,则可能需要增加此限制的值,方法是使用 Configuration Agent 向导 (/usr/bin/apoc-config) 更改“最大客户端连接数”设置。如果 Configuration Agent 达到最大连接数,则会在 Configuration Agent 日志中记录与以下内容类似的错误消息:


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.

我使用 Desktop Manager 修改了一些策略,但是在我的客户端计算机上看不到这些修改

设计 Configuration Agent 时的假设之一是,Desktop Manager 所创建的策略数据是相对静态的(即,不会发生频繁更改)。此假设导致生成了一个步骤,即代理间歇性地参考策略系统信息库,以查看是否进行过修改。默认情况下,代理每小时为所有正在运行的桌面应用程序检查一次系统信息库。因此,使用 Desktop Manager 进行更改之后,至多需要等一小时,正在运行的桌面应用程序即会收到更改通知。如果需要,可以使用 Agent Configuration 向导 (/usr/bin/apoc-config ) 更改“常规检测间隔”的值,以提高系统信息库检查频率。另外,也可以强制 Configuration Agent 为所有连接的应用程序刷新策略数据,方法是以超级用户身份登录,然后执行 /usr/lib/apoc/apocd change-detect 命令。