test

Sun Desktop Manager 1.0 설치 설명서

3장 클라이언트 구성 요소

Desktop Manager에서 구성 데이터에 액세스하려면 데스크탑 클라이언트에 Java Desktop System Configuration Agent가 필요합니다. Configuration Agent는 원격 구성 데이터 리포지토리 및 어댑터와 통신하고 데이터를 특정 구성 시스템에 통합합니다. 현재 지원되는 구성 시스템은 GConf, Java 기본 설정, Mozilla 기본 설정 및 StarSuite 레지스트리입니다.

Configuration Agent 버전은 Solaris 10 운영 체제와 함께 제공됩니다. 그러나, Desktop Manager에는 최신 버전의 도구가 필요합니다. 이 최신 버전은 Desktop Manager 클라이언트 구성 요소 및 관련 패치 설치의 일부로 설치됩니다.

Desktop Manager 클라이언트 구성 요소를 설치하려면 다음 작업을 수행합니다.

  1. Desktop Manager zip 아카이브를 다운로드한 다음 임시 디렉토리에 압축을 풉니다.


    # unzip SunDesktopMgr-1.0.zip

  2. 권장 패치를 설치합니다.

    이러한 패치는 SunDesktopMgr-1.0/<platform>/client/Patches 디렉토리에 제공됩니다. 각 패치와 함께 제공된 설치 지침을 따릅니다.

  3. 수퍼유저(루트)로 다음을 통해 설치 스크립트를 실행합니다. 


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

Configuration Agent

Configuration Agent는 다음 표에 나열된 여러 패키지 중 일부입니다.

Solaris 패키지 이름 

설명 

SUNWapbas 

Configuration Shared 라이브러리 

SUNWapmsc 

Configuration Agent 기타 파일 

SUNWapoc 

Configuration Agent 

SUNWapdc 

Configuration Agent 마법사 

이 패키지를 설치할 때 이 API에 필요한 파일이 설치됩니다. 패키지는 수동으로 설치하거나 Java Desktop System 설치를 통해 설치할 수 있습니다. 설치한 후에는 시스템에서 Configuration Agent를 구성하여 활성화해야 합니다.

주 –

Configuration Agent 패키지는 Java Desktop System 설치에 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 서버 작업이 증가하므로설정 값을 변경할 때는 주의해야 합니다. 예를 들어, 초기 배포 단계에서 클라이언트 응용 프로그램에 대한 원격 구성의 영향을 테스트하기 위해 이 값을 1분으로 설정했다가 테스트가 끝나면 다시 이 설정을 원래 값으로 되돌릴 수 있습니다.

작동 설정

그림 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를 수동으로 다시 시작하려면 관련된 클라이언트 응용 프로그램이 실행되고 있지 않은지 확인하고 루트로 로그인하여 /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" 설정을 변경하는 경우 root로 로그인한 다음 /usr/lib/apoc/apocd reload 명령을 입력하여 Configuration Agent를 다시 로드해야 합니다.

    이러한 방법으로 배포되는 로컬 정책은 다음 Configuration Agent 변경 감지 주기 중에 클라이언트에서 사용할 수 있게 됩니다.

Configuration Agent 자동 재시작

오류가 발생할 경우 Configuration Agent가 자동으로 다시 시작됩니다. smf(5)(service management facility)가 이 의사 결정을 담당합니다. 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 방법을 사용하려면 데스크탑에서 커버로스 자격 증명을 획득해야 합니다. 커버로스 자격 증명 획득과 사용자 로그인을 통합하려면 Java Desktop System 호스트에서 pam_krb5 모듈을 설치 및 구성해야 합니다.

gdm을 사용하여 커버로스와 사용자 로그인을 통합할 수도 있습니다. 예를 들어 다음 /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

이런 방식으로 커버로스와 사용자 로그인을 통합하는 경우에는 화면 보호기의 커버로스 지원을 활성화해야 합니다. 예를 들어, 다음 /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 어댑터는 다른 기존 구현에 대한 래퍼로 사용되어야 하는 기본 설정 API 구현으로 제공됩니다(예: JRE와 함께 제공된 기본 파일 기반 시스템). 기본 설정 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 어댑터를 제거하면 기본 설정 API를 사용하여 Java 응용 프로그램을 시작하기 위해 작성된 시작 스크립트가 더 이상 사용되지 않습니다. 일부 필요한 클래스를 더 이상 사용할 수 없으므로 Java 호출에 실패합니다.

어댑터 문제 해결

해당 응용 프로그램에서 중앙 구성 데이터가 표시되지 않는 문제의 대부분은 모든 어댑터에서 데이터를 검색하는 데 사용되는 공통 메커니즘인 Configuration Agent로부터 비롯됩니다.

중앙 구성 변경이 지정된 설정 또는 그룹에 적용되지 않으면, 사용자는 응용 프로그램에서 주로 제품의 옵션 또는 기본 설정 대화 상자를 사용하여 해당 설정 값을 명시적으로 설정합니다. 이 경우, 중앙 설정이 보호됨으로 정의되어 있지 않으면(즉, 관리자가 해당 값을 강제로 적용하여 사용자가 수정할 수 없음) 사용자 기본 설정이 Desktop Manager를 사용하여 설정한 값보다 우선합니다.

