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 프로그램은 시스템과 무관한 프로토타입 파일을 사용하여 표준 디스크 구성을 정의합니다. 프로토타입 파일은 로컬 클라이언트 디스트에 상주하는 파일, AFS에 연결된 파일 등을 나타냅니다. 프로토타입 파일은 시스템 유형마다 구성 파일로 컴파일됩니다.
모든 클라이언트 시스템의 구성이 같지는 않습니다. 원하는 경우 서로 다른 클라이언트 기능(인쇄 서버, 일반 클라이언트 등)에 대해 다른 프로토타입 파일을 작성할 수 있습니다.
package 프로그램은 로컬 클라이언트 디스크의 내용을 구성 파일과 비교합니다. 차이가 있으면 package 프로그램은 AFS에서 디스크로 파일을 복사하여 로컬 디스크를 적절히 갱신합니다. package 프로그램은 또한 시스템 구성의 일부가 아닌 파일을 삭제하도록 구성하거나 특정 파일(예를 들어 dkload 파일)이 갱신된 경우 클라이언트를 자동으로 재부트하도록 구성할 수 있습니다.
package 프로그램에서는 프로토타입 파일을 준비하기 위해 시간이 걸리지만 다음과 같은 이익을 제공합니다.
package 프로그램은 클라이언트 시스템에서 사용하도록 설계되었지만 파일 서버 시스템의 디스크를 구성할 때도 사용할 수 있습니다. 그러나 구성 파일에서 참조된 파일 중에서 파일 서버의 볼륨에 상주하는 것이 있으면 package 프로그램은 재부트중에 볼륨을 액세스할 수 없습니다(그리고 파일 서버 프로세스와 볼륨 서버 프로세스가 다시 시작할 때까지).
package 프로그램은 파일을 액세스할 수 없을 때 중단되므로 AFS의 파일 중에서 파일 서버 시스템의 볼륨에 상주하는 파일에 대한 참조를 제거해야 합니다. 이런 제한으로 인해 앞으로는 package 프로그램이 클라이언트 구성에서만 사용되는 것으로 간주하겠습니다.
package 프로그램을 실행하기 전에 수행해야 하는 3가지 주요 단계가 있습니다.
다음 절은 이런 단계를 요약합니다.
클라이언트 시스템에서 수행하는 여러 기능 및 역할과 이런 기능을 지원하는 로컬 디스크 구성을 나열하는 것으로 시작합니다. 역할 예에는 AFS 액세스를 제공하는 표준 클라이언트, 프린터를 구동하는 인쇄 서버 그리고 백업 스위트에서 명령을 발행하는 백업 시스템이 있습니다. 각 역할마다 서로 다른 프로토타입 파일을 작성하십시오.
프로토타입 파일은 고유 역할을 지원하는 디스크 구성을 정의합니다. 일반적으로, 프로토타입 파일은 기능마다 고유하지만 시스템과는 무관합니다. 시스템별 값은 변수와 라이브러리 파일을 사용하여 정의할 수 있습니다. 그런 후, 변수나 라이브러리 파일을 수정하면 변경사항은 package 프로그램이 호출될 때 적절한 모든 클라이언트로 전달됩니다.
유지하기 쉬운 유연한 프로토타입 파일을 작성하는 방법은 예제 프로토타입 및 라이브러리 파일에 있습니다.
프로토타입 파일은 보통 시스템과 무관하지만 여러 가지 시스템 유형의 요구를 만족시키기 위해 ifdef문을 포함할 수 있습니다. 프로토타입 파일을 컴파일하여 운영 체제 고유 버전을 생성합니다. 컴파일중에 package 프로그램은 각 시스템 유형에 적합한 정의를 선택하고 변수를 실제 값으로 바꿉니다. 이런 컴파일된 시스템 고유 파일은 구성 파일이라고 합니다.
프로토타입 파일은 Package Makefile 파일에 있는 설명대로 표준형의 Makefile 파일을 사용하여 컴파일됩니다.
일단 시스템 고유 구성 파일이 있으면 package 프로그램은 클라이언트를 실행할 수 있습니다. 먼저 package 2진을 사용할 수 있게 만들고 올바른 구성 파일을 지정해야 합니다.
다음과 같이 클라이언트를 수정하십시오.
이런 단계는 클라이언트 시스템 수정에 더 자세히 설명되어 있습니다.
본 절에서는 package 관련 파일이 AFS 빠른 시작에서 권한 대로 /afs/cellname/wsadmin 디렉토리의 하위 디렉토리인 src, lib 그리고 etc에 설치되어 있다고 간주합니다.
이런 디렉토리에는 여러 예제 프로토타입, 라이브러리 그리고 구성 파일이 있는 데, 이는 package 프로그램의 작업 방법을 명확하게 보여 줄 수 있습니다. 그러나, 이는 사용자 셀에서 사용하기에 적합하지 않을 수도 있습니다. 각자의 요구에 맞도록 수정해야 합니다.
src 디렉토리에는 몇 가지 예제 프로토타입 파일(구성 파일 작성에 사용), 이를 작성하는 데 사용되는 Makefile 파일 그리고 결과인 컴파일된 구성 파일이 있습니다.
프로토타입 파일은 function.proto 양식의 이름을 사용합니다. 예를 들어, minimal.proto 파일은 AFS 실행에 필요한 최소한의 라이브러리 파일 집합을 정의하고 staff.dkload.proto 파일은 동적 커널 로드 프로그램을 사용하는 클라이언트 구성을 정의합니다. 프로토타입 파일에는 hosts.equiv 파일과 같은 시스템 관리 파일에 대한 정의가 있을 수도 있습니다.
Makefile 파일은 시스템과 무관한 프로토타입 파일을 시스템 고유 구성 파일로 컴파일할 때 사용됩니다. 사용자의 셀에서 사용할 수 있도록 이 파일을 수정하는 방법에 대해 알아보려면 Package Makefile 파일을 참조하십시오.
구성 파일은 프로토타입 파일의 컴파일된 버전이며 function.sysname으로 명명됩니다. 구성 파일은 디스크를 구성할 때 package 프로그램이 액세스하는 etc 하위 디렉토리에도 나타납니다.
lib 디렉토리에는 프로토타입 파일에서 참조되는 여러 예제 라이브러리 파일이 있습니다. 예를 들어, base.generic 파일은 셀 이름 정의, 시스템 옵션 그리고 변수를 포함하는 시스템과 무관한 파일입니다. 이는 파일과 심볼릭 링크 정의에서 owner, group 그리고 mode_bits 필드를 설정하는 데 사용됩니다.
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에 있습니다.
| 주: | 각 구성 명령은 끊기지 않은 하나의 행에 표시되어야 합니다. 여기서 명령은
때때로 읽기 편하도록 여러 행에 나타날 수 있습니다.
구성 파일은 정확해야 합니다. 구문 오류가 있거나 틀린 값이 있으면 package 명령 인터프리터는 명령을 실행하지 않고 종료합니다. |
로컬 클라이언트 디스크에서 파일의 수를 최소한으로 유지하여 AFS를 활용할 수 있습니다. 대신 AFS를 가리키는 심볼릭 링크를 작성하십시오. 이는 캐슁과 스와핑에 더 많은 공간을 허용하여 시스템의 성능을 향상시킬 수 있습니다.
그러나, 일부 파일은 다음 설명대로 로컬 디스크에 상주해야 합니다. 이런 파일을 L(심볼릭 링크) 명령이 아닌 F(파일) 명령을 사용하여 프로토타입이나 라이브러리 파일에서 작성합니다.
다음 파일 유형은 모든 AFS 클라이언트의 로컬 디스크에 상주해야 합니다.
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진의 복사본을 액세스할 수 있습니다.
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 디렉토리에서 참조하십시오. 프로토타입과 라이브러리 파일의 구성은 각 셀마다 다릅니다.
일단 적합한 프로토타입과 라이브러리 파일을 작성하면 각 시스템 유형마다 프로토타입을 컴파일해야 합니다. 결과는 시스템마다 고유한 구성 파일입니다.
Makefile 파일은 사용된 프로토타입과 라이브러리 파일 그리고 컴파일 순서를 정의합니다. 이 절에서 설명하는 대로 AFS를 분배할 때 함께 제공되는 예를 수정하여 Makefile 파일을 작성하는 것이 바람직합니다. 전형적인 구성에서 이는 /afs/cellname/wsadmin/src/Makefile에 위치합니다.
다음 목록은 섹션을 시작하는 헤더 이름으로 식별되는 package Makefile 파일의 섹션을 요약합니다. 자세한 설명은 다음과 같습니다.
마지막으로 Makefile 파일에는 package 프로그램이 구성 파일을 생성하기 위해 따르는 명령 세트가 들어 있습니다. 일반적으로 이 섹션을 변경할 필요가 없습니다. Makefile 명령 섹션을 참조하십시오.
앞에서 언급했듯이 구성 파일은 특정 운영 체제 유형에 대해 컴파일된 프로토타입 파일입니다. 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 섹션의 항목은 다음 형식을 사용합니다.
예를 들어, staff.rs_aix42는 staff.proto 파일은 AIX 4.2를 실행하는 시스템에 대해 컴파일된다는 것을 나타냅니다. 결과의 컴파일된 구성 파일은 staff.rs_aix42라고 합니다.
이 섹션은 프로토타입 파일에 포함된 모든 시스템 및 기능에 무관한 라이브러리 파일의 완전한 경로 이름을 정의합니다(시스템 고유 라이브러리 파일은 MACHINE_LIBS 섹션에 정의되어 있음). 경로 이름에는 make 명령행에서 값을 제공하는 ${wsadmin} 변수가 포함됩니다.
프로토타입 파일에 참조되는 모든 라이브러리 파일을 포함해야 합니다. 포함되었지만 사용되지 않는 파일은 무시됩니다.
다음 예를 살펴보십시오. 모든 항목(단, 마지막 것 제외) 다음에는 역슬래쉬가 와야 합니다.
BASE_LIBS = \
${wsadmin}/src/admin \
${wsadmin}/lib/devel \
${wsadmin}/lib/base.generic
이 섹션은 프로토타입 파일에 포함된 모든 운영 체제 고유 라이브러리 파일의 완전한 경로 이름을 나열합니다(시스템 및 기능에 무관한 라이브러리 파일은 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가 MACHINE_LIBS 및 BASE_LIBS의 조합으로 정의되었다는 것을 나타내는 명령 하나만 들어 있습니다. 행 다음에 빈 행을 넣어 이 섹션을 다음 섹션과 구분하십시오.
LIBS = ${MACHINE_LIBS} ${BASE_LIBS}
이 섹션은 유효한 시스템 유형 접미어를 나열합니다. 이 목록에는 AFS에 대해 현재 지원되는 시스템 유형이 들어 있습니다. 사용되지 않는 접미어는 무시됩니다.
.SUFFIXES: .rs_aix42 \
.alpha_dux40 \
.proto \
.sun4x_56 \
.i386_linux22 \
.hp_ux110
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
다음과 같은 경우에 package Makefile 파일을 수정하십시오.
다음 절은 이런 이유로 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으로 대체하십시오. |
% fs listacl [dir/file path]
% cd /afs/cellname/wsadmin/src
% cp Makefile Makefile.example
wsadmin= 인수를 사용하여 package 디렉토리를 지정합니다. 이는 프로토타입과 라이브러리 파일에서 ${wsadmin} 변수의 값이 됩니다.
package 프로그램은 구성 파일을 생성하고 이를 wsadmin=으로 지정된 디렉토리의 etc와 src 하위 디렉토리에 설치합니다.
% make system wsadmin=/afs/cellname/wsadmin
package 프로그램을 자동으로 실행하도록 클라이언트를 준비하려면 다음 단계를 수행하십시오. 명령은 시스템 고유 구성 파일을 참조하지 않으므로 일반적입니다. 원하는 경우 AFS Administration Reference의 설명 대로 고유 인수를 사용하여 package 프로그램을 호출할 수 있습니다.
클라이언트 시스템의 루트(/) 디렉토리에 있는 .package 파일은 package 명령에 인수로 방향 전환됩니다. .package 파일은 package 프로그램에서 사용하는 구성 파일을 지정합니다.
package 프로그램을 실행하는 모든 클라이언트에서 다음 명령을 반복 수행하십시오.
이런 명령은 package 구성 파일(프로토타입 파일이 컴파일될 때 작성됨)이 /afs/cellname/wsadmin/etc 디렉토리에 상주한다고 간주합니다.
% su root Password: root_password
# echo "/afs/cellname/wsadmin/etc/config_file" >> /.package
예를 들어, 시스템을 직원용 시스템으로 구성하려면(적합한 프로토타입 파일이 그 시스템 유형에 대해 정의되고 컴파일되었다고 간주) 이에 해당하는 명령은 다음과 같습니다.
# echo "/afs/cellname/wsadmin/etc/staff" >> /.package
package 2진을 로컬에 저장하려면 다음 명령을 입력하십시오.
# cp /afs/cellname/sysname/usr/afsws/etc/package /etc/package
심볼릭 링크를 작성하려면 다음 명령을 입력하십시오.
# ln -s /afs/cellname/sysname/usr/afsws/etc/package /etc/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 프로그램을 실행할 수 있습니다. 재부트할 때 시스템의 AFS 초기설정 파일에서 package 프로그램을 호출하여 자동으로 실행하는 것이 가장 편리할 것입니다. 명령 쉘 프롬프트에서 명령을 실행할 수도 있습니다.
구성 파일은 정확해야 합니다. 구문 오류가 있거나 틀린 값이 있으면 프로그램을 명령을 실행하지 않고 종료합니다. 구성 파일을 확인하려면 명령 쉘 프롬프트에서 package 명령을 -noaction과 -debug 플래그와 함께 실행하십시오. 명령을 실제로 실행하지 않고 잠재적인 문제 목록을 표시합니다.
package 프로그램은 다음과 같은 일반 규칙을 따릅니다. 완전한 설명은 패키지 구성 파일 명령 구문에 있습니다.
% su root Password: root_password
# shutdown
% su root Password: root_password
# package [initcmd] [-config <base name of configuration file>] \
[-fullconfig <full name of configuration file, or stdin for standard input>] \
[-overwrite] [-noaction]
[-verbose] [-silent] [-rebootfiles]
여기서,
`cat /.package`
이 인수나 -fullconfig 인수를 사용하십시오.
또 다른 가능성은 표준 입력 스트림을 통해 실행자가 구성 정보를 파이프 파일로 또는 키보드에서 구성 파일을 입력하여 제공하고 있음을 나타내는 stdin 문자열입니다. <Ctrl-d>를 눌러 입력을 완료합니다.
이 인수나 -config 인수를 사용하십시오.