test

Sun Desktop Manager 1.0 安装指南

第 3 章 客户端组件

要从 Desktop Manager 访问配置数据，桌面客户端需要安装 Java Desktop System Configuration Agent。Configuration Agent 可以与远程配置数据系统信息库和适配器进行通信，还能将数据集成到特定的配置系统中。当前支持的配置系统为： GConf、Java Preferences、Mozilla Preferences 和 StarSuite Registry。

Solaris 10 操作系统随附有 Configuration Agent 的一个版本。 但是，Desktop Manager 需要安装该工具的较新版本。此较新版本将在安装 Desktop Manager 客户端组件及相关修补程序时一起安装。

安装 Desktop Manager 客户端组件：

  1. 下载 Desktop Manager 的 Zip 归档文件，并将其内容解压缩到临时目录中。


    # unzip SunDesktopMgr-1.0.zip

  2. 安装建议的修补程序。

    在 SunDesktopMgr-1.0/<platform>/client/Patches 目录中提供了这些修补程序。请按照每个修补程序的安装说明进行操作。

  3. 以超级用户 (root) 身份登录，然后通过以下命令执行安装脚本：


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

Configuration Agent

Configuration Agent 是多个不同软件包之一，下表列出了这些软件包：

Solaris 软件包名称 

描述 

SUNWapbas 

配置共享库 

SUNWapmsc 

Configuration Agent 的其他文件 

SUNWapoc 

Configuration Agent 

SUNWapdc 

Configuration Agent 向导 

安装这些软件包时，将安装此 API 需要的所有文件。可以手动安装这些软件包，也可以通过 Java Desktop System 安装来完成。安装完成之后，必须在系统上配置并启用 Configuration Agent。

注 –

在 Java Desktop System 安装中，Configuration Agent 软件包将作为 Solaris 的一部分进行安装。但是，Desktop Manager 会在安装过程中对这些文件进行修补，以便提供正确的功能级别。

要访问远程配置数据，Configuration Agent 需要某些最基本的引导信息，例如 LDAP 服务器的主机名和端口。这些信息保存在一组属性文件（如 policymgr.properties、apocd.properties 和 os.properties）中。这些文件存储在本地 /etc/apoc 目录中。可以手动编辑这些属性文件（请参见附录 A，配置参数），也可以使用 Configuration Agent 的配置向导。

该配置向导提供了一个图形用户界面，可以引导您完成 Configuration Agent 的必要设置。对于该向导的每个页面，都存在一个相应的帮助屏幕。您可以通过 /usr/bin/apoc-config 脚本以超级用户 (root) 的身份启动该向导。

注 –

也可以启动该向导而不启动图形界面。例如，通过执行 /usr/bin/apoc-config -nodisplay 在控制台模式下启动该向导。

引导信息

图 3–1 Configuration Agent，配置系统信息库

配置系统信息库和状态

注 –

在括号中指明了关联的属性文件关键字（在适当的位置）。

图 3–2 Configuration Agent, LDAP 层次结构和基于文件的存储

LDAP 层次结构和基于文件的存储

注 –

图 3–2 中的屏幕将随着在前一个屏幕中所选的上下文类型而变化。如果选择了 LDAP 或混合式上下文类型，则必须提供服务器标识符、服务器端口和后缀。如果选择了基于文件或混合式上下文类型，则必须提供配置设置 URL。

图 3–3 Configuration Agent，验证机制

验证

端口设置

Configuration Agent 使用以下两个端口：

图 3–4 Configuration Agent，端口设置

Configuration Agent，端口设置

更改检测间隔

Configuration Agent 使用以下两种间隔定期检查配置数据中的更改：

可以使用常规检测间隔来调整远程配置数据更改至客户端应用程序的传播。为此设置指定的值表示最长经过多少分钟后，远程更改才反映在客户端应用程序中。

值越小，Configuration Agent 和 LDAP 服务器活动就越多。因此，调整此设置的值时应谨慎。例如，在初始部署阶段，可以将该值设置为一分钟，这样就可以测试远程配置对客户端应用程序的影响。完成测试后，请将此设置还原为初始值。

操作设置

图 3–5 Configuration Agent，数据目录

Configuration Agent，数据目录

可以配置以下设置：

图 3–6 Configuration Agent，请求处理和日志记录

Configuration Agent，请求处理和日志记录

注 –

