'SMF'에 해당되는 글 2건

  1. 2009.05.29 Solaris 10 11/06 릴리스의 새로운 기능
  2. 2009.02.17 솔라리스 서비스 관리 설비 - 서비스 개발자를 위한 소개
2009. 5. 29. 23:51

Solaris 10 11/06 릴리스의 새로운 기능

시스템 관리 기능 향상

Solaris 10 11/06 릴리스에는 다음과 같은 시스템 관리 기능과 향상된 기능이 추가되었습니다.

Storage Networking Industry Association Multipath Management API 지원

이 기능은 Sun에서 구현하는 SNIA(Storage Networking Industry Association) MP API(Multipath Management API)를 제공합니다. 지원되는 내용은 다음과 같습니다.

  • MP API 공통 라이브러리

  • Solaris 원시 다중 경로 지정 솔루션에 대한 플러그인 라이브러리 - MPxIO/scsi_vhci 드라이버

  • mpathadm CLI

MP API 공통 라이브러리는 정의된 표준 인터페이스 집합을 내보냅니다. scsi_vhci 드라이버용 플러그인 라이브러리를 사용하면 MP API 및 연관된 CLI인 mpathadm을 통해 scsi_vhci 다중 경로 지정 장치를 관리할 수 있습니다.

SNIA MP API는 Solaris의 공급업체별 다중 경로 지정 솔루션에서 다중 경로 지정 관리 응용 프로그램이 공통된 API 집합을 사용할 수 있도록 하는 다중 경로 지정 검색 및 관리를 위한 표준 인터페이스를 정의합니다. Sun은 API 및 연관된 CLI를 통해 Solaris 원시 다중 경로 지정 솔루션을 관리할 수 있게 하는 플러그인 라이브러리를 제공하고 있습니다.

Sun Java 웹 콘솔 변경 사항

Sun JavaTM 웹 콘솔을 통해 사용자는 한 곳에서 웹 기반 관리 응용 프로그램을 작업할 수 있습니다. 사용자는 HTTPS 포트를 통해 로깅하여 콘솔에 액세스할 수 있으며 다양한 지원되는 웹 브라우저를 사용할 수 있습니다. 콘솔이 제공하는 단일 입력 지점을 사용하면 여러 응용 프로그램의 URL을 기억할 필요가 없습니다. 콘솔에서는 콘솔에 등록된 응용 프로그램에 대한 인증 및 권한 부여 서비스가 제공됩니다.

모든 콘솔 기반 응용 프로그램은 동일한 사용자 인터페이스 지침을 따릅니다. Sun Java 웹 콘솔에는 또한 모든 등록된 응용 프로그램에 대한 감사 및 로깅 서비스가 제공됩니다.

Solaris ZFS 관리 도구는 Solaris 10 6/06 릴리스부터 제공되는 콘솔 응용 프로그램입니다. Solaris ZFS 웹 기반 관리 도구를 사용하는 방법에 대한 자세한 내용은 Solaris ZFS Administration Guide를 참조하십시오.

Solaris 10 11/06 릴리스부터 Sun Java 웹 콘솔에 다음 변경 사항이 포함되었습니다.

  • 이제 콘솔은 JavaServerTM Faces 기술을 기반으로 하는 응용 프로그램을 지원합니다.

  • 콘솔 서버는 SMF(Service Management Facility)가 관리하는 서비스로 실행되도록 구성됩니다. SMF 명령을 사용하여 FMRI(Fault Managed Resource Identifier) “system/webconsole:console”을 통해 콘솔 웹 서버를 관리할 수 있습니다. 이전 Solaris 10 릴리스에서와 같이 smcwebserver 명령을 사용하여 콘솔 서버를 시작, 정지, 사용 및 사용하지 않을 수 있습니다.

    자세한 내용은 smcwebserver(1M) 매뉴얼 페이지를 참조하십시오.

  • 새 명령인 wcadmin을 사용하여 콘솔 등록 정보를 구성할 수 있습니다. 또한 이 명령을 사용하여 새 콘솔 버전용으로 작성되는 콘솔 응용 프로그램을 배포하고 활성화할 수 있습니다. 이전에 비슷한 작업을 수행하는 데 사용되었던 smreg 명령은 이제 이전 버전의 콘솔용으로 개발된 응용 프로그램을 등록 및 등록 취소하는 경우에만 사용됩니다.

    자세한 내용은 smreg(1M)wcadmin(1M) 매뉴얼 페이지를 참조하십시오.

