'서비스관리'에 해당되는 글 2건

  1. 2013.10.18 Windows 7 ActiveX Installer 서비스 관리 (1)
  2. 2009.02.17 솔라리스 서비스 관리 설비 - 서비스 개발자를 위한 소개
2013. 10. 18. 18:09

Windows 7 ActiveX Installer 서비스 관리

적용 대상: Windows 7, Windows Server 2008 R2

AXIS(ActiveX Installer 서비스)는 IT 전문가가 그룹 정책을 사용하여 조직의 컴퓨터에 대한 ActiveX® 컨트롤 배포를 관리할 수 있도록 하는 서비스입니다. ActiveX 컨트롤은 자체 등록 COM 개체로, 이를 사용하면 한층 강화된 대화식 사용자 환경의 Internet Explorer를 경험할 수 있습니다. ActiveX 컨트롤은 주로 .cab 파일로 배포됩니다. 기본적으로 표준 사용자 계정에는 ActiveX 컨트롤을 설치할 수 있는 권한이 없습니다. 이 문서를 사용하여 Windows® 7에서 ActiveX Installer 서비스를 구현하고 관리하는 방법을 알아볼 수 있습니다.

note참고
ActiveX Installer 서비스는 Windows Server® 2008 R2에 포함되지 않습니다. Windows Server 2008 R2를 실행하는 컴퓨터의 웹 브라우저에서 ActiveX 컨트롤을 설치하려 하면 노란색 알림 표시줄과 게시자를 알 수 없다는 경고 메시지가 있는 사용자 계정 컨트롤 대화 상자가 나타납니다.

ActiveX Installer 서비스 시작

Windows 7을 실행하는 컴퓨터에서는 ActiveX 컨트롤러 서비스가 기본적으로 설정 및 구성되므로 ActiveX 컨트롤을 제공하는 웹 사이트에서 요청할 경우 해당 서비스가 시작됩니다.

ActiveX Installer 서비스 구성

ActiveX Installer 서비스에 사용되는 옵션과 사이트는 그룹 정책 설정을 통해 구성되며, 그룹 정책 설정은 GPMC(그룹 정책 관리 콘솔)나 로컬 그룹 정책 편집기를 사용하여 수정할 수 있습니다. ActiveX Installer 서비스에 대한 정책 설정은 ActiveX 컨트롤용 승인된 설치 사이트와 신뢰할 수 있는 영역의 사이트에 대한 ActiveX 설치 정책의 두 가지가 있습니다. ActiveX 컨트롤용 승인된 설치 사이트 정책 설정은 ActiveX Installer 서비스에서 ActiveX 컨트롤을 설치할 수 있는지 여부를 확인하는 데 사용하는 승인된 설치 사이트 목록으로 이루어져 있습니다. 신뢰할 수 있는 영역의 사이트에 대한 ActiveX 설치 정책 정책 설정은 신뢰할 수 있는 사이트 영역을 사용하여 ActiveX 컨트롤을 설치하는 방법을 나타냅니다. 웹 사이트가 ActiveX 컨트롤을 설치하려 하면 ActiveX Installer 서비스가 웹 사이트의 URL이 승인된 설치 사이트 목록이나 신뢰할 수 있는 사이트 영역에 포함되어 있는지 확인합니다. 사이트가 둘 중 하나에 포함되어 있는 경우 ActiveX Installer 서비스는 사이트가 정책에 정의된 요구 사항에 맞는지 확인합니다. 사이트와 ActiveX 컨트롤이 정책 설정의 요구 사항에 맞으면 컨트롤이 설치됩니다.

Important중요
그룹 정책 설정을 수정하려면 원격 컴퓨터에서 Administrators 그룹 구성원인 계정으로 로그온해야 합니다.

ActiveX Installer 서비스에 대해 승인된 설치 정책 설정을 구성하려면

  1. 시작을 클릭하고 프로그램 및 파일 검색 상자에 gpedit.msc를 입력한 다음 Enter 키를 눌러 로컬 그룹 정책 편집기를 엽니다.

  2. 사용자 계정 컨트롤 대화 상자가 나타나면 원하는 작업이 표시되었는지 확인한 다음 를 클릭합니다.

  3. 로컬 컴퓨터 정책\컴퓨터 구성\관리 템플릿\Windows 구성 요소 아래 콘솔 트리에서 ActiveX Installer 서비스를 클릭합니다.

  4. 세부 정보 창에서 ActiveX 컨트롤용 승인된 설치 사이트를 마우스 오른쪽 단추로 클릭하고 편집을 클릭하여 정책 설정을 엽니다.

  5. ActiveX 컨트롤용 승인된 설치 사이트 대화 상자에서 사용을 클릭하고 옵션에서 표시를 클릭합니다.

  6. 내용 표시 대화 상자의 값 이름 텍스트 상자에 ActiveX 컨트롤 설치를 허용할 URL의 이름을 입력하고 ActiveX Installer 서비스 호스트 URL 설정의 값을 입력합니다. URL을 추가할 때, ActiveX Installer 서비스의 설정을 자세히 설명하는 값을 쉼표로 구분하여 지정할 수 있습니다. 다음 4개의 값을 구성할 수 있습니다.

    • 신뢰할 수 있는 서명이 있는 ActiveX 컨트롤 설치. 값에 대한 자세한 내용은 이 문서에서 표 1: 신뢰할 수 있는 서명이 있는 ActiveX 컨트롤 설치에 대한 값을 참조하십시오.

    • 서명된 ActiveX 컨트롤 설치. 값에 대한 자세한 내용은 이 문서에서 표 2: 서명된 ActiveX 컨트롤 설치에 대한 값을 참조하십시오.

    • 서명되지 않은 ActiveX 컨트롤 설치. 값에 대한 자세한 내용은 이 문서에서 표 3: 서명되지 않은 ActiveX 컨트롤 설치에 대한 값을 참조하십시오.

    • HTTPS 오류 예외. 값에 대한 자세한 내용은 이 문서에서 표 2: 서명된 ActiveX 컨트롤 설치에 대한 값을 참조하십시오.

    note참고
    사용할 값을 결정할 때는 샘플 구성 섹션을 참조하십시오.

  7. URL 추가를 마쳤으면 확인을 두 번 클릭하여 변경 내용을 적용합니다.

