# 관리 안내서

# package 프로그램을 사용한 클라이언트 시스템 구성

package 프로그램은 클라이언트 구성 프로세스의 여러 측면을 자동화합니다. package 프로그램을 통해 전역 구성 파일을 정의하여 여러 클라이언트의 로컬 디스크를 쉽게 구성할 수 있습니다.

## 명령 요약

본 장에서는 프로토타입 파일에 있는 명령(들)을 사용하여 다음 타스크를 수행하는 방법을 설명합니다.

클라이언트 시스템의 로컬 디스크 구성 | package
디렉토리 정의 | D [update_code] directory owner group mode_bits
파일 정의 | F [update_code] file source_file [owner group mode_bits]
심볼릭 링크 정의 | L [update_code] link actual_file [owner group mode_bits]
블록 특별 장치 정의 | B device_name major_device_number minor_device_number owner group mode_bits
문자 특별 장치 정의 | C device_name major_device_number minor_device_number owner group mode_bits
소켓 정의 | S socket_name [owner group mode_bits]

## package 프로그램 사용

package 프로그램은 시스템과 무관한 프로토타입 파일을 사용하여 표준 디스크 구성을 정의합니다. 프로토타입 파일은 로컬 클라이언트 디스트에 상주하는 파일, AFS에 연결된 파일 등을 나타냅니다. 프로토타입 파일은 시스템 유형마다 구성 파일로 컴파일됩니다.

모든 클라이언트 시스템의 구성이 같지는 않습니다. 원하는 경우 서로 다른 클라이언트 기능(인쇄 서버, 일반 클라이언트 등)에 대해 다른 프로토타입 파일을 작성할 수 있습니다.

package 프로그램은 로컬 클라이언트 디스크의 내용을 구성 파일과 비교합니다. 차이가 있으면 package 프로그램은 AFS에서 디스크로 파일을 복사하여 로컬 디스크를 적절히 갱신합니다. package 프로그램은 또한 시스템 구성의 일부가 아닌 파일을 삭제하도록 구성하거나 특정 파일(예를 들어 dkload 파일)이 갱신된 경우 클라이언트를 자동으로 재부트하도록 구성할 수 있습니다.

package 프로그램에서는 프로토타입 파일을 준비하기 위해 시간이 걸리지만 다음과 같은 이익을 제공합니다.

- 더 이상 각 시스템을 개별적으로 구성할 필요가 없습니다. 프로토타입 구성 파일은 모든 시스템에 적용됩니다.
- 프로토타입 파일을 변경한 후 클라이언트를 재부트하여 시스템의 구성을 쉽게 바꿀 수 있습니다.
- 디스크 구성은 시스템 그룹에서 동일합니다.
- 구성 파일은 디스크에서 파일 레코드의 역할을 하고 AFS에서는 심볼릭 링크의 역할을 합니다.

### 파일 서버 시스템에서의 Package 사용

package 프로그램은 클라이언트 시스템에서 사용하도록 설계되었지만 파일 서버 시스템의 디스크를 구성할 때도 사용할 수 있습니다. 그러나 구성 파일에서 참조된 파일 중에서 파일 서버의 볼륨에 상주하는 것이 있으면 package 프로그램은 재부트중에 볼륨을 액세스할 수 없습니다(그리고 파일 서버 프로세스와 볼륨 서버 프로세스가 다시 시작할 때까지).

package 프로그램은 파일을 액세스할 수 없을 때 중단되므로 AFS의 파일 중에서 파일 서버 시스템의 볼륨에 상주하는 파일에 대한 참조를 제거해야 합니다. 이런 제한으로 인해 앞으로는 package 프로그램이 클라이언트 구성에서만 사용되는 것으로 간주하겠습니다.

## Package 개요

package 프로그램을 실행하기 전에 수행해야 하는 3가지 주요 단계가 있습니다.

1. 기능별 프로토타입 파일(그리고 포함된 라이브러리 파일) 준비.
2. package Makefile을 수정하고 프로토타입 파일을 시스템별 구성 파일로 컴파일.
3. 적합한 package 구성 파일을 자동으로 실행할 수 있도록 클라이언트 시스템 수정.

다음 절은 이런 단계를 요약합니다.

### 프로토타입 파일 준비

클라이언트 시스템에서 수행하는 여러 기능 및 역할과 이런 기능을 지원하는 로컬 디스크 구성을 나열하는 것으로 시작합니다. 역할 예에는 AFS 액세스를 제공하는 표준 클라이언트, 프린터를 구동하는 인쇄 서버 그리고 백업 스위트에서 명령을 발행하는 백업 시스템이 있습니다. 각 역할마다 서로 다른 프로토타입 파일을 작성하십시오.

프로토타입 파일은 고유 역할을 지원하는 디스크 구성을 정의합니다. 일반적으로, 프로토타입 파일은 기능마다 고유하지만 시스템과는 무관합니다. 시스템별 값은 변수와 라이브러리 파일을 사용하여 정의할 수 있습니다. 그런 후, 변수나 라이브러리 파일을 수정하면 변경사항은 package 프로그램이 호출될 때 적절한 모든 클라이언트로 전달됩니다.

유지하기 쉬운 유연한 프로토타입 파일을 작성하는 방법은 예제 프로토타입 및 라이브러리 파일에 있습니다.

### 프로토타입 파일 컴파일

프로토타입 파일은 보통 시스템과 무관하지만 여러 가지 시스템 유형의 요구를 만족시키기 위해 `ifdef`문을 포함할 수 있습니다. 프로토타입 파일을 컴파일하여 운영 체제 고유 버전을 생성합니다. 컴파일중에 package 프로그램은 각 시스템 유형에 적합한 정의를 선택하고 변수를 실제 값으로 바꿉니다. 이런 컴파일된 시스템 고유 파일은 구성 파일이라고 합니다.

프로토타입 파일은 Package Makefile 파일에 있는 설명대로 표준형의 Makefile 파일을 사용하여 컴파일됩니다.

### 클라이언트 준비

일단 시스템 고유 구성 파일이 있으면 package 프로그램은 클라이언트를 실행할 수 있습니다. 먼저 package 2진을 사용할 수 있게 만들고 올바른 구성 파일을 지정해야 합니다.

다음과 같이 클라이언트를 수정하십시오.

1. 기본 구성 파일을 정의하는 각 클라이언트의 로컬 디스크의 루트(/) 디렉토리에 .package 파일을 작성합니다.
2. 로컬 디스크에서 package 2진(/etc/package)을 사용할 수 있게 만듭니다.
3. 시스템의 초기 파일(/etc/rc 또는 이와 동등한 것)을 수정하여 package 프로그램에 대한 호출을 포함합니다.

이런 단계는 클라이언트 시스템 수정에 더 자세히 설명되어 있습니다.

## package 디렉토리 구조

본 절에서는 package 관련 파일이 AFS 빠른 시작에서 권한 대로 /afs/cellname/wsadmin 디렉토리의 하위 디렉토리인 src, lib 그리고 etc에 설치되어 있다고 간주합니다.

