일반적인 개념
-
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 작성하기
-
서비스 명명하기
명명을 위한 일반적인 서비스 카테고리를 제공합니다. 이러한 카테고리들은 시스템에 의해 사용되진 않습니다 그러나 관리자가 서비스의 일반적인 사용을 인식하는데 도움을 줍니다.
이러한 카테고리들은
/var/svc/manifest에서 확인 할 수 있고 다음을 포함하고 있습니다:application-- apache 같은 상위 레벨 어플리케이션milestone--name-services같은 서비스의 집합platform-- 동적 재구성 데몬 같이 플랫폼 특정 서비스system-- coreadm 같은 솔라리스 시스템 서비스device-- 디바이스-특정 서비스network-- 프로토콜 같은 네트워크/인터넷 서비스site-- 사이트 특정 디스크립션
서비스 이름은 무엇을 제공하는지 묘사하고, 카테고리 인식자와 '/'로 분리된 실제 서비스 네임 두가지 모두 포함 합니다. 서비스 이름은 반드시 관리자에 의해 쉽게 구분 될 수 있도록 지어져야 합니다.
인스턴스 이름은 인스턴스에 대한 특정한 기능을 묘사 합니다. 대부분의 서비스는 '기본' 인스턴스를 생성합니다. 몇몇 (예를 들어 오라클 같은) 소프트웨어들은 관리 설정 선택에 기반하여 인스턴스를 생성하길 원할 것입니다.
제품의 일부로써 제공되는 서비스 혹은 일반적인 사이트-독립적인 정의를 넘어선 확장은 반드시 stock 심볼이나 카테고리의 일부로써 콤마에 의해 표현 되는 자바-스타일의 역 도메인 프리픽스 혹은 서비스 이름을 그 자체의 유일성을 위해 포함해야 합니다.
위의 명명 법의 예제로 크론 서비스는 다음과 같이 기술 됩니다:
<service
name='system/cron'
type='service'
version='1'>
-
사용자의 서비스가 여러가지 인스턴스를 가지고 있는지 확인하기
만약 시스템상에서 여러가지 바이너리가 동시에 수행 되는 것이 오류를 유발한다면 사용자는 반드시 그것을
single_instance서비스로 정의해야 합니다. 이 태그는 재시작자에게 관리적 설정에 관계 없이 여러가지 서비스 인스턴스를 동시에 시작시키지 않도록 합니다.대부분의 설정과 시스템 서비스는
single_instance태그를 필요로 합니다. 복수의 설정으로 동시에 수행 될수 있는 서비스 혹은 데이타 베이스 같은 것은(서로 다른 데이타베이스 소스 혹은 서로 다른 포트를 사용하는) 반드시single_instance로 지정 되면 안됩니다.서비스 블럭 다음에 다음을 지정합니다:
<single_instance />
-
서비스 모델을 확인하기
서로 다른 실행시간 특성을 가진 서비스에 대한 재시작 기능을 제공 하기 위해
smf(5) 는 다양한 모델을 제공합니다. 현재 이러한 모델은svc.startd와inetd두가지 재시작자에 의해 제공 됩니다. 이러한 모델 외에 추가적인 모델도 앞으로 지원하게 될 것입니다. 이 글에서는svc.startd(1M) 와inetd(1M) 두가지 기능에 대해 서술하고 있고 재시작자 문서를 참고하여 그것이 제공하는 어플리케이션 모델에 대해 자세히 알아보시기 바랍니다.만약 서비스가
inetd에 의해 시작된다면 아래의 "Writing aninetdservice 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>
-
-
서비스가 어떻게 시작 되고 정지 될지 확인하기
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 메소드는 데몬을 수행 상태로 유지해야 합니다.
-
contract 와 transient 서비스에서 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>
- 모든 메소드
-
오류가 무시되어야 하는지 결정
만약 서비스 자체가 오동작을 한다거나 오동작을 하는 서브프로세스를 만든다면 사용자는 재시작에게 특정한 오류가 발생할 것이라고 알려주고 이것을 서비스 오류와 연관시키지 않도록 알려주길 원할 것입니다.
사용자는 서브프로세스의 코어덤프가 에러로 간주되지 않도록 지정할 수 있습니다. 혹은 외부의 종료 시그널이 에러가 아님을 알려 줄 수 있습니다. 이러한 예제는 아래와 같습니다.
<property_group name='startd' type='framework'>
<propval name='ignore_error' type='astring' value='core,signal' />
</property_group>
-
의존성 확인하기
이것은 서비스 전환에서 가장 어려운 부분 입니다. 왜냐하면 모든 의존성이 명시적으로 기술 되지 않기 때문입니다. 여기에는 두가지 타입의 의존성이 있습니다;파일 과서비스 의존성.
일단 사용자의 서비스가 시작되기 위해 어떠한 서비스가 먼저 시작되어야 하는 지 확인합니다. 예를 들어 사용자의 서비스가 네트워크 인터페이스를 사용해야 하고, 로컬 디바이스를 설정해야 하고 네임 서비스가 사용이 가능해야 하는지 확인 하는 것입니다.
어떠한 서비스에 의존하고 있는지 확인 했다면 사용자는 오류 전달 모델을 지정 해야 합니다. 각 의존성마다 서비스가 다시 시작해야 하는지에 대한 조건을 결정해야 합니다:
none-- 의존성은 오직 시작시에만 요구 됩니다. 어떠한 오류 혹은 관리 작업도 재시작시에 필요하지 않습니다error-- 만약 의존성에 오류가 발생한다면 재시작 합니다(코어 덤프, 시스템 오류 등등)restart-- 만약 의존성이 재시작 되면 사용자의 서비스도 반드시 재시작 되어야 합니다refresh-- 만약 의존성이 refresh 되면 (설정이 바뀌면) 서비스는 반드시 재시작 되어야 합니다
이러한 값들은
restart_on속성을 통해서 지정된 의존성에 재시작을 다루는 것과 관계가 있습니다.의존성은 그룹단위로 지정 됩니다. 가능한 그룹단위는:
require_all-- 그룹에 모든 것은 반드시 온라인 되거나 의존성이 시작 되기 전에 degrade 되어야 합니다require_any-- 그룹에 모든 서비스가 반드시 온라인 되거나 의존성이 시작 되기 전에 degrade 되어야 합니다optional_all-- 만약 서비스가 활성화 되거나 실행 될 수 있다면(유지보수가 아닌) 그들은 반드시 온라인이 되거나 의존성이 시작 되기 전에 degrade 되어야 합니다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>
-
의존성 확인하기
만약 사용자가 사용자가 전달 하지 않는 다른 서비스를 의존하고 있는 서비스를 전달 하고자 한다면 사용자는 사용자의 manifest에 이것을 지정하여 사용자가 소유하고 있지 않은 manifest를 수정하지 않아도 됩니다. 즉 의존성 상세는 썬에 의해 서비스가 전달 되기 전에 서비스를 수행 시킬 수 있는 쉬운 방법 입니다.
만약 모든 의존 적인 서비스들이 전환되지 않았다면 사용자는 이 것들 또한 변환 시킬 필요가 있습니다. 왜냐하면 legacy 스크립트에 의존성을 지정할 방법이 없기 때문입니다.
충돌을 피하기 위해 우리는 서비스의 이름을 의존적인 이름 앞에 붙여 넣기를 권장합니다.
예를 들어 만약 사용자가 syslog 전에 반드시 실행되어야 하는 서비스(
mysvc) 를 전달한다면:<dependent
name='mysvc_syslog'
grouping='optional_all'
restart_on='none'>
<service_fmri value='svc:/system/system-log' />
<dependent>
-
사용자의 서비스를 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>
-
적절하다면 기본 인스턴스를 생성
만약 서비스가 설정을 위한 추가적인 관리적 간섭이 처음 시작 이전에 필요로 하지 않다면 사용자는 반드시 서비스의 기본 인스턴스를 설정해야 합니다.
만약 인스턴스가 서비스와 아무런 설정 차이가 없다면 이것은 다음과 같이 간단히 작업할 수 있습니다:
<create_default_instance enabled='false' />
대신 인스턴스를 명시적으로 정의 할 수도 있습니다.
<instance name='default' enabled='false'>
<!-- instance-specific properties, methods, etc. go here. -->
</instance>
필자는 모든 인스턴스가 시스템 부트에 치명적인 영향을 미칠때에는 비활성화 된채로 딜리버 되기를 추천합니다. 커스터마이제이션은 관리자 혹은 프로파일에 의해 수행 할 수 있습니다.
-
템플릿 정보를 작성해서 서비스를 묘사하기
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>
-
Write/update an administrative command
사용자의 서비스가 서비스를 stop, start, restart하는 것 같은 관리 커맨드를 이미 가지고 있다면 그것을
svcadm(1M) 혹은 libscf 콜을 업데이트 해줘야 합니다. 만약 관리 커맨드가 명시적으로smf(5) 외부에서 데몬을 호출 하고 있다면smf(5) 프레임워크는 다른 데몬이 돌아가고 있는지 알지 못할 것입니다. 데몬 끼리의 충돌, 잘못된 계약svcs(1) 를 이용해서도 서비스 상황을 알지 못함 등의 문제가 발생할 수 있습니다. -
/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/
댓글