신뢰할 수 있는 사이트 영역에 대한 ActiveX 설치 정책 구성

조직에서 신뢰하는 웹 사이트를 신뢰할 수 있는 사이트 영역에 추가하여 관리자의 승인 없이 ActiveX 컨트롤 설치가 가능하도록 할 수 있습니다. 신뢰할 수 있는 사이트 영역의 사이트는 와일드카드 문자와 하위 도메인을 조합하여 지정할 수 있습니다. 예를 들어https://*.contoso.com이라는 웹 사이트를 신뢰할 수 있는 사이트 영역에 추가하고 신뢰할 수 있는 영역의 사이트에 대한 ActiveX 설치 정책 정책 설정을 구성하면 contoso.com 도메인의 모든 웹 사이트가 조직의 컴퓨터에 ActiveX 컨트롤을 설치할 수 있게 됩니다. 이러한 기능은 조직에서 신뢰하는 포리스트가 여러 개 있는 경우에 유용할 수 있습니다.

이 정책 설정을 사용하려면 컴퓨터 구성\관리 템플릿\Win dows 구성 요소\Internet Explorer 에서 보안 영역: 시스템 설정만 사용 정책 설정을 사용하도록 설정하고, 컴퓨터 구성\관리 템플릿\Internet Explorer\인터넷 제어판\보안 페이지의 영역에 대한 사이트 할당 목록 정책 설정에서 그룹 정책을 사용해 배포할 신뢰할 수 있는 사이트의 목록을 구성해야 합니다.

security보안 참고
이 기능을 사용하여 신뢰할 수 있는 사이트의 ActiveX 컨트롤 설치를 허용하는 경우 표준 사용자가 임의의 ActiveX 컨트롤을 설치하지 않도록 하려면 영역에 대한 사이트 할당 목록 그룹 정책 설정의 신뢰할 수 있는 사이트 목록에 항목을 하나 이상 추가해야 합니다.

와일드카드 문자와 하위 도메인의 조합을 사용하면 표준 사용자가 와일드카드 문자를 사용한 하위 도메인에 있는 모든 서버로부터 프로그램과 응용 프로그램을 설치할 수 있습니다. 여기에는 맬웨어나 잠재적으로 사용자 동의 없이 설치되는 소프트웨어가 포함될 수 있습니다. 따라서 이 기능을 설정하기 전에 하위 도메인의 모든 서버가 완전히 트러스트되었는지 확인해야 합니다.

신뢰할 수 있는 영역의 사이트에 대한 ActiveX 설치 정책을 구성하려면

  1. 시작을 클릭하고 프로그램 및 파일 검색 상자에 gpedit.msc를 입력한 다음 Enter 키를 눌러 로컬 그룹 정책 편집기를 엽니다.

  2. 로컬 컴퓨터 정책\컴퓨터 구성\관리 템플릿\Windows 구성 요소 아래 콘솔 트리에서 ActiveX Installer 서비스를 클릭합니다.

  3. 세부 정보 창에서 신뢰할 수 있는 영역의 사이트에 대한 ActiveX 설치 정책을 마우스 오른쪽 단추로 클릭하고 편집을 클릭하여 정책 설정을 엽니다.

  4. 신뢰할 수 있는 영역의 사이트에 대한 ActiveX 설치 정책 대화 상자에서 사용을 클릭합니다.

  5. 옵션에서 설치를 시도하는 ActiveX 컨트롤의 유형에 따라 신뢰할 수 있는 사이트 영역의 사이트에 적용할 정책 설정을 선택합니다.

    • 사용자의 설치 승인 없이 컨트롤을 자동으로 설치하려면 자동으로 설치를 선택합니다.

    • 사용자가 컨트롤 설치 여부를 결정하도록 하려면 사용자에게 확인을 선택합니다.

    • 조건에 일치하는 컨트롤이 설치되지 않도록 하려면 설치 안 함을 선택합니다.

    다음과 컨트롤 유형에 대해 정책을 구성할 수 있습니다.

    • 신뢰할 수 있는 게시자가 서명한 ActiveX 컨트롤

    • 서명된 ActiveX 컨트롤

    • 서명 안 된 ActiveX 컨트롤

  6. 신뢰할 수 있는 사이트 영역의 사이트가 서버 유효성 검사(HTTPS)를 지원하는 경우 인증서 오류가 발생할 때 신뢰할 수 있는 사이트에 대한 연결을 제어하는 정책을 구성할 수도 있습니다. 기본적으로 모든 HTTPS 연결은 모든 유효성 검사 조건을 통과하는 서버 인증서를 제공해야 합니다. 신뢰할 수 있는 사이트의 유효성을 완전히 신뢰하고 오류 발생 이유가 확실한 경우에만 예외를 지정해야 합니다.

  7. 확인을 클릭하여 변경 내용을 적용합니다.