이런 디렉토리에는 여러 예제 프로토타입, 라이브러리 그리고 구성 파일이 있는 데, 이는 package 프로그램의 작업 방법을 명확하게 보여 줄 수 있습니다. 그러나, 이는 사용자 셀에서 사용하기에 적합하지 않을 수도 있습니다. 각자의 요구에 맞도록 수정해야 합니다.

### src 디렉토리

src 디렉토리에는 몇 가지 예제 프로토타입 파일(구성 파일 작성에 사용), 이를 작성하는 데 사용되는 Makefile 파일 그리고 결과인 컴파일된 구성 파일이 있습니다.

프로토타입 파일은 function.proto 양식의 이름을 사용합니다. 예를 들어, minimal.proto 파일은 AFS 실행에 필요한 최소한의 라이브러리 파일 집합을 정의하고 staff.dkload.proto 파일은 동적 커널 로드 프로그램을 사용하는 클라이언트 구성을 정의합니다. 프로토타입 파일에는 hosts.equiv 파일과 같은 시스템 관리 파일에 대한 정의가 있을 수도 있습니다.

Makefile 파일은 시스템과 무관한 프로토타입 파일을 시스템 고유 구성 파일로 컴파일할 때 사용됩니다. 사용자의 셀에서 사용할 수 있도록 이 파일을 수정하는 방법에 대해 알아보려면 Package Makefile 파일을 참조하십시오.

구성 파일은 프로토타입 파일의 컴파일된 버전이며 function.sysname으로 명명됩니다. 구성 파일은 디스크를 구성할 때 package 프로그램이 액세스하는 etc 하위 디렉토리에도 나타납니다.

### lib 디렉토리

lib 디렉토리에는 프로토타입 파일에서 참조되는 여러 예제 라이브러리 파일이 있습니다. 예를 들어, base.generic 파일은 셀 이름 정의, 시스템 옵션 그리고 변수를 포함하는 시스템과 무관한 파일입니다. 이는 파일과 심볼릭 링크 정의에서 owner, group 그리고 mode_bits 필드를 설정하는 데 사용됩니다.

### etc 디렉토리

etc 디렉토리에는 src 하위 디렉토리에 있는 프로토타입 파일에서 작성된 시스템 고유 구성 파일이 있습니다. package 프로그램은 etc 디렉토리에 있는 구성 파일을 사용하여 디스크를 구성합니다.

일부 예제 파일에는 여러 시스템 유형에 대해 컴파일된 minimal과 staff 프로토타입 파일이 있습니다.

## 예제 프로토타입 및 라이브러리 파일

프로토타입 파일은 클라이언트의 로컬 디스크의 구성을 정의하는 템플릿입니다. 프로토타입 파일은 보통 기능마다 고유하지만(예를 들어, 백업 시스템, 인쇄 서버 등) 시스템과 무관합니다. 프로토타입 파일은 `ifdef`문과 변수의 사용을 지원하므로 시스템 고유 정의를 포함할 수 있습니다. 실제 시스템 고유 구성 파일은 프로토타입 파일이 컴파일될 때 생성됩니다.

프로토타입 파일에서 정의되는 구성요소는 디렉토리, 파일, 심볼릭 링크, 블록 특별 장치, 문자 특별 장치와 클라이언트의 로컬 디스크에 상주해야 하는 소켓을 포함하여 인쇄 서버나 백업 시스템과 같은 고유 역할을 수행합니다. 그러므로, 서로 다른 클라이언트 기능마다 고유한 프로토타입 파일을 작성하는 것이 바람직합니다.

package 프로그램을 더 효과적으로 만들고 유지하기 쉽게 하려면 라이브러리 파일과 변수를 사용하여 고유한 것 대신 모듈러 방식의 일반적인 프로토타입 파일을 작성하십시오.

- 범용 라이브러리 파일을 작성하면 같은 라이브러리 파일을 여러 프로토타입 파일에 포함시킬 수 있습니다. 그러므로, 단일 라이브러리 파일을 수정하여 전역으로 구성을 변경할 수 있습니다. 각각의 프로토타입 파일을 수정하지 않아도 됩니다.
- 변수의 값을 변경하여 간단히 정의를 변경할 수 있습니다.

### 예제 프로토타입 파일

다음은 AFS를 실행하는 데 필요한 최소한의 정의가 들어 있는 예제 프로토타입 파일의 일부입니다. minimal.proto라고 하는 비슷한 파일은 src 하위 디렉토리에 상주할 수 있습니다. 권장한 대로 이 프로토타입 파일은 라이브러리 파일을 참조하고 실제 정의는 포함하지 않습니다.

                .
                .
       # Package prototype for a minimal configuration.
       # Base components
       %include ${wsadmin}/lib/base.generic
       # Machine-specific components
       %ifdef rs_aix42
       %include ${wsadmin}/lib/rs_aix42.readonly
       %include ${wsadmin}/lib/rs_aix42.AFS
       %endif rs_aix42
       %ifdef alpha_dux40
       %include ${wsadmin}/lib/alpha_dux40.readonly
       %include ${wsadmin}/lib/alpha_dux40.AFS
       %endif alpha_dux40
       %ifdef sun4x_56
       %include ${wsadmin}/lib/sun4x_56.readonly
       %include ${wsadmin}/lib/sun4x_56.AFS
       %endif sun4x_56
                .
                .

앞 예제에서 주석이 없는 첫 행에는 /lib/base.generic 라이브러리 파일이 포함됩니다. 이 라이브러리 파일에는 여러 프로토타입 파일에 적합한 정의가 있습니다. base.generic 라이브러리 파일은 또한 staff.proto나 backup.proto 파일과 같은 기타 프로토타입 파일에 포함될 수 있습니다. 예제 라이브러리 파일은 다음 절에 나타납니다.

시스템 고유 정의는 `ifdef`문과 변수(예를 들어, `${wsadmin}`은 경로명 지정에 사용됨)의 사용을 통해 허용됩니다. 그러므로, AIX 4.2나 Solaris 2.6에서 서로 다른 파일, 디렉토리, 심볼릭 링크와 장치가 필요해도 같은 프로토타입 파일을 사용하여 이를 실행하는 시스템을 구성할 수 있습니다.

이 예제에서 주석이 없는 다음 행에서 관리자는 시스템 유형마다 서로 다른 라이브러리 파일을 작성했습니다. 각각은 고유한 구성 파일로 컴파일됩니다. 예를 들어, 이 프로토타입 파일에서 다음 행은 package 프로그램에게 `rs_aix42` 값이 선언되었을 때 구성 파일에 대해 lib/rs_aix42.readonly와 lib/rs_aix42.AFS 라이브러리 파일을 사용하도록 지시합니다(시스템 유형 정의는 Makefile에서 선언됩니다. Package Makefile 파일을 참조하십시오).

       %ifdef rs_aix42
       %include ${wsadmin}/lib/rs_aix42.readonly
       %include ${wsadmin}/lib/rs_aix42.AFS
       %endif rs_aix42