자세한 내용은 System Administration Guide: Basic Administration의 “Working With the Sun Java Web Console(Tasks)”을 참조하십시오.

파일 시스템 모니터링 도구

이 파일 시스템의 향상된 성능은 Solaris 10 11/06 릴리스의 새로운 기능입니다.

새로운 파일 시스템 모니터링 도구인 fsstat를 사용하여 파일 시스템 작업을 보고할 수 있습니다. 마운트 지점이나 파일 시스템 유형별로 작업을 보고할 수 있습니다.

자세한 내용은 fsstat(1M) 매뉴얼 페이지를 참조하십시오.

시스템 자원 향상

Solaris 10 11/06 릴리스에는 다음과 같은 자원 기능과 향상된 기능이 추가되었습니다.

자원 관리 기능

Solaris 10 11/06 릴리스에는 다음과 같은 자원 관리 기능과 향상된 기능이 추가되었습니다.

자원 풀 퍼실리티 서비스 FMRI

자원 풀 및 동적 자원 풀이 Solaris SMF(Service management facility)와 통합되었습니다. 이제 동적 자원 풀은 자원 풀 서비스와는 별도로 활성화됩니다.

동적 자원 풀 서비스 FMRI(fault management resource identifier)는 svc:/system/pools/dynamic입니다. 자원 풀 서비스 FMRI는 svc:/system/pools입니다.

pooladm(1M)을 통한 활성화 및 비활성화 메커니즘을 계속 사용할 수 있습니다.


주 –

시스템이 업그레이드될 때 /etc/pooladm.conf 파일이 있을 경우 이 파일에 포함된 구성이 시스템에 적용됩니다.


자세한 내용은 다음을 참조하십시오.

Solaris 영역 기능

Solaris 10 11/06 릴리스에는 다음과 같은 Solaris 영역 기능과 향상된 기능이 추가되었습니다.

Solaris 영역 이름 변경 기능

이제 영역 이름은 zonecfg 명령을 통해 설정할 수 있는 속성입니다. 구성 또는 설치된 상태의 영역만 이름을 바꿀 수 있습니다.

영역 구성 및 영역 상태에 대한 자세한 내용은 다음을 참조하십시오.

영역 이동 및 복제 기능

새 하위 명령인 moveclonezoneadm 명령에 추가되었습니다. 이제 다음과 같은 작업을 수행할 수 있습니다.

  • 시스템의 한 지점에서 동일한 시스템의 다른 지점으로 비전역 영역을 재배치합니다.

  • 동일한 시스템에 있는 기존 영역의 구성에 기초하여 새 비전역 영역을 신속하게 제공합니다.

자세한 내용은 다음을 참조하십시오.

한 시스템에서 다른 시스템으로 비전역 영역 마이그레이션

zonecfgzoneadm 명령은 한 시스템에서 다른 시스템으로 비전역 영역을 마이그레이션할 수 있도록 수정되었습니다. 정지된 영역을 현재 위치에서 분리한 다음 해당 영역을 새 위치에 연결하는 절차가 사용됩니다. 대상 시스템의 전역 영역에서는 다음이 실행 중이어야 합니다.

  • 원래 호스트와 동일한 릴리스

  • 원래 호스트와 동일한 버전의 운영 체제 패키지 및 패치

영역 분리 프로세스는 다른 시스템에서 영역을 연결하는 데 필요한 정보를 만듭니다. 영역 연결 프로세스는 새 시스템이 영역을 호스팅하기 위한 올바른 구성을 갖고 있는지 확인합니다. 여러 방법으로 영역 경로를 새 호스트에서 사용 가능하게 만들 수 있습니다. 따라서 실제로 한 시스템에서 다른 시스템으로 영역 경로를 이동하는 작업은 영역 관리자가 수행하는 수동 프로세스입니다.