大多数操作设置（“数据目录”和“连接超时”设置除外）也可以通过 LDAP 服务器中存储的相应策略进行集中维护。如果要使用此功能，请不要通过向导更改相应的设置。相反，应使用 Desktop Manager 中的 Configuration Agent 策略来集中指定操作设置。

应用代理设置

已通过 Desktop Manager 存储在 LDAP 服务器中的操作设置（“数据目录”和“连接超时”除外）将在代理配置的下一个更改检测周期自动生效（请参见 DaemonChangeDetectionInterval）。

图 3–7 Configuration Agent，“汇总”页

摘要页面

在本地更改的所有其他设置均需要重新装入 Configuration Agent，或者重新启动 Configuration Agent。如果使用配置向导，将自动执行重新装入和重新启动操作。

注 –

要手动重新启动 Configuration Agent，请确保未运行任何相关的客户端应用程序，然后以 root 身份登录，并键入命令 /usr/lib/apoc/apocd restart。

其他代理设置

注 –

在配置向导中未提供以下设置。

使用本地策略

可以配置 Configuration Agent 来应用部署于本地的策略 （替代全局策略或作为其补充） 中的设置。可以使用以下步骤部署此类本地策略：

Procedure部署本地策略

步骤

  1. 使用 Desktop Manager 创建具有所需策略设置的配置文件。

  2. 使用 Desktop Manager 将配置文件导出为一个 Zip 文件。

  3. 在客户端主机上，创建 ${DataDir}/Policies/profiles/PROFILE_REPOSITORY_default 目录（如果此目录尚未存在）。

    ${DataDir} 与 Configuration Agent 数据目录的值（默认值为 /var/opt/apoc）相对应。

  4. 将先前导出的 Zip 文件复制到 ${DataDir}/Policies/profiles/PROFILE_REPOSITORY_default 中。

  5. 确保将 Configuration Agent 配置为应用可用的本地策略（有关详细信息，请参见其他代理设置）。

    注 –

    如果更改了 Configuration Agent 的 "ApplyLocalPolicy" 设置，则需要重新加载 Configuration Agent（方法是以 root 身份登录，然后键入命令 /usr/lib/apoc/apocd reload）。

    在下一个 Configuration Agent 更改检测周期中，所有以此方式部署的本地策略都将可用于客户端。

自动重新启动 Configuration Agent

如果失败，Configuration Agent 将自动重新启动。服务管理工具 ( smf(5) ) 负责作出此项决策。如果服务管理工具认为不应该重新启动（例如，如果失败次数太多），则会将 Configuration Agent 置于维护模式。

如果无法重新启动 Configuration Agent，则应暂时禁用此代理（方法是以 root 身份登录，然后执行命令 /usr/lib/apoc/apocd disable），纠正导致代理失败的所有问题，然后通过执行命令 /usr/lib/apoc/apocd enable 重新启用代理。

数据访问/用户验证

Configuration Agent 将基于桌面用户的登录 ID 从 LDAP 服务器中检索信息。组织映射文件中的 User/UniqueIdAttribute 设置会将登录 ID 映射到 LDAP 服务器中的用户元素。Configuration Agent 还将检索有关主机的信息，例如主机的名称或 IP 地址。这些信息将通过组织映射文件中的 Host/UniqueIdAttribute 设置映射到 LDAP 服务器中的主机元素。有关组织映射的详细信息，请参见附录 C，组织映射。

有两种方式访问 LDAP 服务器：匿名方式或使用 GSSAPI。对于匿名访问，无需在桌面上执行任何操作。对于 GSSAPI 方式，必须在桌面上获得 Kerberos 凭证。要将 Kerberos 凭证的获得与用户登录集成在一起，必须在 Java Desktop System 主机上安装和配置 pam_krb5 模块。

您可以使用 gdm 将 Kerberos 同用户登录集成在一起，例如使用以下 /etc/pam.d/gdm 文件：


#%PAM-1.0
auth   required    pam_unix2.so  nullok #set_secrpc
auth   optional  pam_krb5.so use_first_pass missing_keytab_ok ccache=SAFE putenv_direct
account required    pam_unix2.so 
password required    pam_unix2.so  #strict=false
session required    pam_unix2.so  # trace or none
session required    pam_devperm.so 
session optional    pam_console.so