이와 비슷하게, 다음 행은 package 프로그램에게 `sun4x_56` 값이 선언되었을 때 lib/sun4x_56.readonly와 lib/sun4x_56.AFS 라이브러리 파일을 사용하도록 지시합니다.

       %ifdef sun4x_56
       %include ${wsadmin}/lib/sun4x_56.readonly
       %include ${wsadmin}/lib/sun4x_56.AFS
       %endif sun4x_56

### 예제 라이브러리 파일

다음은 기본 구성 정의에 대한 예제 라이브러리 파일의 일부입니다. base.generic라고 하는 비슷한 파일은 lib 하위 디렉토리에 상주할 수 있습니다. 구성은 표준 `ifdef`문을 사용하여 정의된다는 점에 유의하십시오.

                .
                .
       #
       # Base package definitions.
       #
       %ifndef	cell
       %define	cell	abc.com
       %endif	cell
       %ifndef	sys
       %include /etc/package.sys
       %endif	sys
       %define	${name}		${name}
       %define	${cpu}		${cpu}
       %define	${sys}		${sys}
       %define	${dept}		${dept}
       %define	${hostname}	${hostname}
       %ifdef	rs_aix42
       %	define 	AIX
       %	define	rootlinks
       %ifndef	noafsd
       %	define	afsd
       %endif	noafsd
       %endif	rs_aix42
                .
                .
       #
       # Some definitions to handle common combinations of owner, group,
       # and protection fields.
       #
       %define	rzmode		root wheel 600
       %define	usermode	root wheel 666
       %define      systemmode	root wheel 644
       %define	diskmode	root wheel 644
       %define	ptymode		root wheel 666
       %define	ttymode		root wheel 666
                .
                .
       %define aix_rootbin	   root bin
       %define aix_rootprintq  root printq
       %define aix_rootstaff   root staff
       %define aix_rootsys	   root system
       %define aix_binbin      bin bin
       %define aix_binmail	   bin mail
       %define aix_binsys	   bin system
       %define aix_addsys	   adduser system
       %define aix_romode	   444
       %define aix_loginmode   544
       %define aix_usermode	   666
       %define aix_systemmode  644
       %define aix_textmode	   644
       %define aix_rwmode1	   660
       %define aix_allrugw	   664

다음 예제 라이브러리 파일은 package에 고유한 구문을 사용하여 파일, 디렉토리, 소켓 등을 정의합니다. 구성 파일 명령이라고 하는 각 행은 디스크 구성의 고유한 구성요소를 정의합니다. 이런 명령에 맞는 구문은 패키지 구성 파일 명령 구문에서 간단하게 설명하고 있습니다. 자세한 내용은 AFS Administration Reference에 있는 package 구성 파일의 참조 페이지를 참조하십시오.

이 예제에서 라이브러리 파일에는 rs_aix42 시스템의 구성에 고유한 명령이 있습니다. lib 하위 디렉토리에 있는 비슷한 라이브러리 파일을 사용할 수 있습니다.

                .
                .
       #
       # Generic configuration for an AFS rs_aix42 machine.
       #
       D	/                                       ${treemode}
       D	/afs
       FAQ	/unix	       ${machine}/unix.std 	${binmode}
       LA	/unix.std	/unix
       D	/bin					${treemode}
       F	/bin/as		${machine}		${binmode}
       F	/bin/ld		${machine}		${binmode}
       F	/bin/nm		${machine}		${binmode}
       FO	/bin/login	${afstest}		${suidmode}
                .
                .
       FAQ  /usr/vice/etc/ThisCell  ${common}/etc/ThisCell ${textmode}
       FQ	/usr/vice/etc/afsd      ${afstest}/root.client ${binmode}
       FA	/usr/vice/etc/bos       ${afstest}/bin/bos     ${binmode}
       FA	/usr/vice/etc/fs        ${afstest}/bin/fs      ${binmode}

## 패키지 구성 파일 명령 구문

라이브러리 파일에서 구성 파일 명령은 고유 디스크 구성을 정의할 때 사용됩니다. 각 명령을 사용하여 파일, 디렉토리, 소켓 또는 클라이언트 시스템의 장치를 정의할 수 있습니다. 유효한 각 명령 유형의 구문은 여기서 간단하게 설명합니다. 필드에 대한 자세한 설명은 AFS Command Reference Manual에 있습니다.

- D는 디렉토리를 정의합니다
- F는 파일을 정의합니다
- L은 링크를 정의합니다
- B는 블록 특별 장치를 정의합니다
- C는 문자 특별 장치를 정의합니다
- S는 소켓을 정의합니다

주: | 각 구성 명령은 끊기지 않은 하나의 행에 표시되어야 합니다. 여기서 명령은 때때로 읽기 편하도록 여러 행에 나타날 수 있습니다. 구성 파일은 정확해야 합니다. 구문 오류가 있거나 틀린 값이 있으면 package 명령 인터프리터는 명령을 실행하지 않고 종료합니다.

### 로컬 파일과 심볼릭 링크 비교

로컬 클라이언트 디스크에서 파일의 수를 최소한으로 유지하여 AFS를 활용할 수 있습니다. 대신 AFS를 가리키는 심볼릭 링크를 작성하십시오. 이는 캐슁과 스와핑에 더 많은 공간을 허용하여 시스템의 성능을 향상시킬 수 있습니다.

그러나, 일부 파일은 다음 설명대로 로컬 디스크에 상주해야 합니다. 이런 파일을 L(심볼릭 링크) 명령이 아닌 F(파일) 명령을 사용하여 프로토타입이나 라이브러리 파일에서 작성합니다.

다음 파일 유형은 모든 AFS 클라이언트의 로컬 디스크에 상주해야 합니다.

- afsd 프로그램 실행 전에 실행된 순서 파일을 부팅합니다.

  afsd가 실행하고 캐쉬 관리 프로그램을 초기화할 때까지 AFS를 클라이언트에서 액세스할 수 없습니다. afsd 프로그램이 실행하기 전에 실행되어야 하는 모든 파일은 로컬 클라이언트 디스크에 상주해야 합니다.

  예를 들어, 디스크 캐쉬를 사용하는 시스템에서 캐쉬 파일을 작성할 수 있는 자리가 있도록 /usr/vice/cache 디렉토리는 캐쉬 관리 프로그램을 불러올 때 있어야 합니다. 2진 파일인 /etc/mount와 /etc/umount는 /usr/vice/cache 디렉토리를 마운트하기 위해 로컬 디스크에서 시스템 부트로 사용할 수 있어야 합니다.

  이 외에도, 초기화 파일(/etc/rc 또는 이와 동등한 것) 및 파일 시스템 맵핑 파일(/etc/fstab 또는 이와 동등한 것)과 같은 특정 UNIX 파일은 로컬 디스크에 상주해야 합니다.