게시자를 신뢰할 수 있는 ActiveX 컨트롤 설치

이 설정은 컴퓨터 또는 엔터프라이즈의 신뢰할 수 있는 게시자 저장소에 있는 인증서로 서명된 ActiveX를 설치할 때의 서비스 동작을 설명합니다. 표 1에서는 이 설정의 가능한 값을 보여 줍니다.

표 1: 신뢰할 수 있는 서명이 있는 ActiveX 컨트롤 설치에 대한 값

설명

0

사용자가 신뢰할 수 있는 서명이 있는 ActiveX 컨트롤을 설치할 수 없게 합니다.

1

신뢰할 수 있는 서명이 있는 ActiveX 컨트롤을 설치하기 전에 사용자에게 확인 메시지를 표시합니다.

2

사용자에게 알리지 않고 신뢰할 수 있는 서명이 있는 ActiveX 컨트롤을 설치합니다. 이 값은 기본값입니다.

서명된 ActiveX 컨트롤 설치

이 설정은 컴퓨터 또는 엔터프라이즈의 신뢰할 수 있는 게시자 저장소에 없는 인증서로 서명된 ActiveX를 설치할 때의 서비스 동작을 결정합니다.

표 2: 서명된 ActiveX 컨트롤 설치에 대한 값

설명

0

사용자가 서명된 ActiveX 컨트롤을 설치할 수 없게 합니다.

1

서명된 ActiveX 컨트롤을 설치하기 전에 사용자에게 확인 메시지를 표시합니다. 이 값은 기본값입니다.

2

사용자에게 알리지 않고 서명된 ActiveX 컨트롤을 설치합니다.

서명되지 않은 ActiveX 컨트롤 설치

이 설정은 서명되지 않은 ActiveX 컨트롤을 설치할 때의 서비스 동작을 결정합니다. 표 3에서는 이 설정의 가능한 값을 보여 줍니다.

표 3: 서명되지 않은 ActiveX 컨트롤 설치에 대한 값

설명

0

사용자가 서명 안 된 ActiveX 컨트롤을 설치할 수 없게 합니다. 이 값은 기본값입니다.

1

사용자에게 알리지 않고 서명되지 않은 ActiveX 컨트롤을 설치합니다.

HTTPS 오류 예외

이 값은 ActiveX Installer 서비스가 HTTPS 연결에서 감지된 오류를 처리하는 방법을 제어합니다. 기본적으로 ActiveX Installer 서비스는 오류가 발견된 경우에 ActiveX 컨트롤 설치를 차단합니다.

표 4: HTTPS 오류 예외에 대한 값

설명

0

연결이 모든 확인 검사를 통과해야 하도록 지정합니다.

0x00000100

ActiveX Installer 서비스에서 알 수 없는 CA(인증 기관)로 인한 오류를 무시하도록 지정합니다.

0x00001000

ActiveX Installer 서비스에서 잘못된 CN(일반 이름)으로 인한 오류를 무시하도록 지정합니다. CN은 개체 DN(고유 이름)을 만들 때 사용하는 명명 특성입니다.

0x00002000

ActiveX Installer 서비스에서 인증서의 날짜로 인한 오류를 무시하도록 지정합니다.

0x00000200

ActiveX Installer 서비스에서 부적절한 인증서 사용으로 인한 오류를 무시하도록 지정합니다.

note참고
OR (|) 문자를 사용하여 ActiveX Installer 서비스에 대한 여러 개의 오류 예외를 지정할 수 있습니다.

샘플 구성

다음 샘플 구성은 ActiveX Installer 서비스 구성 방법을 보여 줍니다. 그러나 이러한 샘플 구성은 권장하지 않습니다.

기본 설정

값을 지정하지 않으면 ActiveX Installer 서비스에서 기본값을 적용합니다. 기본값은 2,1,0,0입니다. 이 설정이 적용되는 경우 ActiveX Installer 서비스는 다음 작업을 수행합니다.

  • 서명되지 않은 ActiveX 컨트롤 설치 차단

  • 서명된 ActiveX 컨트롤 설치를 승인하라는 메시지를 사용자에게 표시

  • 사용자에게 메시지를 표시하지 않고 신뢰할 수 있는 게시자 저장소에 있는 인증서로 서명된 ActiveX 컨트롤을 자동으로 설치

높은 보안 설정

ActiveX Installer 서비스의 가장 안전한 구성은 관리자가 다음과 같이 서비스를 구성하는 경우입니다.

  • HTTPS 사이트를 호스트 URL로 사용

  • 신뢰할 수 있는 게시자 저장소에 있는 인증서로 서명된 ActiveX 컨트롤만 설치 허용

이 설정을 구성하는 값은 2,0,0,0입니다.




출처 : technet.microsoft.com


Trackback 0 Comment 1
  1. Favicon of https://blog.pages.kr 날으는물고기 2013.10.29 07:38 신고 address edit & del reply

    고급 사용자가 새 버전의 Windows Update 오프라인 검색 파일 Wsusscn2.cab를 사용할 수 있다
    http://support.microsoft.com/kb/926464/ko

2009. 2. 17. 11:32

솔라리스 서비스 관리 설비 - 서비스 개발자를 위한 소개