새 시스템에 연결된 경우 영역은 설치된 상태가 됩니다.

자세한 내용은 다음을 참조하십시오.

비전역 영역에 대한 구성 가능한 권한

zonecfg 명령의 limitpriv 등록 정보를 사용하여 프로세스가 비전역 영역으로 제한되는 권한 집합을 지정할 수 있습니다.

다음과 같은 작업을 수행할 수 있습니다.

  • 전역 자원을 제어할 수 있는 기능을 통해 변경 사항으로 인해 한 영역의 프로세스가 다른 영역의 프로세스에 영향을 줄 수 있다는 점을 고려하면서 기본 권한 집합을 확대합니다.

  • 안전한 기본 집합보다 적은 권한을 가진 영역을 만듭니다.

영역의 권한 및 영역 권한 제한을 구성하는 방법에 대한 자세한 내용은 다음을 참조하십시오.


주 –

다음 사항에 유의하십시오.

  • 기본적으로 비전역 영역은 계속해서 표준 안전 권한 집합으로 부트됩니다.

  • 하나의 권한 집합을 영역의 권한 집합에서 제거할 수 없고 또 다른 권한 집합을 영역의 권한 집합에 포함할 수 없습니다.


논리 도메인 기능

Solaris 10 11/06 릴리스에는 다음과 같은 논리 도메인 기능과 향상된 기능이 추가되었습니다.

LDoms(Logical Domains) 1.0 소프트웨어

LDoms(Logical Domains) 1.0 소프트웨어를 사용하여 시스템 관리자는 논리 도메인을 만들고 관리할 수 있습니다. 이 소프트웨어는 Sun4v 기반 플랫폼을 위한 여러 소프트웨어 파티션 지원과 다음 기능을 제공합니다.

  • UltraSPARC T1 시스템에 대한 소프트웨어 업그레이드(Solaris 10 11/06 및 펌웨어 업그레이드)

  • 별개의 다운로드로 제공되는 CLI인 LDoms(Logical Domains) Manager 1.0 소프트웨어에 의해 관리되는 시스템당 최대 32개의 논리 도메인

  • 독립적으로 작성, 완전 삭제, 재구성 및 재부트할 수 있는 각각의 게스트 도메인

  • 가상 콘솔, 이더넷, 디스크 및 암호화 가속

  • 가상 CPU의 라이브 동적 재구성

  • 각 논리 도메인에 대한 FMA(오류 관리 아키텍처) 진단

논리 도메인 기능을 사용하려면 Solaris 10 11/06 OS와 최소 레벨의 시스템 펌웨어 6.4 및 Logical Domains Manager 1.0 소프트웨어가 필요합니다.

보안 개선 내용

Solaris 10 11/06 릴리스에는 다음과 같은 보안 기능과 향상된 기능이 추가되었습니다.

Solaris Trusted Extensions

Solaris Trusted Extensions 소프트웨어는 다음에 대한 필수 액세스 제어를 포함하여 Solaris OS에 대한 다중 레벨 보안을 제공합니다.

  • 파일

  • 파일 시스템

  • 프로세스

  • 이동식 장치

  • 네트워킹

  • 데스크탑 환경

  • 인쇄

또한 Solaris Trusted Extensions 소프트웨어는 다음 작업을 위한 도구를 제공합니다.

  • 정책 정의

  • 민감도 레이블 설정

  • 신뢰할 수 있는 시스템 관리 수행

Solaris Trusted Extensions 기능을 사용하면 정보를 유연하면서도 매우 안전한 방식으로 제어할 수 있도록 데이터 액세스 정책을 정의할 수 있습니다. Solaris Trusted Extensions를 Solaris OS에 대한 구성 옵션으로 사용할 수 있습니다.

Solaris Trusted Extensions에 대한 자세한 내용은 http://www.sun.com/smi/Press/sunflash/2006-02/sunflash.20060214.3.xml을 참조하십시오.

인쇄용 Solaris Trusted Extensions