- 진단 및 복구 파일

  특정 명령을 사용하여 파일 서버 정전으로 발생하는 문제를 진단하고 복구할 수 있습니다. 이런 명령에 대한 2진의 복사본을 로컬 디스크에 보관하는 것이 가장 좋습니다. 예를 들어, bos 및 fs 2진을 로컬 디스크의 /usr/vice/etc 디렉토리와 /usr/afsws 디렉토리(여기서 전형적인 구성은 AFS로의 심볼릭 링크임)에 저장합니다. 그런 후, /usr/afsws 디렉토리가 /usr/vice/etc 디렉토리 전에 나타나도록 PATH 변수를 설정합니다. 그러면, 사용자가 AFS를 액세스할 수 없어도(예를 들어, 파일 서버 정전으로 인하여) 계속 로컬 디스크의 /usr/vice/etc 디렉토리에서 bos와 fs 2진의 복사본을 액세스할 수 있습니다.

- /usr/vice 디렉토리에 있는 파일

  cache 하위 디렉토리에 있는 캐쉬 파일과 etc 하위 디렉토리에 있는 구성 파일을 포함한 /usr/vice 디렉토리의 내용은 로컬 디스크에 상주해야 합니다. 디렉토리에 있는 파일의 설명은 로컬 디스크에서의 구성 및 캐쉬 관련 파일을 참조하십시오.

### 디렉토리 정의

D 명령은 로컬 디스크에 작성할 디렉토리를 정의합니다. 로컬 디스크에 있는 심볼릭 링크, 파일 또는 기타 요소가 같은 이름을 사용하면 이는 디렉토리로 바뀝니다. 디렉토리가 이미 있으면 그 소유자, 그룹 그리고 모드 비트는 필요한 경우 명령을 따르도록 변경됩니다.

다음 명령을 사용하여 디렉토리를 정의하십시오.

       D [update_code] directory owner group mode_bits

다음 예는 /usr 디렉토리를 정의합니다.

       D /usr root wheel 755

### 파일 정의

F 명령은 로컬 디스크에서 작성할 파일을 정의합니다. 원본 파일은 AFS나 로컬 디스크에 상주할 수 있습니다.

이 이름을 사용하는 파일이 이미 있으면 I 갱신 코드가 지정되지 않는 이상 이는 원본 파일로 갱신됩니다(겹쳐쓰여짐). 이 이름을 사용하는 심볼릭 링크나 라이브러리가 있으면 package 프로그램은 이를 원본 파일로 바꿉니다.

주: | 일부 파일은 로컬 디스크에 상주해야 합니다. 이는 심볼릭 링크가 될 수 없습니다. 로컬 파일과 심볼릭 링크 비교를 참조하십시오.

다음 명령을 사용하여 파일을 정의하십시오.

       F [update_code] file source_file [owner group mode_bits]

로컬 디스크에서 /bin/grep 파일을 작성/갱신하는 예에서 /afs/abc.com/rs_aix42/bin/grep을 원본으로 사용합니다.

       F /bin/grep /afs/abc.com/rs_aix42 root wheel 755

다음 예에서 두 갱신 코드가 사용되고 owner, group 그리고 mode_bits 슬롯은 비어 있는 상태로 남으므로 디스크 파일은 이런 파일에 대해 원본 파일의 값을 사용합니다.

       FAQ /usr/vice/etc/ThisCell /afs/abc.com/common/etc/ThisCell

### 심볼릭 링크 정의

L 명령은 로컬 디스크에서 작성할 심볼릭 링크를 정의합니다. 심볼릭 링크는 AFS 파일 시스템이나 로컬 디스크를 가리킬 수 있습니다. 똑같은 심볼릭 링크가 이미 있으면 package 프로그램을 아무 작업도 수행하지 않습니다. 그러나, 디스크에 같은 이름을 사용하는 요소가 파일이나 디렉토리로 있으면 package 프로그램은 요소를 심볼릭 링크로 바꿉니다.

주: | 일부 파일은 로컬 디스크에 상주해야 합니다. 이는 심볼릭 링크가 될 수 없습니다. 로컬 파일과 심볼릭 링크 비교를 참조하십시오.

다음 명령을 사용하여 심볼릭 링크를 정의하십시오.

       L [update_code] link actual_file  [owner group mode_bits]