일반적인 개념
  • smf(5) 서비스 모델

    서비스 관리 설비는 서비스라고 불리는 계속적으로 실행 되고 있는 어플리케이션에 프로그래밍 모델을 정의 합니다. 서비스는 수행되고 있는 프로세스들의 셋, 혹은 시스템 설정 파라미터들의 셋, 혹은 수행 중인 프로세스 들의 인공적인 셋등과 같이 소프트웨어 설비의 숫자를 나타 냅니다. 솔라리스 서비스는 오직 명시적으로 활성화 되었을 때(관리자에 의해), 그리고 모든 의존 조건들이 만족 되었을 때에만 시작 됩니다.

    현존 하는 서비스를 smf(5) 로 변환 하는 것은 시간이 걸리는 작업이지만 하드웨어 오류 상황이나 예상치 못한 서비스 오류 혹은 관리 오류가 발생할 수 있는 상황에서 자동적으로 서비스를 시작 할 수 있는 장점을 가질 수 있도록 해 줍니다. 서비스 관리 설비에 참여 함으로써 svcs(1) 에 서비스가 노출되는 장점을 얻을 수 있고 svcadm(1M) 과 다른 솔라리스 관리 툴을 이용해 쉽게 관리 할 수 있는 장점을 얻을 수 있습니다. 이 작업은 오직 짧은 XML 파일을 생성하고 서비스 init 스크립트에 간단한 수정을 가하는 것만을 요구 합니다.

  • XML vs repository

    서비스는 보통 서비스 manifest 라고 불리는 서비스와 그 서비스와 연관된 항목들을 정의 하는 XML 파일에 의해 정의 됩니다. 서비스 manifest 는 부트 타임이나 혹은 svccfg import 서브 커맨드를 통해 repository에 집어 넣어 집니다. 서비스 manifest의 XML 포맷은 /usr/share/lib/xml/dtd/service_bundle.dtd.1 에 위치한 서비스 디스크립션 DTD에 의해 정의 됩니다.

    repository는 인증된 서비스 설정들이 저장되는 곳입니다. 이 곳은 서비스가 시스템에 설치 될때 서비스 셋팅을 커스터마이즈 하는 곳입니다.

    이 글의 나머지 부분은 모든 서비스를 위한 딜리버리 메카니즘인 서비스 manifest를 생성 하는 방법에 대해 다룹니다.

  • 개체 vs 서비스 분리

    서비스는 일반적인 서비스 정의와 서비스를 구현하는 하나 혹은 여러개의 인스턴스 들로 구성되어 있습니다. 인스턴스의 속성들은 서비스에서 상속됩니다.

    그러므로 이 글의 나머지 내용에서의 일반적인 가이드를 위해서, 다른 서비스들에 의해서도 변경 되지 않은 모든 속성들을 (만약 서비스가 그것을 지원 한다면) 반드시 서비스 레벨 에서 정의 되어야 합니다.

    만약 서비스가 다른 인스턴스에 의해 다르게 구현 되었다면 (예: 'smtp' 는 sendmail, postfix, qmail, 등에 의해 구현 가능) 사용자는 반드시 현재 구현에 특정한 모든 속성들을 서비스가 아닌 인스턴스 상에 위치 시켜야 합니다.

    아래에서 언급되는 모든 속성들은 모두 인스턴스 혹은 서비스 레벨에서 정의 됩니다.

  • 호환성 그리고 제한

    smf(5) 는 /etc/rc?.d 디렉토리에 존재하는 init(1M) 으로 시작 되는 대부분의 어플리케이션과 inetd.conf 에 딜리버되는 대부분의 어플리케이션의 호환성을 유지 시켜 줍니다.

    몇몇 init 서비스는 어쨌든 부팅 순서를 보존 하기 위해서 반드시 smf 로 변환되어야 합니다. init 서비스는 디바이스나 파일 시스템 혹은 네트워크 설정의 초기 셋업처럼 다른 기반 서비스에 영향을 주는 것들은 변환이 필요 합니다. 서비스는 또한 부트 과정에서 콘솔의 입력을 필요 하는 서비스들의 변환도 필요 합니다.(이러한 서비스를 사용 하는 것은 권장하지 않음)