인쇄 기능의 Solaris Trusted Extensions를 통해 다음 기능을 사용할 수 있습니다.

  • 레이블 범위로 제한하여 프린터 출력

  • 특수하게 레이블이 지정된 배너 및 트레일러 페이지

  • 특수하게 레이블이 지정된 머리글 및 바닥글

Solaris Trusted Extensions 파일 시스템 레이블 지정

이 릴리스부터는 파일과 디렉토리를 내보내는 영역 또는 호스트에 의해 파일과 디렉토리에 레이블이 지정됩니다. 직접 쓸 수 없도록 마운트 정책이 제한됩니다.

장치 관리 향상

Solaris 10 11/06 릴리스에는 다음과 같은 장치 관리 기능과 향상된 기능이 추가되었습니다.

PCIe(PCI Express) 지원

이 Solaris 릴리스는 SPARC 및 x86 시스템 모두에서 PCIe(PCI Express) 상호 연결을 지원합니다.

PCIe는 데스크탑, 엔터프라이즈, 모바일, 통신 및 내장 응용 프로그램 등에 주변 기기를 연결하는 데 사용됩니다.

PCIe 상호 연결은 업계 표준의 고성능 직렬 I/O 버스입니다.

PCIe 소프트웨어는 이 Solaris 릴리스에서 다음과 같은 기능을 제공합니다.

  • 확장된 PCIe 구성 공간 지원

  • PCIe 기본 오류 처리 및 MSI 인터럽트 지원

  • PCIe 장치에 대한 수정된 IEEE-1275 등록 정보

  • cfgadm 명령의 cfgadm_pci 구성 요소를 향상하여 PCIe 핫 플러그 지원(고유 및 ACPI 기반 모두)

  • ATTN 버튼 사용 기반 PCIe 주변 기기 자동 구성

다음 cfgadm 출력 예는 x86 시스템의 핫 플러그 가능 PCIe 장치를 표시합니다. 아래 표시되는 내용은 플랫폼마다 다를 수 있습니다. 정확한 cfgadm 구문은 해당 하드웨어 플랫폼 설명서를 참조하십시오.


# cfgadm pci
Ap_Id                          Type         Receptacle   Occupant     Condition
pcie1                          unknown      empty        unconfigured unknown
pcie2                          unknown      empty        unconfigured unknown
pcie3                          unknown      empty        unconfigured unknown
pcie4                          etherne/hp   connected    configured   ok
pcie5                          pci-pci/hp   connected    configured   ok
pcie6                          unknown      disconnected unconfigured unknown

PCIe 주변 기기를 핫 플러그할 수 있는 관리 모델은 cfgadm 명령을 사용하는 PCI 주변 기기와 동일합니다.

자세한 내용은 cfgadm_pci(1M) 매뉴얼 페이지 및 System Administration Guide: Devices and File Systems을 참조하십시오. 사용자 시스템에서 PCIe 및 PCIe 핫 플러그 기능이 지원되는지 여부는 해당 하드웨어 플랫폼 설명서를 참조하십시오. 또한 해당되는 경우에는 시스템에서 어댑터를 물리적으로 삽입 또는 제거하는 방법에 대한 지침과 장치 자동 구성의 의미를 신중하게 검토합니다.

PCIe 기술에 대한 자세한 내용은 http://www.pcisig.com을 참조하십시오.

x86: Sun Fire X4500 SATA 디스크 FMA

새로운 오류 관리 아키텍처 기반의 DE(진단 엔진)가 Sun Fire X4500에서 제공됩니다. 이 DE는 디스크 드라이브의 고유한 펌웨어에서 SMART 기술을 사용하여 디스크 드라이브에서 예상 오류를 모니터링합니다. 디스크 오류가 발생하려고 하면 디스크 옆의 LED에 불이 켜지고 오류 관리 아키텍처 오류가 생성됩니다. 이 오류는 시스템 가용성과 완전한 성능을 보장하기 위해 특정 작업을 수행해야 한다는 것을 관리자에게 경고합니다.

SPARC: Ipge에서 E1000g 네트워크 드라이버로 SPARC 기반 시스템 전환