주: | 이름이 숫자 기호(#)나 퍼센트 기호(%)로 시작하는 파일에 심볼릭 링크를 작성하지 마십시오. 캐쉬 관리 프로그램은 일반 읽기/쓰기 볼륨에서 이런 링크를 마운트 포인트로 해석합니다.

다음 예는 로컬 디스크의 /etc/ftpd 디렉토리에서 AFS의 /afs/abc.com/hp_ux110/etc/ftpd 파일로 심볼릭 링크를 작성합니다. owner, group 그리고 mode_bits 필드는 비어 있으므로 심볼릭 링크는 실제 파일에서 이런 필드의 값을 가져옵니다.

       L /etc/ftpd /afs/abc.com/hp_ux110

이 예는 A 갱신 코드를 사용합니다.

       LA /etc/printcap /afs/abc.com/common/etc/printcap.remote
                   root wheel 644

### 블록 특별 장치 정의

B 명령은 디스크와 같은 다중바이트 블록의 단위로 데이터를 처리하는 장치인 블록 특별 장치를 정의합니다. 같은 이름을 사용하는 장치가 이미 있으면 package 프로그램은 이를 지정된 블록 장치로 바꿉니다.

다음 명령을 사용하여 블록 특별 장치(알아보기 쉽도록 여기서만 두 행에 걸쳐 표시됨)를 정의합니다.

       B device_name   major_device_number   minor_device_number  \
          owner   group   mode_bits

다음 예는 /dev/hd0a라고 하는 디스크에 주 장치 번호 1과 부 장치 번호 0이 오도록 정의합니다.

       B /dev/hd0a 1 0 root wheel 644

### 문자 특별 장치 정의

C 명령은 터미널이나 tty와 같이 데이터를 한번에 문자 하나의 단위로 처리하는 장치인 문자 특별 장치를 정의합니다. 같은 이름을 사용하는 장치가 이미 있으면 package 프로그램은 이를 지정된 문자 장치로 바꿉니다.

다음 명령을 사용하여 문자 특별 장치(알아보기 쉽도록 여기서만 두 행에 걸쳐 표시됨)를 정의합니다.

       C device_name   major_device_number   minor_device_number  \
          owner   group   mode_bits

다음 예는 /dev/ttyp5라고 하는 tty에 주 장치 번호 6과 부 장치 번호 5가 오도록 정의합니다.

       C /dev/ttyp5 6 5 root wheel 666

### 소켓 정의

S 명령은 UDP와 TCP/IP 연결의 통신 장치인 소켓을 정의합니다. 같은 이름을 사용하는 소켓이 이미 있으면 package 프로그램은 이를 바꿉니다.

다음 명령을 사용하여 소켓을 정의하십시오.

       S   socket_name  [owner group mode_bits]

다음 예는 /dev/printer라고 하는 소켓을 정의합니다.

       S /dev/printer root wheel 777

## 프로토타입 및 라이브러리 파일 구성

이 절에서는 package 프로토타입과 라이브러리 파일을 작성하는 데 필요한 일반 단계를 설명합니다. 지침으로 이전 절을 참조하고 예제는 wsadmin 디렉토리에서 참조하십시오. 프로토타입과 라이브러리 파일의 구성은 각 셀마다 다릅니다.

### 프로토타입과 그 구성요소 라이브러리 파일을 구성하려면

1. 셀의 파일 트리에서 3가지 package 관련 하위 디렉토리(src, lib 그리고 etc)가 상주하는 위치를 결정합니다. 다음 명령은 AFS 빠른 시작의 설명대로 /afs/cellname/wsadmin 디렉토리에 이런 디렉토리가 로드되었다고 간주합니다.
2. 셀의 클라이언트 시스템에서 수행할 기능의 수를 결정합니다. 각 기능마다 별도의 프로토타입 파일을 구성하는 것이 바람직합니다. 공동 기능에는 다음이 포함됩니다.
   - 표준 워크스테이션: 사용자에게 AFS에 있는 파일에 대한 액세스를 제공합니다.
   - 프린터 서버: 프린터를 구동합니다. 이를 "직원" 기능과 결합할 수 있습니다.
   - 백업 시스템: AFS 백업 시스템 소프트웨어를 실행하여 AFS 볼륨의 백업을 테이프에 수행합니다
3. 모든 클라이언트(예를 들어, AFS 설정)에 필요한 최소한의 기능을 결정하고 이런 일반 정의를 두 개 이상의 라이브러리 파일에 보관합니다.
4. 각 클라이언트 유형(프린터 서버, 백업 시스템 등)마다 시스템과 무관한 모든 정의를 파일 하나에 보관하고 운영 체제마다 다른 모든 정의를 또 다른 파일에 보관합니다.

## Package Makefile 파일

일단 적합한 프로토타입과 라이브러리 파일을 작성하면 각 시스템 유형마다 프로토타입을 컴파일해야 합니다. 결과는 시스템마다 고유한 구성 파일입니다.

Makefile 파일은 사용된 프로토타입과 라이브러리 파일 그리고 컴파일 순서를 정의합니다. 이 절에서 설명하는 대로 AFS를 분배할 때 함께 제공되는 예를 수정하여 Makefile 파일을 작성하는 것이 바람직합니다. 전형적인 구성에서 이는 /afs/cellname/wsadmin/src/Makefile에 위치합니다.

### 개요

다음 목록은 섹션을 시작하는 헤더 이름으로 식별되는 package Makefile 파일의 섹션을 요약합니다. 자세한 설명은 다음과 같습니다.

`CONFIG=`
  작성되고 시스템 유형마다 컴파일되는 프로토타입 파일을 정의하는 모든 구성 파일을 나열합니다. CONFIG 섹션을 참조하십시오.

`BASE_LIBS=`
  모든 프로토타입 파일에 포함된 모든 운영 체제 및 기능에 무관한 라이브러리 파일의 경로 이름을 나열합니다. BASE_LIBS 섹션을 참조하십시오.

`MACHINE_LIBS=`
  모든 프로토타입 파일에 포함된 모든 운영 체제마다 고유한 라이브러리 파일의 경로 이름을 나열합니다. MACHINE_LIBS 섹션을 참조하십시오.

`LIBS=`
  `LIBS`를 `BASE_LIBS`와 `MACHINE_LIBS`의 조합으로 정의하는 일 행 명령입니다. LIBS 섹션을 참조하십시오.

`.SUFFIXES`
  프로토타입이나 구성 파일에 표시될 수 있는 모든 접미어를 정의합니다. .SUFFIXES 섹션을 참조하십시오.

마지막으로 Makefile 파일에는 package 프로그램이 구성 파일을 생성하기 위해 따르는 명령 세트가 들어 있습니다. 일반적으로 이 섹션을 변경할 필요가 없습니다. Makefile 명령 섹션을 참조하십시오.

### CONFIG 섹션

앞에서 언급했듯이 구성 파일은 특정 운영 체제 유형에 대해 컴파일된 프로토타입 파일입니다. Makefile 파일의 `CONFIG` 섹션은 각 시스템 유형마다 컴파일할 프로토타입 파일을 정의합니다. 결과의 컴파일된 파일은 시스템마다 고유한 구성 파일입니다.

Makefile 파일 예에서 취한 다음 예를 살펴보십시오. 구성 파일은 프로토타입-시스템 조합을 prototype_file.sysname으로 지정하여 정의됩니다. 각 프로토타입-시스템 유형 조합마다 구성 파일을 생성할 필요는 없습니다.

       #Makefile...
       #	(C) Copyright IBM Corporation 1999
       #	Licensed Materials - Property of IBM
       #	All Rights Reserved.
       #
       CONFIG = \
                staff.rs_aix42 \
                staff.alpha_dux40 \
                staff.xdm.alpha_dux40 \
                staff.sun4x_56 \
                staff.hp_ux110 \
                minimal.rs_aix42 \
                minimal.alpha_dux40 \
                minimal.hp_ux110 \
                minimal.sun4x_56

`CONFIG` 섹션의 항목은 다음 형식을 사용합니다.

- 항목의 첫 부분은 프로토타입 파일을 정의하고 프로토타입 파일 이름과 같습니다(.proto 확장자 없음). 항목의 둘째 부분은 프로토타입 파일이 컴파일될 시스템 유형을 나타냅니다. 이런 접미어의 완전한 목록은 .SUFFIXES 섹션의 설명 대로 Makefile 파일의 `.SUFFIXES` 섹션에 있습니다. 이 prototype_file.sysname 정의는 컴파일된 구성 파일의 이름이 됩니다.

  예를 들어, staff.rs_aix42는 staff.proto 파일은 AIX 4.2를 실행하는 시스템에 대해 컴파일된다는 것을 나타냅니다. 결과의 컴파일된 구성 파일은 staff.rs_aix42라고 합니다.

- 각 구성 파일은 별도의 행에 나타나야 합니다.
- 역슬래쉬는 마지막 행을 제외하고 `CONFIG=` 헤더 및 모든 이름 다음에 와야합니다. 역슬래쉬는 빈 행에도 나타나야 합니다.

### BASE_LIBS 섹션

이 섹션은 프로토타입 파일에 포함된 모든 시스템 및 기능에 무관한 라이브러리 파일의 완전한 경로 이름을 정의합니다(시스템 고유 라이브러리 파일은 `MACHINE_LIBS` 섹션에 정의되어 있음). 경로 이름에는 make 명령행에서 값을 제공하는 `${wsadmin}` 변수가 포함됩니다.

프로토타입 파일에 참조되는 모든 라이브러리 파일을 포함해야 합니다. 포함되었지만 사용되지 않는 파일은 무시됩니다.

다음 예를 살펴보십시오. 모든 항목(단, 마지막 것 제외) 다음에는 역슬래쉬가 와야 합니다.

       BASE_LIBS = \
    	   ${wsadmin}/src/admin \
    	   ${wsadmin}/lib/devel \
    	   ${wsadmin}/lib/base.generic

### MACHINE_LIBS 섹션

이 섹션은 프로토타입 파일에 포함된 모든 운영 체제 고유 라이브러리 파일의 완전한 경로 이름을 나열합니다(시스템 및 기능에 무관한 라이브러리 파일은 `BASE_LIBS` 섹션에 정의되어 있습니다).

다음 예를 살펴보십시오. 이 예에서 라이브러리 파일은 운영 체제 유형별로 나누었습니다. 다시 한번, 모든 행(마지막 것 제외) 다음에는 역슬래쉬가 와야 하고 `${wsadmin}` 변수가 허용되며 포함되었지만 사용되지 않은 파일은 무시됩니다.

       MACHINE_LIBS = \
               ${wsadmin}/lib/rs_aix42.generic \
               ${wsadmin}/lib/rs_aix42.generic.dev \
               ${wsadmin}/lib/rs_aix42.readonly \
               ${wsadmin}/lib/rs_aix42.readwrite \
               ${wsadmin}/lib/rt_aix42.generic.printer \
        \
        .
        .
               ${wsadmin}/lib/alpha_dux40.AFS \
               ${wsadmin}/lib/hp_ux110.AFS \
               ${wsadmin}/lib/sun4x_56.AFS \
               ${wsadmin}/lib/rs_aix42.AFS

### LIBS 섹션

이 섹션에는 `LIBS`가 `MACHINE_LIBS` 및 `BASE_LIBS`의 조합으로 정의되었다는 것을 나타내는 명령 하나만 들어 있습니다. 행 다음에 빈 행을 넣어 이 섹션을 다음 섹션과 구분하십시오.

       LIBS = ${MACHINE_LIBS} ${BASE_LIBS}

### .SUFFIXES 섹션

이 섹션은 유효한 시스템 유형 접미어를 나열합니다. 이 목록에는 AFS에 대해 현재 지원되는 시스템 유형이 들어 있습니다. 사용되지 않는 접미어는 무시됩니다.

       .SUFFIXES: .rs_aix42 \
                  .alpha_dux40 \
                  .proto \
                  .sun4x_56 \
                  .i386_linux22 \
                  .hp_ux110

### Makefile 명령 섹션

Makefile 파일의 나머지는 package 프로그램이 구성 파일을 생성하는 방법을 제어합니다.

다음 명령을 살펴보십시오. 여기서 사용자는 프로그래밍과 Makefile 개념에 익숙해 있다는 가정하에서 시작합니다.

       #The following appear on a single line each in the actual file
       .proto.rs_aix42: ;  mpp -Dwsadmin=${wsadmin} -Dsys=rs_aix42
                               -Dname=$* $*.proto > $@
       .proto.alpha_dux40: ; mpp -Dwsadmin=${wsadmin} -Dsys=alpha_dux40
                               -Dname=$* $*.proto > $@
       .proto.sun4x_56:  ; mpp -Dwsadmin=${wsadmin} -Dsys=sun4x_56
                               -Dname=$* $*.proto > $@
       .proto.hp_ux110:  ; mpp -Dwsadmin=${wsadmin} -Dsys=hp_ux110
                               -Dname=$* $*.proto > $@
       all: ${CONFIG}
       ${CONFIG}: ${LIBS}
       system: install
       install: ${CONFIG}
    	   cp ${CONFIG} ${wsadmin}/etc
       clean:
    	   rm -f ${CONFIG} *.BAK *.CKP

## Makefile 수정

다음과 같은 경우에 package Makefile 파일을 수정하십시오.

- 새 프로토타입 파일(function.proto) 추가.
- 새 시스템 유형 추가.
- 새 라이브러리 파일 추가.

다음 절은 이런 이유로 Makefile 파일을 수정하는 방법에 대한 간단한 예를 제공합니다.

### 새 프로토타입 파일 추가

새 프로토타입 파일을 작성할 때 파일 이름과 그 시스템 유형을 Makefile 파일의 `CONFIG` 섹션에 추가합니다.

예를 들어, alpha_dux40과 hp_ux110에 대해 function.proto 파일을 추가하려면 다음 항목을 `CONFIG` 섹션에 추가하십시오.

       CONFIG = \
       ...
               function.alpha_dux40 \
               function.hp_ux110 \
       ...

이 프로토타입 기능에 대해 새 라이브러리 파일을 추가한 경우 이를 `MACHINE_LIBS` 섹션에 추가하십시오.

### 새 시스템 유형 추가

새 시스템 유형을 작성할 각 프로토타입 파일에 대해 항목을 `CONFIG` 섹션에 추가합니다. 또한, 새 라이브러리를 `MACHINE_LIBS` 섹션에 추가하고 새 시스템 유형을 `.SUFFIXES` 섹션에 추가합니다.

다음 예는 이 새 시스템 유형에 대해 staff와 minimal 프로토타입을 작성할 때 적합한 수정을 보여줍니다.

       CONFIG = \
       ...
               staff.sysname \
               minimal.sysname \
       ...

이 새 시스템 유형에 해당하는 라이브러리 파일을 작성하면 이를 `MACHINE_LIBS` 섹션에 추가합니다.

       MACHINE_LIBS = \
       ...
               ${wsadmin}/lib/sysname.generic \
               ${wsadmin}/lib/sysname.generic.dev \
               ${wsadmin}/lib/sysname.readonly \
               ${wsadmin}/lib/sysname.readwrite \
       ...

새 시스템 유형을 `SUFFIXES` 섹션에 추가합니다.

       .SUFFIXES: ...\
                .sysname \
       ...

나머지 명령으로 섹션에 있는 이 시스템에 대해 구성 파일을 작성하기 위한 행을 추가하여 구성 파일을 작성하십시오.

       .proto.sysname: ; mpp -Dwsadmin=${wsadmin} \
       -Dsys=sysname  -Dname=$* $*.proto > $

### 새 라이브러리 파일 추가

각 시스템 유형마다 새 라이브러리 파일인 sysname.library_file을 추가하면 이런 파일을 Makefile의 MACHINE_LIBS 섹션에 추가하십시오.

       MACHINE_LIBS = \
       ...
               ${wsadmin}/lib/rs_aix42.library_file \
       ...
               ${wsadmin}/lib/alpha_dux40.library_file \
       ...
               ${wsadmin}/lib/sun4x_56.library_file \
       ...

모든 시스템 유형에 공통인 새 라이브러리 파일인 library_file을 추가하면 이를 `BASE_LIBS` 섹션에만 추가하십시오.

       BASE_LIBS = \
       ...
               ${wsadmin}/lib/library_file \
       ...

## 프로토타입 파일 컴파일

package 프로그램은 구성 파일을 생성하고 이를 make 명령행에서 wsadmin=으로 지정된 디렉토리의 etc와 src 하위 디렉토리에 설치합니다. 프로토타입이나 라이브러리 파일을 수정할 때마다 다시 컴파일하십시오.

### 프로토타입 파일을 컴파일하려면

주: | 이런 명령은 사용자가 자신의 package 관련 파일을 /afs/cellname/wsadmin 디렉토리에 저장한다고 가정합니다. 다른 디렉토리를 사용하면 그 이름을 /afs/cellname/wsadmin으로 대체하십시오.

1. /afs/cellname/wsadmin 디렉토리와 src, lib 그리고 etc 하위 디렉토리에 모든 특권이 있는지 확인합니다. 필요한 경우, fs listacl 명령을 실행하십시오.

          % fs listacl [dir/file path]

2. /afs/cellname/wsadmin/src 하위 디렉토리로 변경합니다.

          % cd /afs/cellname/wsadmin/src

3. AFS를 분배할 때 포함되는 Makefile 파일의 백업 복사본을 작성합니다.

          % cp  Makefile Makefile.example

4. CONFIG 섹션, BASE_LIBS 섹션 그리고 MACHINE_LIBS 섹션의 설명 대로 Makefile 파일의 `CONFIG`, `BASE_LIBS` 그리고 `MACHINE_LIBS` 섹션을 수정합니다.
5. make command.

   wsadmin= 인수를 사용하여 package 디렉토리를 지정합니다. 이는 프로토타입과 라이브러리 파일에서 `${wsadmin}` 변수의 값이 됩니다.

   package 프로그램은 구성 파일을 생성하고 이를 wsadmin=으로 지정된 디렉토리의 etc와 src 하위 디렉토리에 설치합니다.

          %
       make system wsadmin=/afs/cellname/wsadmin

## 클라이언트 시스템 수정

package 프로그램을 자동으로 실행하도록 클라이언트를 준비하려면 다음 단계를 수행하십시오. 명령은 시스템 고유 구성 파일을 참조하지 않으므로 일반적입니다. 원하는 경우 AFS Administration Reference의 설명 대로 고유 인수를 사용하여 package 프로그램을 호출할 수 있습니다.

1. 사용할 구성 파일을 지정합니다.

   클라이언트 시스템의 루트(/) 디렉토리에 있는 .package 파일은 package 명령에 인수로 방향 전환됩니다. .package 파일은 package 프로그램에서 사용하는 구성 파일을 지정합니다.

2. package 2진을 로컬 디스크에 복사하거나 AFS에 대한 심볼릭 링크를 만들어서 클라이언트에서 사용할 수 있게 만드십시오.
   - 심볼릭 링크는 로컬 디스크 공간을 절약합니다. 그러나, package 2진이 들어 있는 파일 서버 시스템이 중단되면 액세스할 수 없습니다.
   - package 2진을 로컬 디스크에 보존하면 파일 서버가 중단된 경우에도 package 프로그램을 실행할 수 있습니다. 그러나, 대부분의 구성 파일 명령이 AFS에 있는 파일을 참조하므로 파일 서버 시스템이 정지되면 보통 package 프로그램을 실행하기 어렵게 됩니다. package 2진의 로컬 복사본은 명령에서 참조한 파일이 복제된 볼륨에 있는 경우 유용합니다.
3. 클라이언트 시스템의 초기설정 파일을 수정하여 재부트할 때 package 프로그램을 호출합니다. 클라이언트 시스템은 package 프로그램이 Q 갱신 코드로 표시된 파일을 갱신할 때 다시 한번 재부트합니다.

### package 프로그램을 실행하도록 클라이언트 시스템을 준비하려면

package 프로그램을 실행하는 모든 클라이언트에서 다음 명령을 반복 수행하십시오.

이런 명령은 package 구성 파일(프로토타입 파일이 컴파일될 때 작성됨)이 /afs/cellname/wsadmin/etc 디렉토리에 상주한다고 간주합니다.

1. 시스템에서 로컬 수퍼유저 루트가 아닌 경우 su 명령을 실행하여 이러한 권한을 얻으십시오.

          % su root
          Password: root_password

2. 루트(/) 디렉토리에서 .package 파일을 작성하고 사용할 프로토타입 파일의 이름을 지정합니다. 시스템 유형 접미어(예를 들어, .rs_aix42)를 포함하지 마십시오. package 프로그램을 올바른 시스템 유형을 자동으로 결정합니다.

          # echo
       "/afs/cellname/wsadmin/etc/config_file" >> /.package

   예를 들어, 시스템을 직원용 시스템으로 구성하려면(적합한 프로토타입 파일이 그 시스템 유형에 대해 정의되고 컴파일되었다고 간주) 이에 해당하는 명령은 다음과 같습니다.

          # echo "/afs/cellname/wsadmin/etc/staff" >> /.package

3. 로컬 디스크에서 package 2진을 /etc/package로 사용할 수 있게 만듭니다. 파일 또는 심볼릭 링크 작성에 따라 다음 명령 중 하나를 실행하십시오.

   package 2진을 로컬에 저장하려면 다음 명령을 입력하십시오.

          # cp
       /afs/cellname/sysname/usr/afsws/etc/package   /etc/package

   심볼릭 링크를 작성하려면 다음 명령을 입력하십시오.

          # ln -s /afs/cellname/sysname/usr/afsws/etc/package   /etc/package

4. afsd 명령을 호출한 다음에 다음 행을 적합한 초기설정 파일에 추가합니다. 파일 서버 시스템인 경우 bosserver 명령은 package 명령 다음에 와야 합니다.

   -v와 -c 옵션을 사용하는 것이 바람직합니다. -v 플래그는 자세한 추적을 생산하고 -c 옵션은 시스템 유형을 구성 파일의 기본 이름에 추가합니다. 기타 옵션에 대한 설명은 AFS Administration Reference를 참조하십시오.

   주: | shutdown 명령이 시스템 재부트에 적합하지 않으면 이를 비슷한 명령으로 바꾸십시오.

          if [ -f /etc/package ]; then
                  if [ -f /.package ]: then
                          /etc/package -v -c `cat /.package` >/dev/console
                  else
                          /etc/package -v >/dev/console
          fi
          case $? in
          0)
                  echo "Package completed successfully" >/dev/console 2>&1
                  date >/dev/console 2>&1
                  ;;
          4)
                  echo "Rebooting to restart system" >/dev/console 2>&1
                  echo >/fastboot
                  shutdown
                  ;;
          *)
                  echo "Update failed, continuing anyway" >/dev/console 2>&1
                  ;;
          esac
          fi