서비스 manifest 작성하기
  1. 서비스 명명하기

    명명을 위한 일반적인 서비스 카테고리를 제공합니다. 이러한 카테고리들은 시스템에 의해 사용되진 않습니다 그러나 관리자가 서비스의 일반적인 사용을 인식하는데 도움을 줍니다.

    이러한 카테고리들은 /var/svc/manifest 에서 확인 할 수 있고 다음을 포함하고 있습니다:

    • application -- apache 같은 상위 레벨 어플리케이션
    • milestone -- name-services 같은 서비스의 집합
    • platform -- 동적 재구성 데몬 같이 플랫폼 특정 서비스
    • system -- coreadm 같은 솔라리스 시스템 서비스
    • device -- 디바이스-특정 서비스
    • network -- 프로토콜 같은 네트워크/인터넷 서비스
    • site -- 사이트 특정 디스크립션

    서비스 이름은 무엇을 제공하는지 묘사하고, 카테고리 인식자와 '/'로 분리된 실제 서비스 네임 두가지 모두 포함 합니다. 서비스 이름은 반드시 관리자에 의해 쉽게 구분 될 수 있도록 지어져야 합니다.

    인스턴스 이름은 인스턴스에 대한 특정한 기능을 묘사 합니다. 대부분의 서비스는 '기본' 인스턴스를 생성합니다. 몇몇 (예를 들어 오라클 같은) 소프트웨어들은 관리 설정 선택에 기반하여 인스턴스를 생성하길 원할 것입니다.

    제품의 일부로써 제공되는 서비스 혹은 일반적인 사이트-독립적인 정의를 넘어선 확장은 반드시 stock 심볼이나 카테고리의 일부로써 콤마에 의해 표현 되는 자바-스타일의 역 도메인 프리픽스 혹은 서비스 이름을 그 자체의 유일성을 위해 포함해야 합니다.

    위의 명명 법의 예제로 크론 서비스는 다음과 같이 기술 됩니다:

          <service
    name='system/cron'
    type='service'
    version='1'>
  2. 사용자의 서비스가 여러가지 인스턴스를 가지고 있는지 확인하기

    만약 시스템상에서 여러가지 바이너리가 동시에 수행 되는 것이 오류를 유발한다면 사용자는 반드시 그것을 single_instance 서비스로 정의해야 합니다. 이 태그는 재시작자에게 관리적 설정에 관계 없이 여러가지 서비스 인스턴스를 동시에 시작시키지 않도록 합니다.

    대부분의 설정과 시스템 서비스는 single_instance 태그를 필요로 합니다. 복수의 설정으로 동시에 수행 될수 있는 서비스 혹은 데이타 베이스 같은 것은(서로 다른 데이타베이스 소스 혹은 서로 다른 포트를 사용하는) 반드시 single_instance 로 지정 되면 안됩니다.

    서비스 블럭 다음에 다음을 지정합니다:

          <single_instance />
  3. 서비스 모델을 확인하기

    서로 다른 실행시간 특성을 가진 서비스에 대한 재시작 기능을 제공 하기 위해 smf(5) 는 다양한 모델을 제공합니다. 현재 이러한 모델은 svc.startd inetd 두가지 재시작자에 의해 제공 됩니다. 이러한 모델 외에 추가적인 모델도 앞으로 지원하게 될 것입니다. 이 글에서는 svc.startd(1M) 와 inetd(1M) 두가지 기능에 대해 서술하고 있고 재시작자 문서를 참고하여 그것이 제공하는 어플리케이션 모델에 대해 자세히 알아보시기 바랍니다.

    만약 서비스가 inetd 에 의해 시작된다면 아래의 "Writing an inetd service manifest" 를 참고하여 필자가 제공하는 전환을 쉽게 도와주는 툴을 확인해 보시기 바랍니다.

    svc.startd 는 프로세스 기반의 재시작자 입니다. 그것은 3가지 상이한 모델을 서비스 프로세스를 위해 제공합니다:

    • Transient 서비스는 보통 설정 서비스로써 서비스를 짧은 시간 동안 제공하는 프로세스가 요구 됩니다. 일반적인 transient 서비스는 부트타임에 클린업 혹은 설정 속성들을 커널에 적재하는 등에 관여 합니다.

      Transient 서비스는 또한 종종 계약 혹은 wait 서비스를 위한 메소드 요구사항을 만족시키는 데에 대한 어려움을 극복하는데 사용 됩니다. 이 것은 추천하는 방법은 아니고 일시적인 해결책으로만 사용 되길 제안 합니다.

    • Wait 서비스는 자식 프로세스의 실행동안 수행 되고 그 프로세스가 종료될때 재시작 됩니다.

    • Contract 서비스는 표준 시스템 데몬 입니다. 이것은 서비스를 제공하기 위해 시작한 후 끝까지 수행 되는 프로세스들을 요구 합니다. 계약 서비스에 포함된 모든 프로세스가 죽는 다면 이것은 서비스 에러로 간주 되고 서비스를 재시작 하게 됩니다.

    기본 서비스 모델은 contract 입니다. 그러나 transient 서비스를 위한 다음과 같은 manifest를 지정하도록 수정해야 합니다:

       <property_group name='startd' type='framework'>
    <propval name='duration' type='astring' value='transient' />
    </property_group>

    다음은 wait 서비스를 위한 것 입니다:

          <property_group name='startd' type='framework'>
    <propval name='duration' type='astring' value='child' />
    </property_group>
  4. 서비스가 어떻게 시작 되고 정지 될지 확인하기

    smf 는 최우선 적으로 서비스와 메소드 를 통해서 상호반응하게 됩니다. stop start 메소드는 svc.startd 에 의해 관리되는 서비스들에게 반드시 제공되어야 하고 또한 서비스 바이너리나 복잡한 설정을 다루는 스크립트등에서 직접적으로 호출 될 수 있어야 합니다. refresh 메소드는 svc.startd 에 의해 관리되는 서비스들을 위한 부가적인 옵션 입니다. 서로 다른 재시작자는 서로 다른 메소드를 요구 합니다.

    존재하는 init 스크립트는 손쉽게 서비스 메소드의 기반으로써 서비스 될 수 있습니다. 우리는 svc.startd 에 의해 지원되는 메소드에 대한 기본적인 룰과 가이드를 제공 합니다:

    • 모든 메소드
      • 쉘 스크립트는 편리한 함수와 값의 정의를 리턴하기 위한 접근 권한을 얻기 위해 반드시 /lib/svc/share/smf_include.sh 를 포함 시켜야 합니다.

      • 오류는 반드시 명시적인 에러를 리턴해야 합니다. 모든 0 이 아닌 값들은 에러로 간주 됩니다. 추가적인 정보 (예를 들어 설정 에러에 기인한 재시작을 회피하기) 는 SMF_EXIT_* 정의를 통해 재시작자에 제공되어야 합니다.

      • 메소드는 오류상황에서 반드시 로그 메세지를 출력해야 합니다. 그것들은 svc.startd 에 ㅡ이해 서비스 로그 파일에 기록 됩니다. 그러므로 관리자는 무슨일이 벌어지고 있는지 알 수 있습니다.

      • 키워드:kill:true 가 모든 메소드 정의에서 사용 가능합니다.

        :true 는 간단히 재시작자에 성공을 리턴 합니다.

        :kill 은 사용자의 서비스 시작 메소드에 의해 시작 된 모든 프로세스들을 종료 시킵니다. 프로세스의 목록은 서비스의 계약에 의해 결정 됩니다.

    • start 메소드
      • start 메소드는 모든 svc.startd 에 의해 관리되는 서비스를 위해 필요 합니다.

      • start 메소드는 서비스가 활성화 되고 모든 의존성 조건이 만족 되었을 때에만 수행 됩니다. 그러므로 만약 서비스가 설정 에러로 인해 제대로 시작 되지 못했을때 반드시 SMF_EXIT_ERR_CONFIG 상태로 종료 되어야 합니다.

      • 만약 서비스의 타입이 contract 라면 프로세스의 종료는 서비스의 재시작을 유발 하기 때문에 반드시 start 메소드는 데몬을 수행 상태로 유지해야 합니다.

      • contracttransient 서비스에서 start 메소드는 반드시 서비스가 완전히 제공 될때 까지 성공을 리턴해서는 안됩니다. 이것은 데몬에도 똑같이 적용 됩니다; 데몬은 초기 과정에서 fork() 후에 바로 exit() 를 호출 하면 안됩니다. 왜냐하면 시작시에 에러가 수집되서 보고 될때까지 리턴되면 안되기 때문입니다. 많은 init 스크립트들이 데몬을 시작시키고 바로 리턴을 하도록 사용 되는데 이것은 의존적인 서비스들이 직렬적으로 시작 되는데 시간이 걸리기 때문입니다. 이제 의존적인 서비스들이 정확하게(종종 곧 바로) 서비스가 성공적으로 시작 메소드에서 리턴 된 후에 시작 되기 때문에 이러한 부정확한 구문은 용납되지 않습니다.

        만약 데몬/서비스에 대한 코드 수정이 이루어 질 수 없다면 성공을 리턴하기 전에 서비스가 올바르게 동작하는지 테스트 해야 합니다. 만약 다른 방법이 없다면 성공을 리턴하기 전에 적당히 긴 시간의 sleep() 을 삽입하여야 합니다.

    • stop 메소드
      • stop 메소드는 모든 svc.startd 에 의해 관리되는 서비스에 사용되어야 합니다.

      • Stop 메소드는 의존성이 오프라인 되었을 경우 혹은 서비스가 실해 했을 경우 혹은 관리자가 비활성화 혹은 재시작을 요구 했을 경우와 같은 여러가지 다른 시나리오 상에서 수행 됩니다.

      • stop 메소드는 서비스의 실행이 완료되서 더이상 수행이 되지 않을 경우에 반드시 성공을 리턴 해야 합니다. 실행이 시작 됐을때 서비스가 수행되고 있지 않았더라도 마찬 가지 입니다. 왜냐하면 stop 메소드는 오류 상황에서 호출 될 것이기 때문입니다.

    • refresh 메소드
      • Refresh 메소드는 모든 svc.startd 에 의해 관리되는 서비스에 선택 옵션입니다.

      • refresh 메소드는 매우 정확한 구문을 가지고 있습니다; 그것은 반드시 repository 혹은 다른 설정 소스에서 서비스를 방해 하지 않고 적절한 설정 파라미터를 재적재 해야 합니다. contract 혹은 wait 서비스 프로세스들이 종료하도록 하면 안됩니다.

    타이아웃은 모든 메소드에 반드시 제공되어야 합니다. 타임아웃은 과중한 로드가 걸리거나 느린 시스템에서도 메소드가 수행 되는데 걸리는 최대한의 시간을 고려해서 지정되어야 합니다. 타임아웃을 초과한 메소드는 종료 될 것입니다. 만약 메소드가 잠재적으로 예측이 불가능한 시간동안 수행이 된다면(큰 파일 시스템의 fsck 같은) 무한 타임아웃은 '0'으로 지정 될 것입니다.

    필자는 서비스 메소드의 일부로 사용자 상호작용을 기대 하는 것을 강력히 비추천합니다(콘솔 입력 같은) 이러한 일을 하는 스크립트는 수정 없이는 수행되지 않을 것입니다. 왜냐하면 stdin/stdout/stderr/dev/console 의 서비스 메소드가 아니기 때문입니다.

    필자는 메소드 상세에서 일반적으로 사용 되는 속성 값을 위한 메소드 토큰의 셋을 제공 합니다. 리스트는 smf_method(5) 에서 찾으 실 수 있습니다.

    기본 메소드 환경은 PATH/usr/sbin:/usr/bin 으로 지정되는것과 함께 init(1M) 에서 상속 됩니다. SMF_ 로 시작하는 변수들은 프레임워크를 위해서 예약 되어 있습니다. smf_method(5) 에 정의되 있는 SMF_ 변수들은모든 메소드에 제공됩니다. ; SMF_FMRI, SMF_METHOD, 그리고 SMF_RESTARTER 를 포함.

    마지막으로 각 메소드는 method context 를 지정해서 메소드 실행시에 시스템을 정의하고 보안 속성값을 사용하는데 이용합니다. 필자는 긴시간 동안 수행되는 서비스들은 최소한의 권한과 안전한 uid, gid를 가지고 실행 되기를 권장 합니다.

    start 메소드의 상세의 예제는 아래와 같습니다.

          <exec_method
    type='method'
    name='start'
    exec='/lib/svc/method/svc-cron'
    timeout_seconds='60'>
    <method_context>
    <method_credential user='root' group='root' />
    </method_context>
    </exec_method>
  5. 오류가 무시되어야 하는지 결정

    만약 서비스 자체가 오동작을 한다거나 오동작을 하는 서브프로세스를 만든다면 사용자는 재시작에게 특정한 오류가 발생할 것이라고 알려주고 이것을 서비스 오류와 연관시키지 않도록 알려주길 원할 것입니다.

    사용자는 서브프로세스의 코어덤프가 에러로 간주되지 않도록 지정할 수 있습니다. 혹은 외부의 종료 시그널이 에러가 아님을 알려 줄 수 있습니다. 이러한 예제는 아래와 같습니다.

      <property_group name='startd' type='framework'>
    <propval name='ignore_error' type='astring' value='core,signal' />
    </property_group>

  6. 의존성 확인하기

    이것은 서비스 전환에서 가장 어려운 부분 입니다. 왜냐하면 모든 의존성이 명시적으로 기술 되지 않기 때문입니다. 여기에는 두가지 타입의 의존성이 있습니다;파일서비스 의존성.

    일단 사용자의 서비스가 시작되기 위해 어떠한 서비스가 먼저 시작되어야 하는 지 확인합니다. 예를 들어 사용자의 서비스가 네트워크 인터페이스를 사용해야 하고, 로컬 디바이스를 설정해야 하고 네임 서비스가 사용이 가능해야 하는지 확인 하는 것입니다.

    어떠한 서비스에 의존하고 있는지 확인 했다면 사용자는 오류 전달 모델을 지정 해야 합니다. 각 의존성마다 서비스가 다시 시작해야 하는지에 대한 조건을 결정해야 합니다:

    1. none -- 의존성은 오직 시작시에만 요구 됩니다. 어떠한 오류 혹은 관리 작업도 재시작시에 필요하지 않습니다
    2. error -- 만약 의존성에 오류가 발생한다면 재시작 합니다(코어 덤프, 시스템 오류 등등)
    3. restart -- 만약 의존성이 재시작 되면 사용자의 서비스도 반드시 재시작 되어야 합니다
    4. refresh -- 만약 의존성이 refresh 되면 (설정이 바뀌면) 서비스는 반드시 재시작 되어야 합니다

    이러한 값들은 restart_on 속성을 통해서 지정된 의존성에 재시작을 다루는 것과 관계가 있습니다.

    의존성은 그룹단위로 지정 됩니다. 가능한 그룹단위는:

    1. require_all -- 그룹에 모든 것은 반드시 온라인 되거나 의존성이 시작 되기 전에 degrade 되어야 합니다
    2. require_any -- 그룹에 모든 서비스가 반드시 온라인 되거나 의존성이 시작 되기 전에 degrade 되어야 합니다
    3. optional_all -- 만약 서비스가 활성화 되거나 실행 될 수 있다면(유지보수가 아닌) 그들은 반드시 온라인이 되거나 의존성이 시작 되기 전에 degrade 되어야 합니다
    4. exclude_all -- 만약 서비스가 활성화 되거나 degrade 된다면 의존성은 반드시 시작되면 안됩니다

    만약 서비스가 legacy 스크립트에 의존적이라면 필자는 이러한 legacy 스크립트를 smf(5) 서비스로 변환하기를 강력히 추천합니다. 이러한 방법 대신 스크립트의 일부인 milestone 상에 의존성을 지정할 수도 있습니다. 이것은 legacy 서비스에서 에러를 전달하지 않을 것이므로 restart_on=none 의존성일 때에만 성립됩니다.

    마지막으로 어떠한 의존성이 필요한지 결정하는 어려운 작업을 끝낸 다음에는 미래의 유지보수를 위해 커멘트를 남기기를 추천합니다.

          <!-- Must be able to resolve hostnames. -->
    <dependency
    name='nameservice'
    type='service'
    grouping='require_all'
    restart_on='none'>
    <service_fmri value='svc:/milestone/name-services' />
    <dependency>
  7. 의존성 확인하기

    만약 사용자가 사용자가 전달 하지 않는 다른 서비스를 의존하고 있는 서비스를 전달 하고자 한다면 사용자는 사용자의 manifest에 이것을 지정하여 사용자가 소유하고 있지 않은 manifest를 수정하지 않아도 됩니다. 즉 의존성 상세는 썬에 의해 서비스가 전달 되기 전에 서비스를 수행 시킬 수 있는 쉬운 방법 입니다.

    만약 모든 의존 적인 서비스들이 전환되지 않았다면 사용자는 이 것들 또한 변환 시킬 필요가 있습니다. 왜냐하면 legacy 스크립트에 의존성을 지정할 방법이 없기 때문입니다.

    충돌을 피하기 위해 우리는 서비스의 이름을 의존적인 이름 앞에 붙여 넣기를 권장합니다.

    예를 들어 만약 사용자가 syslog 전에 반드시 실행되어야 하는 서비스(mysvc) 를 전달한다면:

          <dependent
    name='mysvc_syslog'
    grouping='optional_all'
    restart_on='none'>
    <service_fmri value='svc:/system/system-log' />
    <dependent>
  8. 사용자의 서비스를 milestone에 삽입하기

    만약 서비스가 이전에 rc?.d 디렉토리에 전달 되었고 다른 서비스가 그에 의존 하고 있다면 사용자는 반드시 milestone 을 이 전의 전달 장소에 독립적으로 지정 했는지 확인해야 합니다.

    예를 들어 만약 서비스가 기존에 런레벨 2에서 시작 되었다면 다음의 구문은 사용자의 서비스가 시작 되기 전까지는 런레벨 2가 완벽히 시작 되지 않았음을 확인하게 됩니다.

       <dependent
    name='mysvc_multi-user'
    grouping='require_all'
    restart_on='none'>
    <service_fmri value='svc:/milestone/multi-user' />
    <dependent>
  9. 적절하다면 기본 인스턴스를 생성

    만약 서비스가 설정을 위한 추가적인 관리적 간섭이 처음 시작 이전에 필요로 하지 않다면 사용자는 반드시 서비스의 기본 인스턴스를 설정해야 합니다.

    만약 인스턴스가 서비스와 아무런 설정 차이가 없다면 이것은 다음과 같이 간단히 작업할 수 있습니다:

    <create_default_instance enabled='false' />

    대신 인스턴스를 명시적으로 정의 할 수도 있습니다.

          <instance name='default' enabled='false'>
    <!-- instance-specific properties, methods, etc. go here. -->
    </instance>

    필자는 모든 인스턴스가 시스템 부트에 치명적인 영향을 미칠때에는 비활성화 된채로 딜리버 되기를 추천합니다. 커스터마이제이션은 관리자 혹은 프로파일에 의해 수행 할 수 있습니다.

  10. 템플릿 정보를 작성해서 서비스를 묘사하기

    C 로케일 과 멘페이지 참고 가능한 최소한의 공통 이름을 문서화해야 합니다. 공통이름은

    • 짧아야 함 (40 문자 혹은 미만),
    • Solaris 같은 트레이드 마크를 제외하고는 대문자 사용을 피하기,
    • 분리자 피하기
    • 워드 서비스를 피하기 (그러나 반드시 클라이언트와 서비스를 구분할것).

      이 정보는 관리자에게 서비스에 대한 정확한 상세 상황가 기술 정보를 어디서 얻을 수 있는지에 대한 정보를 svcs(1) 의 다양한 폼에 의해 제공 합니다. 공통 이름은 로컬라이즈 됩니다.

      <template>
      <common_name>
      <loctext xml:lang='C'>
      Solaris fault manager
      <loctext>
      <common_name>
      <documentation>
      <manpage title='fmd' section='1M' manpath='/usr/share/man' />
      <documentation>
      <template>

  11. Write/update an administrative command

    사용자의 서비스가 서비스를 stop, start, restart하는 것 같은 관리 커맨드를 이미 가지고 있다면 그것을 svcadm(1M) 혹은 libscf 콜을 업데이트 해줘야 합니다. 만약 관리 커맨드가 명시적으로 smf(5) 외부에서 데몬을 호출 하고 있다면 smf(5) 프레임워크는 다른 데몬이 돌아가고 있는지 알지 못할 것입니다. 데몬 끼리의 충돌, 잘못된 계약 svcs(1) 를 이용해서도 서비스 상황을 알지 못함 등의 문제가 발생할 수 있습니다.

  12. /etc/rc?.d 디렉토리와 /etc/init.d 에서 사용자 스크립트 제거하기

    만약 사용자의 init 스크립트를 제거하지 않는 다면 여전히 legacy 모드로 동작할 것입니다.