Ipge 드라이버는 NorthStar 카드가 설치된 Ontario 및 기타 SPARC 플랫폼에서 사용됩니다. E1000g 드라이버는 다른 모든 플랫폼에서 사용됩니다.

이 릴리스부터 Ontario 및 다른 SPARC 기반 플랫폼은 ipge에서 e1000g 드라이버로 전환됩니다. 이 기능으로 인해 e1000g는 Intel 1G 칩셋을 사용하는 모든 Sun 플랫폼의 기본 드라이버가 됩니다. 전환을 사용하면 고객은 ipge 또는 e1000g 드라이버가 지원하는 플랫폼이나 특정 플랫폼에서 설치할 드라이버를 알 필요가 없습니다. 따라서 시스템 관리 복잡도가 줄어듭니다.

자세한 내용은 http://sunsolve.sun.com/“Certain 3rd Party Applications May Break on Transition From ipge to e1000g Network Driver”를 참조하십시오.

Solaris 광 섬유 채널 호스트 기반 Logical Unit Number 마스킹

Solaris 광 섬유 채널 LUN(Logical Unit Number) 마스킹 기능을 사용하면 시스템 관리자는 승인되지 않은 특정 LUN에 대해 커널에서 장치 노드를 만들지 않도록 방지할 수 있습니다.

자세한 내용은 fp(7d) 매뉴얼 페이지를 참조하십시오.

SPARC: Fire 기반 플랫폼에 대한 Extended Message Signaled Interrupt 지원

MSI-X(Extended Message Signaled Interrupts)는 향상된 버전의 MSI 인터럽트입니다. MSI-X 지원을 사용하면 장치 드라이버 작성자는 MSI 및 MSI-X 인터럽트 간에 선택할 수 있습니다. 이제 MSI-X 인터럽트는 SPARC PCI-Express 플랫폼(Ultra 45 및 Sun Fire T2000)에서 지원됩니다. Sun Fire T2000에는 Sun Fire T1000 시스템이 포함될 수도 있습니다.

또한 지원되는 SPARC 및 x86 시스템에서 장치의 등록된 인터럽트 정보를 검색하기 위해 새로운 mdb/kmdb 디버거 명령인 ::interrupts가 제공됩니다.

자세한 내용은 Writing Device Drivers의 “Interrupt Handlers”를 참조하십시오.

향상된 사용 중인 장치 오류 검사

지정된 장치가 사용 중인 시점을 감지하기 위해 다음 유틸리티가 향상되었습니다.

  • dumpadm

  • format

  • mkfsnewfs

  • swap

향상된 기능으로 인해 다음과 같은 일부 사용 시나리오를 이러한 유틸리티에서 감지할 수 있습니다.

  • 장치가 ZFS 저장소 풀의 일부인 경우

  • 장치가 덤프 또는 스왑 장치인 겨우

  • 마운트된 파일 시스템 또는 장치에 대한 항목이 /etc/vfstab 파일에 있을 경우

  • 장치가 Live Upgrade 구성의 일부인 경우

  • 장치가 Solaris Volume Manager 구성 또는 Veritas Volume Manager 구성의 일부인 경우

예를 들어, format 유틸리티를 사용하여 활성 장치에 액세스하려고 하면 다음과 비슷한 메시지가 표시됩니다.


# format
.
.
.
Specify disk (enter its number): 1
selecting c0t1d0
[disk formatted]
Warning: Current Disk has mounted partitions.
/dev/dsk/c0t1d0s0 is currently mounted on /. Please see umount(1M).
/dev/dsk/c0t1d0s1 is currently used by swap. Please see swap(1M).

그러나 이러한 유틸리티가 모든 시나리오를 동일한 방식으로 감지하지는 않습니다. 예를 들어, newfs 명령을 사용하여 Live Upgrade 구성의 장치에 새 파일 시스템을 만들 수 있습니다. 마운트된 파일 시스템도 갖고 있는 경우에는 newfs 명령을 사용하여 Live Upgrade 구성의 일부인 장치에서 새 파일 시스템을 만들 수 없습니다.

데스크탑 기능 향상