## package 프로그램 실행

프로토타입 파일을 작성 및 컴파일하고 클라이언트 시스템을 수정한 다음 package 프로그램을 실행할 수 있습니다. 재부트할 때 시스템의 AFS 초기설정 파일에서 package 프로그램을 호출하여 자동으로 실행하는 것이 가장 편리할 것입니다. 명령 쉘 프롬프트에서 명령을 실행할 수도 있습니다.

구성 파일은 정확해야 합니다. 구문 오류가 있거나 틀린 값이 있으면 프로그램을 명령을 실행하지 않고 종료합니다. 구성 파일을 확인하려면 명령 쉘 프롬프트에서 package 명령을 -noaction과 -debug 플래그와 함께 실행하십시오. 명령을 실제로 실행하지 않고 잠재적인 문제 목록을 표시합니다.

package 프로그램은 다음과 같은 일반 규칙을 따릅니다. 완전한 설명은 패키지 구성 파일 명령 구문에 있습니다.

- package 프로그램은 프로토타입 파일에 R 갱신 코드가 지정되지 않는 이상 디스크에서 파일을 삭제하지 않습니다. R 갱신 코드가 상위 디렉토리와 연관되어 있으면 package 프로그램은 로컬 디스크 디렉토리에서 구성 파일에 지정되지 않은 모든 것을 제거합니다.
- 로컬 파일은 오래된 경우에만 갱신됩니다. 구성 파일의 각 F 명령에 대해 package 프로그램은 로컬 파일의 시간을 지정된 원본 파일과 비교합니다. 원본 파일이 로컬 파일보다 최근 것이면 파일이 갱신됩니다.
- 초기설정 파일이 클라이언트 시스템 수정에서 권장하는 대로 수정될 때 Q 갱신 코드로 표시된 파일이 갱신되고 package 프로그램이 초기설정 파일에서 호출되면 package 프로그램은 워크스테이션을 자동으로 재부트합니다. Q 갱신 코드로 표시된 파일이 변경되면 package 프로그램은 상태 코드 4와 함께 종료하고 재부트(초기설정 파일에서 지시하는 대로)를 일으킵니다. 변경사항을 인식하기 전에 재부트되어야 하는 파일(예를 들어, 운영 체제 커널과 /usr/vice/etc/CellServDB 파일)은 구성 파일에서 Q 갱신 코드로 표시되어야 합니다.
- package 프로그램은 /etc/package.sysname에서 방금 사용한 구성 파일을 복사합니다. 여기서 sysname은 이 시스템의 시스템 유형을 나타냅니다. 구성 파일 이름을 입력하지 않으면 package 명령 인터프리터는 이 파일을 참조합니다. 이것이 원하는 대로 로컬 디스크를 구성하는지 확인하려면 그 내용을 검토하십시오.