추가 정보

DTD는 그 자체로 문서 입니다. 많은 질문들이 솔라리스10에 있는 /usr/share/lib/xml/dtd/service_bundle.dtd 파일을 읽는 것 만으로도 해결이 가능합니다.

썬은 많은 manifest를 /var/svc/manifest 에서 제공합니다. 이것은 템플릿 혹은 예제로써 사용이 가능합니다. 빠른 시작을 위해서:

  • system/utmp 는 간단한 standalone 데몬 입니다,
  • system/coreadm 는 간단한 transient 서비스 이고,

  • network/telnet inetd(1M) 기반의 데몬 입니다.

다음의 멘페이지는 처음 시작하는데 도움을 줄 수 있습니다: smf(5), smf_bootstrap(5), smf_method(5), smf_restarter(5), smf_security(5), svc.startd(1M), inetd(1M), inetconv(1M).

마지막으로, BigAdmin의 SMF System Administration Guide Documentation, 과 Predictive Self-Healing site 는 큰 도움을 줄 것입니다.

inetd 서비스 manifest 작성하기

inetconv(1M) 부터 시작해서 템플릿을 추가하고 이름을 정제 하는 등에 수정을 포함합니다.

여기에 덧붙여서:

  • 패키징
  • pre-converted이전에 변환되었던 inetd.conf 서비스 제거하기


출처 : http://blog.sdnkorea.com/


Trackback 0 Comment 0