Solaris 10 11/06 릴리스에는 다음과 같은 데스크탑 기능과 향상된 기능이 추가되었습니다.

dtlogin의 기본 데스크탑 세션

이 릴리스부터는 사용자가 Solaris 데스크탑에 처음 로그인했을 때 CDE(Common Desktop Environment) 대신에 Sun Java DS(JavaTM Desktop System)가 기본 데스크탑 환경입니다. 또한 Java DS는 OpenWindowsTM 또는 GNOME 2.0과 같이 이 Solaris 릴리스에서 더 이상 존재하지 않는 이전 Solaris 릴리스의 데스크탑 환경을 선택한 사용자를 위한 기본 환경이 되었습니다.

시스템 관리자는 defaultDtfallbackDt 자원을 사용하여 기본 선택 항목을 무시하도록 dtlogin 구성을 수정할 수 있습니다.

defaultDtfallbackDt 자원에 대한 자세한 내용은 dtlogin(1M) 매뉴얼 페이지를 참조하십시오.

Solaris용 Adobe Flash Player 플러그인

이전에 Macromedia Flash Player로 알려졌던 Adobe Flash Player는 효과적이고 풍부한 웹 컨텐트를 제공하기 위한 표준입니다. 디자인, 애니메이션 및 응용 프로그램 사용자 인터페이스가 모든 브라우저와 플랫폼에서 즉시 배포되어 풍부한 웹 경험으로 사용자를 끌어들입니다.

GNOME-VFS 및 Nautilus ACL 지원

이 릴리스부터는 ACL 지원이 GNOME-VFS 및 Nautilus에 추가되었습니다. 이제 GNOME 파일 관리자를 통해 파일 시스템 액세스 제어 목록을 액세스 및 수정할 수 있습니다. GNOME-VFS 및 Nautilus ACL 지원 기능은 기존의 파일 시스템 기능을 데스크탑으로 가져옵니다.

Solaris Trusted Extensions 데스크탑

Solaris 10 11/06 릴리스에서는 레이블이 있는 보안이 두 개의 데스크탑 인터페이스로 확장되었습니다. 사용자는 다음 기능을 포함하는 Trusted Java DS(Trusted Java Desktop System) 및 Trusted CDE(Trusted Common Desktop Environment)에 액세스할 수 있습니다.

  • 보안을 손상시키지 않고 볼 수 있는 권한이 부여된 데이터에 사용자가 액세스할 수 있게 하는 다중 레벨 세션

  • 사용자 세션이 하이재킹되지 않도록 보장하기 위한 신뢰할 수 있는 경로 확인

  • 창이나 문서의 레이블을 표시하기 위한 레이블이 있는 창

  • 데이터 이동을 제어하고 보안 위반을 사용자에게 알리기 위한 끌어 놓기 보안 강제 시행 체계 적용

  • 비보안 장치로 중요한 데이터를 전송할 수 없도록 제한하기 위한 CD-ROM, DVD, 오디오 및 기타 장치에 대한 레이블이 있는 장치 할당

  • 다른 시스템의 다중 레벨 세션 및 단일 레벨 세션에 대한 보안된 원격 액세스

설치 기능 강화

Solaris 10 11/06 릴리스에는 다음과 같은 설치 기능과 향상된 기능이 추가되었습니다.

Solaris Flash 아카이브

이 향상된 Solaris Flash 기능을 통해 사용자는 큰 파일을 포함하는 아카이브를 만들 수 있습니다. flarcreate 명령은 4GB 이상의 개별 파일을 포함할 수 있는 Solaris Flash 아카이브를 만듭니다. 사용할 수 있는 아카이브 유틸리티는 다음과 같습니다.

  • cpio 아카이브 유틸리티가 기본값입니다. 개별 파일은 2GB 또는 4GB보다 클 수 없습니다. 크기 제한은 사용된 cpio 버전에 따라 다릅니다.

  • 이식 가능 아카이브 교환 유틸리티인 pax-L pax 옵션과 함께 시작됩니다. -L pax 옵션이 지정된 경우 개별 파일에 대한 크기 제한 없이 아카이브를 만들 수 있습니다. pax 유틸리티는 Solaris 7 OS 릴리스에 포함되어 있었습니다. pax 유틸리티를 사용하여 만든 Solaris Flash 아카이브는 pax 유틸리티가 있는 Solaris OS에서만 배포할 수 있습니다. Solaris 2.6 이전 버전을 실행하는 시스템에서 아카이브를 배포할 경우 cpio 옵션을 사용해야 합니다.