如果您以这种方式将 Kerberos 同用户登录集成在一起，则您应启用屏幕保护程序的 Kerberos 支持。例如，使用以下 /etc/pam.d/xscreensaver 文件：


auth required pamkrb5.so use_first_pass missing_keytab_ok 
ccache=SAFE putenv_direct

适配器

应用程序适配器是 Desktop Manager 所支持的配置系统的扩展。适配器允许各种应用程序使用集中配置数据（具体取决于配置系统）。支持的配置系统包括：

此外还提供了桌面定义适配器，它向用户桌面中添加了桌面启动器、菜单项和启动程序。

GConf 适配器

GConf 适配器是用于 Solaris 的 SUNWapoc-adapter-gconf 软件包的一部分。从相应的 packageAdapter 安装适配器时，将更新 /etc/gconf/2/path 中的 GConf 数据源路径，以包括 Desktop Manager 源。适配器提供两种数据源，它们为：

GConf 适配器配置

GConf 适配器是作为安装的一部分进行配置的，但其操作取决于在 GConf 路径文件 (/etc/GConf/2/path) 中是否包含表示强制性集中设置和默认设置的两个数据源。安装完系统之后，即使此路径文件中包含正确的信息（使 GConf 能够按预期那样使用集中设置），管理员也要确保以 "apoc" 为前缀的数据源仍存在于该文件中，以便在需要时可以修改此路径以包含其他自定义数据源。此外，还要确保表示强制性集中设置的数据源位于本地强制性设置和用户设置之间，而表示默认集中设置的数据源位于用户设置和本地默认设置之间。

Java Preferences 适配器

Java Preferences 适配器是用于 Solaris 的 SUNWapcj 软件包的一部分。

Java Preferences 适配器配置

Java Preferences 适配器是作为 Preferences API 实现提供的，此实现必须用作其他现有实现（例如随 JRE 一起提供的默认基于文件的系统）的包装器。要在使用 Preferences API 的 Java 应用程序中使用集中配置，必须为该应用程序编写启动脚本（使用 /usr/lib/apoc/apocjlaunch 脚本作为帮助程序）。此脚本需要定义几个环境变量，然后在其末尾添加 apocjlaunch 脚本（此脚本可在必要的环境中启动 Java 应用程序）。必须设置的环境变量包括：

可以设置的其他可选环境变量包括：

Mozilla 适配器

Mozilla 适配器是用于 Solaris 的 SUNWmozapoc-adapter 软件包的一部分。

Mozilla 适配器配置

Mozilla 适配器是作为此产品安装的一部分进行安装的，且不需要其他任何配置。

StarSuite 适配器

StarSuite 适配器包含在标准的 StarSuite 安装中，并且允许您访问配置文件配置数据，而无需进行任何特殊的修改。

StarSuite 适配器配置

StarSuite 适配器是作为此产品安装的一部分进行安装的，且不需要其他任何配置。

桌面定义适配器

桌面定义适配器由以下软件包组成：

软件包名称 

描述 

SUNWapleg 

配置访问二进制文件 

SUNWardsa 

桌面定义适配器 

SUNWardsa-misc 

适配器的系统集成 

这些软件包将在安装 Desktop Manager 客户端组件时进行安装，且不需要任何其他设置。

桌面定义适配器配置

桌面定义适配器由安装进程配置（以便在用户登录时使用），且不需要任何其他设置。

删除适配器

删除这些产品时会同时删除 Mozilla 适配器和 StarSuite 适配器。通过删除安装部分所提到的软件包，可以使用相应的软件包管理系统工具来删除 GConf、Java Preferences 和桌面定义适配器。

删除 Java Preferences 适配器后，不应再使用为启动 Java 应用程序（该程序使用 Preferences API）而编写的启动脚本。这些脚本中的 Java 调用将失败，因为缺少了某些必需的类。

适配器疑难解答

导致在相应的应用程序中看不到集中配置数据的大多数问题都可能来源于 Configuration Agent，因为它是所有适配器用于检索数据的通用机制。

如果对于给定设置（或其中的组），对集中配置所做的更改看上去未能生效，则可能是因为用户已经在应用程序中为此设置明确设置了一个值（通常使用产品的“选项”或“首选项”对话框）。在这种情况下，除非将集中设置定义为受保护（即管理员强制指定一个值，且不允许用户修改），否则用户首选项将优先于使用 Desktop Manager 设置的值。

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 命令。