Configuration Agent 문제 해결

이 절에서는 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을 설치한 경우 다음에 수행할 작업은 무엇입니까?

Configuration Agent는 기본적으로 비활성화되어 있고 구성되어 있지 않습니다. Configuration Agent를 사용하려면 최소 수준 이상으로 구성하여 활성화해야 합니다. 이 단계를 완료하면 데스크탑 클라이언트 응용 프로그램이 자동으로 시작되고 다음 번에 시작될 때부터 사용자가 제공한 정책이 사용됩니다.

Configuration Agent를 구성하려면 어떻게 해야 합니까?

Configuration Agent를 올바르게 구성하려면 Configuration Agent 마법사를 사용합니다. 루트로 /usr/bin/apoc-config 명령을 실행하여 마법사를 시작할 수 있습니다. 마법사는 에이전트를 올바르게 구성하는 데 필요한 단계를 안내합니다. 대부분의 경우 마법사를 완료하는 데 절대적으로 필요한 유일한 정보는 정책 리포지토리의 위치입니다.

구성 파일을 수동으로 편집하여 Configuration Agent를 구성할 수도 있습니다. 수동으로 편집하여 구성하면 에이전트가 잘못 구성되기 쉬우므로 이 방법은 사용하지 않는 것이 좋습니다. 또한, Configuration Agent 마법사에는 에이전트를 다시 시작하거나 다시 로드하기 위해 특정 구성 변경이 필요한지 여부를 결정하는 추가 논리가 포함되어 있습니다.

Configuration Agent를 활성화하려면 어떻게 해야 합니까?

다음과 같은 세 가지 기법을 사용하여 에이전트를 활성화할 수 있습니다.

  1. Configuration Agent 마법사( /usr/bin/apoc-config)를 사용하여 에이전트 상태를 활성으로 설정합니다.

  2. Configuration Agent 컨트롤러 프로그램(/usr/lib/apoc/apocd)을 사용하여 루트로 다음을 실행합니다. 


    /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입니다.

Configuration Agent는 데이터 디렉토리가 액세스할 수 없는 위치(즉, /dev/null/cant/write/here)로 설정되어 있는 경우 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을 통해 설정됩니다.

다른 서비스에서 이미 사용 중인 포트 1234를 사용하도록 Configuration Agent를 구성할 경우 다음과 같은 오류 메시지가 표시됩니다. 오류 메시지는 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을 통해 설정됩니다.

다른 서비스에서 이미 사용 중인 포트 1234를 사용하도록 Configuration Agent를 구성할 경우 다음과 같은 오류 메시지가 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 서버에 액세스할 수 없습니다. 이 문제를 해결하려면 에이전트 구성 마법사(/usr/bin/apoc-config)를 사용하여 정책 리포지토리를 올바르게 식별했는지 확인하고, 올바르게 식별한 경우 정책 리포지토리에 액세스 가능한지 확인합니다. 예를 들어, LDAP 리포지토리의 경우 LDAP 서버가 실행 중이고 LDAP 서버를 호스트하는 시스템이 네트워크에서 사용 가능하며, 지정한 포트가 LDAP 서버에 사용 중인지 확인해야 합니다.

SSL 연결을 사용하여 LDAP 서버에 액세스할 경우 Configuration Agent를 실행하는 데 사용되는 Java 런타임 환경과 연관된 키 저장소에서 적절한 인증서를 사용할 수 있는지 확인합니다. 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 로그에 "maximum number of client connections" 관련 메시지가 표시됩니다. 이 메시지의 의미는 무엇입니까?

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를 사용하여 일부 정책을 수정했지만 수정된 내용이 내 클라이언트 시스템에 표시되지 않습니다.

Desktop Manager에서 만든 정책 데이터는 상대적으로 정적이기 때문에 자주 변경할 수 없다는 가정하에 Configuration Agent를 설계했습니다. 이 가정에 따라 에이전트는 정책 리포지토리를 자주 참조하여 수정 사항이 있는지를 확인합니다. 기본적으로 에이전트는 실행 중인 모든 데스크탑 응용 프로그램에서 한 시간에 한 번씩 리포지토리를 확인합니다. 따라서, Desktop Manager를 사용하여 변경한 경우 실행 중인 데스크탑 응용 프로그램에서 변경 사항을 알려면 최대 1시간까지 기다려야 합니다. 원하는 경우 Agent Configuration 마법사(/usr/bin/apoc-config)를 사용하여 "일반 감지 간격" 값을 늘려 리포지토리 확인 빈도를 늘릴 수도 있습니다. 또는 수퍼유저로 /usr/lib/apoc/apocd change-detect 명령을 실행하여 Configuration Agent에서 연결된 모든 응용 프로그램에 대한 정책 데이터를 강제로 새로 고칠 수 있습니다.