자세한 내용은 pax(1)cpio(1) 매뉴얼 페이지를 참조하십시오. 또한 Solaris 10 설치 설명서: Solaris Flash 아카이브(작성 및 설치)를 참조하십시오.

기본 네트워크 프로필에 의한 보안

이 릴리스부터는 설치 도중에 네트워크 서비스의 기본 동작을 설정하여 훨씬 더 보안된 방식으로 실행할 수 있습니다. 대화형 설치(수동) 도중에 이 보안 옵션이 설치 구성 선택 화면에서 제공됩니다. 자동화된 JumpStart 설치(자동)의 경우 sysidcfg 파일에서 새 service_profile 키워드를 사용하여 제한된 네트워크 프로필을 선택할 수 있습니다.

초기 설치 도중에 네트워크 보안을 제한하도록 선택할 경우 설치 도중에 수많은 서비스가 완전히 사용할 수 없게 됩니다. 일부 서비스는 여전히 사용할 수 있지만 이러한 서비스는 로컬 연결로만 제한됩니다. Solaris Secure Shell은 시스템에 대한 원격 관리 액세스에 사용 가능한 상태로 유지됩니다.

이 제한된 네트워킹 프로필을 통해 인터넷이나 LAN에 노출될 위험성이 줄어듭니다. 시스템이 전체 그래픽 데스크탑 사용 및 송신 네트워크 액세스를 유지합니다. 예를 들어, 계속해서 그래픽 인터페이스에 액세스하고 브라우저 또는 전자 메일 클라이언트를 사용하고 NFSv4 파일 공유를 마운트할 수 있습니다.

기존 서비스 구성은 업그레이드에 의해 변경되지 않습니다.

설치 후에 netservices open을 사용하거나 SMF 명령으로 개별 서비스를 사용 가능하게 하여 네트워크 서비스를 손쉽게 다시 열 수 있습니다.

이러한 새 보안 옵션에 대한 자세한 내용은 다음 관련 자료를 참조하십시오.

표 4–1 추가 보안 정보

네트워크 서비스에 대한 보안 관리

System Administration Guide: Basic AdministrationHow to Create an SMF Profile

설치 후 네트워크 서비스 다시 열기

Solaris 10 11/06 설치 설명서: 설치 및 업그레이드 계획설치 후 보안 설정 수정

설치 구성 계획

Solaris 10 11/06 설치 설명서: 설치 및 업그레이드 계획네트워크 보안 계획

수동 설치 도중에 제한된 네트워크 보안 선택

Solaris 10 설치 설명서: 기본 설치의 2 장, Solaris 설치 프로그램을 사용하여 설치(작업)

JumpStart 설치에 대한 제한된 네트워크 보안 설정

Solaris 10 11/06 Installation Guide: Network-Based Installationsservice_profile 키워드

Solaris Trusted Extensions 설치

Solaris Trusted Extensions는 Solaris OS에 대한 다중 레벨 보안을 제공합니다. 이 기능을 사용하면 유연하면서도 매우 안전한 방식으로 정보를 제어할 수 있습니다. 단순히 데이터 소유권이 아니라 데이터 민감도에 기초하여 데이터에 대한 엄격한 액세스 제어를 적용할 수 있습니다.

Solaris Trusted Extensions에 액세스하는 설치는 표준 설치와 다릅니다. 이러한 설치상 차이점과 Solaris Trusted Extensions에 대한 자세한 내용은Solaris Trusted Extensions 설치 및 구성의 3 장, Solaris Trusted Extensions 소프트웨어 설치(작업)를 참조하십시오.