### 재부트로 package 프로그램을 호출하려면

1. 시스템에서 로컬 수퍼유저 루트가 아닌 경우 su 명령을 실행하여 이러한 권한을 얻으십시오.

          % su root
          Password: root_password

2. (권장사항) 다음을 확인하십시오.
   - /.package 파일은 원하는 구성 파일을 식별합니다
   - package 2진은 /etc/package로 사용할 수 있습니다
   - 초기설정 파일은 package 프로그램을 자동으로 호출할 수 있도록 적절히 수정됩니다
3. 적절한 명령을 사용하여 시스템을 재부트합니다.

          # shutdown

### package 프로그램을 직접 호출하려면(재부트하지 않고)

1. 시스템에서 로컬 수퍼유저 루트가 아닌 경우 su 명령을 실행하여 이러한 권한을 얻으십시오.

          % su root
          Password: root_password

2. 다음을 확인하십시오.
   - /.package 파일은 원하는 구성 파일을 식별합니다
   - package 2진은 /etc/package로 사용할 수 있습니다
   - 초기설정 파일은 package 프로그램을 자동으로 호출할 수 있도록 적절히 수정됩니다
3. package 명령을 실행합니다.

          # package  [initcmd]  [-config <base name of configuration file>]  \
           [-fullconfig <full name of configuration file, or stdin for standard input>]  \
           [-overwrite]  [-noaction]
       [-verbose]  [-silent] [-rebootfiles]

   여기서,

   -config
     사용할 구성 파일의 전체 경로 이름을 지정합니다. 이 이름은 시스템 유형을 나타내는 접미어를 생략하는 파일의 기본 이름으로 끝납니다. package 프로그램은 시스템 유형을 결정하는 방법을 알고 있으며 기본 파일 이름의 해당 버전을 자동으로 선택합니다. 이 인수의 적합한 값의 예는 staff.rs_aix42보다는 staff입니다. package 프로그램에서 /.package를 참조하여 다음 값을 통해 구성 파일에 대해 배울 수도 있습니다.

     `cat /.package`

     이 인수나 -fullconfig 인수를 사용하십시오.

   -fullconfig
     시스템 유형 확장자가 있는 사용할 구성 파일의 전체 이름을 지정합니다. 예는 staff.rs_aix42와 minimal.hp_ux110 파일입니다.

     또 다른 가능성은 표준 입력 스트림을 통해 실행자가 구성 정보를 파이프 파일로 또는 키보드에서 구성 파일을 입력하여 제공하고 있음을 나타내는 stdin 문자열입니다. <Ctrl-d>를 눌러 입력을 완료합니다.

     이 인수나 -config 인수를 사용하십시오.

   -overwrite
     첫(소유자) w(write) 모드 비트가 파일의 로컬 디스크 복사본에서 꺼져 있어도 구성 파일에 지정된 원본 버전으로 로컬 디스크의 요소를 겹쳐씁니다. I 갱신 코드로 보호되는 파일은 겹쳐쓸 수 없습니다. F 명령에 대한 정의를 참조하십시오.

   -noaction
     실제로 명령을 실행하지 않은 상태에서 표준 출력 스트림에 명령을 실행하여 발생할 수 있는 잠재적 문제를 추적한 내용을 표시합니다. -verbose 플래그가 추가되면 추적은 또한 package 프로그램이 시도하려는 작업도 기록합니다.

   -silent
     명령을 실행하는 중에 만날 수 있는 문제의 목록만 포함하는 추적의 기본 레벨을 명시적으로 호출합니다.

   -verbose
     표준 출력 스트림에 프로그램 작업의 자세한 추적을 생산합니다. 추적은 구성 파일에 있는 각 요소의 전송과 소유권/모드 비트를 기록합니다.

   -rebootfiles
     구성 파일에서 Q 갱신 모드 코드로 표시된 모든 요소를 겹쳐쓰지 못하도록 막습니다. 이는 package 프로그램이 초기설정 파일에서 호출되었을 때 시스템이 다시 자동으로 재부트하지 않게 효과적으로 막습니다.
4. Q 갱신 코드로 표시된 파일이 갱신되었다고 생각하면 시스템을 재부트합니다. 이 때 재부트 작업은 자동으로 일어나지 않습니다.

[ 페이지의 맨 위 | 이전 페이지 | 다음 페이지 | 목차 | 색인 ]

© IBM Corporation 2000. All Rights Reserved