이 장에서는 셀을 구성 및 관리할 때 고려해야 할 여러 가지 문제점을 설명하고 이 안내서의 다른 부분에서 제공하는 관련 정보도 소개합니다. 또한 사용자가 AFS 관리의 개요의 정보를 이미 이해하고 있다고 가정합니다.
셀의 첫 번째 파일 서버 시스템을 설치하거나 다른 관리 타스크를 수행하기 전에 이 장을 읽는 것이 좋습니다.
AFS는 여러 측면에서 볼 때 표준 UNIX 파일 시스템처럼 작동하면서 동시에 셀 내 및 셀 간의 파일 공유를 용이하게 해 줍니다. 이 절에서는 AFS 및 UNIX 파일 시스템 간의 몇몇 차이점을 설명하고 좀더 자세한 정보를 제공합니다.
AFS는 표준 UNIX 파일 보호 메카니즘을 두 가지 방식으로 보완합니다. 첫째로 액세스 제어 목록(ACL)을 각 디렉토리와 연관짓고, 둘째로는 사용자가 ACL에 포함시킬 수 있는 많은 수의 자체의 그룹을 정의할 수 있게 합니다.
AFS는 모드 비트에 배타적으로 의존하지 않고 ACL을 사용하여 파일 및 디렉토리를 보호합니다. 이것은 다음과 같은 몇 가지 함축적 의미를 가지며 지정한 절에서 좀더 자세히 설명됩니다.
AFS는 사용자가 다른 사용자 그룹을 정의할 수 있게 합니다. ACL에 이들 그룹을 추가하면 지정된 정확한 수의 사용자에게 동시에 동일한 권한이 확장되며 이것은 ACL에 개인을 직접 추가하는 것보다 훨씬 더 편리합니다. 보호 데이터베이스 관리를 참조하십시오.
ACL에서 있을 때 한 번에 광범위한 사용자로 액세스 권한을 확장해 주는 system:anyuser 및 system:authuser의 시스템 정의 그룹도 있습니다. 시스템 그룹 및 ACL에서 그룹 사용을 참조하십시오.
AFS 파일 공간이 각 시스템의 로컬 파일 시스템과 구분되는 것처럼 AFS 인증은 로컬 로그인과 분리되어 있습니다. 이것은 두 가지의 실질적 의미를 가지며 AFS 수정 로그인 유틸리티 사용에서 좀더 자세히 설명됩니다.
AFS는 하나의 암호를 기초로 로컬 로그인과 AFS 인증을 동시에 수행하는 각 시스템 유형에 대해 수정된 로그인 유틸리티를 제공합니다. AFS 수정 로그인 유틸리티를 사용하지 않기로 하면 사용자는 AFS 사용자 안내서에서 설명하는 것처럼 별도의 단계로 로그인하고 인증을 받아야 합니다.
이 절에서는 일부 UNIX 명령의 기능을 AFS가 어떻게 변경하는지 요약해서 설명합니다.
일부 시스템 유형에 대한 AFS 분산 기능에는 수정된 rlogind 프로그램이 포함되지 않을 수 있습니다. AFS 릴리스 노트을 참조하십시오.
AFS 파일 서버 시스템에서는 표준 UNIX fsck 명령을 절대 실행하지 마십시오. 이 명령은 파일 서버가 디스크에 볼륨 데이터를 구성하는 방식을 이해하지 못하므로 모든 AFS 데이터를 파티션의 lost+found 디렉토리로 옮깁니다.
대신 AFS 분산 기능에 포함되어 있는 fsck 프로그램 버전을 사용하십시오. AFS 빠른 시작에서는 각 서버 시스템을 설치할 때 제조업체 제공 fsck 프로그램을 AFS 버전과 바꾸는 방법을 설명합니다.
AFS 버전은 UFS와 AFS 파티션 모두에 저장된 데이터에 대해 표준 fsck 프로그램과 같은 방식으로 기능합니다. fsck 프로그램이 초기화될 때 다음과 같은 표제의 모양에 따라 올바른 프로그램을 실행하고 있는지 확인할 수 있습니다.
--- AFS (R) version fsck---
여기서 version은 AFS 버전입니다. 올바른 결과를 위해서는 이 버전이 시스템에서 사용 중인 서버 2진의 AFS 버전과 일치해야 합니다.
표준 버전의 프로그램을 우연히 실행하고 있었다면 AFS 제품 지원부에 바로 문의하십시오. 경우에 따라 lost+found 디렉토리에서 볼륨 데이터를 복구할 수 있습니다.
AFS는 다른 디렉토리에 위치하는 파일 간의 하드 연결(UNIX ln 명령으로 작성)은 허용하지 않습니다. 왜냐하면 이 경우 디렉토리의 어떤 ACL이 연결과 연관되어 있는지 명확하지 않기 때문입니다.
AFS는 또한 파일 시스템을 트리로 구성하기 위해 디렉토리로의 하드 연결을 허용하지 않습니다.
두 개의 다른 AFS 디렉토리의 요소 간이나 AFS의 한 요소와 시스템의 로컬 UNIX 파일 시스템의 한 요소 간의 기호 연결(UNIX ln -s 명령으로 작성)을 작성할 수 있습니다. 그러나 그 이름이 숫자 기호(#)나 퍼센트 기호(%)로 시작되는 파일로의 기호 연결을 작성하면 안됩니다. 캐쉬 관리 프로그램은 이러한 연결을 각각 일반 볼륨이나 읽기/쓰기 볼륨으로 해석합니다.
응용프로그램이 파일에 대해 UNIX close 시스템 호출을 실행할 때 캐쉬 관리 프로그램은 파일의 중앙 사본을 유지하는 파일 서버로 데이터의 동시 쓰기를 수행합니다. 캐쉬 관리 프로그램은 파일 서버가 데이터의 수신에 응답할 때까지 응용프로그램의 제어 권한을 반환하지 않습니다. fsync 시스템 호출의 경우 파일 서버가 파일 서버 시스템의 비휘발성 저장 영역에 데이터를 썼음을 나타낼 때까지 응용 프로그램으로 제어 권한이 반환되지 않습니다.
응용프로그램이 UNIX write 시스템 호출을 실행할 때 캐쉬 관리 프로그램은 로컬 AFS 클라이언트 캐쉬에만 수정 내용을 씁니다. 로컬 시스템이 중단되거나 응용프로그램이 close 시스템 호출을 실행하지 않고 종료되면 수정 내용이 파일 서버에서 유지하는 파일의 중앙 사본에 기록되지 않을 수 있습니다. 캐쉬 관리 프로그램은 경우에 따라 새 데이터를 위해 캐쉬 청크를 사용 가능하게 해제할 필요가 있는 경우와 같은 상황에서 close 또는 fsync 시스템 호출없이 캐쉬로부터 이러한 유형의 수정된 데이터를 파일 서버로 씁니다. 그러나 이러한 경우 캐쉬 관리 프로그램이 언제 수정된 데이터를 파일 서버로 전송할지 예상하지 못하는 것이 일반적입니다.
이것은 응용프로그램의 저장 옵션이 close 또는 fsync가 아닌 write 시스템 호출을 호출할 경우 변경 내용이 반드시 파일 서버 시스템에 영구히 저장되는 것은 아님을 뜻합니다. 대부분의 응용프로그램은 파일 처리를 끝내고 종료될 때와 저장 작업을 위해 close 시스템 호출을 실행합니다.
로컬 수퍼유저 루트에 대해서만 UNIX setuid 비트를 설정하십시오. 이렇게 하면 자동 보안 위험이 발생하지 않습니다. 로컬 수퍼유저는 AFS에서 특수 권한을 가지지 않고 로컬 시스템의 UNIX 파일 시스템과 커널에서만 특수 권한을 가집니다.
파일은 setuid 비트로 표시될 수 있지만 system:administrators 그룹의 구성원만 chown 시스템 호출이나 /etc/chown 명령을 실행할 수 있습니다.
fs setcell 명령은 외부 셀에서 시작된 setuid 프로그램이 주어진 클라이언트 시스템에서 실행될 수 있는지 여부를 결정합니다. 클라이언트가 Setuid 프로그램을 실행할 수 있는 지 결정을 참조하십시오.
이 절에서는 셀 이름을 선택하는 방법과 적절한 셀 이름을 선택하는 것이 왜 중요한지 설명합니다.
셀 이름은 셀을 AFS 전역 이름 공간의 다른 모든 셀과 구분해야 합니다. 규칙에 따르면 셀 이름은 AFS 경로 이름의 두 번째 요소이므로 고유한 셀 이름을 사용하면 셀에서 로컬 AFS 파일 공간의 하위 레벨에서 동일한 디렉토리 이름을 사용하는 경우에도 모든 AFS 경로 이름이 파일을 고유하게 식별합니다. 예를 들어 두 ABC Corporation의 셀 및 State University 셀에서 사용자 pat에 대해 하나의 홈 디렉토리를 가질 수 있습니다. 바로 경로 이름인 /afs/abc.com/usr/pat와 /afs/stateu.edu/usr/pat가 고유하기 때문입니다.
규칙에 따르면 셀 이름은 사이트 이름에 대해 ARPA 인터넷 도메인 시스템 규칙을 따릅니다. 사용자가 이미 인터넷 사이트이면 인터넷 도메인 이름으로 셀 이름을 선택하는 것이 가장 쉽습니다.
인터넷 사이트가 아니면 앞으로 인터넷에 접속할 계획인 경우에 고유한 인터넷 스타일 이름을 선택하는 것이 가장 좋습니다. 적절한 이름을 선택할 때 AFS 제품 지원부에서 도움을 얻을 수 있습니다. AFS 셀 이름에 대해 다음의 몇 가지 제한 조건이 있습니다.
이들 중 적절한 것이 없을 때 다른 접미어를 사용할 수 있습니다. 미국의 Defense Data Network [Internet] Network Information Center에 (800) 235-3155번으로 전화하여 접미어에 대한 정보를 얻을 수 있습니다. 또한 NIC는 셀 이름을 인터넷 도메인 이름으로 등록하는 데 필요한 양식을 제공해 줍니다. 이름을 등록하면 나중에 다른 인터넷 사이트가 이 이름을 사용할 수 없게 됩니다.
셀 이름은 각 파일 서버 및 클라이언트 시스템의 로컬 디스크에 있는 두 개의 파일에 기록됩니다. 다른 기능도 제공하지만 이들 파일은 시스템의 셀 멤버쉽을 정의하므로 프로그램과 프로세스가 시스템에서 실행되는 방식에 영향을 미칩니다. 적절한 셀 이름을 선택하는 것이 중요한 이유를 참조하십시오. 셀 이름을 설정하는 절차는 두 가지 유형의 시스템에서 각기 다릅니다.
파일 서버 시스템의 경우 셀 이름을 기록하는 두 파일은 /usr/afs/etc/ThisCell과 /usr/afs/etc/CellServDB 파일입니다. AFS 빠른 시작에 좀더 명확하게 설명하고 있는 것처럼 셀에 설치한 첫 번째 파일 서버 시스템에 대해 bos setcellname 명령을 실행하여 두 파일 모두에서 셀 이름을 설정하게 됩니다. 이 명령을 다시 실행할 필요는 거의 없습니다. 미국판 AFS를 실행하고 갱신 서버를 사용하는 경우 이 서버는 ThisCell 및 CellServDB 파일의 사본을 설치하는 추가 서버 시스템에 분배합니다. 각국 언어판 AFS를 사용하는 경우 AFS 빠른 시작에서 이들 파일을 수동으로 복사하는 방법을 설명합니다.
클라이언트 시스템의 경우 셀 이름을 기록하는 두 파일은 /usr/vice/etc/ThisCell과 /usr/vice/etc/CellServDB 파일입니다. 문서 편집기를 사용하거나 AFS의 중앙 소스로부터 시스템에 복사하여 클라이언트마다 이들 파일을 작성하게 됩니다. 자세한 정보는 데이터베이스 서버 시스템 정보 유지를 참조하십시오.
시스템을 다른 셀로 전송하려는 경우에만 이들 파일에서 셀 이름을 변경하십시오 (시스템은 한 번에 한 셀에만 속할 수 있음). 시스템이 파일 서버이면 새 셀을 구성하기 위한 자세한 지침을 AFS 빠른 시작에서 찾을 수 있습니다. 시스템이 클라이언트이면 파일을 적절히 변경하고 시스템을 재부트하기만 하면 됩니다. 다음 절에서는 기존 셀의 이름을 변경함으로써 발생하는 부정적 결과에 대해 좀더 자세히 설명합니다.
로컬 /usr/vice/etc/ThisCell 파일을 변경하지 않고 대부분의 AFS 명령에서 사용하는 기본 셀 이름을 설정하려면 명령 쉘에서 AFSCELL 환경 변수를 설정하십시오. 외부 셀에서 중요한 관리 작업을 완료해야 하는 경우 이 변수를 설정하는 것이 바람직합니다.
| 주: | fs checkservers 및 fs mkmount 명령은 AFSCELL 변수를 사용하지 않습니다. fs checkservers 명령은 -cell 인수가 사용되지 않는 한 항상 ThisCell 파일에 명명된 셀을 기본값으로 사용합니다. fs mkmount 명령은 새 마운트 포인트의 상위 디렉토리가 있는 셀을 기본값으로 사용합니다. |
장기간에 걸쳐 사용하는 데 적절한 셀 이름은 신중히 선택하십시오. 나중에 셀 이름을 변경하면 작업이 복잡해 집니다. 적절한 셀 이름은 셀의 파일 트리에 있는 모든 파일의 경로 이름에서 두 번째 요소가 되므로 중요합니다. 각 셀 이름이 고유하므로 AFS 경로 이름에 셀 이름이 사용될 경우 복수의 셀이 하위 레벨에 있는 유사한 파일 공간 구성을 사용하는 경우에도 AFS 전역 이름 공간에서 경로 이름은 고유해집니다. 예를 들어 모든 셀이 충돌을 발생하지 않으면서 /afs/cellname/usr/pat라는 홈 디렉토리를 가질 수 있습니다. 경로 이름에 셀 이름이 들어 있다는 것은 파일이 로컬 셀에 있는지 외부 셀에 있는지에 관계 없이 모든 셀의 사용자가 파일을 액세스하기 위해 동일한 경로 이름을 사용하게 됨을 의미하기도 합니다.
셀을 설치하는 과정 초기에 올바른 셀 이름을 선택해야 하는 또 다른 이유는 각 시스템의 ThisCell 파일에 정의된 셀 멤버쉽이 시스템에서 실행되는 많은 프로그램과 프로세스의 성능에 영향을 미친다는 것입니다. 예를 들어 AFS 명령(fs, kas, pts 및 vos 명령)은 기본적으로 발행된 시스템의 셀에서 실행됩니다. 명령은 로컬 디스크에서 ThisCell 파일을 확인한 다음 지정된 셀에 대해 CellServDB 파일에 나열된 데이터베이스 서버 시스템을 접속합니다(bos 명령은 실행자가 항상 명령을 실행할 시스템의 이름을 지정해야 하므로 다르게 작동함).
ThisCell 파일은 또한 사용자가 시스템에 로그인할 때 AFS 토큰을 수신하는 셀을 결정하기도 합니다. 셀 이름은 또한 보안에서 중요한 역할을 합니다. 인증 서버는 인증 데이터베이스에 저장하기 위해 사용자 암호를 암호화 키로 변환할 때 이 암호를 ThisCell 파일에 있는 셀 이름과 조합합니다. AFS 수정 로그인 유틸리티는 동일한 알고리즘을 사용하여 인증 서버에 접속하여 사용자에 대한 토큰을 얻기 전에 사용자의 암호를 암호화 키로 변환합니다(AFS의 보안 시스템에서 암호화 키를 사용하는 방식에 대한 설명을 보려면 상호 인증에 대한 상세한 설명을 참조하십시오).
암호를 암호화 키로 변환하는 이러한 방법은 동일한 암호를 사용해도 다른 셀의 다른 키를 생성할 수 있게 합니다. 사용자가 복수의 셀에서 동일한 암호를 사용하는 경우에도 한 셀로부터 사용자의 토큰을 얻었을 때 다른 셀의 사용자 계정에 권한 없이 액세스할 수 없습니다.
셀 이름을 변경하는 경우에는 모든 서버 및 클라이언트 시스템에서 ThisCell 및 CellServDB 파일을 변경해야 합니다. 모든 시스템에서 이들 셀 이름을 변경하지 못하면 로그인 유틸리티에서 생성한 암호화 키가 인증 데이터베이스에 저장된 키와 일치되지 않으므로 로그인이 실패할 수 있습니다. 또한 AFS 제품군의 많은 명령이 예상대로 작동되지 않습니다.
AFS 전역 이름 공간에 참여하면 사용자 셀의 로컬 파일 트리를 외부 셀의 AFS 사용자가 볼 수 있게 되고 다른 셀의 파일 트리를 로컬 사용자가 볼 수 있게 됩니다. 한 셀 내에서 파일을 공유하는 것처럼 쉽게 여러 셀에서 파일을 공유할 수 있는 것입니다. 이 절에서는 전역 이름 공간에 참여하는 데 필요한 절차를 대략 설명합니다.
AFS 전역 이름 공간은 소규모의 경로 이름 구성 규칙을 준수하므로 참여하는 모든 AFS 셀에 동일하게 나타납니다.
첫 번째 규칙은 모든 AFS 경로 이름이 문자열 /afs로 시작하여 AFS 전역 이름에 속해 있음을 나타낸다는 것입니다.
두 번째 규칙은 셀 이름이 AFS 경로 이름에서 두 번째 요소라는 것입니다. 이것은 파일이 상주하는 위치를 나타냅니다(즉 파일 서버 시스템의 파일이 있는 셀). 앞서 설명한 것처럼 경로 이름에 셀 이름이 포함된 경우 셀들이 그 AFS 파일 공간의 하위 레벨에 있는 동일한 디렉토리 이름을 사용하는 경우에도 모든 AFS 경로 이름이 고유함을 보장하기 때문에 해당 전역 이름 공간이 존재할 수 있게 됩니다.
AFS 경로 이름의 세 번째 이하의 레벨에서 나타나는 항목에 따라 그 파일 공간을 재배열할 셀을 어떻게 선택했는지 알 수 있습니다. 세 번째 레벨에는 몇 가지 권장되는 규칙 디렉토리가 있습니다. 세 번째 레벨을 참조하십시오.
자신의 셀 이름과 데이터베이스 서버 시스템을 공개하여 다른 사람이 자신의 셀을 볼 수 있게 할 수 있습니다. 로컬 셀의 클라이언트 시스템처럼 외부 셀의 시스템에 있는 캐쉬 관리 프로그램은 볼륨 및 파일 위치 정보가 필요할 때 이 정보를 사용하여 셀의 볼륨 위치(VL) 서버에 도달합니다. 이와 마찬가지로 외부 셀에서 실행되는 클라이언트 측 인증 프로그램은 이 정보를 사용하여 셀의 인증 서비스를 접속합니다.
다음의 두 위치에서 이 정보를 사용 가능하게 할 수 있습니다.
이 파일에서 셀의 목록을 추가하거나 변경하려면 사이트 문의처로 공식 지원을 신청하거나 AFS 제품 지원부에 연락하십시오. 파일 변경은 자주 발생하므로 AFS 제품 지원부에서 각 개인에게 알리지 않습니다. 따라서 정기적으로 파일이 변경되었는지 확인하는 것이 바람직합니다.
셀의 데이터베이스 서버 시스템의 ID를 변경할 때마다 이들 파일을 갱신하십시오. 또한 모든 서버 시스템(/usr/afs/etc 디렉토리에 있음)과 클라이언트 시스템(/usr/vice/etc 디렉토리에 있음)의 CellServDB 파일 사본을 갱신해야 합니다. 지침을 보려면 서버 CellServDB 파일 유지 및 데이터베이스 서버 시스템 정보 유지를 참조하십시오.
일단 데이터베이스 서버 시스템을 공개한 경우 셀을 다시 보이지 않게 하는 것이 어려울 수 있습니다. CellServDB.local 파일을 제거하고 AFS 제품 지원부에 문의하여 전역 CellServDB 파일에서 항목을 제거하지 못하게 요청할 수 있으나 다른 셀들이 이미 로컬 CellServDB 파일에 있는 셀에 대한 항목을 가지고 있을 수 있습니다. 이들 항목을 유효하지 않게 하려면 데이터베이스 서버 시스템의 이름이나 IP 주소를 변경해야 합니다.
그러나 셀을 액세스하지 못하게 하기 위해 셀을 보이지 않게 할 필요는 없습니다. 외부 사용자가 사용자의 셀을 완전히 액세스하지 못하게 하려면 파일 공간의 상위 세 레벨에 있는 모든 ACL에서 system:anyuser 그룹을 제거하십시오. 외부 사용자에게 셀에 대한 액세스 권한 부여 및 거부를 참조하십시오.
셀의 클라이언트 시스템에서 외부 셀의 파일 공간을 볼 수 있게 하려면 다음 세 단계를 수행하십시오.
모든 클라이언트 시스템의 로컬 디스크에 있는 /usr/vice/etc/CellServDB 파일은 로컬 및 외부 셀에 대한 데이터베이스 서버 시스템을 나열합니다. afsd 프로그램은 캐쉬 관리 프로그램을 초기화할 때 CellServDB 파일의 내용을 커널 메모리로 읽어 들입니다. 또한 fs newcell 명령을 사용해서 시스템 재부트 중간에 커널 메모리에서 직접 항목을 추가하거나 교체할 수 있습니다. 데이터베이스 서버 시스템 정보 유지를 참조하십시오.
클라이언트 시스템에서 외부 셀을 볼 수 있게 해도 사용자가 그 파일 공간을 액세스할 수 있다고 보장할 수 없습니다. 외부 셀의 ACL에서 필요한 권한을 사용자에게 부여해야 합니다.
AFS 전역 이름 공간에서 사용자의 셀을 가시적으로 만들어도 외부 셀의 사용자가 사용자의 파일 트리를 액세스하는 방식을 계속 제어할 수 있습니다.
기본적으로 외부 사용자는 사용자 anonymous로 셀을 액세스하며 이것은 외부 사용자들이 각 디렉토리의 ACL에 있는 system:anyuser 그룹에 대해 부여된 권한만 가지게 됨을 의미합니다. 보통 이들 권한은 l (lookup) 및 r (read) 권한으로 제한됩니다.
외부 사용자에게 보다 광범위한 액세스 권한을 부여하는 방법에는 다음의 두 가지가 있습니다.
이 절에서는 AFS 파일 공간을 구성할 때 고려해야 할 문제점을 요약해서 설명합니다. 파일 공간의 디렉토리 구조에 가장 효율적으로 일치하는 볼륨을 작성하는 것에 대한 설명을 보려면 볼륨을 작성하여 관리 간편화하기를 참조하십시오.
Windows 사용자에 대한 주: Windows에서는 경로 이름의 요소를 구분하기 위해 역슬래쉬 ( / )보다 슬래쉬 ( \ )를 사용합니다. 그러나 파일 공간의 계층형 구조는 UNIX 시스템에서와 동일합니다.
AFS 경로 이름은 AFS 전역 이름 공간이 AFS 클라이언트 시스템에서 볼 때 동일하게 보이므로 몇몇 규칙을 따라야 합니다. 경로 이름이 파일 트리의 구조를 반영할 뿐 아니라 AFS 캐쉬 관리 프로그램이 특정 구성을 예상하기 때문에 파일 트리를 작성할 때 따라야할 규칙이 있는 것입니다.
첫 번째 규칙은 파일 트리의 상위 레벨을 /afs 디렉토리라고 부른다는 것입니다. 이것을 다르게 명명하면 -mountdir 인수를 afsd 프로그램과 함께 사용하여 캐쉬 관리 프로그램이 AFS를 제대로 마운트하게 해야 합니다. 이 경우 AFS 전역 이름 공간에 참여할 수 없습니다.
두 번째 규칙은 /afs 디렉토리 바로 아래에 로컬 트리에서 그 파일 트리를 볼 수 있고 액세스할 수 있는 각 셀에 해당 디렉토리를 배치한다는 것입니다. 최소한 로컬 셀에 대해 하나의 디렉토리가 있어야 합니다. 이러한 각 디렉토리는 지정된 셀의 root.cell 볼륨으로의 마운트 포인트입니다. 예를 들어 ABC Corporation 셀에서 /afs/abc.com은 셀 자체의 root.cell 볼륨에 대한 마운트 포인트이고 stateu.edu는 State University 셀의 root.cell 볼륨에 대한 마운트 포인트입니다. fs lsmount 명령을 실행하면 command displays 마운트 포인트가 표시됩니다.
% fs lsmount /afs/abc.com '/afs/abc.com' is a mount point for volume '#root.cell' % fs lsmount /afs/stateu.edu '/afs/stateu.edu' is a mount point for volume '#stateu.edu:root.cell'
경로 이름을 쓸 때 입력해야 하는 글자 수를 줄이려면 사용자가 자주 액세스하는 각 셀(특히 홈 셀)의 마운트 포인트에 대한 축약 이름을 포함하는 기호 연결을 작성할 수 있습니다. 예를 들어 ABC Corporation 셀에서 /afs/abc는 fs lsmount 명령이 보여주는 것처럼 /afs/abc.com 마운트 포인트에 대한 기호 연결입니다.
% fs lsmount /afs/abc '/afs/abc' is a symbolic link, leading to a mount point for volume '#root.cell'
원하는 방식대로 셀의 파일 트리의 세 번째 레벨을 구성할 수 있습니다. 다음 목록은 일반적 구성에서 이 레벨에 나타나는 디렉토리를 설명합니다.
다른 셀이 이 디렉토리의 etc 하위 디렉토리에서 찾을 것으로 예상하는 파일은 다음과 같습니다.
이러한 각 디렉토리 내에서 bin, etc, usr 등의 디렉토리를 작성하여 로컬 디스크의 /bin, /etc 및 /usr 디렉토리에 일반적으로 보유되는 프로그램을 저장하십시오. 그런 다음 클라이언트 시스템의 로컬 디렉토리에서 AFS로의 기호 연결을 작성하십시오. 로컬 디스크 구성을 참조하십시오. 이러한 방식으로 기호 연결을 사용하기로 선택하지 않았다고 해도 AFS에서 시스템 2진 파일의 중앙 사본을 유지하는 것이 편리할 수 있습니다. 2진 파일이 우연히 시스템에서 제거된 경우에도 테이프에서 복구하지 않고 AFS에서 로컬 디스크로 재복사할 수 있습니다.
셀이 상당히 큰 경우 단일 usr 디렉토리에 모든 홈 디렉토리를 넣을 경우 디렉토리 조회가 느려질 수 있습니다. 복수의 그룹 디렉토리에 사용자 홈 디렉토리를 분산하는 것에 대한 제안 사항을 보려면 홈 디렉토리 그룹화를 참조하십시오.
이 절에서는 시스템을 보다 쉽게 관리하는 방식으로 볼륨을 작성하는 방법을 설명합니다.
파일 트리의 맨 위 레벨에서(적어도 세 번째 레벨 통과) 각 디렉토리는 보통 별도의 볼륨에 대응됩니다. 셀 중에서 일부 세 번째 레벨 디렉토리의 하위 디렉토리를 별도의 볼륨으로 구성하는 셀도 있습니다. 일반적인 예로 /afs/cellname/common 및 /afs/cellname/usr 디렉토리를 들 수 있습니다.
하나의 트리에 모든 디렉토리 레벨에 대한 별도의 볼륨을 작성할 필요는 없으나 각 볼륨이 더 작아지고 로드 밸런스를 위해 이동하기 쉬워진다는 이점이 있습니다. 마운트 포인트에 대한 오버헤드도 표준 디렉토리에 대한 경우보다 더 크지 않으며 볼륨 구조 자체도 더 많은 디스크 공간을 요구하지 않습니다. 대부분의 셀은 트리의 네 번째 레벨 아래에서 각 디렉토리에 대한 별도의 볼륨을 사용하는 것이 더 이상 효율적이지 않다는 것을 인식합니다. 예를 들어 각 사용자의 홈 디렉토리(트리의 네 번째 레벨)가 별도의 볼륨에 대응되지만 홈 디렉토리의 모든 하위 디렉토리는 보통 같은 볼륨에 위치합니다.
하나의 볼륨만 트리의 제공된 한 디렉토리 위치에 마운트될 수 있다는 사실을 기억해 두십시오. 이와는 대조적으로 하나의 볼륨을 별도의 위치에 마운트할 경우 파일 트리의 계층 형태를 파괴하여 혼란을 유발할 수 있으므로 별로 권장되지는 않지만 이렇게 할 수도 있습니다.
다음의 몇 가지 제한에 따라 선택하는 볼륨의 이름을 지정할 수 있습니다.
이들 이름에서 벗어나면 혼란과 불필요한 작업량만 늘어날 뿐입니다. 예를 들어 root.afs 볼륨의 이름을 변경할 경우 모든 클라이언트 시스템의 afsd 프로그램에 대해 인수 -rootvol를 사용하여 대체 볼륨을 명명해야 합니다.
이와 마찬가지로 root.cell 볼륨 이름을 변경하면 파일 공간에 있는 사용자의 셀에 대한 마운트 포인트가 일반적인 root.cell 이름을 참조하는 경우 외부 셀의 사용자가 사용자의 파일 공간을 액세스할 수 없게 됩니다. 물론 이것은 다른 셀에서 사용자의 셀을 볼 수 없게 만드는 한 가지 방법입니다.
볼륨이 포함하는 데이터 유형을 나타내는 볼륨 이름을 지정하고 유사한 내용을 가진 볼륨에 대해 유사한 이름을 지정하는 것이 가장 좋은 방법입니다. 볼륨 이름이 마운트된 디렉토리의 이름과 유사한 경우에도(또는 적어도 공통되는 요소를 포함하고 있는 경우) 도움이 됩니다. 패턴을 이해하면 볼륨에 포함된 내용과 볼륨이 마운트된 위치를 정확히 추측할 수 있게 됩니다.
많은 셀들은 가장 효과적인 볼륨 이름 지정 기법이 관련된 모든 볼륨의 이름에
공통된 접두어를 추가하는 것이라는 점을 인식하고 있습니다.
표 1에서 권장되는 접두어 지정 기법을 설명합니다.
| 접두어 | 내용 | 예제 이름 | 예제 마운트 포인트 |
|---|---|---|---|
| common. | 자주 사용되는 프로그램 및 파일 | common.etc | /afs/cellname/common/etc |
| src. | 소스 코드 | src.afs | /afs/cellname/src/afs |
| proj. | 프로젝트 데이터 | proj.portafs | /afs/cellname/proj/portafs |
| test. | 검사 또는 다른 임시 데이터 | test.smith | /afs/cellname/usr/smith/test |
| user. | 사용자 홈 디렉토리 데이터 | user.terry | /afs/cellname/usr/terry |
| sys_type. | 운영 체제 유형에 맞게 컴파일된 프로그램 | rs_aix42.bin | /afs/cellname/rs_aix42/bin |
표 2는 셀의 rs_aix42 시스템
볼륨 및 디렉토리에 대한 가장 구체적인 예를 보여 줍니다.
| 예제 이름 | 예제 마운트 포인트 |
|---|---|
| rs_aix42.bin | /afs/cellname/rs_aix42/bin/afs/cell/rs_aix42/bin |
| rs_aix42.etc | /afs/cellname/rs_aix42/etc |
| rs_aix42.usr | /afs/cellname/rs_aix42/usr |
| rs_aix42.usr.afsws | /afs/cellname/rs_aix42/usr/afsws |
| rs_aix42.usr.lib | /afs/cellname/rs_aix42/usr/lib |
| rs_aix42.usr.bin | /afs/cellname/rs_aix42/usr/bin |
| rs_aix42.usr.etc | /afs/cellname/rs_aix42/usr/etc |
| rs_aix42.usr.inc | /afs/cellname/rs_aix42/usr/inc |
| rs_aix42.usr.man | /afs/cellname/rs_aix42/usr/man |
| rs_aix42.usr.sys | /afs/cellname/rs_aix42/usr/sys |
| rs_aix42.usr.local | /afs/cellname/rs_aix42/usr/local |
이 기법을 사용할 경우 다음과 같은 이점이 있습니다.
셀이 충분히 커서 실용적인 경우 관련된 볼륨을 하나의 파티션에 그룹화하는 것을 고려해 보십시오. 일반적으로 볼륨 그룹화가 효과적일 수 있으려면 적어도 세 대 이상의 파일 서버 시스템이 필요합니다. 그룹화는 몇 가지 이점을 제공하며 파일 서버 시스템을 액세스할 수 없을 때 그 이점이 명확하게 드러납니다.
관련된 볼륨을 하나의 파티션에 그룹화할 때의 이점은 한 파일 서버 시스템의 모든 관련 볼륨 그룹으로 반드시 확장되는 것은 아닙니다. 예를 들어 두 대의 파일 서버 시스템이 있는 한 셀에서 한 시스템에 모든 시스템 볼륨을 두고 다른 시스템에 모든 사용자 볼륨을 두는 것은 현명하지 못합니다. 한 시스템의 작동 중지가 모든 볼륨에 영향을 미칠 수 있게 됩니다.
일반적으로 로드 밸런스 목적으로 볼륨을 옮길 경우 관련된 볼륨을 그룹화할 때 얻어지는 실용성을 제한할 수 있습니다. 사례별로 다른 이점을 얻을 수 있습니다.
복제에서 설명하는 것처럼 복제는 읽기/쓰기 소스 볼륨의 사본이나 클론을 생성한 다음 이 사본을 하나 이상의 추가 파일 서버 시스템에 배치하는 것을 의미합니다. 볼륨을 복제하면 그 내용의 사용 효율이 높아질 수 있습니다. 볼륨을 포함하는 하나의 파일 서버를 액세스할 수 없어도 사용자는 여전히 다른 시스템에 저장된 볼륨 사본을 액세스할 수 있습니다. 파일을 여러 서버 시스템에서 사용할 수 있으므로 어떠한 시스템도 자주 사용되는 파일에 대한 요청으로 인해 과부하되지 않습니다.
그러나 복제가 모든 셀에 적절한 것은 아닙니다. 셀에 많은 디스크 공간이 없으면 읽기/쓰기 소스가 있는 같은 파티션에 없는 각 클론이 처음 생성되었을 때 소스 볼륨이 차지했던 것만큼 많은 디스크 공간을 차지하므로 상당히 비경제적일 수 있습니다. 또한 한 대의 파일 서버 시스템만 있는 경우 복제는 사용 효율을 높이지도 않으면서 디스크 공간을 소비하게 됩니다.
복제는 또한 변경이 자주 발생하는 볼륨에는 적절하지 않습니다. 읽기/쓰기 소스에 변경 내용을 반영하기 위해 읽기 전용 볼륨을 갱신해야 할 때마다 vos release 명령을 실행해야 합니다.
이러한 두 가지 이유 때문에 복제는 시스템 2진 파일 및 파일 공간의 상위 레벨에 마운트된 다른 볼륨과 같이 그 내용이 자주 변경되지 않으면서 자주 사용되는 볼륨에만 적절합니다. 보통 사용자 볼륨은 자주 변경되므로 읽기/쓰기 버전에만 존재합니다.
볼륨을 복제하는 경우 선호되는 두 또는 세 사이트 각각에(셀에 둘 또는 셋의 파일 서버 시스템만 있는 경우에도) root.afs 및 root.cell 볼륨을 복제해야 합니다. 캐쉬 관리 프로그램은 경로 이름을 해석할 때처럼 root.afs 및 root.cell 볼륨에 해당하는 디렉토리를 통과해야 합니다. 이들 볼륨이 사용 불가능할 경우 다른 볼륨을 저장하는 파일 서버 시스템이 여전히 기능하는 경우에도 다른 모든 볼륨이 사용 불가능해집니다.
root.afs 볼륨을 복제하는 또 다른 이유는 파일 서버 시스템의 작업 부하를 줄일 수 있다는 것입니다. 캐쉬 관리 프로그램은 복제본인 경우 root.afs 볼륨의 읽기 전용 버전을 액세스하는 경향이 있으며 이로 인해 캐쉬 관리 프로그램은 AFS 파일 공간을 통과하는 읽기 전용 경로를 따라 진행합니다. 캐쉬 관리 프로그램은 읽기 전용 경로에 있는 동안 복제 볼륨의 읽기 전용 사본을 액세스하려고 합니다. 파일 서버는 읽기/쓰기 볼륨에 대해 추적해야 하는 파일 당 하나의 콜백이 아니라 읽기 전용 볼륨에 있는 모든 데이터에 대해 캐쉬 관리 프로그램 당 하나의 콜백만 추적하면 됩니다. 콜백 횟수가 적을 수록 파일 서버의 작업 부하가 더 작아집니다.
root.afs 볼륨이 복제되지 않으면 캐쉬 관리 프로그램은 파일 공간을 통과하는 읽기/쓰기 경로를 따라 각 볼륨의 읽기/쓰기 버전을 액세스합니다. 파일 서버는 읽기/쓰기 볼륨의 각 파일에 대한 별도의 콜백을 분배 및 추적하여 더 많은 작업 부하를 초래합니다.
읽기/쓰기 및 읽기 전용 경로에 대한 자세한 정보를 보려면 마운트 포인트 통과 규칙을 참조하십시오.
대부분의 경우 /afs/cellname/usr 디렉토리에 해당하는 볼륨과 /afs/cellname/common 디렉토리 및 그 하위 디렉토리에 해당하는 볼륨 뿐 아니라 시스템 2진 볼륨을 복제하는 것이 바람직합니다.
읽기/쓰기 소스와 동일한 파티션에 복제본을 배치하는 것이 좋습니다. 이 경우 읽기 전용 볼륨은 클론(백업 볼륨과 같음)이 됩니다. 이것은 볼륨 내용의 전체 사본이 아니라 소스 볼륨의 vnode index 사본이 됩니다. 읽기/쓰기 볼륨이 다른 파티션으로 이동되거나 본질적으로 변경될 경우에만 읽기 전용 볼륨이 많은 디스크 공간을 소비합니다. 다른 파티션에 보유되는 읽기 전용 볼륨은 읽기 전용 볼륨이 작성되었을 때 읽기/쓰기 소스가 소비한 디스크 공간의 전체 크기를 항상 소비합니다.
모든 AFS 볼륨은 볼륨 사용이 허용되는 디스크 공간의 크기를 제한하는 관련된 할당량을 가집니다. 할당량을 설정하거고 변경하려면 볼륨 할당량과 현재 크기 설정 및 표시에서 설명하는 명령을 사용하십시오.
기본적으로 모든 새 볼륨에는 -maxquota 인수를 vos create 명령에 포함시키지 않는 한 5000 KB 블록의 공간 할당량이 지정됩니다. 또한 기본적으로 모든 새 볼륨의 루트 디렉토리에 있는 ACL은 system:administrators 그룹의 구성원에게 모든 권한을 부여합니다. 개별 명령으로 계정을 작성할 때 이들 값을 변경하는 방법을 알려면 개별 명령을 사용하여 사용자 계정을 하나 작성하려면을 참조하십시오. uss 명령을 사용하여 계정을 작성할 때 템플릿 파일의 V 명령어(instruction)에 대체 ACL 및 할당량 값을 지정하십시오. V 명령어를 사용한 볼륨 작성을 참조하십시오.
이 절에서는 AFS 데이터를 저장하고, 요청이 있을 때 이를 클라이언트 시스템으로 전송하고, AFS 관리 데이터베이스를 포함하는 서버 시스템을 구성할 때 고려해야 할 몇 가지 문제를 설명합니다. 클라이언트 시스템에 대한 정보를 보려면 클라이언트 시스템 구성을 참조하십시오.
셀에 둘 이상의 AFS 서버 시스템이 있을 경우 특수한 기능을 수행하도록 이들을 구성할 수 있습니다. 하나의 시스템이 다음 목록에서 설명하는 하나 이상의 역할을 가정할 수 있습니다. 자세한 정보를 보려면 파일 서버 시스템의 네 가지 역할을 참조하십시오.
AFS 빠른 시작에서는 네 가지 모든 역할을 수행할 것으로 가정되는 셀의 첫 번째 파일 서버를 구성하는 방법을 설명합니다. 추가 서버 시스템 설치에 대한 AFS 빠른 시작 장에서도 하나 이상의 역할을 수행하도록 파일 서버를 구성하는 방법을 설명합니다.
AFS 관리 데이터베이스는 데이터베이스 서버 시스템에 위치하며 올바른 셀 기능에 중요한 정보를 저장합니다. 서버 프로세스와 캐쉬 관리 프로그램 모두 다음과 같은 경우에 자주 이 정보를 액세스합니다.
셀을 유지하는 일은 첫 번째 시스템이 데이터베이스 서버 시스템으로 사용하려는 시스템 중에서 가장 낮은 IP 주소를 가지고 있을 경우 가장 간단해집니다. 나중에 더 낮은 IP 주소를 가진 시스템을 데이터베이스 서버 시스템으로 사용하기로 결정하면 새 시스템을 도입하기 전에 모든 클라이언트에서 CellServDB 파일을 갱신해야 합니다.
셀에 둘 이상의 서버 시스템이 있는 경우 둘 이상의 시스템을 데이터베이스 서버 시스템으로 실행하는 것이 좋습니다(그러나 셋 이상은 불필요할 수 있음). 이러한 방식으로 관리 데이터베이스를 복제하는 경우 사용 효율 및 신뢰성 증가와 같이 볼륨을 복제하는 것과 동일한 이점을 얻을 수 있습니다. 한 데이터베이스 서버 시스템이나 프로세스가 기능을 중단해도 해당 데이터베이스의 정보를 계속 사용할 수 있습니다. 데이터베이스 정보 요청에 따른 작업 부하는 여러 시스템에 분산되므로 한 시스템이 과부하되는 일이 없습니다.
그러나 복제된 데이터베이스는 복제된 볼륨과는 달리 자주 변경됩니다. 일관된 시스템 성능을 발휘하기 위해서는 모든 사본의 데이터베이스가 항상 동일해야 하므로 사본 중 일부만 변경 내용을 기록할 수 있습니다. 데이터베이스 사본을 동기화하기 위해 데이터베이스 서버 프로세스는 AFS의 분산 데이터베이스 기술인 Ubik를 사용합니다. AFS 관리 데이터베이스 복제를 참조하십시오.
셀에 하나의 파일 서버 시스템만 있을 경우 이 시스템은 데이터베이스 서버 시스템으로도 기능해야 합니다. 셀에 두 파일 서버 시스템에 있으면 두 시스템을 모두 데이터베이스 서버 시스템으로 실행하는 것이 항상 적절한 것은 아닙니다. 서버, 프로세스 또는 네트워크 장애가 두 시스템의 데이터베이스 서버 프로세스 간의 통신을 방해할 경우 두 시스템 모두 단독으로는 동기화 사이트로 기능할 수 없으므로 데이터베이스에서 정보를 갱신하지 못하게 됩니다.
일부 프로세스가 시스템에서 능동적으로 실행되지 않는다고 해도 모든 파일 서버 시스템의 /usr/afs/bin 디렉토리에 모든 AFS 서버 프로세스에 대한 2진 파일을 저장하는 것은 가장 간단한 일입니다. 이를 통해 새 역할을 수행하도록 시스템을 재구성하는 일을 보다 쉽게 할 수 있습니다.
보안 이유로 인해 파일 서버 시스템의 /usr/afs 디렉토리와 그 하위 디렉토리 및 파일은 로컬 수퍼유저 루트가 소유하며 첫 번째 w(write) 모드 비트만 on으로 설정되어 있어야 합니다. 어떤 파일은 첫 번째 r(read) 모드 비트만 on으로 설정되어 있기도 합니다(예를 들어 AFS 서버 암호화 키를 나열하는 /usr/afs/etc/KeyFile 파일). BOS 서버는 시작될 때마다 특정 파일 및 디렉토리의 모드 비트가 예상 값과 일치하는지 확인합니다. 목록을 보려면 중요한 AFS 디렉토리 보호에 대한 AFS 빠른 시작 절이나 서버 프로세스의 상태와 BosConfig 항목을 표시하려면에서 bos status 명령 출력에 대한 설명을 참조하십시오.
파일 서버 시스템의 로컬 디스크에 있는 모든 AFS 디렉토리의 내용에 대한 설명을 보려면 서버 시스템 관리를 참조하십시오.
파일 서버 시스템에서 AFS 볼륨을 포함하는 파티션은 다음 이름의 디렉토리에 마운트되어야 합니다.
/vicepindex
여기서 index는 하나나 두 개의 소문자입니다. 규칙에 따르면 작성된 첫 번째 AFS 파티션은 /vicepa 디렉토리에, 두 번째 AFS 파티션은 /vicepb 디렉토리에 마운트되고 계속해서 /vicepz 디렉토리까지 마운트됩니다. 그런 다음 이름들은 /vicepaa에서 /vicepaz까지, /vicepba에서 /vicepbz까지 계속되며 AFS 릴리스 노트에서 지정된 것처럼 지원되는 최대 서버 파티션 수까지 작성됩니다.
각 /vicepx 디렉토리는 전체 파티션이나 논리 볼륨에 해당해야 하며 루트 디렉토리(/)의 하위 디렉토리여야 합니다. /usr 파티션의 부분을 AFS 서버 파티션으로 구성하고 이를 /usr/vicepa라는 디렉토리에 마운트할 수 없습니다.
또한 AFS 서버 파티션에 비 AFS 파일을 저장하지 않도록 하십시오. 파일 서버 및 볼륨 서버는 파티션의 모든 공간을 사용할 수 있습니다. 또한 공간을 공유하면 특히 UNIX 파일이 자주 사용되는 경우에 파티션 액세스를 위해 AFS 및 로컬 UNIX 파일 시스템 간에 경쟁이 발생하게 됩니다.
AFS는 scout 및 afsmonitor 프로그램을 포함하여 파일 서버 모니터링을 위한 몇몇 도구를 제공합니다. 예를 들어 서버 파티션이 95% 이상 꽉 찼을 때처럼 특정 임계치가 초과될 때 경고를 발생하도록 구성할 수 있습니다. AFS 성능 모니터 및 감사를 참조하십시오.
파일 서버 시스템을 재부팅하면 AFS 프로세스를 종료해야 하므로 서비스 작동 중단이 발생할 수 밖에 없습니다. 가능한 한 파일 서버 시스템을 재부트하지 않도록 하십시오. 지침을 보려면 서버 시스템 재부팅을 참조하십시오.
기본적으로 각 파일 서버 시스템의 BOS 서버는 일주일에 한 번 일요일 오후 4시에 시스템의 모든 AFS 서버 프로세스(자신 포함)를 중지했다가 즉시 재시작합니다. 이를 통해 확장된 시간동안 프로세스가 실행됨으로써 발생할 수 있는 중요한 누출 가능성을 줄일 수 있습니다.
또한 BOS 서버는 /usr/afs/bin 디렉토리에서 새로 설치된 2진 파일이 있는지 매일 아침 5시에 확인합니다. BOS 서버는 각 2진 파일의 시간 소인을 해당 프로세스가 마지막으로 재시작된 시간과 비교합니다. 2진 파일의 시간 소인이 더 늦으면 BOS 서버는 해당 프로세스를 재시작합니다.
기본 시간은 프로세스를 재시작함으로써 발생하는 작동 중지가 가장 적은 수의 사람들에게 문제를 발생할 수 있는 이른 아침 시간입니다. bos getrestart 명령을 사용하여 각 시스템에 대한 재시작 시간을 표시하고 bos setrestart 명령을 사용하여 이들 시간을 재설정할 수 있습니다. 두 번째 명령을 사용하면 시간을 never 시간으로 설정하여 전체적인 자동 재시작을 작동 불가능하게 할 수 있습니다. BOS 서버의 재시작 시간 설정을 참조하십시오.
이 절에서는 셀의 클라이언트 시스템을 설치 및 구성할 때 고려해야 할 문제점을 요약해서 설명합니다.
AFS에 표준 UNIX 파일을 저장하고 로컬 디스크로부터 이 파일로의 기호 연결을 작성하여 AFS 클라이언트 시스템에서 상당한 로컬 디스크 공간을 사용 가능하게 할 수 있습니다. @sys 경로 이름 변수는 시스템 고유 파일로의 연결에서 유용할 수 있습니다. 경로 이름에 @sys 변수 사용을 참조하십시오.
로컬 디스크에는 afsd 프로그램이 호출되기 전에 필요한 부트 순서 파일과 파일 서버 시스템 작동 중지 중에 도움이 될 수 있는 파일의 두 가지 유형의 파일이 실제로 상주해야 합니다.
재부트 중에 AFS는 afsd 프로그램이 실행되고 캐쉬 관리 프로그램을 초기화할 때까지 액세스할 수 없습니다(일반적 구성에서 AFS 초기설정 파일은 시스템의 초기설정 순서에 포함되며 afsd 프로그램을 호출합니다). 이보다 앞서 재부트 중에 필요한 파일은 로컬 디스크에 위치해야 합니다. 이들 파일은 다음과 같습니다. 그러나 이 목록이 완전한 것은 아닙니다.
이들 파일에 대한 자세한 정보를 보려면 로컬 디스크에서의 구성 및 캐쉬 관련 파일을 참조하십시오.
로컬 디스크에 보유해야 하는 다른 유형의 파일 및 프로그램은 AFS에 저장된 사본을 액세스할 수 없게 만드는 파일 서버 작동 중지로 인한 문제점을 진단 및 수정할 때 필요한 파일 및 프로그램들입니다. 예제에는 문서 편집기(예: ed 또는 vi) 및 fs 및 bos 명령에 대한 2진 파일이 포함됩니다. AFS 명령 2진 파일 사본을 /usr/vice/etc 디렉토리에 저장하고 AFS로의 정상적인 연결에 해당하는 /usr/afsws 디렉토리에도 포함시키십시오. 그런 다음 /usr/afsws 디렉토리를 사용자의 PATH 환경 변수 정의의 /usr/vice/etc 디렉토리 앞에 두십시오. AFS가 정상적으로 기능할 때 사용자는 /usr/afsws 디렉토리에서 사본을 액세스할 수 있는 데 이 사본은 로컬 사본보다 더 현재 상태일 수 있습니다.
구성 파일과 일치하도록 로컬 디스크의 내용을 갱신하는 package 프로그램을 사용하여 클라이언트 시스템 로컬 디스크의 구성을 자동화할 수 있습니다. package 프로그램을 사용한 클라이언트 시스템 구성을 참조하십시오.
사용자의 셀에서 다른 셀을 볼 수 있게 만들기에서 자세히 설명하는 것처럼 캐쉬 관리 프로그램에서 로컬 /usr/vice/etc/CellServDB 파일에 셀의 데이터베이스 서버 시스템 목록을 저장하여 셀의 AFS 파일 공간을 액세스하게 할 수 있습니다. 캐쉬 관리 프로그램은 보다 빠른 검색을 위해 재부트 시 이 목록을 커널 메모리로 읽어 들입니다. fs newcell 명령을 사용하여 재부트 중간에 커널 메모리에서 이 목록을 변경할 수 있습니다. AFS에 CellServDB 파일의 중앙 버전을 저장하고 package 프로그램을 주기적으로 사용하여 소스 사본으로 각 클라이언트 버전을 갱신하는 것이 보다 일반적인 방법입니다. 데이터베이스 서버 시스템 정보 유지를 참조하십시오.
각 클라이언트 시스템이 자체의 CellServDB 파일 사본을 유지하므로 이론적으로는 다른 클라이언트 시스템의 다른 외부 셀을 액세스할 수 있습니다. 그러나 이것은 사용자가 항상 동일한 시스템에서 작업하는 것이 아닌 경우에 특히 비실제적입니다.
로컬 디스크의 AFS로의 기호 연결을 작성할 때 경로 이름에 @sys 변수를 사용하는 것이 일반적입니다. 캐쉬 관리 프로그램은 로컬 시스템의 AFS 시스템 이름(CPU/운영 체제 유형)을 @sys 변수로 자동으로 대체합니다. 이것은 다양한 유형의 시스템에 동일한 연결을 배치하고 해당 시스템 유형에 대한 2진 파일에 각 시스템이 여전히 액세스할 수 있음을 의미합니다. 예를 들어 AIX 4.2가 실행되는 시스템의 캐쉬 관리 프로그램은 /afs/abc.com/@sys에서 /afs/abc.com/rs_aix42로 변환하지만 Solaris 7이 실행되는 시스템은 이를 /afs/abc.com/sun4x_57로 변환합니다.
@sys 변수를 사용하려는 경우 AFS 릴리스 노트에 지정하는 것처럼 일반적인 AFS 시스템 유형 이름을 사용하는 것이 가장 간단합니다. 캐쉬 관리 프로그램은 초기설정 중에 커널 메모리에 로컬 시스템의 시스템 유형 이름을 기록합니다. 일반적인 이름을 사용하지 않는 경우 fs sysname 명령을 사용하여 적절한 시스템 유형의 모든 클라이언트 시스템에 대해 캐쉬 관리 프로그램 초기설정 후에 바로 기본값에서 커널 메모리의 값을 변경해야 합니다. fs sysname 명령을 실행해도 현재 값이 표시됩니다. 시스템 유형 이름 표시 및 설정을 참조하십시오.
AFS 파일 공간의 경로 이름에서 @sys 변수를 사용할 때는 예측하지 못한 결과가 발생할 수 있으므로 주의해야 합니다. 보통 파일 공간의 한 레벨로만 그 사용을 제한하는 것이 가장 바람직합니다. 세 번째 레벨은 많은 셀들이 다른 시스템 유형의 2진 파일을 저장하는 위치이므로 가장 흔히 선택됩니다.
경로 이름의 많은 @sys 변수 인스턴스는 해당 디렉토리를 유지하는 관리자나 개발자와 같이 디렉토리를 작업 중인 시스템 이외의 시스템 유형에 대한 2진 파일을 저장하는 디렉토리로 명시적으로 변경해야 하는 (cd 명령 사용) 사람들에게 특히 위험합니다. 디렉토리를 변경한 후에는 원하는 디렉토리에 내용이 들어 있는지 확인하는 것이 좋습니다.
캐쉬 관리 프로그램은 커널 메모리에 파일 서버 시스템에 대한 선호 사항 테이블을 저장합니다. 하나의 선호 사항 순위에는 파일 서버 시스템 인터페이스 IP 주소와 1-65,534의 정수가 쌍으로 들어 있습니다. 캐쉬 관리 프로그램은 파일을 액세스해야 할 때 해당 파일이 들어 있는 모든 시스템의 인터페이스 순위들을 비교하고 먼저 최고 순위를 가진 인터페이스를 통해 파일을 액세스하려고 합니다. 캐쉬 관리 프로그램은 초기화될 때 네트워크 토폴로지 관점에서 볼 때 가까운 인터페이스를 통해 파일을 액세스할 수 있는 적절한 기본 순위를 설정합니다. 원하는 경우 선호 사항 순위를 조정하여 성능을 향상시킬 수도 있습니다.
캐쉬 관리 프로그램은 또한 볼륨 위치(VL) 서버 시스템에 대해서도 유사한 선호 사항을 사용합니다. 선호 사항 순위를 표시할 때는 fs getserverprefs 명령을 사용하여 이들 순위를 설정할 때는 fs setserverprefs 명령을 사용하십시오. 서버 선호 사항 순위 유지를 참조하십시오.
이 절에서는 AFS 사용자 계정을 구성할 때 고려해야 할 몇몇 문제점을 요약해서 설명합니다. AFS가 UNIX 파일 시스템과 분리되어 있으므로 사용자의 AFS 계정은 UNIX 계정과 별도입니다.
사용자 계정을 작성하기 위한 선호되는 방법은 uss 명령 집합을 사용하는 것입니다. 단일 명령을 사용할 경우 계정 작성 단계를 안내하는 템플릿 파일을 준비한 후에 하나 이상의 계정의 모든 구성요소를 작성할 수 있습니다. uss 명령 집합을 사용한 사용자 계정 작성 및 삭제를 참조하십시오.
또는 한 계정의 각 구성요소를 작성하는 개별 명령들을 실행할 수 있습니다. 사용자 계정 제거 및 사용자 암호, 사용자 볼륨 할당량 및 사용자 이름 변경에 대한 지침과 함께 관련 지침을 보려면 사용자 계정 관리를 참조하십시오.
사용자는 시스템을 떠날 때 자신의 게정을 제거하는 것이 좋습니다. uss delete 명령을 사용한 개별 계정 삭제 및 사용자 계정 제거에서 관련 지침을 참조하십시오.
AFS 사용자 계정은 AFS 사용자 계정의 구성요소에서 자세히 설명하는 것처럼 다음 구성요소로 구성됩니다.
모두 그런 것은 아니지만 일부 구성요소를 작성할 경우 uss 명령 집합을 사용한 사용자 계정 작성 및 삭제에서 설명하는 것처럼 uss 명령이나 사용자 계정 관리에서 설명하는 것처럼 개별 명령을 사용하여 다른 기능 레벨에서 계정을 작성할 수 있습니다. 기능 레벨에는 다음이 포함됩니다.
사용자가 셀의 AFS 도입보다 이전에 지정된 UNIX 사용자 계정을 가지는 경우 이를 AFS 계정으로 변환할 수 있습니다. 이 경우 다음과 같이 세 가지 문제점을 고려해야 합니다.
자세한 설명을 보려면 uss를 사용한 기존 UNIX 계정 변환 또는 기존 UNIX 계정 변환을 참조하십시오.
이 절에서는 사용자 이름, AFS UID, 사용자 볼륨 이름 및 마운트 포인트 이름 선택에 대한 기법을 제안하고 선택 시 적용되는 몇몇 제한 사항을 대략적으로 설명합니다.
사용자 이름
AFS는 사용자 이름 양식을 별로 제한하지 않습니다. 많은 유틸리티와 응용 프로그램이 최대 8자를 포함하는 사용자 이름을 처리할 수 있으며 규칙에 따라 AFS의 많은 구성요소와 계정이 이 이름을 포함하므로 사용자 이름을 축약형으로 지정하는 것이 좋습니다. 여기에는 보호 및 인증 데이터베이스, 볼륨 및 마운트 포인트의 항목이 들어 있습니다. 사용하는 전자 메일 전달 시스템에 따라 사용자 이름이 사용자의 메일 주소의 일부가 될 수 있습니다. 사용자 이름은 또한 클라이언트 시스템에 로그인할 때 사용자가 입력하는 문자열이기도 합니다.
사용자 이름과 이름, 성, 이니셜 또는 이들의 조합이나 경우에 따라 숫자가 추가된 사용자 이름을 선택할 수 있습니다. 다음 문자는 명령 쉘에서 특수한 의미를 가지므로 사용하지 않는 것이 좋습니다.
AFS UID 및 UNIX UID
AFS는 고유한 식별 번호인 AFS UID를 모든 사용자 이름과 연관지으며 사용자의 보호 데이터베이스 항목에 이 맵핑을 기록합니다. UNIX UID가 로컬 파일 시스템에서 수행하는 것과 같이 AFS UID는 AFS 내에서 기능합니다. AFS 서버 프로세스 및 캐쉬 관리 프로그램은 이를 내부적으로 사용하여 사용자 이름이 아닌 사용자를 식별합니다.
또한 모든 AFS 사용자는 로그온하는 각 클라이언트 시스템의 로컬 암호 파일(/etc/passwd 또는 동급)에 기록된 UNIX UID가 있어야 합니다. AFS UID 및 UNIX UID가 일치하는 경우 관리자 및 사용자 AFS 액세스가 모두 간단해 집니다. UID가 일치할 경우 얻을 수 있는 중요한 결과는 ls -l 명령이 보고하는 소유자가 AFS 사용자 이름과 일치한다는 것입니다.
보호 서버에서 보호 데이터베이스 항목을 작성할 때 AFS UID를 할당할 수 있게 하는 것이 가장 바람직합니다. 그러나 사용자 계정을 작성하는 pts createuser 명령과 uss 명령 모두 AFS UID를 명시적으로 할당할 수 있게 해 줍니다. 이것은 다음의 두 가지 경우에서 적절합니다.
보호 서버는 셀의 첫 번째 파일 서버 시스템에서 처음으로 초기화된 후에 기본값으로 AFS UID를 할당하기 시작합니다. 사용자 계정을 작성하기 전에 또는 언제든지 기본값을 변경하려면 pts setmax 명령을 사용하여 max user id 카운터를 재설정하십시오. 카운터를 표시하려면 pts listmax 명령을 사용하십시오. AFS UID와 GID 카운터 표시 및 설정을 참조하십시오.
AFS에서는 사용자 anonymous에 대해 AFS UID, 32766을 예약합니다. AFS 서버 프로세스는 이 ID와 AFS UID를 로컬 셀에 대한 토큰을 소유하지 않는 사용자에게 지정합니다. 이 AFS UID를 다른 사용자에게 지정하거나 그 현재 값을 프로그램이나 파일의 소유자 필드로 하드코딩하지 않도록 하십시오. 왜냐하면 이 값은 앞으로 출시될 버전에서 변경될 수 있기 때문입니다.
사용자 볼륨 이름
다른 볼륨 이름과 같이 사용자 볼륨의 기본(읽기/쓰기) 이름 길이는 22자를 포함할 수 없으며 .readonly 또는 .backup 확장자를 포함할 수 없습니다. 볼륨을 작성하여 관리 간편화하기를 참조하십시오. 규칙에 따르면 사용자 볼륨 이름은 형식 user.username을 가져야 합니다. user. 접두어를 사용하면 볼륨의 내용을 식별하기 쉬울 뿐 아니라 단일 vos backupsys 명령을 실행하여 모든 사용자 볼륨의 백업 버전을 작성하기도 쉬워집니다.
마운트 포인트 이름
규칙에 따르면 사용자 볼륨의 마운트 포인트는 사용자 이름 다음에 명명됩니다. 많은 셀들은 세 번째 레벨에서 설명하는 것처럼 /afs/cellname/usr 디렉토리의 사용자 볼륨 마운트 규칙을 따릅니다. 경우에 따라 아주 많은 셀들이 동일한 디렉토리에 모든 사용자 볼륨을 마운트할 경우 디렉토리 조회 속도가 느려지지만 제안되는 대안을 보려면 다음 절을 참조하십시오.
/afs/cellname/usr 디렉토리에 사용자 볼륨을 마운트하는 것은 /usr 하위 디렉토리 아래에 사용자 홈 디렉토리를 두는 표준 UNIX 작업 방식에 대한 AFS 호환 방식입니다. 그러나 100명이 넘는 사용자가 있는 셀에서는 단일 디렉토리에 모든 사용자 볼륨을 마운트할 경우 디렉토리 조회에 많은 시간이 걸린다는 사실을 인식하고 있습니다. 그 해결 방법은 여러 디렉토리에 사용자 볼륨 마운트 포인트를 분배하는 것입니다. 이를 수행하는 방법에는 여러 가지가 있습니다.
uss 프로그램을 사용하여 사용자 계정을 작성할 때 다양한 기법을 구현하는 방식에 대한 정보를 보려면 G 명령어를 사용하여 사용자 홈 디렉토리의 공평한 분배 및 V 명령어를 사용한 볼륨 작성을 참조하십시오.
사용자 볼륨의 백업 버전을 마운트하는 것은 사용자 자신이 실수로 제거했거나 삭제한 데이터를 복원할 수 있게 해 주는 간단한 방법입니다. 사용자 홈 디렉토리의 하위 디렉토리(대개 OldFiles 하위 디렉토리라고 함)에 백업 버전을 마운트하는 것이 일반적이지만 다른 방법도 사용할 수 있습니다. 하루에 한 번씩 새 백업 버전을 작성하고 그 날 수행된 변경사항을 캡처한 다음 이전 날의 백업 버전을 새 버전으로 덮어쓸 수 있습니다. 사용자들은 항상 관리자의 도움 없이 이전 날의 파일 사본을 검색할 수 있으므로 사용자는 좀더 긴급한 타스크를 처리할 수 있는 상황이 됩니다.
경우에 따라 사용자들은 백업 볼륨의 내용이 할당량에 비해 부족하다고 잘못 생각할 수 있기 때문에 백업 볼륨에 대한 마운트 포인트를 삭제하려고 합니다. 사용자들에게 백업 볼륨을 별도의 것이므로 사용자 볼륨에서 백업 볼륨이 사용하는 공간만 마운트 포인트에서 필요한 양임을 상기시켜 주십시오.
백업 볼륨에 대한 자세한 설명을 보려면 AFS 데이터 백업 및 백업 볼륨 작성을 참조하십시오.
UNIX 관리자로서의 경험을 통해 로그인 및 쉘 초기설정 파일(예: .login 및 .cshrc 파일) 사용에 익숙하므로 계정을 사용하기 더 쉽게 만들 수 있을 것입니다.
다음을 포함하여 일부 AFS 고유 디렉토리를 사용자의 PATH 환경 변수 정의에 추가하는 일은 일반적으로 수행되는 작업입니다.
AFS 수정 로그인 유틸리티를 사용하지 않는 경우 사용자가 로그인의 일부로서 AFS 토큰을 얻을 수 있도록 .login 파일에서 klog 명령을 호출하는 것이 도움이 될 수 있습니다. 다음 예제 명령 순서에서 첫째 행은 문자열 klog를 표준 출력 스트림으로 에코하므로 사용자는 둘째 행이 실행될 때 나타나는 Password: 프롬프트의 목적을 이해할 수 있습니다. -setpag 플래그는 PAG에 의한 AFS 토큰 식별에서 자세히 설명하는 것처럼 새 토큰을 프로세스 인증 그룹(PAG)과 연관짓습니다.
echo -n "klog " klog -setpag
다음 명령 시퀀스는 pagsh 명령이 PAG와 토큰이 연관되는 새 쉘을 분기한다는 사실을 제외하고 유사한 효과를 나타냅니다.
pagsh echo -n "klog " klog
AFS 수정 로그인 유틸리티를 사용하는 경우 이러한 유틸리티가 로컬로 사용자를 로그인하고 AFS 토큰을 얻기 때문에 이 시퀀스가 반드시 필요한 것은 아닙니다.
AFS를 사용하면 사용자는 다른 사용자나 시스템의 그룹을 정의할 수 있습니다. 그룹은 각 사용자를 개별적으로 나열하지 않고 많은 사용자에게 동일한 권한을 부여하기 위해 ACL에 추가됩니다. 그룹 작성 지침을 보려면 보호 데이터베이스 관리를 참조하십시오.
사용자와 마찬가지로 그룹은 AFS ID 번호를 가지지만 AFS 그룹 ID(GID)는 사용자의 AFS UID가 양의 정수인데 반해 음의 정수입니다. 기본적으로 보호 서버는 새 그룹의 AFS GID를 자동적으로 할당하지만 system:administrators 그룹의 구성원은 pts creategroup 명령을 실행하여 GID를 지정할 수 있습니다. GID를 명시적으로 지정하기 전에 해당 GID가 아직 사용되고 있지 않은지 확인하는 것이 좋습니다.
그룹은 다른 그룹에 속할 수 없으나 그룹(소유 그룹)이 하나 이상의 구성원을 가지는 경우 다른 그룹이나 자신을 소유할 수 있습니다. 그룹의 현재 소유자는 새 소유자의 권한이 없는 경우에도 그룹의 소유권을 다른 사용자나 그룹에 전환할 수 있습니다. 이 경우 현재 소유자는 그룹에 대한 관리 제어 능력을 잃게 됩니다.
기본적으로 각 사용자는 20개의 그룹을 작성할 수 있습니다. 시스템 관리자는 pts setfields 명령을 사용하여 이러한 그룹 작성 할당량을 늘리거나 줄일 수 있습니다.
각 보호 데이터베이스 항목(그룹 또는 사용자)은 항목을 관리할 수 있는 사람과 이들이 할 수 있는 작업을 제한하는 다섯 가지 개인 플래그 집합에 의해 보호됩니다. 기본 개인 플래그는 적절히 제한적이며 사용자 입력 항목에 대해 특히 그렇습니다. 데이터베이스 항목에서 개인 플래그 설정을 참조하십시오.
보호 서버는 처음으로 셀의 첫째 데이터베이스 서버 시스템에서 초기화될 때 system:anyuser, system:authuser 및 system:administrators의 세 가지 그룹 항목을 자동으로 작성합니다.
처음 두 시스템 그룹은 안정적인 멤버쉽을 가지지 않는다는 면에서 보호 서버의 다른 그룹과 다릅니다.
이 그룹이 안정적인 멤버쉽을 가지지 않기 때문에 pts membership 명령을 사용해도 출력이 생성되지 않습니다. 이와 마찬가지로 이들은 사용자가 속해 있는 그룹 목록에도 나타나지 않습니다.
system:administrators 그룹은 안정적인 멤버쉽을 가지며 셀의 권한 있는 관리자로 구성됩니다. 이 그룹의 구성원은 pts 명령을 실행할 수 있으며 다른 제한적인 명령(예: AFS 파일에 대한 chown 명령)을 실행할 수 있는 유일한 그룹입니다. 기본적으로 이들은 파일 공간의 모든 ACL에 대해 암시적으로 a(administer) 및 l (lookup) 권한을 가집니다. 이 기본값을 변경하는 것에 대한 자세한 정보를 보려면 system:administrators 그룹 관리를 참조하십시오.
ACL의 시스템 그룹을 효과적으로 사용하는 방법에 대한 설명을 보려면 ACL에서 그룹 사용을 참조하십시오.
모든 사용자는 일반 그룹을 작성할 수 있습니다. 일반 그룹 이름은 콜론으로 구분된 두 개의 필드를 가지며 이 중 첫째 필드는 그룹의 소유권을 나타내야 합니다. 보호 서버는 그 결과가 정확하게 소유권을 나타내지 않을 경우 그룹의 이름을 작성하거나 변경하는 것을 거부합니다.
system:administrators 그룹의 구성원은 그 이름에 소유권을 나타내는 첫째 필드가 포함되어 있지 않은 prefix-less 그룹을 작성할 수 있습니다. 두 가지 유형의 그룹을 효과적으로 사용하기 위한 제안 사항을 보려면 그룹을 효과적으로 사용하는 방법을 참조하십시오.
인증의 차이점에서 설명하는 것처럼 AFS 인증은 두 가지 파일 시스템이 별도이므로 UNIX 인증과는 별도로 진행됩니다. 이와 같이 인증이 별도로 진행된다는 사실은 다음을 의미합니다.
사용자가 성공적으로 인증을 받으면 AFS 인증 서비스는 사용자의 캐쉬 관리 프로그램에 토큰을 제공합니다. 이 토큰은 사용자가 특정 AFS ID와 연관된 암호를 제대로 제공했음을 인증하는 작은 데이터 모음입니다. 캐쉬 관리 프로그램은 사용자가 진짜라는 증거로서 서비스 요청과 함께 AFS 서비스 프로세스에 이 토큰을 제시합니다. 신원을 확인하는 데 사용하는 상호 인증 절차에 대한 정보를 보려면 상호 인증에 대한 상세한 설명을 참조하십시오.
캐쉬 관리 프로그램은 커널 메모리의 사용자 자격사항 구조에 토큰을 저장합니다. 한 사용자의 자격사항 구조를 다른 사용자의 자격사항 구조와 구분하기 위해 캐쉬 관리 프로그램은 사용자의 UNIX UID나 셀에서 고유한 것으로 보장되는 식별 번호인 프로세스 인증 그룹(PAG)에 따라 각 사용자를 식별합니다. 자세한 설명을 보려면 PAG에 의한 AFS 토큰 식별을 참조하십시오.
한 명의 사용자는 별도로 식별되는 각 자격사항 구조에서 셀당 하나의 토큰만 가질 수 있습니다. 동일한 셀에 대해 두 번째 토큰을 얻으려면 다른 시스템에 로그인하거나 기존의 자격사항 구조와 다른 식별자를 사용하는 다른 자격사항 구조를 얻어야 합니다. 이 작업은 pagsh 명령을 실행하면 가장 쉽게 수행할 수 있습니다 (PAG에 의한 AFS 토큰 식별 참고). 단일 자격사항 구조에서 사용자는 동시에 여러 셀 각각에 대해 하나의 셀을 가질 수 있습니다. 이것이 의미하는 것처럼 한 시스템이나 PAG의 인증 상태는 다른 시스템이나 PAG의 인증 상태와 독립되어 있으며 이것은 사용자나 시스템 관리자에게 상당히 유용할 수 있습니다.
AFS 분산에는 한 단계의 작업으로 각 시스템 유형의 로그인 유틸리티가 AFS에서 사용자를 인증하고 이들이 로컬 파일 시스템으로 로그인할 수 있게 하는 라이브러리 파일이 포함되어 있습니다. 클라이언트 시스템에서 AFS 수정 로그인 유틸리티를 구성하지 않은 경우 그 사용자는 로그인한 후에 klog 명령을 실행하여 AFS에 인증을 받아야 합니다.
| 주: | AFS 수정 라이브러리가 운영 체제에 있는 로그인 유틸리티에서 사용할 수 있는 모든 기능을 반드시 지원하지는 않습니다. 일부 경우에 유틸리티가 전혀 지원되지 않을 수도 있습니다. 각 AFS 버전에서 지원되는 유틸리티에 대한 자세한 정보를 보려면 AFS 릴리스 노트를 참조하십시오. |
앞서 설명한 것처럼 캐쉬 관리 프로그램은 UNIX UID 또는 PAG에 의해 사용자 자격사항 구조를 식별합니다. PAG는 고유한 것이 보장되므로 PAG를 사용하는 것이 선호됩니다. 캐쉬 관리 프로그램은 각 사용에 따라 점층적으로 증가되는 계수를 토대로 PAG를 할당합니다. 이와는 대조적으로 한 시스템의 여러 사용자가 동일한 UNIX UID를 공유하거나 가정할 수 있으며 이로 인해 잠재적인 보안 문제가 발생합니다. 다음은 이러한 상황을 나타내는 두 가지 일반적인 경우입니다.
그러나 UID에 비해 PAG가 가지는 또 다른 이점으로 사용자가 생성하는 프로세스가 PAG를 계승하고 토큰을 공유하므로 이들은 인증된 사용자로서 AFS에 대한 액세스 권한을 얻게 됩니다. 많은 환경에서, 가령 AFS 서버가 처리하는 ID(예: 로컬 수퍼유저 루트) 하에서 실행되는 프린터와 다른 디먼은 anonymous 사용자로서만 인식됩니다. PAG가 사용되지 않는 한 이러한 디먼은 system:anyuser 그룹이 필요한 ACL 권한을 가지지 않는 파일을 액세스할 수 없습니다.
일단 사용자가 PAG를 가지는 경우 사용자가 얻는 모든 새 토큰은 해당 PAG와 연관됩니다. 이 PAG는 연관된 토큰이 만기되거나 삭제되고 2시간이 경과하면 만기됩니다. PAG가 만기되기 전에 사용자가 klog 명령을 실행하면 새 토큰은 기존의 PAG와 연관됩니다(이 PAG는 이 경우 재생된다고 합니다).
AFS 수정 로그인 유틸리티는 다음 절에서 설명하는 것처럼 자동으로 PAG를 생성합니다. 표준 로그인 유틸리티를 사용하는 경우 사용자는 klog 명령을 실행하기 전에 pagsh 명령을 실행하거나 klog 명령의 -setpag 플래그를 포함시켜야 합니다. 지침을 보려면 2단계 로그인 및 인증 사용을 참조하십시오.
사용자는 또한 새 PAG를 작성하기 위해 언제든지 이들 명령을 사용할 수 있습니다. 두 명령의 차이점은 klog 명령이 연관된 PAG를 현재 명령 쉘 및 토큰으로 바꾼다는 것입니다. pagsh 명령은 새 PAG를 작성하기 전에 새 명령 쉘을 초기화합니다. 사용자가 이미 PAG를 가지고 있으면 실행중인 프로세스나 작업이 이전의 PAG와 연관된 토큰을 계속 사용하지만 새 작업이나 프로세스는 새로운 PAG와 연관된 토큰을 사용하게 됩니다. 새 쉘을 종료하면(예를 들어 <Ctrl-d>를 눌러) 원래의 PAG 및 쉘로 복귀됩니다. 기본적으로 pagsh 명령을 실행하면 Bourne 쉘이 초기화되지만 -c 인수를 포함시켜 그 대신 C 쉘(많은 시스템 유형에 대해 /bin/csh 프로그램) 또는 Korn 쉘(/bin/ksh 프로그램)을 초기화할 수 있습니다.
앞서 언급한 것처럼 AFS 수정 로그인 유틸리티는 동시에 AFS 토큰을 얻고 로컬 파일 시스템으로 사용자를 로그인하게 합니다. 이 절에서는 로그인 및 인증 프로세스를 대략적으로 설명하고 로컬 암호 파일의 암호 필드에 있는 값이 어떻게 사용되는지 설명합니다.
AFS 수정 로그인 유틸리티는 다음과 유사한 일련의 단계를 수행합니다. 세부 사항은 운영 체제마다 다를 수 있습니다.
앞에서 지적한 것처럼 AFS 수정 로그인 유틸리티를 사용할 때 로컬 암호 파일의 암호 필드는 더 이상 시스템 액세스를 위한 기본 관문이 아닙니다. 사용자가 올바른 AFS 암호를 제공하면 프로그램은 로컬 암호 파일을 절대 확인하지 않습니다. 그러나 다음과 같은 방법으로 여전히 암호 필드를 사용하여 액세스를 제어할 수 있습니다.
로그인 및 AFS 인증에 대해 PAM(Pluggable Authentication Module)을 사용하는 시스템은 로컬 암호 파일을 절대 확인하지 않습니다. 이 경우 시스템은 인증 및 로그인 시도를 제어하기 위해 암호 필드를 사용하지 않습니다. 대신 PAM 구성 파일(많은 시스템 유형에서 /etc/pam.conf)의 명령은 동일한 기능을 수행합니다. AFS 수정 로그인 유틸리티 설치에 대한 설명을 보려면 AFS 빠른 시작의 지침을 참조하십시오.
AFS 수정 로그인 유틸리티를 사용하지 않는 셀에서 사용자는 AFS 사용자 안내서에서 설명하는 것처럼 별도의 명령을 실행하여 로그인 및 인증을 수행해야 합니다.
새 AFS 계정에 표준 파일 작성에서 설명하는 것처럼 사용자는 로그인한 후에 klog -setpag 명령을 실행해야 한다는 사실을 기억할 필요 없이 이 명령을 사용자의 .login 파일(또는 동급)에서 호출할 수 있습니다. 사용자는 여전히 로그인 유틸리티에서 생성하는 프롬프트에서 한 번, klog 명령 프롬프트에서 또 한 번, 암호를 두 번 입력해야 합니다. 이것은 두 암호가 다를 수 있다는 것을 의미하지만 두 암호가 같을 경우 혼란이 덜 발생할 수 있습니다.
AFS 수정 로그인 유틸리티를 사용하지 않음으로써 얻을 수 있는 또 다른 효과는 AFS 서버가 표준 로그인 프로그램을 anonymous 사용자로 인식한다는 것입니다. 로그인 프로그램이 AFS 파일(예: 사용자 홈 디렉토리의 .login 파일)을 액세스해야 할 경우 이 파일을 보호하는 ACL에는 l (lookup) 및 r (read) 권한을 system:anyuser 그룹에 부여하는 항목이 포함되어야 합니다.
AFS 수정 로그인 유틸리티를 사용하지 않을 경우 실제(혼합된) 암호는 각 사용자에 대한 로컬 암호 파일에 나타나야 합니다. 이들 암호를 삽입하거나 변경하려면 /bin/passwd 파일을 사용하십시오. 로컬 암호 파일의 암호가 AFS 암호와 일치하면 작업은 더욱 간단해지지만 반드시 그럴 필요는 없습니다.
사용자는 일단 로그인되면 언제든지 klog 명령을 사용하여 토큰을 얻을 수 있습니다. 유효한 토큰이 이미 있으면 새 토큰이 이전 토큰을 덮어씁니다. PAG가 이미 있으면 새 토큰이 이 PAG와 연관됩니다.
기본적으로 klog 명령은 로컬 파일 시스템에 현재 로그인한 ID를 사용하여 발행자를 인증합니다. 다른 ID로서 인증을 받으려면 -principal 인수를 사용하십시오. 외부 셀에 대한 토큰을 얻으려면 -cell 인수(-principal 인수와 조합되어 사용할 수 있음)를 사용하십시오. AFS 사용자 안내서와 AFS Administration Reference에서 klog 명령에 대한 입력 항목을 참조하십시오.
모든 토큰이나 특정 셀에 대한 토큰을 버리려면 unlog 명령을 실행하십시오. 이 명령은 현재 명령 쉘과 연관된 토큰에만 영향을 미칩니다. AFS 사용자 안내서와 AFS Administration Reference에서 unlog 명령에 대한 입력 항목을 참조하십시오.
현재 명령 쉘과 연관된 토큰을 표시하려면 tokens 명령을 실행하십시오. 다음 예는 다양한 상황에서의 출력 결과를 보여 줍니다.
발행자가 어떠한 셀에서도 인증을 받지 못한 경우:
% tokens
Tokens held by the Cache Manager:
--End of list--
다음은 ABC Corporation 셀에서 AFS UID 1000을 가진 사용자에 대한 출력 결과를 보여 줍니다.
% tokens
Tokens held by the Cache Manager:
User's (AFS ID 1000) tokens for afs@abc.com [Expires Jun 2 10:00]
--End of list--
다음은 ABC Corporation 셀, State University 셀 및 DEF Company 셀에서 인증을 받은 사용자에 대한 출력 결과를 보여 줍니다. 사용자는 세 가지 셀에서 다른 AFS UID를 가집니다. 마지막 셀에 대한 토큰은 만기되었습니다.
% tokens
Tokens held by the Cache Manager:
User's (AFS ID 1000) tokens for afs@abc.com [Expires Jun 2 10:00]
User's (AFS ID 4286) tokens for afs@stateu.edu [Expires Jun 3 1:34]
User's (AFS ID 22) tokens for afs@def.com [>>Expired<<]
--End of list--
tokens 명령의 Kerberos 버전(tokens.krb 명령)은 다음 예에서처럼 티켓의 소유자, 티켓 권한 부여 서비스 및 만기일을 포함하여 티켓 권한 부여 티켓에 대한 정보도 보고합니다. 또한 Kerberos 인증 지원을 참조하십시오.
% tokens.krb
Tokens held by the Cache Manager:
User's (AFS ID 1000) tokens for afs@abc.com [Expires Jun 2 10:00]
User smith's tokens for krbtgt.ABC.COM@abc.com [Expires Jun 2 10:00]
--End of list--
사용자 토큰의 최대 수명은 다음의 세 가지 인증 데이터베이스 항목에 기록된 티켓 수명 중에서 가장 짧습니다. kas examine 명령은 그 수명을 최대 티켓 수명으로서 보고합니다. 인증 데이터베이스 항목에 ADMIN 플래그를 가진 관리자는 kas setfields 명령에 대해 -lifetime 인수를 사용하여 항목의 티켓 수명을 설명할 수 있습니다.
| 주: | AFS 수정 로그인 유틸리티는 항상 앞서 설명한 세 값으로부터 계산된 수명을 가진 토큰을 부여합니다. klog 명령을 실행할 때 사용자는 -lifetime 인수를 사용하여 기본값보다 더 짧은 수명을 요청할 수 있습니다. 추가 정보를 보려면 AFS 사용자 안내서와 AFS Administration Reference의 klog 참조 페이지를 참조하십시오. |
일반 AFS 사용자는 kpasswd 또는 kas setpassword 명령을 사용하여 자신의 암호를 변경할 수 있습니다. 이 명령을 실행하면 현재 암호를 입력하라는 메시지가 나타나고 입력 오류를 수정하기 위해 새 암호를 두 번 입력하라는 메시지가 다시 나타납니다.
인증 데이터베이스 항목에 ADMIN 플래그가 있는 관리자는 kpasswd 명령(현재 암호를 알아야 함) 또는 kas setpassword 명령을 사용하여 사용자의 암호를 변경할 수 있습니다.
셀에서 AFS 수정 로그인 유틸리티를 사용하지 않으면 운영 체제의 암호 변경 명령을 사용하여 로컬 암호도 변경해야 합니다. 암호 변경에 대한 자세한 정보를 보려면 AFS 암호 변경을 참조하십시오.
암호 및 인증 시도에 대해 제한을 적용하여 셀을 보다 안전하게 유지하는데 도움을 얻을 수 있습니다. 계정을 작성할 때 제한을 적용하려면 A 명령어로 계정 보안 높이기에서 설명하는 것처럼 uss 템플릿 파일에서 A 명령어(instruction)를 시용하십시오. 기존 계정에 대한 값을 설정하거나 변경하려면 암호 및 인증 보안 향상에서 설명하는 것처럼 kas setfields 명령을 사용하십시오.
기본적으로 AFS 암호는 절대 만기되지 않습니다. 암호 수명을 제한하면 암호를 풀려는 시도에 필요한 시간을 단축함으로써 보안을 향상시킬 수 있습니다. 암호가 마지막으로 변경된 이후 1-254일 중에서 수명을 선택할 수 있습니다. 이 수명은 설정되면 각 새 암호에 자동으로 적용됩니다. 사용자가 암호를 변경할 때 새 암호가 이전에 사용된 20개 암호 중 어떤 것과도 유사하지 않도록 지정할 수 있습니다.
부도덕한 사용자가 인증받은 사용자 암호를 추측하여 사용자의 AFS 셀을 액세스하려고 할 수 있습니다. 이러한 공격에서 보호받기 위해 사용자가 올바른 암호를 제공하지 못하고 연속으로 실패해도 괜찮은 횟수를 제한할 수 있습니다. 이 제한이 초과되면 인증 서비스는 지정된 기간 동안 (잠금 시간) 추가 인증 시도를 거부합니다. 잠금 시간이 만기되기 전에 인증 시도를 다시 사용 가능하게 하려면 관리자가 kas unlock 명령을 실행해야 합니다.
사용자의 인증 계정을 설정할 뿐 아니라 새 사용자 암호의 품질을 자동으로 확인하여 보안을 향상시킬 수 있습니다. kpasswd 및 kas setpassword 명령은 있는 경우 kpwvalid라는 프로그램이나 스크립트에 제안된 암호를 전달합니다. kpwvalid는 품질을 확인하고 암호가 수용될 수 있는지 알려 주는 코드를 리턴합니다. AFS 분산에 포함된 예제 프로그램을 수정하거나 자체의 프로그램을 작성할 수 있습니다. AFS Administration Reference에서 kpwvalid 참조 페이지를 참조하십시오.
암호 품질을 향상시킬 수 있는 몇 가지 유형의 확인 방법이 있습니다.
생트에서 AFS 인증 서버 대신 표준 Kerberos 인증을 사용하고 있으면 Kerberos 인증을 지원하는 수정된 버전의 klog, pagsh 및 tokens 명령을 사용하십시오. 이들 명령의 수정된 버전에 대한 2진 파일은 .krb 확장자가 추가된 표준 2진 파일과 같은 이름을 가집니다.
전체 셀에서 Kerberos 버전이나 표준 명령을 사용하십시오. 두 버전을 혼합해서 사용하지 마십시오. AFS 제품 지원부에서는 이들 네 명령의 Kerberos 버전을 설치하는 방법을 제공할 수 있습니다. 이들 명령의 두 가지 버전 간의 차이점을 보려면 AFS Administration Reference를 참조하십시오.
AFS는 여러 기능을 통합하여 허가된 사용자만 데이터를 액세스할 수 있게 합니다. 이 절에서는 이러한 기능 중 중요한 기능을 요약해서 설명하고 셀의 보안 향상 방법에 대해서도 알려 줍니다.
디렉토리에 대한 ACL
AFS의 파일은 상위 디렉토리와 연관된 액세스 제어 목록(ACL)으로 보호됩니다. ACL은 디렉토리의 데이터를 액세스할 수 있는 사용자나 그룹을 정의하고 액세스 방법에 대해서도 설명합니다. 액세스 제어 목록 관리를 참조하십시오.
클라이언트 및 서버 간의 상호 인증
AFS 클라이언트 및 서버 프로세스가 통신할 때 각각은 상호 인증 중에 상대방의 신원을 입증하도록 서로에게 요구하며 이것은 유효한 상대방만 암호를 해독하여 응답할 수 있는 암호화 정보를 교환하는 작업과 관련됩니다. 상호 인증 프로세스에 대한 자세한 설명을 보려면 상호 인증에 대한 상세한 설명을 참조하십시오.
AFS 서버 프로세스는 서로 그리고 인간 사용자를 나타내는 프로세스와 상호 인증합니다. 상호 인증이 완료되면 서버 및 클라이언트는 인증된 연결을 형성하고 이 연결이 만기되거나 상대방 중 한쪽이 연결을 닫을 때까지 다시 인증을 받을 필요 없이 반복적으로 통신할 수 있습니다. 인증된 연결은 다양한 수명을 가집니다.
토큰
AFS 파일을 액세스하기 위해 사용자는 올바른 AFS 암호를 제공하여 AFS 인증 서비스에 자신의 신원을 증명해야 합니다. 암호가 올바르면 인증 서비스는 사용자에게 인증된 상태라는 증거로서 토큰을 보냅니다. AFS의 로그인 및 인증을 참조하십시오.
서버는 유효한 토큰이 없는 사용자 및 프로세스에 사용자 ID anonymous를 지정합니다. anonymous ID는 ACL의 system:anyuser 그룹에 부여된 액세스 권한만 가집니다.
권한 확인
상호 인증은 서로 통신하는 두 상대방이 실제로 원하는 상대방이 될 수 있게 해 줍니다. 많은 기능을 사용하기 위해 AFS 서버 프로세스는 검증한 ID를 가진 클라이언트가 요청을 수행할 권한도 가지는지 확인합니다. 다른 요청을 하기 위해서는 다른 유형의 권한이 필요합니다. 세 가지 유형의 권한을 참조하십시오.
AFS 서버 프로세스는 클라이언트에게 중요한 정보를 보내기 전에 암호화합니다. 권한 없는 상대방이 인증된 연결에 몰래 들어오는 경우에도 적절한 키가 없으면 암호화된 데이터의 암호를 해독할 수 없습니다.
다음 AFS 명령은 서버 암호화 키 및 암호와 관련되어 있으므로 데이터를 암호화합니다.
또한 미국판 갱신 서버는 중요한 정보(예: KeyFile의 내용)를 분산할 때 암호화합니다. bos 집합의 다른 명령과 fs, pts 및 vos 집합의 명령은 데이터를 전송하기 전에 데이터를 암호화하지 않습니다.
AFS는 별도의 특권이 필요한 이유에서 설명하는 이유로 인해 세 가지 별도의 권한 유형을 사용합니다.
AFS에서는 인증과 권한 확인이 다른 의미를 가집니다. 인증은 ID를 증명하는 프로세스를 참조합니다. 권한 확인은 인증된 ID가 특정 작업을 수행할 권한을 가지는지 확인하는 프로세스를 참조합니다.
AFS는 연결 레벨에서 인증을 구현합니다. 두 상대방이 새로운 연결을 설정할 때마다 상호 인증을 받습니다. 일반적으로 AFS의 명령을 실행할 때마다 AFS 서버 프로세스와 클라이언트 사이에 새 연결이 설정됩니다.
AFS는 서버 시스템 레벨에서 권한 확인을 수행합니다. 서버 시스템에 대해 권한 확인이 설정되면 이 서버 시스템에서 실행되는 모든 서버 프로세스는 권한 있는 사용자에게만 서비스를 제공합니다. 서버 시스템에 대해 권한 확인이 해제되면 어떠한 사용자도 모든 서버 프로세스를 사용할 수 있습니다. 권한 확인을 해제하면 상당한 보안 위험이 초래됨을 명백히 알 수 있습니다. 자세한 내용은 인증 관리 및 권한 부여 요구조건을 참조하십시오
지정된 방식대로 사용자 계정, 서버 시스템 및 시스템 관리자 계정을 구성하여 셀의 보안 레벨을 향상시킬 수 있습니다.
사용자 계정
서버 시스템
시스템 관리자
파일 시스템에서 보안은 AFS의 주요 관심사입니다. 파일 공유를 보다 쉽게 만든 파일 시스템은 파일 공유를 의무적으로 만드는 경우에 유용하지 못합니다. 따라서 AFS는 권한 없는 사용자의 데이터 액세스를 막는 몇몇 기능을 통합하고 있습니다. 네트워크 환경의 보안은 거의 모든 절차가 거의 모든 사람이 끼어들 수 있는 무선을 통한 정보의 전송을 요구하므로 더 어렵습니다. 또한 네트워크의 많은 시스템들은 부도덕한 사용자들이 트랜잭션을 모니터하거나 심지어 전송을 가로채거나 참여자 중 하나의 ID를 가장할 수 있을 만큼 충분한 강력합니다.
엿보기와 정보 훔치기 또는 가장 등의 속임수를 효과적으로 예방하는 방법은 서버 및 클라이언트가 충분한 증거가 있을 때만 다른 상대방이 요구한 ID를 승인하게 하는 것입니다. 즉 네트워크의 본질은 강제로 네트워크의 모든 상대방이, 입증될 때까지 트랜잭션의 다른 상대방을 진짜가 아니라고 가정하게 합니다. 상호 인증은 상대방이 자신이 진짜임을 증명하는 수단입니다.
속임수를 막는 데 필요한 방법이 상당히 복잡하므로 상호 인증 구현 절차도 복잡합니다. 그러나 기본 개념을 단순합니다. 상대방은 공유 비밀을 알고 있음을 증명함으로써 자신의 ID를 증명합니다. 공유 비밀은 상호 인증을 받는 상대방에게만 알려져 있는 정보의 조각입니다(이들은 경우에 따라 트러스트된 제3자 또는 다른 소스로부터 처음 이 정보를 구할 수 있음). 트랜잭션을 시작한 상대방은 공유 비밀을 제시하고 다른 상대방도 이 비밀을 알고 있음을 보여줄 때까지 다른 상대방의 승인을 거부합니다.
AFS 트랜잭션에서 가장 일반적인 공유 비밀 형태는 암호화 키이며 간단하게 키라고도 합니다. 두 상대방은 공유 키를 사용하여 자신들이 보낸 정보 패킷을 암호화하고 받은 정보의 암호를 해독합니다. 키를 사용하는 암호화는 실제로 두 가지 목적을 가집니다. 첫째, 네트워크를 통과할 때 메시지를 보호하여 키를 모르는 사람은 메시지를 엿볼 수 없게 합니다. 둘재, 메시지를 성공적으로 암호화하고 해독하는 능력은 쌍방이 해당 키(공유 비밀)를 사용하고 있음을 나타냅니다. 다른 키를 사용하고 있으면 암호 해독 후에 메시지가 뒤섞여서 읽을 수 없는 상태가 됩니다.
다음 절은 AFS의 상호 인증 절차를 좀더 자세히 설명합니다. 상호 인증 프로세스에 관심이 없으면 관련 절을 건너뛰십시오.
단순 상호 인증은 하나의 암호화 키만 포함하며 쌍방은 보통 클라이언트와 서버가 됩니다. 클라이언트는 둘 중 하나만 알고 있는 키로 암호화된 챌린지 메시지를 보내어 서버에게 접속합니다. 서버는 이 키를 사용하여 메시지의 암호를 해독하며 이 키는 이들이 동일한 비밀을 실제로 공유하고 있을 경우 클라이언트의 키와 같습니다. 서버는 이 챌린지에 응답하고 키를 사용하여 응답을 암호화합니다. 클라이언트는 그 키를 사용하여 서버 응답의 암호를 해독하고 키가 올바른 경우 클라이언트는 서버가 진짜임을 확신할 수 있습니다. 클라이언트와 동일한 키를 알고 있는 사람만 챌린지의 암호를 해독할 수 있고 올바르게 응답할 수 있습니다. 서버는 서버가 챌린지 메시지의 암호를 해독했을 때 그 내용을 이해할 수 있었으므로 클라이언트가 진짜라고 결론을 내립니다.
AFS는 단순 상호 인증을 사용하여 로그인 절차 첫 부분 중에 사용자 ID를 검증합니다. 이 경우 키는 사용자 암호를 기본으로 합니다.
복합 상호 인증은 세 개의 암호화 키와 세 상대방과 관련되어 있습니다. 모든 보안 AFS 트랜잭션(로그인 프로세스의 처음 부분 제외)은 복합 상호 인증을 채택합니다.
클라이언트는 서버와 통신하려고 할 때 먼저 티켓 부여자라고 하는 제3자에게 접속합니다. 티켓 부여자와 클라이언트는 간단한 절차를 사용하여 상호 인증합니다. 상호 인증이 끝나면 티켓 부여자는 클라이언트의 ID를 미리 검증했다는 증거로서 클라이언트에게 서버 티켓(또는 간단히 티켓이라고 함)을 부여합니다. 티켓 부여자는 서버 암호화 키라고 하는 세 키 중 첫째 키를 사용하여 티켓을 암호화합니다. 왜냐하면 이 키는 티켓 부여자와 클라이언트가 접속하려는 서버만이 알고 있기 때문입니다. 클라이언트는 이 키를 알지 못합니다.
티켓 부여자는 티켓과 함께 여러 조각의 정보를 보냅니다. 이들은 클라이언트가 티켓 자체의 암호를 해독할 수 없지만 티켓을 효과적으로 사용할 수 있게 합니다. 토큰을 티켓과 함께 다음 항목으로 구성됩니다.
티켓 부여자는 복합 상호 인증과 관련된 세 번째 키(티켓 부여자와 클라이언트에게만 알려져 있는 키)를 사용하여 전체 토큰을 봉인합니다. 일부 경우에 이 세 번째 키는 클라이언트가 나타내는 사용자의 암호로부터 파생됩니다.
클라이언트가 유효한 서버 티켓을 가지고 있는 한 서버에 접속할 준비가 된 것입니다. 클라이언트는 서버에게 다음의 두 가지 항목을 보냅니다.
이 때 서버는 티켓 부여자가 세션 키를 작성했으므로 세션 키를 알지 못합니다. 그러나 티켓 부여자는 티켓에 세션 사본을 넣습니다. 서버는 서버 암호화 키를 사용하여 티켓의 암호를 해독하고 세션 키를 알게 됩니다. 그런 다음 이 세션 키를 사용하여 클라이언트의 요청 메시지의 암호를 해독합니다. 서버는 응답을 생성하고 이를 클라이언트에 보냅니다. 세션 키를 사용하여 응답을 암호화하여 네트워크를 통과할 때 응답을 보호합니다.
이 단계는 동일한 비밀을 알고 있는 쌍방을 모두 입증하므로 클라이언트와 서버 간의 상호 인증 작업의 핵심이 됩니다.
(티켓 부여자와 서버의 관계가 티켓 기반 상호 인증에서 중심이 된다고는 해도 이들 간의 직접 연결은 없다는 점을 알아 두십시오. 이들은 공유 비밀로 봉인한 티켓을 클라이언트가 소유하는 방식을 통해 간접적으로만 상호 작용합니다.)
AFS는 관리자가 AFS 데이터를 백업하는 데 도움을 주는 두 가지 관련 기능이 백업 볼륨과 AFS 백업 시스템을 제공합니다.
첫 번째 기능은 읽기/쓰기 볼륨을 클론하여 작성하는 백업 볼륨입니다. 이 백업 볼륨은 읽기 전용이므로 클론이 작성되었을 때의 읽기/쓰기 볼륨의 상태를 보존합니다.
백업 볼륨은 파일 시스템에 마운트하여 그 내용을 사용자들이 사용할 수 있으므로 관리를 용이하게 해 줄 수 있습니다. 예를 들어 각 사용자 볼륨의 백업 버전을 사용자 홈 디렉토리의 하위 디렉토리로 마운트할 수 있습니다. 이 마운트 포인트의 일반적인 이름은 OldFiles입니다. 하루에 한 번씩 새 버전의 백업 볼륨을 작성(즉 읽기/쓰기 볼륨 재클론)하여 이전 백업 이후에 수행된 변경사항을 캡처하십시오. 사용자가 실수로 데이터를 제거하거나 변경하는 경우 사용자는 복원을 요청하지 않고 백업 볼륨으로부터 복원할 수 있습니다.
AFS 사용자 안내서에서는 백업 볼륨을 언급하지 않으므로 일반 사용자는 이 백업 볼륨을 사용하지 않기로 결정한 경우에는 관련 내용을 알 필요가 없습니다. 이것은 사용자 볼륨의 백업 버전을 만들 경우 사용자에게 백업이 작동되는 방식과 백업을 마운트한 위치를 알려주어야 함을 의미합니다.
사용자는 종종 백업 볼륨의 데이터 양을 볼륨 할당량에 비교하여 측정하고 경우에 따라 OldFiles 마운트 포인트를 제거하려고 합니다. 백업 볼륨이 별도의 볼륨에 있으므로 이렇게 할 필요는 없습니다. 사용자 볼륨에서 사용하는 공간만 마운트 포인트에 필요한 양이며 이것은 표준 디렉토리 요소에 필요한 공간 크기와 동일할 수 있습니다.
백업 볼륨은 백업 볼륨 작성에서 보다 상세히 설명합니다.
백업 볼륨은 복원 요청을 줄여줄 수 있으나 디스크에 위치하므로 하드웨어 장애로 인한 데이터 손실을 막지 못합니다. 다른 파일 시스템과 같이 AFS 파일 시스템은 이러한 종류의 데이터 손실을 입을 가능성이 높습니다.
영구적인 데이터 손실로부터 셀의 사용자를 보호하려면 정기적으로나 자주 테이프에 파일 시스템을 백업하는 것이 바람직합니다. AFS 백업 시스템은 백업의 관리와 성능을 향상시키는 데 사용할 수 있습니다. AFS 백업 시스템에 대한 자세한 정보를 보려면 AFS 백업 시스템 구성 및 AFS 데이터 백업 및 복원을 참조하십시오.
AFS 분산에는 몇몇 표준 UNIX 명령의 수정 버전, 디먼 및 다음을 포함하는 원격 서비스를 제공하는 프로그램이 포함됩니다.
이들 수정 사항을 사용하면 명령들이 AFS 인증 정보(토큰)를 처리할 수 있습니다. 이를 통해 발행자는 원격 시스템에서 인증된 AFS 사용자로 인식됩니다.
파일 트리에서 이들 프로그램의 표준 버전을 AFS 수정 버전으로 바꾸는 것은 선택적입니다. AFS의 가시적 액세스는 일부 프로그램, 특히 ftpd 및 rcp 프로그램과 같이 시스템 간의 파일 전송과 관련된 프로그램이 없어도 작업할 수 있는 결과를 가져올 수 있습니다.
이들 명령의 AFS 버전을 사용하기로 한 경우 이들 명령 일부가 상호 종속되어 있음을 알아 두어야 합니다. 예를 들어 AFS 인증 정보를 전달하는 일은 rcp 및 inetd 명령을 모두 AFS 버전으로 사용할 경우에만 rcp 명령을 사용했을 때 제대로 작동됩니다.
수정된 원격 명령에 대한 일반적인 설치 위치는 /usr/afsws/bin 및 /usr/afsws/etc 디렉토리입니다. 명령의 기능에 대해 좀더 알려면 AFS Administration Reference에서 해당 참조 페이지를 참조하십시오.
NFS 클라이언트 시스템의 사용자는 NFS/AFS 변환기가 실행되는 AFS 클라이언트 시스템의 /afs 디렉토리를 마운트하여 AFS 파일 공간을 액세스할 수 있습니다. 이것은 AFS를 사용할 수 없는 클라이언트 시스템을 사용하는 AFS를 액세스하려는 NFS가 이미 실행되고 있는 셀에서 특히 유용합니다. 부록 A, NFS/AFS 변환기 관리를 참조하십시오.