Solaris Trusted Extensions에 대한 자세한 내용은 Solaris_10/ExtraValue/CoBundled/Trusted_Extensions 디렉토리에서 README 파일을 참조하십시오. 또한 Solaris Trusted Extensions를 참조하십시오.

시스템 성능 향상

Solaris 10 11/06 릴리스에는 다음과 같은 시스템 성능 기능과 향상된 기능이 추가되었습니다.

SPARC: Sun4V용 워치독 타이머

이 기능은 시스템 전반의 워치독 타이머 기능을 제공합니다. 워치독 타이머는 커널에 의해 지속적으로 재설정됩니다. 만료되기 전에 커널에서 타이머를 재설정하지 못할 경우 시스템에서 재설정합니다.

네트워킹 향상

Solaris 10 11/06 릴리스에는 다음과 같은 네트워킹 기능과 향상된 기능이 추가되었습니다.

Sun Java System Message Queue 3.7 Update 1

MQ(Message Queue) 3.7 Update 1은 MQ 3.6용 유지 관리 릴리스입니다. 이 릴리스에는 버그 수정뿐만 아니라 트랜잭션된 메시지에 대한 디스크 쓰기 오버헤드를 줄여주는 개선된 성능이 포함되어 있습니다.

새 드라이버 및 업데이트된 드라이버

Solaris 10 11/06 릴리스에서는 다음과 같은 드라이버가 추가 또는 향상되었습니다.

Quantum LTO-2 및 LTO-3 테이프 드라이브에 대한 ST 드라이버 지원

이 릴리스부터는 Quantum LTO-2 및 LTO-3 테이프 드라이브에 대한 ST 드라이버 지원이 제공됩니다.

ST 드라이버에 대한 자세한 내용은 st 매뉴얼 페이지를 참조하십시오.

CDB 길이 기능

HBA 드라이버를 통해 대상 드라이버는 scsi_ifgetcap을 사용하여 지원되는 최대 CDB 길이를 쿼리할 수 있습니다. 대상 드라이버는 연결 시에 이 기능을 요청하며 HBA 드라이브에서 기능을 지원할 경우 CDB의 최대 길이를 바이트 단위로 반환합니다. 그런 다음 대상 드라이버는 이 값을 사용하여 해당 HBA에 사용할 CDB를 결정할 수 있습니다.

언어 지원 선택

Solaris 10 11/06 릴리스에는 다음과 같은 언어 지원 기능과 향상된 기능이 추가되었습니다.

IIIMF 및 언어 엔진

IIIMF(Internet Intranet Input Method Framework)가 rev.10에서 rev.12로 업그레이드되었습니다.

이 프레임워크는 다음과 같은 새로운 기능을 제공합니다.

  • 입력 메소드 전환기 - 이 기능은 입력 메소드 상태를 표시하고 입력 언어를 전환합니다. Java DS(Java Desktop System) 패널에 입력 메소드 전환기를 추가할 수 있습니다. 패널에 추가 -> 유틸리티 -> 입력 메소드 전환기를 선택하여 입력 메소드 전환기를 Java DS 패널에 추가합니다.

  • iiim-properties에 대한 유틸리티 - 이 기능은 다양한 입력 메소드 기본 설정을 지원합니다. 다음 방법 중 하나를 사용하여 iiim-properties 유틸리티를 시작할 수 있습니다.

    • 실행 -> 기본 설정 -> 데스크탑 기본 설정 -> 입력 메소드를 선택합니다.

    • 입력 메소드 전환기를 마우스 오른쪽 버튼으로 누르고 기본 설정을 선택합니다.

    • CDE 환경의 CDE 기본 메뉴에서 도구 -> 입력 메소드 기본 설정을 선택하거나 명령 프롬프트에 iiim-properties를 입력합니다.

각 언어 엔진이 IIIMF rev.12 base로 업그레이드되었습니다. 일본어 엔진 ATOK12 및 Wnn6은 각각 “ATOK for Solaris” 및 Wnn8로 업데이트되었습니다. "ATOK for Solaris"는 ATOK17과 같습니다. 또한 새로운 중국어 입력 메소드가 IIIMF에 추가되었습니다.


Trackback 0 Comment 0
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